- 25 Mar, 2013 14 commits
-
-
Alan Stern authored
This patch (as1662) does some more QH-related cleanup in ehci-hcd. The qh->needs_rescan flag is currently used for two different purposes; the patch replaces it with two separate flags for greater clarity: qh->dequeue_during_giveback indicates that a completion handler dequeued an URB (implying that a rescan is needed), and qh->exception indicates that the QH is in an exceptional state requiring an unlink (either it encountered an I/O error or an unlink was requested). The new flags get set where the dequeue, exception, or unlink request occurred, rather than where the unlink is started. This is so that in the future, if we need to, we will be able to tell apart unlinks that truly were required from those that were carried out merely because the QH wasn't being used. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Alan Stern authored
This patch (as1658) cleans up the usage of qh_completions() in ehci-hcd. Currently the function's return value indicates whether any URBs were given back; the idea was that the caller can scan the QH over again to handle any URBs that were dequeued by a completion handler. This is not necessary; when qh_completions() is ready to give back dequeued URBs, it does its own rescanning. Therefore the new return value will be a flag indicating whether the caller needs to unlink the QH. This is more convenient than forcing the caller to check qh->needs_rescan, and it makes a lot more sense -- why should "needs_rescan" imply that an unlink is needed? The callers are also changed to remove the unneeded rescans. Lastly, the check for whether qh->qtd_list is non-empty is removed from the start of qh_completions(). Two of the callers have to make this test anyway, so the same test can simply be added to the other two callers. Signed-off-by:
-
Alan Stern authored
This patch (as1638) makes several changes to the ehci-hcd driver, all related to the qh_refresh() function. This function must be called whenever an idle QH gets linked back into either the async or the periodic schedule. Change a BUG_ON() in the qh_update routine to a WARN_ON(). Since this code runs in atomic context, a BUG_ON() would immediately freeze the whole system. Remove two unneeded calls to qh_refresh(), one when a QH is initialized and one when a QH becomes idle. Adjust the adjacent comments accordingly. Move the qh_refresh() and qh_link_periodic() calls for new interrupt URBs to after the new TDs have been added. As a result of the previous two changes, qh_refresh() is never called when the qtd_list is empty. The corresponding check in qh_refresh() can be removed, along with an indentation level. These changes should not cause any alteration of behavior. Signed-off-by:
-
Du Xing authored
In skel_read,the reader blocked in wait_for_completion before submit bulk in urb. Using processed_urb is for retaining the completion in the case that previous interruptible wait in skel_read was interrupted and complete before next skel_read. Replacing completion with waitqueue can avoid working around the counting nature of completions and fix the bug. Signed-off-by: Du Xing duxing2007@gmail.com Signed-off-by: -
Bjørn Mork authored
Userspace applications need to know the maximum supported message size. The cdc-wdm driver translates between a character device stream and a message based protocol. Each message is transported as a usb control message with no further encapsulation or syncronization. Each read or write on the character device should translate to exactly one usb control message to ensure that message boundaries are kept intact. That means that the userspace application must know the maximum message size supported by the device and driver, making this size a vital part of the cdc-wdm character device API. CDC WDM and CDC MBIM functions export the maximum supported message size through CDC functional descriptors. The cdc-wdm and cdc_mbim drivers will parse these descriptors and use the value chosen by the device. The only current way for a userspace application to retrive the value is by duplicating the descriptor parsing. This is an unnecessary complex task, and application writers are likely to postpone it, using a fixed value and adding a "todo" item. QMI functions have no way to tell the host what message size they support. The qmi_wwan driver use a fixed value based on protocol recommendations and observed device behaviour. Userspace applications must know and hard code the same value. This scheme will break if we ever encounter a QMI device needing a device specific message size quirk. We are currently unable to support such a device because using a non default size would break the implicit userspace API. The message size is currently a hidden attribute of the cdc-wdm userspace API. Retrieving it is unnecessarily complex, increasing the possibility of drivers and applications using different limits. The resulting errors are hard to debug, and can only be replicated on identical hardware. Exporting the maximum message size from the driver simplifies the task for the userspace application, and creates a unified information source independent of device and function class. It also serves to document that the message size is part of the cdc-wdm userspace API. This proposed API extension has been presented for the authors of userspace applications and libraries using the current API: libmbim, libqmi, uqmi, oFono and ModemManager. The replies were: Aleksander Morgado: "We do really need max message size for MBIM; and as you say, it may be good to have the max message size info also for QMI, so the new ioctl seems a good addition. So +1 from my side, for what it's worth." Dan Williams: "Yeah, +1 here. I'd prefer the sysfs file, but the fact that that doesn't work for fd passing pretty much kills it." No negative replies are so far received. Cc: Aleksander Morgado <aleksander@lanedo.com> Cc: Dan Williams <dcbw@redhat.com> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Acked-by:
Oliver Neukum <oliver@neukum.org> Signed-off-by:
-
David Linares authored
Return an error if hub->descriptor->bNbrPorts==0. Without this additional check, we can end up doing a "hub->ports = kzalloc(0, GFP_KERNEL)". This hub->ports pointer will therefore be non-NULL and will be used. Example of dmesg: INIT: usb 1-1: New USB device found, idVendor=0424, idProduct=2512 usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 hub 1-1:1.0: USB hub found version 2.86 bootinghub 1-1:1.0: 0 ports detected Unable to handle kernel NULL pointer dereference at virtual address 00000010 Signed-off-by:
David Linares <dlinares.linux@gmail.com> Signed-off-by:
-
Ming Lei authored
If suspend callback fails in system sleep context, usb core will ignore the failure and let system sleep go ahead further, so this patch doesn't recover device under this situation. Also add comments on this case. Acked-by:
David S. Miller <davem@davemloft.net> Cc: Steve Glendinning <steve.glendinning@shawell.net> Signed-off-by:
Ming Lei <ming.lei@canonical.com> Signed-off-by:
-
Ming Lei authored
If suspend callback fails in system sleep context, usb core will ignore the failure and let system sleep go ahead further, so this patch doesn't recover device under this situation. Also add comments on the case. Acked-by:
-
Ming Lei authored
If suspend callback fails in system sleep context, usb core will ignore the failure and let system sleep go ahead further, so this patch comments on the case and requires that both usbnet_suspend() and subdriver->suspend() MUST return 0 in system sleep context. Acked-by:
-
Ming Lei authored
If suspend callback fails in system sleep context, usb core will ignore the failure and let system sleep go ahead further, so this patch comments on the case and requires that both usbnet_suspend() and subdriver->suspend() MUST return 0 in system sleep context. Acked-by:
-
Ming Lei authored
If suspend callback fails in system sleep context, usb core will ignore the failure and let the system sleep go ahead further, so this patch doesn't recover device under this situation, otherwise may cause resume() confused. Acked-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Ming Lei authored
If suspend callback fails in system sleep context, usb core will ignore the failure and let system sleep go ahead further, so this patch comments on the case and requires that serial->type->suspend() MUST return 0 in system sleep context. Acked-by:
Johan Hovold <jhovold@gmail.com> Signed-off-by:
-
Ming Lei authored
This patch adds comments on interface driver suspend callback to emphasize that the failure return value is ignored by USB core in system sleep context, so do not try to recover device for this case and let resume/reset_resume callback handle the suspend failure if needed. Also kerneldoc for usb_suspend_both() is updated with the fact. Acked-by:
-
Greg Kroah-Hartman authored
This picks up the fixes we had for USB in 3.9-rc4 Signed-off-by:
-
- 23 Mar, 2013 8 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pendingLinus Torvalds authored
Pull SCSI target fixes from Nicholas Bellinger: "These are mostly minor fixes this time around. The iscsi-target CHAP big-endian bugfix and bump FD_MAX_SECTORS=2048 default patch to allow 1MB sized I/Os for FILEIO backends on >= v3.5 code are both CC'ed to stable. Also, there is a persistent reservations regression that has recently been reported for >= v3.8.x code, that is currently being tracked down for v3.9." * git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending: target/pscsi: Reject cross page boundary case in pscsi_map_sg target/file: Bump FD_MAX_SECTORS to 2048 to handle 1M sized I/Os tcm_vhost: Flush vhost_work in vhost_scsi_flush() tcm_vhost: Add missed lock in vhost_scsi_clear_endpoint() target: fix possible memory leak in core_tpg_register() target/iscsi: Fix mutual CHAP auth on big-endian arches target_core_sbc: use noop for SYNCHRONIZE_CACHE
-
git://neil.brown.name/mdLinus Torvalds authored
Pull md fixes from NeilBrown: "A few bugfixes for md - recent regressions in raid5 - recent regressions in dmraid - a few instances of CONFIG_MULTICORE_RAID456 linger Several tagged for -stable" * tag 'md-3.9-fixes' of git://neil.brown.name/md: md: remove CONFIG_MULTICORE_RAID456 entirely md/raid5: ensure sync and DISCARD don't happen at the same time. MD: Prevent sysfs operations on uninitialized kobjects MD RAID5: Avoid accessing gendisk or queue structs when not available md/raid5: schedule_construction should abort if nothing to do.
-
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-devLinus Torvalds authored
Pull libata updates from Jeff Garzik: "Simple stuff. See one-line summaries." * tag 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev: pata_samsung_cf: use module_platform_driver_probe() [libata] Avoid specialized TLA's in ZPODD's Kconfig libata-acpi.c: fix copy and paste mistake in ata_acpi_register_power_resource sata_fsl: Remove redundant NULL check before kfree ahci: Add Device IDs for Intel Wellsburg PCH ata_piix: Add MODULE_PARM_DESC to prefer_ms_hyperv
-
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linuxLinus Torvalds authored
Pull i2c fixes from Wolfram Sang: "One bugfix for the tegra driver. Two updates regarding email addresses and MAINTAINERS which I like to have up-to-date so people can be reached immediately. While we are here, there is on PCI_ID addition." * 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: MAINTAINERS: add maintainer entry for atmel i2c driver i2c: Fix my e-mail address in drivers and documentation i2c: iSMT: add Intel Avoton DeviceIDs i2c: tegra: check the clk_prepare_enable() return value
-
git://www.linux-watchdog.org/linux-watchdogLinus Torvalds authored
Pull watchdog fixes from Wim Van Sebroeck: "Fix a boot issues and correct the AcpiMmioSel bitmask in the sp5100_tco watchdog device driver" * git://www.linux-watchdog.org/linux-watchdog: watchdog: sp5100_tco: Set the AcpiMmioSel bitmask value to 1 instead of 2 watchdog: sp5100_tco: Remove code that may cause a boot failure
-
Torsten Duwe authored
When KMS has parsed an EDID "detailed timing", it leaves the frame rate zeroed. Consecutive (debug-) output of that mode thus yields 0 for vsync. This simple fix also speeds up future invocations of drm_mode_vrefresh(). While it is debatable whether this qualifies as a -stable fix I'd apply it for consistency's sake; drm_helper_probe_single_connector_modes() does the same thing already for all probed modes. Cc: stable@vger.kernel.org Signed-off-by:
Torsten Duwe <duwe@lst.de> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Torsten Duwe authored
EDID spreads some values across multiple bytes; bit-fiddling is needed to retrieve these. The current code to parse "detailed timings" has a cut&paste error that results in a vsync offset of at most 15 lines instead of 63. See http://en.wikipedia.org/wiki/EDID and in the "EDID Detailed Timing Descriptor" see bytes 10+11 show why that needs to be a left shift. Cc: stable@vger.kernel.org Signed-off-by:
-
- 22 Mar, 2013 18 commits
-
-
git://git.infradead.org/users/willy/linux-nvmeLinus Torvalds authored
Pull NVMe driver update from Matthew Wilcox: "These patches have mostly been baking for a few months; sorry I didn't get them in during the merge window. They're all bug fixes, except for the addition of the SMART log and the addition to MAINTAINERS." * git://git.infradead.org/users/willy/linux-nvme: NVMe: Add namespaces with no LBA range feature MAINTAINERS: Add entry for the NVMe driver NVMe: Initialize iod nents to 0 NVMe: Define SMART log NVMe: Add result to nvme_get_features NVMe: Set result from user admin command NVMe: End queued bio requests when freeing queue NVMe: Free cmdid on nvme_submit_bio error
-
Linus Torvalds authored
Merge misc fixes from Andrew Morton. * emailed patches from Andrew Morton <akpm@linux-foundation.org>: mqueue: sys_mq_open: do not call mnt_drop_write() if read-only mm/hotplug: only free wait_table if it's allocated by vmalloc dma-debug: update DMA debug API to better handle multiple mappings of a buffer dma-debug: fix locking bug in check_unmap() drivers/rtc/rtc-at91rm9200.c: use a variable for storing IMR drivers/video/ep93xx-fb.c: include <linux/io.h> for devm_ioremap() drivers/rtc/rtc-da9052.c: fix for rtc device registration mm: zone_end_pfn is too small poweroff: change orderly_poweroff() to use schedule_work() mm/hugetlb: fix total hugetlbfs pages count when using memory overcommit accouting printk: Provide a wake_up_klogd() off-case irq_work.h: fix warning when CONFIG_IRQ_WORK=n
-
Vladimir Davydov authored
mnt_drop_write() must be called only if mnt_want_write() succeeded, otherwise the mnt_writers counter will diverge. mnt_writers counters are used to check if remounting FS as read-only is OK, so after an extra mnt_drop_write() call, it would be impossible to remount mqueue FS as read-only. Besides, on umount a warning would be printed like this one: ===================================== [ BUG: bad unlock balance detected! ] 3.9.0-rc3 #5 Not tainted ------------------------------------- a.out/12486 is trying to release lock (sb_writers) at: mnt_drop_write+0x1f/0x30 but there are no more locks to release! Signed-off-by:
Vladimir Davydov <vdavydov@parallels.com> Cc: Doug Ledford <dledford@redhat.com> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: <stable@vger.kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Jianguo Wu authored
zone->wait_table may be allocated from bootmem, it can not be freed. Signed-off-by:
Jianguo Wu <wujianguo@huawei.com> Reviewed-by:
Tang Chen <tangchen@cn.fujitsu.com> Cc: Tang Chen <tangchen@cn.fujitsu.com> Cc: Jiang Liu <jiang.liu@huawei.com> Signed-off-by:
-
Alexander Duyck authored
There were reports of the igb driver unmapping buffers without calling dma_mapping_error. On closer inspection issues were found in the DMA debug API and how it handled multiple mappings of the same buffer. The issue I found is the fact that the debug_dma_mapping_error would only set the map_err_type to MAP_ERR_CHECKED in the case that the was only one match for device and device address. However in the case of non-IOMMU, multiple addresses existed and as a result it was not setting this field once a second mapping was instantiated. I have resolved this by changing the search so that it instead will now set MAP_ERR_CHECKED on the first buffer that matches the device and DMA address that is currently in the state MAP_ERR_NOT_CHECKED. A secondary side effect of this patch is that in the case of multiple buffers using the same address only the last mapping will have a valid map_err_type. The previous mappings will all end up with map_err_type set to MAP_ERR_CHECKED because of the dma_mapping_error call in debug_dma_map_page. However this behavior may be preferable as it means you will likely only see one real error per multi-mapped buffer, versus the current behavior of multiple false errors mer multi-mapped buffer. Signed-off-by:
Alexander Duyck <alexander.h.duyck@intel.com> Cc: Joerg Roedel <joro@8bytes.org> Reviewed-by:
Shuah Khan <shuah.khan@hp.com> Tested-by:
-
Alexander Duyck authored
In check_unmap() it is possible to get into a dead-locked state if dma_mapping_error is called. The problem is that the bucket is locked in check_unmap, and locked again by debug_dma_mapping_error which is called by dma_mapping_error. To resolve that we must release the lock on the bucket before making the call to dma_mapping_error. [akpm@linux-foundation.org: restore 80-col trickery to be consistent with the rest of the file] Signed-off-by:
-
Nicolas Ferre authored
On some revisions of AT91 SoCs, the RTC IMR register is not working. Instead of elaborating a workaround for that specific SoC or IP version, we simply use a software variable to store the Interrupt Mask Register and modify it for each enabling/disabling of an interrupt. The overhead of this is negligible anyway. The interrupt mask register (IMR) for the RTC is broken on the AT91SAM9x5 sub-family of SoCs (good overview of the members here: http://www.eewiki.net/display/linuxonarm/AT91SAM9x5 ). The "user visible effect" is the RTC doesn't work. That sub-family is less than two years old and only has devicetree (DT) support and came online circa lk 3.7 . The dust is yet to settle on the DT stuff at least for AT91 SoCs (translation: lots of stuff is still broken, so much that it is hard to know where to start). The fix in the patch is pretty simple: just shadow the silicon IMR register with a variable in the driver. Some older SoCs (pre-DT) use the the rtc-at91rm9200 driver (e.g. obviously the AT91RM9200) and they should not be impacted by the change. There shouldn't be a large volume of interrupts associated with a RTC. Signed-off-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Reported-by:
Douglas Gilbert <dgilbert@interlog.com> Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Cc: Ludovic Desroches <ludovic.desroches@atmel.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
H Hartley Sweeten authored
Commit be867814 ("drivers/video/ep93xx-fb.c: use devm_ functions") introduced a build error: drivers/video/ep93xx-fb.c: In function 'ep93xxfb_probe': drivers/video/ep93xx-fb.c:532: error: implicit declaration of function 'devm_ioremap' drivers/video/ep93xx-fb.c:533: warning: assignment makes pointer from integer without a cast Include <linux/io.h> to pickup the declaration of 'devm_ioremap'. Signed-off-by:
H Hartley Sweeten <hsweeten@visionengravers.com> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Acked-by:
Ryan Mallon <rmallon@gmail.com> Cc: Damien Cassou <damien.cassou@lifl.fr> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Ashish Jangam authored
Add support for the virtual irq since now MFD only handles virtual irq Without this patch rtc device will fail in registration. (akpm: Ashish has a different version whcih will be needed for 3.8.x and earlier kernels) Signed-off-by:
Ashish <ashish.jangam@kpitcummins.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Russ Anderson authored
Booting with 32 TBytes memory hits BUG at mm/page_alloc.c:552! (output below). The key hint is "page 4294967296 outside zone". 4294967296 = 0x100000000 (bit 32 is set). The problem is in include/linux/mmzone.h: 530 static inline unsigned zone_end_pfn(const struct zone *zone) 531 { 532 return zone->zone_start_pfn + zone->spanned_pages; 533 } zone_end_pfn is "unsigned" (32 bits). Changing it to "unsigned long" (64 bits) fixes the problem. zone_end_pfn() was added recently in commit 108bcc96 ("mm: add & use zone_end_pfn() and zone_spans_pfn()") Output from the failure. No AGP bridge found page 4294967296 outside zone [ 4294967296 - 4327469056 ] ------------[ cut here ]------------ kernel BUG at mm/page_alloc.c:552! invalid opcode: 0000 [#1] SMP Modules linked in: CPU 0 Pid: 0, comm: swapper Not tainted 3.9.0-rc2.dtp+ #10 RIP: free_one_page+0x382/0x430 Process swapper (pid: 0, threadinfo ffffffff81942000, task ffffffff81955420) Call Trace: __free_pages_ok+0x96/0xb0 __free_pages+0x25/0x50 __free_pages_bootmem+0x8a/0x8c __free_memory_core+0xea/0x131 free_low_memory_core_early+0x4a/0x98 free_all_bootmem+0x45/0x47 mem_init+0x7b/0x14c start_kernel+0x216/0x433 x86_64_start_reservations+0x2a/0x2c x86_64_start_kernel+0x144/0x153 Code: 89 f1 ba 01 00 00 00 31 f6 d3 e2 4c 89 ef e8 66 a4 01 00 e9 2c fe ff ff 0f 0b eb fe 0f 0b 66 66 2e 0f 1f 84 00 00 00 00 00 eb f3 <0f> 0b eb fe 0f 0b 0f 1f 84 00 00 00 00 00 eb f6 0f 0b eb fe 49 Signed-off-by:Russ Anderson <rja@sgi.com> Reported-by:
George Beshers <gbeshers@sgi.com> Acked-by:
Hedi Berriche <hedi@sgi.com> Cc: Cody P Schafer <cody@linux.vnet.ibm.com> Cc: Michal Hocko <mhocko@suse.cz> Signed-off-by:
-
Oleg Nesterov authored
David said: Commit 6c0c0d4d ("poweroff: fix bug in orderly_poweroff()") apparently fixes one bug in orderly_poweroff(), but introduces another. The comments on orderly_poweroff() claim it can be called from any context - and indeed we call it from interrupt context in arch/powerpc/platforms/pseries/ras.c for example. But since that commit this is no longer safe, since call_usermodehelper_fns() is not safe in interrupt context without the UMH_NO_WAIT option. orderly_poweroff() can be used from any context but UMH_WAIT_EXEC is sleepable. Move the "force" logic into __orderly_poweroff() and change orderly_poweroff() to use the global poweroff_work which simply calls __orderly_poweroff(). While at it, remove the unneeded "int argc" and change argv_split() to use GFP_KERNEL. We use the global "bool poweroff_force" to pass the argument, this can obviously affect the previous request if it is pending/running. So we only allow the "false => true" transition assuming that the pending "true" should succeed anyway. If schedule_work() fails after that we know that work->func() was not called yet, it must see the new value. This means that orderly_poweroff() becomes async even if we do not run the command and always succeeds, schedule_work() can only fail if the work is already pending. We can export __orderly_poweroff() and change the non-atomic callers which want the old semantics. Signed-off-by:Oleg Nesterov <oleg@redhat.com> Reported-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Reported-by:
David Gibson <david@gibson.dropbear.id.au> Cc: Lucas De Marchi <lucas.demarchi@profusion.mobi> Cc: Feng Hong <hongfeng@marvell.com> Cc: Kees Cook <keescook@chromium.org> Cc: Serge Hallyn <serge.hallyn@canonical.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Signed-off-by:
-
Wanpeng Li authored
hugetlb_total_pages is used for overcommit calculations but the current implementation considers only the default hugetlb page size (which is either the first defined hugepage size or the one specified by default_hugepagesz kernel boot parameter). If the system is configured for more than one hugepage size, which is possible since commit a137e1cc ("hugetlbfs: per mount huge page sizes") then the overcommit estimation done by __vm_enough_memory() (resp. shown by meminfo_proc_show) is not precise - there is an impression of more available/allowed memory. This can lead to an unexpected ENOMEM/EFAULT resp. SIGSEGV when memory is accounted. Testcase: boot: hugepagesz=1G hugepages=1 the default overcommit ratio is 50 before patch: egrep 'CommitLimit' /proc/meminfo CommitLimit: 55434168 kB after patch: egrep 'CommitLimit' /proc/meminfo CommitLimit: 54909880 kB [akpm@linux-foundation.org: coding-style tweak] Signed-off-by:
Wanpeng Li <liwanp@linux.vnet.ibm.com> Acked-by:
Michal Hocko <mhocko@suse.cz> Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> Cc: Hillf Danton <dhillf@gmail.com> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: <stable@vger.kernel.org> [3.0+] Signed-off-by:
-
Frederic Weisbecker authored
wake_up_klogd() is useless when CONFIG_PRINTK=n because neither printk() nor printk_sched() are in use and there are actually no waiter on log_wait waitqueue. It should be a stub in this case for users like bust_spinlocks(). Otherwise this results in this warning when CONFIG_PRINTK=n and CONFIG_IRQ_WORK=n: kernel/built-in.o In function `wake_up_klogd': (.text.wake_up_klogd+0xb4): undefined reference to `irq_work_queue' To fix this, provide an off-case for wake_up_klogd() when CONFIG_PRINTK=n. There is much more from console_unlock() and other console related code in printk.c that should be moved under CONFIG_PRINTK. But for now, focus on a minimal fix as we passed the merged window already. [akpm@linux-foundation.org: include printk.h in bust_spinlocks.c] Signed-off-by:
Frederic Weisbecker <fweisbec@gmail.com> Reported-by:
James Hogan <james.hogan@imgtec.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
James Hogan authored
A randconfig caught repeated compiler warnings when CONFIG_IRQ_WORK=n due to the definition of a non-inline static function in <linux/irq_work.h>: include/linux/irq_work.h +40 : warning: 'irq_work_needs_cpu' defined but not used Make it inline to supress the warning. This is caused commit 00b42959 ("irq_work: Don't stop the tick with pending works") merged in v3.9-rc1. Signed-off-by:
-
Takahisa Tanaka authored
The AcpiMmioSel bit is bit 1 in the AcpiMmioEn register, but the current sp5100_tco driver is using bit 2. See 2.3.3 Power Management (PM) Registers page 150 of the AMD SB800-Series Southbridges Register Reference Guide [1]. AcpiMmioEn - RW – 8/16/32 bits - [PM_Reg: 24h] Field Name Bits Default Description AcpiMMioDecodeEn 0 0b Set to 1 to enable AcpiMMio space. AcpiMMIoSel 1 0b Set AcpiMMio registers to be memory-mapped or IO-mapped space. 0: Memory-mapped space 1: I/O-mapped space The sp5100_tco driver expects zero as a value of AcpiMmioSel (bit 1). Fortunately, no problems were caused by this typo, because the default value of the undocumented misused bit 2 seems to be zero. However, the sp5100_tco driver should use the correct bitmask value. [1] http://support.amd.com/us/Embedded_TechDocs/45482.pdfSigned-off-by:Takahisa Tanaka <mc74hc00@gmail.com> Signed-off-by:
Paul Menzel <paulepanter@users.sourceforge.net> Signed-off-by:
Wim Van Sebroeck <wim@iguana.be> Cc: stable <stable@vger.kernel.org>
-
Takahisa Tanaka authored
A problem was found on PC's with the SB700 chipset: The PC fails to load BIOS after running the 3.8.x kernel until the power is completely cut off. It occurs in all 3.8.x versions and the mainline version as of 2/4. The issue does not occur with the 3.7.x builds. There are two methods for accessing the watchdog registers. 1. Re-programming a resource address obtained by allocate_resource() to chipset. 2. Use the direct memory-mapped IO access. The method 1 can be used by all the chipsets (SP5100, SB7x0, SB8x0 or later). However, experience shows that only PC with the SB8x0 (or later) chipsets can use the method 2. This patch removes the method 1, because the critical problem was found. That's why the watchdog timer was able to be used on SP5100 and SB7x0 chipsets until now. Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1116835 Link: https://lkml.org/lkml/2013/2/14/271Signed-off-by:
-
git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds authored
Pull KVM fix from Marcelo Tosatti: "Fix compilation on PPC with !CONFIG_KVM" * git://git.kernel.org/pub/scm/virt/kvm/kvm: Revert "KVM: allow host header to be included even for !CONFIG_KVM"
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usbLinus Torvalds authored
Pull USB fixes from Greg Kroah-Hartman: "Here are a number of USB fixes that resolve issues that have been reported against 3.9-rc3." * tag 'usb-3.9-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (37 commits) USB: ti_usb_3410_5052: fix use-after-free in TIOCMIWAIT USB: ssu100: fix use-after-free in TIOCMIWAIT USB: spcp8x5: fix use-after-free in TIOCMIWAIT USB: quatech2: fix use-after-free in TIOCMIWAIT USB: pl2303: fix use-after-free in TIOCMIWAIT USB: oti6858: fix use-after-free in TIOCMIWAIT USB: mos7840: fix use-after-free in TIOCMIWAIT USB: mos7840: fix broken TIOCMIWAIT USB: mct_u232: fix use-after-free in TIOCMIWAIT USB: io_ti: fix use-after-free in TIOCMIWAIT USB: io_edgeport: fix use-after-free in TIOCMIWAIT USB: ftdi_sio: fix use-after-free in TIOCMIWAIT USB: f81232: fix use-after-free in TIOCMIWAIT USB: cypress_m8: fix use-after-free in TIOCMIWAIT USB: ch341: fix use-after-free in TIOCMIWAIT USB: ark3116: fix use-after-free in TIOCMIWAIT USB: serial: add modem-status-change wait queue USB: serial: fix interface refcounting USB: io_ti: fix get_icount for two port adapters USB: garmin_gps: fix memory leak on disconnect ...
-
