aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2013-09-27i2c: mv64xxx: Do not use writel_relaxed()Thierry Reding1-2/+2
The driver is used on PowerPC which don't provide writel_relaxed(). This breaks the c2k and prpmc2800 default configurations. To fix the build, turn the calls to writel_relaxed() into writel(). The impacts for ARM should be minimal. Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2013-09-27i2c: mv64xxx: Fix some build warningsThierry Reding1-5/+7
Some functions and variables are only used if the configuration selects HAVE_CLK. Protect them with a corresponding #ifdef CONFIG_HAVE_CLK block to avoid compiler warnings. Signed-off-by: Thierry Reding <[email protected]> [wsa: added marker to #endif] Signed-off-by: Wolfram Sang <[email protected]>
2013-09-27i2c: s3c2410: fix clk_disable/clk_unprepare WARNingsKim Phillips1-2/+0
commit d16933b33914a6dff38a4ecbe8edce44a17898e8 "i2c: s3c2410: Move location of clk_prepare_enable() call in probe function" refactored clk_enable and clk_disable calls yet neglected to remove the clk_disable_unprepare call in the module's remove(). It helps remove warnings on an arndale during unbind: echo 12c90000.i2c > /sys/bus/platform/devices/12c90000.i2c/driver/unbind ------------[ cut here ]------------ WARNING: CPU: 0 PID: 2548 at drivers/clk/clk.c:842 clk_disable+0x18/0x24() Modules linked in: CPU: 0 PID: 2548 Comm: bash Not tainted 3.11.0-next-20130916-00003-gf4bddbc #6 [<c0014d48>] (unwind_backtrace+0x0/0xf8) from [<c00117d0>] (show_stack+0x10/0x14) [<c00117d0>] (show_stack+0x10/0x14) from [<c0361be8>] (dump_stack+0x6c/0xac) [<c0361be8>] (dump_stack+0x6c/0xac) from [<c001d864>] (warn_slowpath_common+0x64/0x88) [<c001d864>] (warn_slowpath_common+0x64/0x88) from [<c001d8a4>] (warn_slowpath_null+0x1c/0x24) [<c001d8a4>] (warn_slowpath_null+0x1c/0x24) from [<c02c4a64>] (clk_disable+0x18/0x24) [<c02c4a64>] (clk_disable+0x18/0x24) from [<c028d0b0>] (s3c24xx_i2c_remove+0x28/0x70) [<c028d0b0>] (s3c24xx_i2c_remove+0x28/0x70) from [<c0217a10>] (platform_drv_remove+0x18/0x1c) [<c0217a10>] (platform_drv_remove+0x18/0x1c) from [<c0216358>] (__device_release_driver+0x58/0xb4) [<c0216358>] (__device_release_driver+0x58/0xb4) from [<c02163d0>] (device_release_driver+0x1c/0x28) [<c02163d0>] (device_release_driver+0x1c/0x28) from [<c02153c0>] (unbind_store+0x58/0x90) [<c02153c0>] (unbind_store+0x58/0x90) from [<c0214c90>] (drv_attr_store+0x20/0x2c) [<c0214c90>] (drv_attr_store+0x20/0x2c) from [<c01032c0>] (sysfs_write_file+0x168/0x198) [<c01032c0>] (sysfs_write_file+0x168/0x198) from [<c00ae1c0>] (vfs_write+0xb0/0x194) [<c00ae1c0>] (vfs_write+0xb0/0x194) from [<c00ae594>] (SyS_write+0x3c/0x70) [<c00ae594>] (SyS_write+0x3c/0x70) from [<c000e3e0>] (ret_fast_syscall+0x0/0x30) ---[ end trace 4c9f9403066f57a6 ]--- ------------[ cut here ]------------ WARNING: CPU: 0 PID: 2548 at drivers/clk/clk.c:751 clk_unprepare+0x14/0x1c() Modules linked in: CPU: 0 PID: 2548 Comm: bash Tainted: G W 3.11.0-next-20130916-00003-gf4bddbc #6 [<c0014d48>] (unwind_backtrace+0x0/0xf8) from [<c00117d0>] (show_stack+0x10/0x14) [<c00117d0>] (show_stack+0x10/0x14) from [<c0361be8>] (dump_stack+0x6c/0xac) [<c0361be8>] (dump_stack+0x6c/0xac) from [<c001d864>] (warn_slowpath_common+0x64/0x88) [<c001d864>] (warn_slowpath_common+0x64/0x88) from [<c001d8a4>] (warn_slowpath_null+0x1c/0x24) [<c001d8a4>] (warn_slowpath_null+0x1c/0x24) from [<c02c5834>] (clk_unprepare+0x14/0x1c) [<c02c5834>] (clk_unprepare+0x14/0x1c) from [<c028d0b8>] (s3c24xx_i2c_remove+0x30/0x70) [<c028d0b8>] (s3c24xx_i2c_remove+0x30/0x70) from [<c0217a10>] (platform_drv_remove+0x18/0x1c) [<c0217a10>] (platform_drv_remove+0x18/0x1c) from [<c0216358>] (__device_release_driver+0x58/0xb4) [<c0216358>] (__device_release_driver+0x58/0xb4) from [<c02163d0>] (device_release_driver+0x1c/0x28) [<c02163d0>] (device_release_driver+0x1c/0x28) from [<c02153c0>] (unbind_store+0x58/0x90) [<c02153c0>] (unbind_store+0x58/0x90) from [<c0214c90>] (drv_attr_store+0x20/0x2c) [<c0214c90>] (drv_attr_store+0x20/0x2c) from [<c01032c0>] (sysfs_write_file+0x168/0x198) [<c01032c0>] (sysfs_write_file+0x168/0x198) from [<c00ae1c0>] (vfs_write+0xb0/0x194) [<c00ae1c0>] (vfs_write+0xb0/0x194) from [<c00ae594>] (SyS_write+0x3c/0x70) [<c00ae594>] (SyS_write+0x3c/0x70) from [<c000e3e0>] (ret_fast_syscall+0x0/0x30) ---[ end trace 4c9f9403066f57a7 ]--- Signed-off-by: Kim Phillips <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2013-09-27arm: Fix build error with context tracking callsFrederic Weisbecker2-4/+16
ad65782fba50 (context_tracking: Optimize main APIs off case with static key) converted context tracking main APIs to inline function and left ARM asm callers behind. This can be easily fixed by making ARM calling the post static keys context tracking function. We just need to replicate the static key checks there. We'll remove these later when ARM will support the context tracking static keys. Reported-by: Guenter Roeck <[email protected]> Reported-by: Russell King <[email protected]> Signed-off-by: Frederic Weisbecker <[email protected]> Tested-by: Kevin Hilman <[email protected]> Cc: Nicolas Pitre <[email protected]> Cc: Anil Kumar <[email protected]> Cc: Tony Lindgren <[email protected]> Cc: Benoit Cousson <[email protected]> Cc: Guenter Roeck <[email protected]> Cc: Russell King <[email protected]> Cc: Kevin Hilman <[email protected]>
2013-09-27pinctrl: palmas: do not abort pin configuration for BIAS_DEFAULTLaxman Dewangan1-2/+3
Recent movement of all configurations of pin in the single call of pin_config_set(), it is aborting configuration if BIAS_PULL_PIN_DEFAULT is selected as return of configuration. The original idea was to just avoid any update on register for pull up/down configuration if this option is selected. Fixing this by just bypassing any register update for BIAS_PULL_PIN_DEFAULT and continuing the remaining configuration. Signed-off-by: Laxman Dewangan <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2013-09-27regulator: ti-abb: Fix bias voltage glitch in transition to bypass modeNishanth Menon1-2/+14
As documented in Application Note SWPA117 v2.1(NDA), LDO override has a requirement that when switching from Bias active + override active mode(FBB/RBB) to Bypass(nominal) mode, LDO reset must be performed *after* LDO transitions to Bypass(nominal) mode. The same rule in reverse applies when switching from a ABB bypass mode to ABB enabled - LDO override *must* be performed prior to transition to required ABB mode, if we do not do that, the same glitch takes place. Currently while transitioning to ABB bypass, we reset the LDO overide prior to the transition which causes a few milliseconds where ABB LDO voltage could go all the way to 800mV(based on SoC process node), during this period, the delta voltage between VDD rail and VBB rail could cause the system to improperly function. Signed-off-by: Nishanth Menon <[email protected]> Signed-off-by: Mark Brown <[email protected]> Cc: [email protected]
2013-09-27Merge remote-tracking branch 'asoc/fix/max98095' into asoc-linusMark Brown1-2/+2
2013-09-27Merge remote-tracking branch 'asoc/fix/fsl' into asoc-linusMark Brown1-2/+5
2013-09-27Merge remote-tracking branch 'asoc/fix/core' into asoc-linusMark Brown1-1/+0
2013-09-27Merge remote-tracking branch 'asoc/fix/bfin' into asoc-linusMark Brown1-0/+1
2013-09-27Merge remote-tracking branch 'asoc/fix/ab8500' into asoc-linusMark Brown1-1/+6
2013-09-27Merge remote-tracking branch 'asoc/fix/88pm860x' into asoc-linusMark Brown1-0/+3
2013-09-27pinctrl: Correct number of pins for s5pv210Mateusz Krawczuk1-6/+6
Values of pins in table s5pv210 bank are incorrect. This patch correct values. Signed-off-by: Mateusz Krawczuk <[email protected]> Signed-off-by: Kyungmin Park <[email protected]> Acked-by: Tomasz Figa <[email protected]> Acked-by: Kukjin Kim <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2013-09-27i40e: clean up coccicheck reported errorsJesse Brandeburg2-5/+4
coccicheck shows: drivers/net/ethernet/intel/i40e/i40e_adminq.c:704:2-8: Replace memcpy with struct assignment drivers/net/ethernet/intel/i40e/i40e_adminq.c:763:1-7: Replace memcpy with struct assignment drivers/net/ethernet/intel/i40e/i40e_adminq.c:810:2-8: Replace memcpy with struct assignment drivers/net/ethernet/intel/i40e/i40e_common.c:510:2-8: Replace memcpy with struct assignment Fix each of them with a *a = *b; Signed-off-by: Jesse Brandeburg <[email protected]> Tested-by: Kavindya Deegala <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2013-09-27i40e: better return valuesJesse Brandeburg1-16/+21
As mentioned by Joe Perches, clean up return values in some functions making sure to have consistent return types, not mixing types. A couple of Joe's comments suggested returning void, but since the functions in question are ndo defined, the return values are fixed. So make a comment in the header that notes this is a function called by net_device_ops. v2: fix post increment bug in return CC: Joe Perches <[email protected]> Signed-off-by: Jesse Brandeburg <[email protected]> Tested-by: Kavindya Deegala <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2013-09-27ALSA: hda - Enable internal mic on a Thinkpad machine with ALC283Kailang Yang1-1/+12
More thorough testing showed that these verbs were necessary to improve quality of the internal mic. Patch originally from Realtek. BugLink: https://bugs.launchpad.net/bugs/1231931 Signed-off-by: David Henningsson <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2013-09-27ALSA: hda - Fix Internal Mic boost can't control with ALC283Kailang Yang1-0/+3
ALC283 pin control for Line1 default control by hidden register. Use line1 as internal Mic will not get sound when boost value up. Set control by verb for hidden register will solve this issue. Signed-off-by: Kailang Yang <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2013-09-27i40e: convert ret to aq_retJesse Brandeburg1-55/+52
When calling admin queue functions the driver should use aq_ret variable to help make clear that the return value is not a regular return variable. This allows for clean up of the return types that were previously converted to int. Signed-off-by: Jesse Brandeburg <[email protected]> Tested-by: Kavindya Deegala <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2013-09-27i40e: small clean ups from reviewJesse Brandeburg1-3/+3
As mentioned by Joe Perches clean up a loop flow. Signed-off-by: Jesse Brandeburg <[email protected]> CC: Joe Perches <[email protected]> Tested-by: Kavindya Deegala <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2013-09-27i40e: use common failure flowJesse Brandeburg1-6/+6
As mentioned by Joe Perches, we should be using foo = alloc(...) if (!foo) return -ENOMEM; return 0; Signed-off-by: Jesse Brandeburg <[email protected]> CC: Joe Perches <[email protected]> Tested-by: Kavindya Deegala <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2013-09-27igb: Fix ethtool loopback test for 82580 copperTodd Fujinaka1-0/+3
Add back 82580 loopback tests to ethtool. Signed-off-by: Todd Fujinaka <[email protected]> Tested-by: Aaron Brown <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2013-09-27ARC: Use clockevents_config_and_register over clockevents_register_deviceUwe Kleine-König1-5/+2
clockevents_config_and_register is more clever and correct than doing it by hand; so use it. [vgupta: fixed build failure due to missing ; in patch] Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Vineet Gupta <[email protected]>
2013-09-27ARC: Workaround spinlock livelock in SMP SystemC simulationVineet Gupta1-1/+8
Some ARC SMP systems lack native atomic R-M-W (LLOCK/SCOND) insns and can only use atomic EX insn (reg with mem) to build higher level R-M-W primitives. This includes a SystemC based SMP simulation model. So rwlocks need to use a protecting spinlock for atomic cmp-n-exchange operation to update reader(s)/writer count. The spinlock operation itself looks as follows: mov reg, 1 ; 1=locked, 0=unlocked retry: EX reg, [lock] ; load existing, store 1, atomically BREQ reg, 1, rety ; if already locked, retry In single-threaded simulation, SystemC alternates between the 2 cores with "N" insn each based scheduling. Additionally for insn with global side effect, such as EX writing to shared mem, a core switch is enforced too. Given that, 2 cores doing a repeated EX on same location, Linux often got into a livelock e.g. when both cores were fiddling with tasklist lock (gdbserver / hackbench) for read/write respectively as the sequence diagram below shows: core1 core2 -------- -------- 1. spin lock [EX r=0, w=1] - LOCKED 2. rwlock(Read) - LOCKED 3. spin unlock [ST 0] - UNLOCKED spin lock [EX r=0,w=1] - LOCKED -- resched core 1---- 5. spin lock [EX r=1] - ALREADY-LOCKED -- resched core 2---- 6. rwlock(Write) - READER-LOCKED 7. spin unlock [ST 0] 8. rwlock failed, retry again 9. spin lock [EX r=0, w=1] -- resched core 1---- 10 spinlock locked in #9, retry #5 11. spin lock [EX gets 1] -- resched core 2---- ... ... The fix was to unlock using the EX insn too (step 7), to trigger another SystemC scheduling pass which would let core1 proceed, eliding the livelock. Signed-off-by: Vineet Gupta <[email protected]>
2013-09-27ARC: Fix 32-bit wrap around in access_ok()Vineet Gupta1-2/+2
Anton reported | LTP tests syscalls/process_vm_readv01 and process_vm_writev01 fail | similarly in one testcase test_iov_invalid -> lvec->iov_base. | Testcase expects errno EFAULT and return code -1, | but it gets return code 1 and ERRNO is 0 what means success. Essentially test case was passing a pointer of -1 which access_ok() was not catching. It was doing [@addr + @sz <= TASK_SIZE] which would pass for @addr == -1 Fixed that by rewriting as [@addr <= TASK_SIZE - @sz] Reported-by: Anton Kolesov <[email protected]> Signed-off-by: Vineet Gupta <[email protected]>
2013-09-27ARC: Handle zero-overhead-loop in unaligned access handlerMischa Jonker1-0/+6
If a load or store is the last instruction in a zero-overhead-loop, and it's misaligned, the loop would execute only once. This fixes that problem. Signed-off-by: Mischa Jonker <[email protected]> Signed-off-by: Vineet Gupta <[email protected]>
2013-09-27ALSA: hda - Add documentation for CS4208 fixupsTakashi Iwai1-0/+6
Signed-off-by: Takashi Iwai <[email protected]>
2013-09-27ALSA: hda - Add fixup for MacBook Air 6,1 and 6,2 with CS4208 codecBen Whitten1-5/+67
This patch adds the default pin configuration and some init verbs for setting COEFs, in addition to the correction of input pin AMP caps for MacBook Air 6,1 and 6,2. With these changes, the headphone jack detection starts working properly. [trivial space fixes by tiwai] Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60811 Signed-off-by: Ben Whitten <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2013-09-27x86/microcode/AMD: Fix patch level reporting for family 15hSuravee Suthikulpanit1-0/+1
On AMD family 14h, applying microcode patch on the a core (core0) would also affect the other core (core1) in the same compute unit. The driver would skip applying the patch on core1, but it still need to update kernel structures to reflect the proper patch level. The current logic is not updating the struct ucode_cpu_info.cpu_sig.rev of the skipped core. This causes the /sys/devices/system/cpu/cpu1/microcode/version to report incorrect patch level as shown below: $ grep . cpu?/microcode/version cpu0/microcode/version:0x600063d cpu1/microcode/version:0x6000626 cpu2/microcode/version:0x600063d cpu3/microcode/version:0x6000626 cpu4/microcode/version:0x600063d Signed-off-by: Suravee Suthikulpanit <[email protected]> Acked-by: Borislav Petkov <[email protected]> Cc: <[email protected]> Cc: <[email protected]> Cc: <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2013-09-27Merge branch 'fixes-for-3.12' of git://gitorious.org/linux-can/linux-canDavid S. Miller1-4/+11
2013-09-27Merge branch 'pm-cpufreq-fixes'Rafael J. Wysocki3-1/+8
* pm-cpufreq-fixes: cpufreq: exynos5440: Fix potential NULL pointer dereference cpufreq: check cpufreq driver is valid and cpufreq isn't disabled in cpufreq_get() acpi-cpufreq: skip loading acpi_cpufreq after intel_pstate
2013-09-27Merge branch 'acpi-fixes'Rafael J. Wysocki2-11/+15
* acpi-fixes: ACPI / scan: fix typo in comments of acpi_bus_unregister_driver() ACPI / IPMI: Fix atomic context requirement of ipmi_msg_handler()
2013-09-26aio: fix use-after-free in aio_migratepageBenjamin LaHaise1-15/+37
Dmitry Vyukov managed to trigger a case where aio_migratepage can cause a use-after-free during teardown of the aio ring buffer's mapping. This turns out to be caused by access to the ioctx's ring_pages via the migratepage operation which was not being protected by any locks during ioctx freeing. Use the address_space's private_lock to protect use and updates of the mapping's private_data, and make ioctx teardown unlink the ioctx from the address space. Reported-by: Dmitry Vyukov <[email protected]> Tested-by: Dmitry Vyukov <[email protected]> Signed-off-by: Benjamin LaHaise <[email protected]>
2013-09-26staging: r8188eu: Add new device IDLarry Finger1-0/+1
The DLink DWA-125 Rev D1 also uses this driver. Signed-off-by: Larry Finger <[email protected]> Reported-by: Sergey Kostanbaev <[email protected]> Tested-by: Sergey Kostanbaev <[email protected]> Cc: Sergey Kostanbaev <[email protected]> Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2013-09-26usb: dwc3: add support for MerrifieldDavid Cohen1-0/+2
Add PCI id for Intel Merrifield Signed-off-by: David Cohen <[email protected]> Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2013-09-26USB: fsl/ehci: fix failure of checking PHY_CLK_VALID during reinitializationShengzhou Liu1-2/+3
In case of usb phy reinitialization: e.g. insmod usb-module(usb works well) -> rmmod usb-module -> insmod usb-module It found the PHY_CLK_VALID bit didn't work if it's not with the power-on reset. So we just check PHY_CLK_VALID bit during the stage with POR, this can be met by the tricky of checking FSL_SOC_USB_PRICTRL register. Signed-off-by: Shengzhou Liu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2013-09-26USB: Fix breakage in ffs_fs_mount()Al Viro1-34/+26
There's a bunch of failure exits in ffs_fs_mount() with seriously broken recovery logics. Most of that appears to stem from misunderstanding of the ->kill_sb() semantics; unlike ->put_super() it is called for *all* superblocks of given type, no matter how (in)complete the setup had been. ->put_super() is called only if ->s_root is not NULL; any failure prior to setting ->s_root will have the call of ->put_super() skipped. ->kill_sb(), OTOH, awaits every superblock that has come from sget(). Current behaviour of ffs_fs_mount(): We have struct ffs_sb_fill_data data on stack there. We do ffs_dev = functionfs_acquire_dev_callback(dev_name); and store that in data.private_data. Then we call mount_nodev(), passing it ffs_sb_fill() as a callback. That will either fail outright, or manage to call ffs_sb_fill(). There we allocate an instance of struct ffs_data, slap the value of ffs_dev (picked from data.private_data) into ffs->private_data and overwrite data.private_data by storing ffs into an overlapping member (data.ffs_data). Then we store ffs into sb->s_fs_info and attempt to set the rest of the things up (root inode, root dentry, then create /ep0 there). Any of those might fail. Should that happen, we get ffs_fs_kill_sb() called before mount_nodev() returns. If mount_nodev() fails for any reason whatsoever, we proceed to functionfs_release_dev_callback(data.ffs_data); That's broken in a lot of ways. Suppose the thing has failed in allocation of e.g. root inode or dentry. We have functionfs_release_dev_callback(ffs); ffs_data_put(ffs); done by ffs_fs_kill_sb() (ffs accessed via sb->s_fs_info), followed by functionfs_release_dev_callback(ffs); from ffs_fs_mount() (via data.ffs_data). Note that the second functionfs_release_dev_callback() has every chance to be done to freed memory. Suppose we fail *before* root inode allocation. What happens then? ffs_fs_kill_sb() doesn't do anything to ffs (it's either not called at all, or it doesn't have a pointer to ffs stored in sb->s_fs_info). And functionfs_release_dev_callback(data.ffs_data); is called by ffs_fs_mount(), but here we are in nasal daemon country - we are reading from a member of union we'd never stored into. In practice, we'll get what we used to store into the overlapping field, i.e. ffs_dev. And then we get screwed, since we treat it (struct gfs_ffs_obj * in disguise, returned by functionfs_acquire_dev_callback()) as struct ffs_data *, pick what would've been ffs_data ->private_data from it (*well* past the actual end of the struct gfs_ffs_obj - struct ffs_data is much bigger) and poke in whatever it points to. FWIW, there's a minor leak on top of all that in case if ffs_sb_fill() fails on kstrdup() - ffs is obviously forgotten. The thing is, there is no point in playing all those games with union. Just allocate and initialize ffs_data *before* calling mount_nodev() and pass a pointer to it via data.ffs_data. And once it's stored in sb->s_fs_info, clear data.ffs_data, so that ffs_fs_mount() knows that it doesn't need to kill the sucker manually - from that point on we'll have it done by ->kill_sb(). Signed-off-by: Al Viro <[email protected]> Acked-by: Michal Nazarewicz <[email protected]> Cc: stable <[email protected]> # 3.3+ Signed-off-by: Greg Kroah-Hartman <[email protected]>
2013-09-26vt: properly ignore xterm-256 colour codesAdam Borowski1-0/+22
This is not a bug on our side, but a misdesign in ITU T.416, yet with all popular terminals supporting these codes, people consider this to be a bug in Linux. By breaking the design principles behind SGR codes (gracefully ignoring unsupported ones should not require knowing about them), 256 colour ones tend to turn blinking on before invoking an arbitrary unrelated command. This commit doesn't add such support, merely skips such codes without ill effects. Signed-off-by: Adam Borowski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2013-09-26vt: break a couple of obsolete SCOish codes.Adam Borowski1-14/+1
No modern terminal supports them, and SGR 38 conflicts with detecting xterm-256 colours. This also makes SGR 39 consistent with other popular terminals. Neither are used by ncurses' terminfo. Signed-off-by: Adam Borowski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2013-09-26hvc_vio: Do not override preferred console set by kernel parameterBen Hutchings1-1/+4
The original version of this was done by Bastian Blank, who wrote: > The problem is the following: > - Architecture specific code sets preferred console to something bogus. > - Command line handling tries to set preferred console but is overruled > by the old setting. > > The udbg0 console is a boot console and independant. References: http://bugs.debian.org/492703 Signed-off-by: Ben Hutchings <[email protected]> Cc: Benjamin Herrenschmidt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2013-09-26serial: clps711x: drop needless devm_clk_putUwe Kleine-König1-2/+0
The nice thing about devm_* is that the driver doesn't need to free the resources but the driver core takes care about that. These calls were introduced in commit c08f015 (serial: clps711x: Using CPU clock subsystem for getting base UART speed). Signed-off-by: Uwe Kleine-König <[email protected]> Cc: Alexander Shiyan <[email protected]> Cc: Russell King <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2013-09-26serial: sccnxp: missing uart_unregister_driver() on error in sccnxp_probe()Wei Yongjun1-0/+1
Add the missing uart_unregister_driver() before return from sccnxp_probe() in the error handling case. Signed-off-by: Wei Yongjun <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2013-09-26OMAP/serial: Fix Mode13 vs Mode16 priorityAlexey Pelykh1-1/+1
Make Mode16 more preferred than Mode13, to match TRM baudrates table. Signed-off-by: Alexey Pelykh <[email protected]> Cc: Tony Lindgren <[email protected]> Cc: Felipe Balbi <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2013-09-26OMAP/serial: Fix misnamed variableAlexey Pelykh1-4/+4
Fix misnamed variable to eliminate confusion. Signed-off-by: Alexey Pelykh <[email protected]> Cc: Tony Lindgren <[email protected]> Cc: Felipe Balbi <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2013-09-26serial: sirf: don't submit dma desc after timeout irqs occurQipan Li1-2/+9
In rx timeout ISR and tasklet, we don't issue new dma desc as rx_done ISR will do that. Signed-off-by: Qipan Li <[email protected]> Signed-off-by: Barry Song <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2013-09-26serial: 8250_pci: remove unnecessary pci_set_drvdata()Jingoo Han1-2/+0
The driver core clears the driver data to NULL after device_release or on probe failure. Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2013-09-26serial: txx9: remove unnecessary pci_set_drvdata()Jingoo Han1-2/+0
The driver core clears the driver data to NULL after device_release or on probe failure. Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2013-09-26serial: mfd: remove unnecessary pci_set_drvdata()Jingoo Han1-1/+0
The driver core clears the driver data to NULL after device_release or on probe failure. Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2013-09-26serial: imx: Change cast to handle 64-bit resource_size_tOlof Johansson1-1/+1
This resolves a warning where resource_size_t is larger than void *: drivers/tty/serial/imx.c:1542:6: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] Since iomem_base is a void *, casting to unsigned long is safe. It's unclear to me that this comparison is truly needed, but it's there on several other drivers as well. Signed-off-by: Olof Johansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2013-09-26serial: samsung: add support for manual RTS settingJosé Miguel Gonçalves1-3/+17
The Samsung serial driver currently does not support setting the RTS pin with an ioctl(TIOCMSET) call. This patch adds this support. Changes in v2: - Preserve the RTS pin's manual setting in set_termios() also when enabling CRTSCTS. Signed-off-by: José Miguel Gonçalves <[email protected]> Reviewed-by: Tomasz Figa <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2013-09-26driver core : Fix use after free of dev->parent in device_shutdownBenson Leung1-7/+7
The put_device(dev) at the bottom of the loop of device_shutdown may result in the dev being cleaned up. In device_create_release, the dev is kfreed. However, device_shutdown attempts to use the dev pointer again after put_device by referring to dev->parent. Copy the parent pointer instead to avoid this condition. This bug was found on Chromium OS's chromeos-3.8, which is based on v3.8.11. See bug report : https://code.google.com/p/chromium/issues/detail?id=297842 This can easily be reproduced when shutting down with hidraw devices that report battery condition. Two examples are the HP Bluetooth Mouse X4000b and the Apple Magic Mouse. For example, with the magic mouse : The dev in question is "hidraw0" dev->parent is "magicmouse" In the course of the shutdown for this device, the input event cleanup calls a put on hidraw0, decrementing its reference count. When we finally get to put_device(dev) in device_shutdown, kobject_cleanup is called and device_create_release does kfree(dev). dev->parent is no longer valid, and we may crash in put_device(dev->parent). This change should be applied on any kernel with this change : d1c6c030fcec6f860d9bb6c632a3ebe62e28440b Cc: [email protected] Signed-off-by: Benson Leung <[email protected]> Reviewed-by: Ming Lei <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>