- 09 Jun, 2015 40 commits
-
-
Xiao Guangrong authored
[ Upstream commit 7cbeed9b ] Current permission check assumes that RSVD bit in PFEC is always zero, however, it is not true since MMIO #PF will use it to quickly identify MMIO access Fix it by clearing the bit if walking guest page table is needed Signed-off-by:
Xiao Guangrong <guangrong.xiao@linux.intel.com> Cc: stable@vger.kernel.org Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Sasha Levin <sasha.levin@oracle.com>
-
Paolo Bonzini authored
[ Upstream commit 89876115 ] smep_andnot_wp is initialized in kvm_init_shadow_mmu and shadow pages should not be reused for different values of it. Thus, it has to be added to the mask in kvm_mmu_pte_write. Reviewed-by:
-
Ingo Molnar authored
[ Upstream commit e88221c5 ] The kernel's handling of 'compacted' xsave state layout is buggy: http://marc.info/?l=linux-kernel&m=142967852317199 I don't have such a system, and the description there is vague, but from extrapolation I guess that there were two kinds of bugs observed: - boot crashes, due to size calculations being wrong and the dynamic allocation allocating a too small xstate area. (This is now fixed in the new FPU code - but still present in stable kernels.) - FPU state corruption and ABI breakage: if signal handlers try to change the FPU state in standard format, which then the kernel tries to restore in the compacted format. These breakages are scary, but they only occur on a small number of systems that have XSAVES* CPU support. Yet we have had XSAVES support in the upstream kernel for a large number of stable kernel releases, and the fixes are involved and unproven. So do the safe resolution first: disable XSAVES* support and only use the standard xstate format. This makes the code work and is easy to backport. On top of this we can work on enabling (and testing!) proper compacted format support, without backporting pressure, on top of the new, cleaned up FPU code. Cc: <stable@vger.kernel.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Borislav Petkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Fenghua Yu <fenghua.yu@intel.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Borislav Petkov authored
[ Upstream commit 17fea54b ] Derek noticed that a critical MCE gets reported with the wrong error type description: [Hardware Error]: CPU 34: Machine Check Exception: 5 Bank 9: f200003f000100b0 [Hardware Error]: RIP !INEXACT! 10:<ffffffff812e14c1> {intel_idle+0xb1/0x170} [Hardware Error]: TSC 49587b8e321cb [Hardware Error]: PROCESSOR 0:306e4 TIME 1431561296 SOCKET 1 APIC 29 [Hardware Error]: Some CPUs didn't answer in synchronization [Hardware Error]: Machine check: Invalid ^^^^^^^ The last line with 'Invalid' should have printed the high level MCE error type description we get from mce_severity, i.e. something like: [Hardware Error]: Machine check: Action required: data load error in a user process this happens due to the fact that mce_no_way_out() iterates over all MCA banks and possibly overwrites the @msg argument which is used in the panic printing later. Change behavior to take the message of only and the (last) critical MCE it detects. Reported-by:
Derek <denc716@gmail.com> Signed-off-by:
Borislav Petkov <bp@suse.de> Cc: <stable@vger.kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tony Luck <tony.luck@intel.com> Link: http://lkml.kernel.org/r/1431936437-25286-3-git-send-email-bp@alien8.deSigned-off-by:
-
Chen Yucong authored
[ Upstream commit e3480271 ] Until now, the mce_severity mechanism can only identify the severity of UCNA error as MCE_KEEP_SEVERITY. Meanwhile, it is not able to filter out DEFERRED error for AMD platform. This patch extends the mce_severity mechanism for handling UCNA/DEFERRED error. In order to do this, the patch introduces a new severity level - MCE_UCNA/DEFERRED_SEVERITY. In addition, mce_severity is specific to machine check exception, and it will check MCIP/EIPV/RIPV bits. In order to use mce_severity mechanism in non-exception context, the patch also introduces a new argument (is_excp) for mce_severity. `is_excp' is used to explicitly specify the calling context of mce_severity. Reviewed-by:
Aravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com> Signed-off-by:
Chen Yucong <slaoub@gmail.com> Signed-off-by:
Tony Luck <tony.luck@intel.com> Signed-off-by:
-
Paolo Bonzini authored
[ Upstream commit 0fdd74f7 ] This reverts commit 4473b570. We'll use the hook again. Cc: stable@vger.kernel.org Signed-off-by:
-
Eric W. Biederman authored
[ Upstream commit 820f9f14 ] This is needed to support lazily umounting locked mounts. Because the entire unmounted subtree needs to stay together until there are no users with references to any part of the subtree. To support this guarantee that the fs_pin m_list and s_list nodes are initialized by initializing them in init_fs_pin allowing for the possibility that pin_insert_group does not touch them. Further use hlist_del_init in pin_remove so that there is a hlist_unhashed test before the list we attempt to update the previous list item. Signed-off-by:
"Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
-
Eric W. Biederman authored
[ Upstream commit cd4a4017 ] The only users of collect_mounts are in audit_tree.c In audit_trim_trees and audit_add_tree_rule the path passed into collect_mounts is generated from kern_path passed an audit_tree pathname which is guaranteed to be an absolute path. In those cases collect_mounts is obviously intended to work on mounted paths and if a race results in paths that are unmounted when collect_mounts it is reasonable to fail early. The paths passed into audit_tag_tree don't have the absolute path check. But are used to play with fsnotify and otherwise interact with the audit_trees, so again operating only on mounted paths appears reasonable. Avoid having to worry about what happens when we try and audit unmounted filesystems by restricting collect_mounts to mounts that appear in the mount tree. Signed-off-by:
-
Thomas Petazzoni authored
This patch is a partial backport of commit ef01c6c3 ("ARM: mvebu: remove Armada 375 Z1 workaround for I/O coherency"). This commit was merged in v3.19, so kernel versions later than v3.19 are not affected by the problem that this commit fixes. It does not make a lot of sense to backport this commit entirely, since it is mainly removing some no longer useful code. However, this commit is also making sure that the bus_register_notifier that register the custom DMA operations that should be used for HW I/O coherency does not get registered when said HW I/O coherency is not enabled. This is particularly critical since we have decided to disable HW I/O coherency completely in all kernels < 4.0, to be on the safe side, while experimenting a new implementation of the HW I/O coherency in >= 4.0. Without this commit, kernels earlier than 3.18 have the custom DMA operations normally used for HW I/O coherency registered (they don't do cache maintenance operations), while HW I/O coherency is disabled. It essentially causes every DMA transfer to transfer garbage. The issue fixed by this commit was introduced by 5ab5afd8 ("ARM: mvebu: implement Armada 375 coherency workaround"), but it was not visible until now since it didn't cause any problem when HW I/O coherency is enabled. Signed-off-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: <stable@vger.kernel.org> v3.16..v3.18 Signed-off-by:
-
Lv Zheng authored
[ Upstream commit 1d0a0b2f ] ACPICA commit b60612373a4ef63b64a57c124576d7ddb6d8efb6 For physical addresses, since the address may exceed 32-bit address range after calculation, we should use 0x%8.8X%8.8X instead of ACPI_PRINTF_UINT and ACPI_FORMAT_UINT64() instead of ACPI_FORMAT_NATIVE_UINT()/ACPI_FORMAT_TO_UINT(). This patch also removes above replaced macros as there are no users. This is a preparation to switch acpi_physical_address to 64-bit on 32-bit kernel builds. Link: https://github.com/acpica/acpica/commit/b6061237Signed-off-by:
Lv Zheng <lv.zheng@intel.com> Signed-off-by:
Bob Moore <robert.moore@intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Lv Zheng authored
[ Upstream commit cc2080b0 ] ACPICA commit 7f06739db43a85083a70371c14141008f20b2198 For physical addresses, since the address may exceed 32-bit address range after calculation, we should use %8.8X%8.8X (see ACPI_FORMAT_UINT64()) to convert the %p formats. This is a preparation to switch acpi_physical_address to 64-bit on 32-bit kernel builds. Link: https://github.com/acpica/acpica/commit/7f06739dSigned-off-by:
-
Lv Zheng authored
[ Upstream commit 6d3fd3cc ] ACPICA commit 154f6d074dd38d6ebc0467ad454454e6c5c9ecdf There are code pieces converting pointers using "(acpi_physical_address) x" or "ACPI_CAST_PTR (t, x)" formats, this patch cleans up them. Known issues: 1. Cleanup of "(ACPI_PHYSICAL_ADDRRESS) x" for a table field For the conversions around the table fields, it is better to fix it with alignment also fixed. So this patch doesn't modify such code. There should be no functional problem by leaving them unchanged. Link: https://github.com/acpica/acpica/commit/154f6d07Signed-off-by:
-
Lv Zheng authored
[ Upstream commit f254e3c5 ] ACPICA commit 7d9fd64397d7c38899d3dc497525f6e6b044e0e3 OSPMs like Linux expect an acpi_physical_address returning value from acpi_find_root_pointer(). This triggers warnings if sizeof (acpi_size) doesn't equal to sizeof (acpi_physical_address): drivers/acpi/osl.c:275:3: warning: passing argument 1 of 'acpi_find_root_pointer' from incompatible pointer type [enabled by default] In file included from include/acpi/acpi.h:64:0, from include/linux/acpi.h:36, from drivers/acpi/osl.c:41: include/acpi/acpixf.h:433:1: note: expected 'acpi_size *' but argument is of type 'acpi_physical_address *' This patch corrects acpi_find_root_pointer(). Link: https://github.com/acpica/acpica/commit/7d9fd643Signed-off-by:
-
Al Viro authored
[ Upstream commit 86cc0584 ] Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Alexey Khoroshilov authored
[ Upstream commit bc26d4d0 ] A deadlock can be initiated by userspace via ioctl(SNDCTL_SEQ_OUTOFBAND) on /dev/sequencer with TMR_ECHO midi event. In this case the control flow is: sound_ioctl() -> case SND_DEV_SEQ: case SND_DEV_SEQ2: sequencer_ioctl() -> case SNDCTL_SEQ_OUTOFBAND: spin_lock_irqsave(&lock,flags); play_event(); -> case EV_TIMING: seq_timing_event() -> case TMR_ECHO: seq_copy_to_input() -> spin_lock_irqsave(&lock,flags); It seems that spin_lock_irqsave() around play_event() is not necessary, because the only other call location in seq_startplay() makes the call without acquiring spinlock. So, the patch just removes spinlocks around play_event(). By the way, it removes unreachable code in seq_timing_event(), since (seq_mode == SEQ_2) case is handled in the beginning. Compile tested only. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
Alexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Mark Rutland authored
[ Upstream commit c0978773 ] arm64 builds with GCC 5 have caused the __asmeq assertions in the PSCI calling code to fire, so move the ARM PSCI calls out of line into their own assembly file for consistency and to safeguard against the same issue occuring with the 32-bit toolchain. [will: brought into line with arm64 implementation] Reported-by:
Andy Whitcroft <apw@canonical.com> Signed-off-by:
Mark Rutland <mark.rutland@arm.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Takeshi Kihara authored
[ Upstream commit bad4371d ] f9fd54f2 ("mmc: sh_mmcif: Use msecs_to_jiffies() for host->timeout") changed the timeout value from 1000 jiffies to 1s. In the case where HZ is 1000 the values are the same. However, for smaller HZ values the timeout is now smaller, 1s instead of 10s in the case of HZ=100. Since the timeout occurs in spite of a normal data transfer a timeout of 10s seems more appropriate. This restores the previous timeout in the case where HZ=100 and results in an increase over the previous timeout for larger values of HZ. Fixes: f9fd54f2 ("mmc: sh_mmcif: Use msecs_to_jiffies() for host->timeout") Signed-off-by:
Takeshi Kihara <takeshi.kihara.df@renesas.com> [horms: rewrote changelog to refer to HZ] Signed-off-by:
Simon Horman <horms+renesas@verge.net.au> Signed-off-by:
Yoshihiro Kaneko <ykaneko0929@gmail.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Grygorii Strashko authored
[ Upstream commit 184af16b ] The PM_RESTORE_PREPARE is not handled now in mmc_pm_notify(), as result mmc_rescan() could be scheduled and executed at late hibernation restore stages when MMC device is suspended already - which, in turn, will lead to system crash on TI dra7-evm board: WARNING: CPU: 0 PID: 3188 at drivers/bus/omap_l3_noc.c:148 l3_interrupt_handler+0x258/0x374() 44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4_PER1_P3 (Idle): Data Access in User mode during Functional access Hence, add missed PM_RESTORE_PREPARE PM event in mmc_pm_notify(). Fixes: 4c2ef25f (mmc: fix all hangs related to mmc/sd card...) Signed-off-by:
Grygorii Strashko <Grygorii.Strashko@linaro.org> Signed-off-by:
-
Chuanxiao Dong authored
[ Upstream commit 4e93b9a6 ] During kernel boot, it will try to read some logical sectors of each block device node for the possible partition table. But since RPMB partition is special and can not be accessed by normal eMMC read / write CMDs, it will cause below error messages during kernel boot: ... mmc0: Got data interrupt 0x00000002 even though no data operation was in progress. mmcblk0rpmb: error -110 transferring data, sector 0, nr 32, cmd response 0x900, card status 0xb00 mmcblk0rpmb: retrying using single block read mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900 mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900 mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900 mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900 mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900 mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900 end_request: I/O error, dev mmcblk0rpmb, sector 0 Buffer I/O error on device mmcblk0rpmb, logical block 0 end_request: I/O error, dev mmcblk0rpmb, sector 8 Buffer I/O error on device mmcblk0rpmb, logical block 1 end_request: I/O error, dev mmcblk0rpmb, sector 16 Buffer I/O error on device mmcblk0rpmb, logical block 2 end_request: I/O error, dev mmcblk0rpmb, sector 24 Buffer I/O error on device mmcblk0rpmb, logical block 3 ... This patch will discard the access request in eMMC queue if it is RPMB partition access request. By this way, it avoids trigger above error messages. Fixes: 090d25fe ("mmc: core: Expose access to RPMB partition") Signed-off-by:
Yunpeng Gao <yunpeng.gao@intel.com> Signed-off-by:
Chuanxiao Dong <chuanxiao.dong@intel.com> Tested-by:
Michael Shigorin <mike@altlinux.org> Signed-off-by:
-
Doug Anderson authored
[ Upstream commit c5272a28 ] Way back, when the world was a simpler place and there was no war, no evil, and no kernel bugs, there was just a single pinctrl lock. That was how the world was when (57291ce2 pinctrl: core device tree mapping table parsing support) was written. In that case, there were instances where the pinctrl mutex was already held when pinctrl_register_map() was called, hence a "locked" parameter was passed to the function to indicate that the mutex was already locked (so we shouldn't lock it again). A few years ago in (42fed7ba pinctrl: move subsystem mutex to pinctrl_dev struct), we switched to a separate pinctrl_maps_mutex. ...but (oops) we forgot to re-think about the whole "locked" parameter for pinctrl_register_map(). Basically the "locked" parameter appears to still refer to whether the bigger pinctrl_dev mutex is locked, but we're using it to skip locks of our (now separate) pinctrl_maps_mutex. That's kind of a bad thing(TM). Probably nobody noticed because most of the calls to pinctrl_register_map happen at boot time and we've got synchronous device probing. ...and even cases where we're asynchronous don't end up actually hitting the race too often. ...but after banging my head against the wall for a bug that reproduced 1 out of 1000 reboots and lots of looking through kgdb, I finally noticed this. Anyway, we can now safely remove the "locked" parameter and go back to a war-free, evil-free, and kernel-bug-free world. Fixes: 42fed7ba ("pinctrl: move subsystem mutex to pinctrl_dev struct") Signed-off-by:
Doug Anderson <dianders@chromium.org> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Christian König authored
[ Upstream commit d52cdfa4 ] MPEG 2/4 are only supported since UVD3. Signed-off-by:
Christian König <christian.koenig@amd.com> CC: stable@vger.kernel.org Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Christian König authored
[ Upstream commit a1b403da ] Invalid messages can crash the hw otherwise. Signed-off-by:
-
Christian König authored
[ Upstream commit 29c63fe2 ] Invalid handles can crash the hw. Signed-off-by:
-
monk.liu authored
[ Upstream commit db12973c ] Fixing a memory leak with userptrs. v2: clean up the loop, use an iterator instead v3: remove unused variable Signed-off-by:
monk.liu <monk.liu@amd.com> Signed-off-by:
-
Christian König authored
[ Upstream commit 013ead48 ] Hardware doesn't seem to work correctly, just block userspace in this case. v2: add missing defines Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=85320Signed-off-by:
-
Jani Nikula authored
[ Upstream commit 9fcb1704 ] The eDP port A register on PCH split platforms has a slightly different register layout from the other ports, with bit 6 being either alternate scrambler reset or reserved, depending on the generation. Our misinterpretation of the bit as audio has lead to warning. Fix this by not enabling audio on port A, since none of our platforms support audio on port A anyway. v2: DDI doesn't have audio on port A either (Sivakumar Thulasimani) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89958Reported-and-tested-by:
Chris Bainbridge <chris.bainbridge@gmail.com> Cc: stable@vger.kernel.org Reviewed-by:
Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Lukas Wunner authored
[ Upstream commit 3916e3fd ] Single channel LVDS maxes out at 112 MHz. The 15" pre-retina models shipped with 1440x900 (106 MHz) by default or 1680x1050 (119 MHz) as a BTO option, both versions used dual channel LVDS even though the smaller one would have fit into a single channel. Notes: Bug report showing that the MacBookPro8,2 with 1440x900 uses dual channel LVDS (this lead to it being hardcoded in intel_lvds.c by Daniel Vetter with commit 618563e3): https://bugzilla.kernel.org/show_bug.cgi?id=42842 If i915.lvds_channel_mode=2 is missing even though the machine needs it, every other vertical line is white and consequently, only the left half of the screen is visible (verified by myself on a MacBookPro9,1). Forum posting concerning a MacBookPro6,2 with 1440x900, author is using i915.lvds_channel_mode=2 on the kernel command line, proving that the machine uses dual channels: https://bbs.archlinux.org/viewtopic.php?id=185770 Chi Mei N154C6-L04 with 1440x900 is a replacement panel for all MacBook Pro "A1286" models, and that model number encompasses the MacBookPro6,2 / 8,2 / 9,1. Page 17 of the panel's datasheet shows it's driven with dual channel LVDS: http://www.ebay.com/itm/-/400690878560 http://www.everymac.com/ultimate-mac-lookup/?search_keywords=A1286 http://www.taopanel.com/chimei/datasheet/N154C6-L04.pdf Those three 15" models, MacBookPro6,2 / 8,2 / 9,1, are the only ones with i915 graphics and dual channel LVDS, so that list should be complete. And the 8,2 is already in intel_lvds.c. Possible motivation to use dual channel LVDS even on the 1440x900 models: Reduce the number of different parts, i.e. use identical logic boards and display cabling on both versions and the only differing component is the panel. Signed-off-by:
Lukas Wunner <lukas@wunner.de> Acked-by:
-
Mario Kleiner authored
[ Upstream commit fdb68e09 ] Since commit 844b03f2 we make sure that after vblank irq off, we return the last valid (vblank count, vblank timestamp) pair to clients, e.g., during modesets, which is good. An overlooked side effect of that commit for kms drivers without support for precise vblank timestamping is that at vblank irq enable, when we update the vblank counter from the hw counter, we can't update the corresponding vblank timestamp, so now we have a totally mismatched timestamp for the new count to confuse clients. Restore old client visible behaviour from before Linux 3.17, but zero out the timestamp at vblank counter update (instead of disable as in original implementation) if we can't generate a meaningful timestamp immediately for the new vblank counter. This will fix this regression, so callers know they need to retry again later if they need a valid timestamp, but at the same time preserves the improvements made in the commit mentioned above. Signed-off-by:
Mario Kleiner <mario.kleiner.de@gmail.com> Cc: <stable@vger.kernel.org> #v3.17+ Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Ulf Hansson authored
[ Upstream commit 11133db7 ] Fixes: c94a4ab7 ("ARM: ux500: Disable the MMCI gpio-regulator by default") Signed-off-by:
Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by:
-
Ulf Hansson authored
[ Upstream commit f9a8c391 ] Fixes: c94a4ab7 ("ARM: ux500: Disable the MMCI gpio-regulator by default") Signed-off-by:
-
Ulf Hansson authored
[ Upstream commit 53d26698 ] The GPIO regulator for the SD-card isn't a ux500 SOC configuration, but instead it's specific to the board. Move the definition of it, into the board DTSs. Fixes: c94a4ab7 ("ARM: ux500: Disable the MMCI gpio-regulator by default") Signed-off-by:
-
Nicolas Schichan authored
[ Upstream commit 19fc99d0 ] In that case, emit_udiv() will be called with rn == ARM_R0 (r_scratch) and loading rm first into ARM_R0 will result in jit_udiv() function being called the same dividend and divisor. Fix that by loading rn first into ARM_R1 and then rm into ARM_R0. Signed-off-by:
Nicolas Schichan <nschichan@freebox.fr> Cc: <stable@vger.kernel.org> # v3.13+ Fixes: aee636c4 (bpf: do not use reciprocal divide) Acked-by:
Mircea Gherzan <mgherzan@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Tony Lindgren authored
[ Upstream commit 102bcb6e ] If we use a combination of VMODE and I2C4 for retention modes, eventually the off idle power consumption will creep up by about 23mW, even during off mode with I2C4 always staying enabled. Turns out this is because of erratum i531 "Extra Power Consumed When Repeated Start Operation Mode Is Enabled on I2C Interface Dedicated for Smart Reflex (I2C4)" as pointed out by Nishanth Menon <nm@ti.com>. Let's fix the issue by adding i2c_cfg_clear_mask for the bits to clear when initializing the I2C4 adapter so we can clear SREN bit that drives the I2C4 lines low otherwise when there is no traffic. Fixes: 3b8c4ebb ("ARM: OMAP3: Fix idle mode signaling for Cc: stable@vger.kernel.org # v3.16+ sys_clkreq and sys_off_mode") Cc: Kevin Hilman <khilman@kernel.org> Cc: Tero Kristo <t-kristo@ti.com> Reviewed-by:
Nishanth Menon <nm@ti.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Gregory CLEMENT authored
[ Upstream commit 750e30d4 ] There is no crystal connected to the internal RTC on the Open Block AX3. So let's disable it in order to prevent the kernel probing the driver uselessly. Eventually this patches removes the following warning message from the boot log: "rtc-mv d0010300.rtc: internal RTC not ticking" Acked-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Cc: <stable@vger.kernel.org> # v3.8 + Signed-off-by:
-
Fabio Estevam authored
[ Upstream commit cfe8c597 ] On imx23-olinuxino the LED turns on when level logic high is aplied to GPIO2_1. Fix the gpios property accordingly. Fixes: b34aa185 ("ARM: dts: imx23-olinuxino: Remove unneeded "default-on"") Reported-by:
Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by:
Fabio Estevam <fabio.estevam@freescale.com> Tested-by:
Shawn Guo <shawn.guo@linaro.org> Signed-off-by:
-
Stefan Wahren authored
[ Upstream commit 0fdebe1a ] The dr_mode of usb0 on imx233-olinuxino is left to default "otg". Since the green LED (GPIO2_1) on imx233-olinuxino is connected to the same pin as USB_OTG_ID it's possible to disable USB host by LED toggling: echo 0 > /sys/class/leds/green/brightness [ 1068.890000] ci_hdrc ci_hdrc.0: remove, state 1 [ 1068.890000] usb usb1: USB disconnect, device number 1 [ 1068.920000] usb 1-1: USB disconnect, device number 2 [ 1068.920000] usb 1-1.1: USB disconnect, device number 3 [ 1069.070000] usb 1-1.2: USB disconnect, device number 4 [ 1069.450000] ci_hdrc ci_hdrc.0: USB bus 1 deregistered [ 1074.460000] ci_hdrc ci_hdrc.0: timeout waiting for 00000800 in 11 This patch fixes the issue by setting dr_mode to "host" in the dts file. Reported-by:
Harald Geyer <harald@ccbib.org> Signed-off-by:
Marek Vasut <marex@denx.de> Acked-by:
Peter Chen <peter.chen@freescale.com> Fixes: b4931294 ("ARM: dts: imx23-olinuxino: Add USB host support") Cc: stable@vger.kernel.org Signed-off-by:
-
Marek Vasut authored
[ Upstream commit 4ada77e3 ] Fix a typo in the TX DMA interrupt name for AUART4. This patch makes AUART4 operational again. Signed-off-by:
-
Philipp Zabel authored
[ Upstream commit 7f8d49dc ] The fixed-regulator bindings require a separate property enable-active-high, the standard gpio phandle property polarity setting is ignored. Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Fixes: 4fe69a93 ("ARM: dts: Add Phytec pfla02 with i.MX6 DualLite/Solo") Cc: stable@vger.kernel.org Signed-off-by:
-
Markus Pargmann authored
[ Upstream commit f90d3f0d ] The property '#pwm-cells' is currently missing. It is not possible to use pwm4 without this property. Signed-off-by:
Markus Pargmann <mpa@pengutronix.de> Fixes: 5658a68f ("ARM i.MX25: Add devicetree") Cc: <stable@vger.kernel.org> Reviewed-by:
-
Pavel Machek authored
[ Upstream commit 1819e303 ] N900 audio recording needs that codec provides bias voltage for integrated digital microphone and headset microphone depending which one is used. Digital microphone uses 2 V bias and it comes from the codec A part. Codec B part drives the headset microphone bias and that is set to 2.5 V. Cc: stable@vger.kernel.org # v3.16+ Signed-off-by:
Pavel Machek <pavel@ucw.cz> [Jarkko: Headset mic bias changed to 2 (2.5 V) as it was before commit e2e8bfdf ("ASoC: tlv320aic3x: Convert mic bias to a supply widget")] Signed-off-by:
Jarkko Nikula <jarkko.nikula@bitmer.com> Signed-off-by:
-
