- 12 Sep, 2014 40 commits
-
-
Lai Jiangshan authored
Lai found that: WARNING: CPU: 1 PID: 13 at arch/x86/kernel/smp.c:124 native_smp_send_reschedule+0x2d/0x4b() ... migration_cpu_stop+0x1d/0x22 was caused by set_cpus_allowed_ptr() assuming that cpu_active_mask is always a sub-set of cpu_online_mask. This isn't true since 5fbd036b ("sched: Cleanup cpu_active madness"). So set active and online at the same time to avoid this particular problem. Fixes: 5fbd036b ("sched: Cleanup cpu_active madness") Signed-off-by:
Lai Jiangshan <laijs@cn.fujitsu.com> Signed-off-by:
Peter Zijlstra <peterz@infradead.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Gautham R. Shenoy <ego@linux.vnet.ibm.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Michael wang <wangyun@linux.vnet.ibm.com> Cc: Paul Gortmaker <paul.gortmaker@windriver.com> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Cc: Toshi Kani <toshi.kani@hp.com> Link: http://lkml.kernel.org/r/53758B12.8060609@cn.fujitsu.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> (cherry picked from commit 6acbfb96) Signed-off-by:
Sasha Levin <sasha.levin@oracle.com>
-
Peter Zijlstra authored
When removing a (sibling) event we do: raw_spin_lock_irq(&ctx->lock); perf_group_detach(event); raw_spin_unlock_irq(&ctx->lock); <hole> perf_remove_from_context(event); raw_spin_lock_irq(&ctx->lock); ... raw_spin_unlock_irq(&ctx->lock); Now, assuming the event is a sibling, it will be 'unreachable' for things like ctx_sched_out() because that iterates the groups->siblings, and we just unhooked the sibling. So, if during <hole> we get ctx_sched_out(), it will miss the event and not call event_sched_out() on it, leaving it programmed on the PMU. The subsequent perf_remove_from_context() call will find the ctx is inactive and only call list_del_event() to remove the event from all other lists. Hereafter we can proceed to free the event; while still programmed! Close this hole by moving perf_group_detach() inside the same ctx->lock region(s) perf_remove_from_context() has. The condition on inherited events only in __perf_event_exit_task() is likely complete crap because non-inherited events are part of groups too and we're tearing down just the same. But leave that for another patch. Most-likely-Fixes: e03a9a55 ("perf: Change close() semantics for group events") Reported-by:
Vince Weaver <vincent.weaver@maine.edu> Tested-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Joe Lawrence authored
Don't allocate and track PCIe ASPM state when "pcie_aspm=off" is specified on the kernel command line. Based-on-patch-from: Matthew Garrett <mjg59@srcf.ucam.org> Signed-off-by:
Joe Lawrence <joe.lawrence@stratus.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
David Bulkow <david.bulkow@stratus.com> Acked-by:
Myron Stowe <myron.stowe@redhat.com> (cherry picked from commit a26d5ecb) Signed-off-by:
-
Joe Perches authored
__ratelimit() can be considered an inverted bool test because it returns true when not ratelimited. Several tests in the kernel tree use this __ratelimit() function incorrectly. No net_ratelimit uses are incorrect currently though. Most uses of net_ratelimit are to log something via printk or pr_<level>. In order to minimize the uses of net_ratelimit, and to start standardizing the code style used for __ratelimit() and net_ratelimit(), add a net_ratelimited_function() macro and net_<level>_ratelimited() logging macros similar to pr_<level>_ratelimited that use the global net_ratelimit instead of a static per call site "struct ratelimit_state". Signed-off-by:
Joe Perches <joe@perches.com> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit 3a3bfb61) Signed-off-by:
-
Marcelo Tosatti authored
Booting a 64-vcpu KVM guest, with CONFIG_PREEMPT_VOLUNTARY, can result in a soft lockup: BUG: soft lockup - CPU#41 stuck for 67s! [setfont:1505] RIP: 0010:[<ffffffff812c48da>] [<ffffffff812c48da>] vgacon_do_font_op.clone.0+0x1ba/0x550 This is due to the 8192 (cmapsz) IO operations taking longer than expected due to lock contention in QEMU. Add conditional resched points in between writes allowing other tasks to execute. Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com> Cc: stable@vger.kernel.org Signed-off-by:
Dave Airlie <airlied@redhat.com> (cherry picked from commit 7e6d72c1) Signed-off-by:
-
Ben Hutchings authored
commit 94e0104b upstream. Commit 1619f441 'rapidio/tsi721: fix bug in MSI interrupt handling' (commit 1ccc819d upstream) makes the MSI handler disable and re-enable interrupts. When re-enabling interrupts, we should set the same flags as were originally set, but this changed in Linux 3.5 so the flags are now inconsistent in 3.2. In fact, the extra flag isn't even defined in 3.2. Remove the extra flag from the MSI handler. Reported-by:
Steve Conklin <steve.conklin@canonical.com> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Cc: Qiang Huang <h.huangqiang@huawei.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 06b08fa4) (cherry picked from commit HEAD) Signed-off-by:
-
Maia Kozheva authored
D-Link DWA-125/B1 is a relatively new USB Wi-Fi adapter, using a Ralink chipset supported by the rt2800usb driver. Currently, to work around the problem (it's missing in all present kernel versions, up to and including 3.7.x), I had to add this to /etc/rc.local: echo 2001 3c1e >> /sys/bus/usb/drivers/rt2800usb/new_id After that, the device works without problems. Been using it for over a week with no bugs in sight. The attached patch is trivial and simply adds the new USB ID to the list of devices handled by rt2800usb. Signed-off-by:
Maia Kozheva <sikon@ubuntu.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> (cherry picked from commit fd7b9270) Signed-off-by:
-
Alex Deucher authored
For r6xx+ asics. This mirrors the behavior of pre-r6xx asics. We need to program the MC even if something else in startup() fails. Failure to do so results in an unusable GPU. Based on a fix from: Mark Kettenis <kettenis@openbsd.org> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org (cherry picked from commit 6fab3feb) Signed-off-by:
-
Carsten Emde authored
A machine may need to invert the panel backlight brightness value. This patch adds the infrastructure for a quirk to do so. Signed-off-by:
Carsten Emde <C.Emde@osadl.org> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit 4dca20ef) Signed-off-by:
-
Jason Wang authored
Even if guest were compiled without SMP support, it could not assume that host wasn't. So switch to use mb() instead of smp_mb() to force memory barriers for UP guest. Signed-off-by:
Jason Wang <jasowang@redhat.com> Cc: Haiyang Zhang <haiyangz@microsoft.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
-
Ben Hutchings authored
commit 80a19deb upstream. In 3.2, unlike mainline, efi_pstore_erase() calls efi_pstore_write() with a size of 0, as the underlying EFI interface treats a size of 0 as meaning deletion. This was not taken into account in my backport of commit d80a361d 'efi_pstore: Check remaining space with QueryVariableInfo() before writing data'. The size check should be omitted when erasing. Signed-off-by:
-
Konrad Rzeszutek Wilk authored
The 'intel_idle_probe' probes the CPU and sets the CPU notifier. But if later on during the module initialization we fail (say in cpuidle_register_driver), we stop loading, but we neglect to unregister the CPU notifier. This means that during CPU hotplug events the system will fail: calling intel_idle_init+0x0/0x326 @ 1 intel_idle: MWAIT substates: 0x1120 intel_idle: v0.4 model 0x2A intel_idle: lapic_timer_reliable_states 0xffffffff intel_idle: intel_idle yielding to none initcall intel_idle_init+0x0/0x326 returned -19 after 14 usecs ... some time later, offlining and onlining a CPU: cpu 3 spinlock event irq 62 BUG: unable to ] __cpuidle_register_device+0x1c/0x120 PGD 99b8b067 PUD 99b95067 PMD 0 Oops: 0000 [#1] SMP Modules linked in: xen_evtchn nouveau mxm_wmi wmi radeon ttm i915 fbcon tileblit font atl1c bitblit softcursor drm_kms_helper video xen_blkfront xen_netfront fb_sys_fops sysimgblt sysfillrect syscopyarea xenfs xen_privcmd mperf CPU 0 Pid: 2302, comm: udevd Not tainted 3.8.0-rc3upstream-00249-g09ad159 #1 MSI MS-7680/H61M-P23 (MS-7680) RIP: e030:[<ffffffff814d956c>] [<ffffffff814d956c>] __cpuidle_register_device+0x1c/0x120 RSP: e02b:ffff88009dacfcb8 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff880105380000 RCX: 000000000000001c RDX: 0000000000000000 RSI: 0000000000000055 RDI: ffff880105380000 RBP: ffff88009dacfce8 R08: ffffffff81a4f048 R09: 0000000000000008 R10: 0000000000000008 R11: 0000000000000000 R12: ffff880105380000 R13: 00000000ffffffdd R14: 0000000000000000 R15: ffffffff81a523d0 FS: 00007f37bd83b7a0(0000) GS:ffff880105200000(0000) knlGS:0000000000000000 CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 00000000a09ea000 CR4: 0000000000042660 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process udevd (pid: 2302, threadinfo ffff88009dace000, task ffff88009afb47f0) Stack: ffffffff8107f2d0 ffffffff810c2fb7 ffff88009dacfce8 00000000ffffffea ffff880105380000 00000000ffffffdd ffff88009dacfd08 ffffffff814d9882 0000000000000003 ffff880105380000 ffff88009dacfd28 ffffffff81340afd Call Trace: [<ffffffff8107f2d0>] ? collect_cpu_info_local+0x30/0x30 [<ffffffff810c2fb7>] ? __might_sleep+0xe7/0x100 [<ffffffff814d9882>] cpuidle_register_device+0x32/0x70 [<ffffffff81340afd>] intel_idle_cpu_init+0xad/0x110 [<ffffffff81340bc8>] cpu_hotplug_notify+0x68/0x80 [<ffffffff8166023d>] notifier_call_chain+0x4d/0x70 [<ffffffff810bc369>] __raw_notifier_call_chain+0x9/0x10 [<ffffffff81094a4b>] __cpu_notify+0x1b/0x30 [<ffffffff81652cf7>] _cpu_up+0x103/0x14b [<ffffffff81652e18>] cpu_up+0xd9/0xec [<ffffffff8164a254>] store_online+0x94/0xd0 [<ffffffff814122fb>] dev_attr_store+0x1b/0x20 [<ffffffff81216404>] sysfs_write_file+0xf4/0x170 [<ffffffff811a1024>] vfs_write+0xb4/0x130 [<ffffffff811a17ea>] sys_write+0x5a/0xa0 [<ffffffff816643a9>] system_call_fastpath+0x16/0x1b Code: 03 18 00 c9 c3 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 48 83 ec 30 48 89 5d e8 4c 89 65 f0 48 89 fb 4c 89 6d f8 e8 84 08 00 00 <48> 8b 78 08 49 89 c4 e8 f8 7f c1 ff 89 c2 b8 ea ff ff ff 84 d2 RIP [<ffffffff814d956c>] __cpuidle_register_device+0x1c/0x120 RSP <ffff88009dacfcb8> This patch fixes that by moving the CPU notifier registration as the last item to be done by the module. Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by:
Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Cc: 3.6+ <stable@vger.kernel.org> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> (cherry picked from commit 6f8c2e79) Signed-off-by:
-
Rashika Kheria authored
This patch fixes the bug in reset_store caused by accessing NULL pointer. The bdev gets its value from bdget_disk() which could fail when memory pressure is severe and hence can return NULL because allocation of inode in bdget could fail. Hence, this patch introduces a check for bdev to prevent reference to a NULL pointer in the later part of the code. It also removes unnecessary check of bdev for fsync_bdev(). Cc: stable <stable@vger.kernel.org> Acked-by:
Jerome Marchand <jmarchan@redhat.com> Signed-off-by:
Rashika Kheria <rashika.kheria@gmail.com> Acked-by:
Minchan Kim <minchan@kernel.org> Signed-off-by:
-
Romain Izard authored
The replacement of the 'count' variable by two variables 'incs' and 'decs' to resolve some race conditions during module unloading was done in parallel with some cleanup in the trace subsystem, and was integrated as a merge. Unfortunately, the formula for this replacement was wrong in the tracing code, and the refcount in the traces was not usable as a result. Use 'count = incs - decs' to compute the user count. Link: http://lkml.kernel.org/p/1393924179-9147-1-git-send-email-romain.izard.pro@gmail.comAcked-by:
Romain Izard <romain.izard.pro@gmail.com> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> (cherry picked from commit 098507ae) Signed-off-by:
-
Tim Chen authored
The crypto algorithm modules utilizing the crypto daemon could be used early when the system start up. Using module_init does not guarantee that the daemon's work queue is initialized when the cypto alorithm depending on crypto_wq starts. It is necessary to initialize the crypto work queue earlier at the subsystem init time to make sure that it is initialized when used. Signed-off-by:
Tim Chen <tim.c.chen@linux.intel.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> (cherry picked from commit 130fa5bc) Signed-off-by:
-
Geert Uytterhoeven authored
The English and Korean translations were updated, the Chinese and Japanese weren't. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Liu Hua authored
When we configure CONFIG_ARM_LPAE=y, pfn << PAGE_SHIFT will overflow if pfn >= 0x100000 in copy_oldmem_page. So use __pfn_to_phys for converting. Signed-off-by:
Liu Hua <sdu.liu@huawei.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> (cherry picked from commit 8fad87bc) Signed-off-by:
-
Jean-Jacques Hiblot authored
When using dt resources retrieval (interrupts and reg properties) there is no predefined order for these resources in the platform dev resource table. Also don't expect the number of resource to be always 2. Signed-off-by:
Jean-Jacques Hiblot <jjhiblot@traphandler.com> Acked-by:
Boris BREZILLON <b.brezillon@overkiz.com> Acked-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Cc: stable <stable@vger.kernel.org> # 3.4 Signed-off-by:
Felipe Balbi <balbi@ti.com> (cherry picked from commit 886c7c42) Signed-off-by:
-
Corey Minyard authored
The OBF timer in KCS was not reset in one situation when error recovery was started, resulting in an immediate timeout. Reported-by:
Bodo Stroesser <bstroesser@ts.fujitsu.com> Signed-off-by:
Corey Minyard <cminyard@mvista.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit eb6d78ec) Signed-off-by:
-
Bodo Stroesser authored
With recent changes it is possible for the timer handler to detect an idle interface and not start the timer, but the thread to start an operation at the same time. The thread will not start the timer in that instance, resulting in the timer not running. Instead, move all timer operations under the lock and start the timer in the thread if it detect non-idle and the timer is not already running. Moving under locks allows the last timeout to be set in both the thread and the timer. 'Timer is not running' means that the timer is not pending and smi_timeout() is not running. So we need a flag to detect this correctly. Also fix a few other timeout bugs: setting the last timeout when the interrupt has to be disabled and the timer started, and setting the last timeout in check_start_timer_thread possibly racing with the timer Signed-off-by:
-
Andreas Schwab authored
GCC 4.8 now generates out-of-line vr save/restore functions when optimizing for size. They are needed for the raid6 altivec support. Signed-off-by:
Andreas Schwab <schwab@linux-m68k.org> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> (cherry picked from commit 8fe9c93e) Signed-off-by:
-
Steven Rostedt (Red Hat) authored
No reason to allocate tp_module structures for modules that have no tracepoints. This just wastes memory. Fixes: b75ef8b4 "Tracepoint: Dissociate from module mutex" Acked-by:
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Signed-off-by:
-
Thomas Graf authored
All xtables variants suffer from the defect that the copy_to_user() to copy the counters to user memory may fail after the table has already been exchanged and thus exposed. Return an error at this point will result in freeing the already exposed table. Any subsequent packet processing will result in a kernel panic. We can't copy the counters before exposing the new tables as we want provide the counter state after the old table has been unhooked. Therefore convert this into a silent error. Cc: Florian Westphal <fw@strlen.de> Signed-off-by:
Thomas Graf <tgraf@suug.ch> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> (cherry picked from commit c58dd2dd) Signed-off-by:
-
Andrey Vagin authored
"len" contains sizeof(nf_ct_ext) and size of extensions. In a worst case it can contain all extensions. Bellow you can find sizes for all types of extensions. Their sum is definitely bigger than 256. nf_ct_ext_types[0]->len = 24 nf_ct_ext_types[1]->len = 32 nf_ct_ext_types[2]->len = 24 nf_ct_ext_types[3]->len = 32 nf_ct_ext_types[4]->len = 152 nf_ct_ext_types[5]->len = 2 nf_ct_ext_types[6]->len = 16 nf_ct_ext_types[7]->len = 8 I have seen "len" up to 280 and my host has crashes w/o this patch. The right way to fix this problem is reducing the size of the ecache extension (4) and Florian is going to do this, but these changes will be quite large to be appropriate for a stable tree. Fixes: 5b423f6a (netfilter: nf_conntrack: fix racy timer handling with reliable) Cc: Pablo Neira Ayuso <pablo@netfilter.org> Cc: Patrick McHardy <kaber@trash.net> Cc: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by:
Andrey Vagin <avagin@openvz.org> Signed-off-by:
-
Dan Carpenter authored
commit 3de22601 upstream. pthru32->dataxferlen comes from the user so we need to check that it's not too large so we don't overflow the buffer. Reported-by:
Nico Golde <nico@ngolde.de> Reported-by:
Fabian Yamaguchi <fabs@goesec.de> Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Sumit Saxena <sumit.saxena@lsi.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
-
Dan Carpenter authored
We always put a NUL terminator one space past the end of the "vendor" buffer. Walter Harms also pointed out that this should just use kstrndup(). Fixes: 7d17c02a ('mtd: Add new SmartMedia/xD FTL') Signed-off-by:
Brian Norris <computersforpeace@gmail.com> (cherry picked from commit b4c23305) Signed-off-by:
-
Dan Carpenter authored
Instead of writing to "nand->reg + REG_FMICSR" we write to "REG_FMICSR" which is NULL and not a valid register. Fixes: 8bff82cb ('mtd: add nand support for w90p910 (v2)') Signed-off-by:
-
Ard Biesheuvel authored
The GHASH setkey() function uses SSE registers but fails to call kernel_fpu_begin()/kernel_fpu_end(). Instead of adding these calls, and then having to deal with the restriction that they cannot be called from interrupt context, move the setkey() implementation to the C domain. Note that setkey() does not use any particular SSE features and is not expected to become a performance bottleneck. Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by:
H. Peter Anvin <hpa@linux.intel.com> Fixes: 0e1227d3 (crypto: ghash - Add PCLMULQDQ accelerated implementation) Signed-off-by:
-
David Cohen authored
When CONFIG_PCI and CONFIG_PM are not selected, xhci.c gets this warning: drivers/usb/host/xhci.c:409:13: warning: ‘xhci_msix_sync_irqs’ defined but not used [-Wunused-function] Instead of creating nested #ifdefs, this patch fixes it by defining the xHCI PCI stubs as inline. This warning has been in since 3.2 kernel and was caused by commit 421aa841 "usb/xhci: hide MSI code behind PCI bars", but wasn't noticed until 3.13 when a configuration with these options was tried Signed-off-by:
David Cohen <david.a.cohen@linux.intel.com> Cc: stable@vger.kernel.org # 3.2 Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
-
Igor Gnatenko authored
After suspend another Renesas PCI-X USB 3.0 card doesn't work. [root@fedora-20 ~]# lspci -vmnnd 1912: Device: 03:00.0 Class: USB controller [0c03] Vendor: Renesas Technology Corp. [1912] Device: uPD720202 USB 3.0 Host Controller [0015] SVendor: Renesas Technology Corp. [1912] SDevice: uPD720202 USB 3.0 Host Controller [0015] Rev: 02 ProgIf: 30 This patch should be applied to stable kernel 3.14 that contain the commit 1aa9578c "xhci: Fix resume issues on Renesas chips in Samsung laptops" Reported-and-tested-by:
Anatoly Kharchenko <rfr-bugs@yandex.ru> Reference: http://redmine.russianfedora.pro/issues/1315Signed-off-by:
Igor Gnatenko <i.gnatenko.brain@gmail.com> Cc: stable@vger.kernel.org # 3.14 Signed-off-by:
-
supriya karanth authored
The TXMAXP register is not set correctly for full speed bulk case when the can_bulk_split() is used. Without this PIO transfers will not take place correctly The "mult" factor needs to be updated correctly for the can_bulk_split() case The AUTOSET bit in the TXCSR is not being set if the "mult" factor is greater than 0 for the High Bandwidth ISO case. But the "mult" factor is also greater than 0 in case of Full speed bulk transfers with the packet splitting in TXMAXP register Without the AUTOSET the DMA transfers will not progress in mode1 [ balbi@ti.com : add braces to both branches ] Signed-off-by:
supriya karanth <supriya.karanth@stericsson.com> Signed-off-by:
Praveena NADAHALLY <praveen.nadahally@stericsson.com> Acked-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Dan Carpenter authored
commit e2c70425 upstream. The original code always set the upper 32 bits to zero because it was doing a shift of the wrong variable. Fixes: 1a4f550a ('[SCSI] arcmsr: 1.20.00.15: add SATA RAID plus other fixes') Signed-off-by:
-
Roger Quadros authored
OMAP3 doesn't contain "l3_init_clkdm" clock domain. Use the proper clock domains for USB Host and USB TLL modules. Gets rid of the following warnings during boot omap_hwmod: usb_host_hs: could not associate to clkdm l3_init_clkdm omap_hwmod: usb_tll_hs: could not associate to clkdm l3_init_clkdm Reported-by:
Nishanth Menon <nm@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by:
Roger Quadros <rogerq@ti.com> Fixes: de231388 ("ARM: OMAP: USB: EHCI and OHCI hwmod structures for OMAP3") Cc: Keshava Munegowda <keshava_mgowda@ti.com> Cc: Partha Basak <parthab@india.ti.com> Signed-off-by:
Paul Walmsley <paul@pwsan.com> (cherry picked from commit c6c56697) Signed-off-by:
-
Jiri Slaby authored
In read_all_bytes, we do unsigned char i; ... bt->read_data[0] = BMC2HOST; bt->read_count = bt->read_data[0]; ... for (i = 1; i <= bt->read_count; i++) bt->read_data[i] = BMC2HOST; If bt->read_data[0] == bt->read_count == 255, we loop infinitely in the 'for' loop. Make 'i' an 'int' instead of 'char' to get rid of the overflow and finish the loop after 255 iterations every time. Signed-off-by:Jiri Slaby <jslaby@suse.cz> Reported-and-debugged-by:
Rui Hui Dian <rhdian@novell.com> Cc: Tomas Cech <tcech@suse.cz> Cc: Corey Minyard <minyard@acm.org> Cc: <openipmi-developer@lists.sourceforge.net> Signed-off-by:
-
Mikulas Patocka authored
This patch reorders reported frequencies from the highest to the lowest, just like in other frequency drivers. Signed-off-by:
Mikulas Patocka <mpatocka@redhat.com> Acked-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
-
Mikulas Patocka authored
The powernow-k6 driver used to read the initial multiplier from the powernow register. However, there is a problem with this: * If there was a frequency transition before, the multiplier read from the register corresponds to the current multiplier. * If there was no frequency transition since reset, the field in the register always reads as zero, regardless of the current multiplier that is set using switches on the mainboard and that the CPU is running at. The zero value corresponds to multiplier 4.5, so as a consequence, the powernow-k6 driver always assumes multiplier 4.5. For example, if we have 550MHz CPU with bus frequency 100MHz and multiplier 5.5, the powernow-k6 driver thinks that the multiplier is 4.5 and bus frequency is 122MHz. The powernow-k6 driver then sets the multiplier to 4.5, underclocking the CPU to 450MHz, but reports the current frequency as 550MHz. There is no reliable way how to read the initial multiplier. I modified the driver so that it contains a table of known frequencies (based on parameters of existing CPUs and some common overclocking schemes) and sets the multiplier according to the frequency. If the frequency is unknown (because of unusual overclocking or underclocking), the user must supply the bus speed and maximum multiplier as module parameters. This patch should be backported to all stable kernels. If it doesn't apply cleanly, change it, or ask me to change it. Signed-off-by:
-
Mikulas Patocka authored
I found out that a system with k6-3+ processor is unstable during network server load. The system locks up or the network card stops receiving. The reason for the instability is the CPU frequency scaling. During frequency transition the processor is in "EPM Stop Grant" state. The documentation says that the processor doesn't respond to inquiry requests in this state. Consequently, coherency of processor caches and bus master devices is not maintained, causing the system instability. This patch flushes the cache during frequency transition. It fixes the instability. Other minor changes: * u64 invalue changed to unsigned long because the variable is 32-bit * move the logic to set the multiplier to a separate function powernow_k6_set_cpu_multiplier * preserve lower 5 bits of the powernow port instead of 4 (the voltage field has 5 bits) * mask interrupts when reading the multiplier, so that the port is not open during other activity (running other kernel code with the port open shouldn't cause any misbehavior, but we should better be safe and keep the port closed) This patch should be backported to all stable kernels. If it doesn't apply cleanly, change it, or ask me to change it. Signed-off-by:
-
Dan Carpenter authored
"idx" is controled by the user and can be a negative offset into the input_names[] array. Signed-off-by:
Takashi Iwai <tiwai@suse.de> (cherry picked from commit bd5fe738) Signed-off-by:
-
Sarah Sharp authored
The RWE bit of the USB 2.0 PORTPMSC register is supposed to enable remote wakeup for devices in the lower power link state L1. It has nothing to do with the device suspend remote wakeup from L2. The RWE bit is designed to be set once (when USB 2.0 LPM is enabled for the port) and cleared only when USB 2.0 LPM is disabled for the port. The xHCI bus suspend method was setting the RWE bit erroneously, and the bus resume method was clearing it. The xHCI 1.0 specification with errata up to Aug 12, 2012 says in section 4.23.5.1.1.1 "Hardware Controlled LPM": "While Hardware USB2 LPM is enabled, software shall not modify the HIRDBESL or RWE fields of the USB2 PORTPMSC register..." If we have previously enabled USB 2.0 LPM for a device, that means when the USB 2.0 bus is resumed, we violate the xHCI specification by clearing RWE. It also means that after a bus resume, the host would think remote wakeup is disabled from L1 for ports with USB 2.0 Link PM enabled, which is not what we want. This patch should be backported to kernels as old as 3.2, that contain the commit 65580b43 "xHCI: set USB2 hardware LPM". That was the first kernel that supported USB 2.0 Link PM. Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org (cherry picked from commit f217c980) Signed-off-by:
-
Takashi Iwai authored
These are almost compatible with the older Conexant codecs. Signed-off-by:
-
