- 26 Oct, 2010 40 commits
-
-
Hong Liu authored
Update the driver for the needed runtime power features. Remove the old user controlled power functions. [akpm@linux-foundation.org: put PM code under CONFIG_PM] Signed-off-by:
Hong Liu <hong.liu@intel.com> Signed-off-by:
Alan Cox <alan@linux.intel.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
anantha authored
This adds support for the ADPS9802ALS sensor. Cleanup by Alan Cox - move mutexes to cover more things - report I/O errors back to user space - report range and values in LUX Signed-off-by:
Anantha Narayanan <anantha.narayanan@intel.com> [The 4K and 64K in the hw spec actually means 4095 (12bit) and 65535 (16bit).] Signed-off-by:
Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by:
-
Alek Du authored
Our Moorestown platform has two max7315 chips which is covered by pca953x i2c gpio driver. A while ago this driver got updated with nested irq thread support, and it broke the compatibity with "request_irq". For example, the gpio_keys.c driver can not work with this driver now. This patch fixes the issue by switching to generic_handle_irq. Also fix the irq_base issue: irq_base == 0 is valid, and a "-1" value should mean invalid. IRQ 0 is not a valid IRQ, irq_base of 0 is valid. Signed-off-by:
Alek Du <alek.du@intel.com> Signed-off-by:
-
Kalhan Trisal authored
The LS driver will read the latest Lux measurement based upon the light brightness and will report the LUX output through sysfs interface. This hardware isn't quite the same as the ISL29003 so has a different driver. [akpm@linux-foundation.org: put PM code under #ifdef CONFIG_PM] Signed-off-by:
Kalhan Trisal <kalhan.trisal@intel.com> [Runtime power management support added] Signed-off-by:
Arjan van de Ven <arjan@linux.intel.com> [Fixes to runtime PM] Signed-off-by:
-
Namhyung Kim authored
Prefix cname and ctype constants with CN/CT_. This is especially for the conflict on BUG which causes a build break if arch defines it as a inline function, i.e. MIPS. Signed-off-by:
Namhyung Kim <namhyung@gmail.com> Cc: Ankita Garg <ankita@in.ibm.com> Signed-off-by:
-
Samu Onkalo authored
Add short documentation for two ALS / proximity chip drivers. Signed-off-by:
Samu Onkalo <samu.p.onkalo@nokia.com> Acked-by:
-
Samu Onkalo authored
This is a driver for Avago APDS990X combined ALS and proximity sensor. Interface is sysfs based. The driver uses interrupts to provide new data. The driver supports pm_runtime and regulator frameworks. See Documentation/misc-devices/apds990x.txt for details Signed-off-by:
-
Samu Onkalo authored
This is a driver for ROHM BH1770GLC and OSRAM SFH7770 combined ALS and proximity sensor. Interface is sysfs based. The driver uses interrupts to provide new data. The driver supports pm_runtime and regulator frameworks. See Documentation/misc-devices/bh1770glc.txt for details Signed-off-by:
-
steven miao authored
The ad5251/ad5252 devices have rdac1 and rdac3, but no rdac0. So make sure we use the right channels so userspace gets correct data and not just garbage. Signed-off-by:
steven miao <realmz6@gmail.com> Signed-off-by:
Mike Frysinger <vapier@gentoo.org> Cc: Michael Hennerich <michael.hennerich@analog.com> Cc: Chris Verges <chrisv@cyberswitching.com> Signed-off-by:
-
Michael Hennerich authored
Add support for AD5270, AD5271, AD5272, AD5274 digital potentiometers. Add 20-TP feature for AD5291 and AD5292 parts, and update feature list. AD5291 rdac read back must be shifted by two. Signed-off-by:
Michael Hennerich <michael.hennerich@analog.com> Cc: Mike Frysinger <vapier@gentoo.org> Cc: Chris Verges <chrisv@cyberswitching.com> Signed-off-by:
-
Michael Hennerich authored
There is no runtime effect by this change. It frees up namespace for defines erroneously used. This is required to actually support devices requiring the namespace, added with "drivers/misc/ad525x_dpot.c: new features". All defines touched have the same value defined, after the change. Signed-off-by:
-
Rahul Ruikar authored
phantom_probe() can fail in many places. Add missing warning messages in pci_enable_device() and pci_request_regions(). Signed-off-by:
Rahul Ruikar <rahul.ruikar@gmail.com> Cc: Jiri Slaby <jirislaby@gmail.com> Cc: Greg KH <greg@kroah.com> Signed-off-by:
-
Andrew Morton authored
Silly though it is, completions and wait_queue_heads use foo_ONSTACK (COMPLETION_INITIALIZER_ONSTACK, DECLARE_COMPLETION_ONSTACK, __WAIT_QUEUE_HEAD_INIT_ONSTACK and DECLARE_WAIT_QUEUE_HEAD_ONSTACK) so I guess workqueues should do the same thing. s/INIT_WORK_ON_STACK/INIT_WORK_ONSTACK/ s/INIT_DELAYED_WORK_ON_STACK/INIT_DELAYED_WORK_ONSTACK/ Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Acked-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Jerome Marchand authored
The lock number in /proc/locks (first field) is implemented by a counter (private field of struct seq_file) which is incremented at each call of locks_show() and reset to 1 in locks_start() whatever the offset is. It should be reset according to the actual position in the list. Because of this, the numbering erratically restarts at 1 several times when reading a long /proc/locks file. Moreover, locks_show() can be called twice to print a single line thus skipping a number. The counter should be incremented in locks_next(). And last, pos is a loff_t, which can be bigger than a pointer, so we don't use the pointer as an integer anymore, and allocate a loff_t instead. Signed-off-by:
Jerome Marchand <jmarchan@redhat.com> Cc: Pavel Emelyanov <xemul@parallels.com> Cc: Matthew Wilcox <matthew@wil.cx> Signed-off-by:
-
Randy Dunlap authored
Move the EXPORTFS kconfig symbol out of the NETWORK_FILESYSTEMS block since it provides a library function that can be (and is) used by other (non-network) filesystems. This also eliminates a kconfig dependency warning: warning: (XFS_FS && BLOCK || NFSD && NETWORK_FILESYSTEMS && INET && FILE_LOCKING && BKL) selects EXPORTFS which has unmet direct dependencies (NETWORK_FILESYSTEMS) Signed-off-by:
Randy Dunlap <randy.dunlap@oracle.com> Cc: Dave Chinner <david@fromorbit.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Alex Elder <aelder@sgi.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Namhyung Kim authored
bh->b_private is initialized within init_buffer(), thus this assignment is redundant. Signed-off-by:
-
Mike Frysinger authored
The new init ramfs format (cpio based) requires an alignment of 4 (per the documentation and per the source files themselves). As for compressed sources, the decompressors can all deal with unaligned buffers. The cpio source is also found in the __init sections of the kernel, so once they are read and expanded into a tmpfs, the source is freed. That means there is no need to force page alignment here either. This has been used on Blackfin systems for many releases without issue. Signed-off-by:
-
Mike Frysinger authored
With the recent change "net: remove time limit in process_backlog()", the softnet_data variable changed from "DEFINE_PER_CPU()" to "DEFINE_PER_CPU_ALIGNED()" which moved it from the .data section to the .data.shared_align section. I'm not saying this patch is wrong, just that is what caused me to notice this larger problem. No one else in the kernel is using this aligned macro variant, so I imagine that's why no one has noticed yet. Since .data..shared_align isn't declared in any vmlinux files that I can see, the linker just places it last. This "just works" for most people, but when building a ROM kernel on Blackfin systems, it causes section overlap errors: bfin-uclinux-ld.real: section .init.data [00000000202e06b8 -> 00000000202e48b7] overlaps section .data.shared_aligned [00000000202e06b8 -> 00000000202e0723] I imagine other arches which support the ROM config option and thus do funky placement would see similar issues ... On x86, it is stuck in a dedicated section at the end: [8] .data PROGBITS ffffffff810ec000 2ec0000303a8 00 WA 0 0 4096 [9] .data.shared_alig PROGBITS ffffffff8111c3c0 31c3c00000c8 00 WA 0 0 64 So make sure we include this section in the DATA_DATA macro so that it is placed in the right location. Signed-off-by:
-
Edward Shishkin authored
Fix up truncation (ssize_t->int). This only matters with >2G reads/writes, which the kernel doesn't permit. Signed-off-by:
Edward Shishkin <edward@redhat.com> Reviewed-by:
Jeff Moyer <jmoyer@redhat.com> Signed-off-by:
-
Mark Brown authored
ihex firmwares can include a jump address for starting execution. Add a -j option which will cause this to be written into the generated file as a record with address zero and data consisting of the address to jump to, allowing drivers to make use of this information. This format is chosen because it most closely follows the original ihex format, though it may make more sense to write a record with length zero and the address stored as the address. The records are not omitted by default since our ihex format does not include record type information and so including additional records may lead to confusion. Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: David Woodhouse <dwmw2@infradead.org> Signed-off-by:
-
Miklos Szeredi authored
Commit 7909b1c6 ("fuse: don't use atomic kmap") removed KM_USER0 usage from fuse/dev.c. Switch KM_USER1 uses to KM_USER0 for clarity. Also replace open coded clear_highpage(). Signed-off-by:
Miklos Szeredi <mszeredi@suse.cz> Cc: Jan Beulich <jbeulich@novell.com> Signed-off-by:
-
Jan Beulich authored
After all that's what they are intended for. Signed-off-by:
Jan Beulich <jbeulich@novell.com> Cc: Miklos Szeredi <miklos@szeredi.hu> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Signed-off-by:
-
Jan Beulich authored
gcc aligns strings as a performance consideration for those cases where strings are being used a lot. Their use is not performance critical, and hence it seems better to save some space. Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
-
Andrew Morton authored
The whole point to using the strict functions is to check the return value. If you don't, strict_strto*() will return you uninitialised garbage. Offenders have been observed in the wild. Signed-off-by:
-
Philippe De Muyter authored
Long ago, PT_TRACESYS_OFF and friends were introduced as hard defines to avoid straight constants in assembler parts of linux m68k. They are not used anymore, and were not updated to follow changes in linux kernel. Remove them. When similar constants are needed, they are now generated using asm-offsets.c. Signed-off-by:
Philippe De Muyter <phdm@macqel.be> Acked-by:
Geert Uytterhoeven <geert@linux-m68k.org> Acked-by:
Greg Ungerer <gerg@uclinux.org> Signed-off-by:
-
Hagen Paul Pfeifer authored
Use the new {max,min}3 macros to save some cycles and bytes on the stack. This patch substitutes trivial nested macros with their counterpart. Signed-off-by:Hagen Paul Pfeifer <hagen@jauu.net> Cc: Joe Perches <joe@perches.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Hartley Sweeten <hsweeten@visionengravers.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Roland Dreier <rolandd@cisco.com> Cc: Sean Hefty <sean.hefty@intel.com> Cc: Pekka Enberg <penberg@cs.helsinki.fi> Signed-off-by:
-
Hagen Paul Pfeifer authored
Introduce two additional min/max macros to compare three operands. This will save some cycles as well as some bytes on the stack and last but not least more pleasing as macro nesting. [akpm@linux-foundation.org: fix warnings] Signed-off-by:
-
Richard Weinberger authored
Some code cleanups for hostfs. Signed-off-by:
Richard Weinberger <richard@nod.at> Cc: Jeff Dike <jdike@addtoit.com> Signed-off-by:
-
Richard Weinberger authored
This patch removes __do_IRQ() from user mode linux. __do_IRQ is deprecated. Signed-off-by:
-
Roland McGrath authored
With glibc 2.11 or later that was built with --enable-multi-arch, the UML link fails with undefined references to __rel_iplt_start and similar symbols. In recent binutils, the default linker script defines these symbols (see ld --verbose). Fix the UML linker scripts to match the new defaults for these sections. Signed-off-by:
Roland McGrath <roland@redhat.com> Cc: Jeff Dike <jdike@addtoit.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
FUJITA Tomonori authored
I think that it's better to detect DMA misuse at build time rather than calling BUG_ON. Architectures that can't do DMA need to define CONFIG_NO_DMA. Thanks to Sam Ravnborg for explaining how CONFIG_NO_DMA and CONFIG_HAS_DMA work: http://marc.info/?l=linux-kernel&m=128359913825550&w=2 HAS_DMA is defined like this: config HAS_DMA boolean depends on !NO_DMA default y So to set HAS_DMA to true an arch should do: 1) Do not define NO_DMA 2) Define NO_DMA abd set it to 'n' Must archs - including um - used principle 1). In the um case we want to say that we do NOT have any DMA. This can be done in two ways. a) define NO_DMA and set it to 'y' b) redefine HAS_DMA and set it to 'n'. The patch you provided used principle b) where other archs use principle a). So I suggest you should use principle a) for um too. Signed-off-by:
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: Miklos Szeredi <miklos@szeredi.hu> Cc: Jeff Dike <jdike@addtoit.com> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
-
Ivan Kokshaysky authored
T2 are the only alpha SMP systems that do HAE switching at runtime, which is fundamentally racy on SMP. This patch limits MMIO space on T2 to HAE0 only, like we did on MCPCIA (rawhide) long ago. This leaves us with only 112 Mb of PCI MMIO (128 Mb HAE aperture minus 16 Mb reserved for EISA), but since linux PCI allocations are reasonably tight, it should be enough for sane hardware configurations. Also, fix a typo in MCPCIA_FROB_MMIO macro which shouldn't call set_hae() if MCPCIA_ONE_HAE_WINDOW is defined. It's more for correctness, as set_hae() is a no-op anyway in that case. Signed-off-by:
Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Matt Turner <mattst88@gmail.com> Cc: Richard Henderson <rth@twiddle.net> Signed-off-by:
-
FUJITA Tomonori authored
Signed-off-by:
-
Vasiliy Kulikov authored
Structure info is copied to userland with some padding fields unitialized. It leads to leaking of stack memory. [akpm@linux-foundation.org: remove now-unneeded zeroing of info->hi_ireqfreq] Signed-off-by:
Vasiliy Kulikov <segooon@gmail.com> Cc: Clemens Ladisch <clemens@ladisch.de> Signed-off-by:
-
Jaswinder Singh Rajput authored
$./hpet_example info /dev/hpet -hpet: executing info hpet_info: hi_irqfreq 0x0 hi_flags 0x0 hi_hpet 0 hi_timer 2 Signed-off-by:
Jaswinder Singh Rajput <jaswinderrajput@gmail.com> Cc: Clemens Ladisch <clemens@ladisch.de> Cc: "Venkatesh Pallipadi (Venki)" <venki@google.com> Cc: john stultz <johnstul@us.ibm.com> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Jaswinder Singh Rajput authored
Fix the following style problems: WARNING: Use #include <linux/uaccess.h> instead of <asm/uaccess.h> WARNING: Use #include <linux/io.h> instead of <asm/io.h> ERROR: code indent should use tabs where possible ERROR: do not initialise statics to 0 or NULL Signed-off-by:
-
Clemens Ladisch authored
Jaswinder Singh Rajput wrote: > By executing Documentation/timers/hpet_example.c > > for polling, I requested for 3 iterations but it seems iteration work > for only 2 as first expired time is always very small. > > # ./hpet_example poll /dev/hpet 10 3 > -hpet: executing poll > hpet_poll: info.hi_flags 0x0 > hpet_poll: expired time = 0x13 > hpet_poll: revents = 0x1 > hpet_poll: data 0x1 > hpet_poll: expired time = 0x1868c > hpet_poll: revents = 0x1 > hpet_poll: data 0x1 > hpet_poll: expired time = 0x18645 > hpet_poll: revents = 0x1 > hpet_poll: data 0x1 Clearing the HPET interrupt enable bit disables interrupt generation but does not disable the timer, so the interrupt status bit will still be set when the timer elapses. If another interrupt arrives before the timer has been correctly programmed (due to some other device on the same interrupt line, or CONFIG_DEBUG_SHIRQ), this results in an extra unwanted interrupt event because the status bit is likely to be set from comparator matches that happened before the device was opened. Therefore, we have to ensure that the interrupt status bit is and stays cleared until we actually program the timer. Signed-off-by:
Clemens Ladisch <clemens@ladisch.de> Reported-by:
Jaswinder Singh Rajput <jaswinderlinux@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: john stultz <johnstul@us.ibm.com> Cc: Bob Picco <bpicco@redhat.com> Cc: <stable@kernel.org> Signed-off-by:
-
Jiri Slaby authored
When the initialization code in hpet finds a memory resource and does not find an IRQ, it does not unmap the memory resource previously mapped. There are buggy BIOSes which report resources exactly like this and what is worse the memory region bases point to normal RAM. This normally would not matter since the space is not touched. But when PAT is turned on, ioremap causes the page to be uncached and sets this bit in page->flags. Then when the page is about to be used by the allocator, it is reported as: BUG: Bad page state in process md5sum pfn:3ed00 page:ffffea0000dbd800 count:0 mapcount:0 mapping:(null) index:0x0 page flags: 0x20000001000000(uncached) Pid: 7956, comm: md5sum Not tainted 2.6.34-12-desktop #1 Call Trace: [<ffffffff810df851>] bad_page+0xb1/0x100 [<ffffffff810dfa45>] prep_new_page+0x1a5/0x1c0 [<ffffffff810dfe01>] get_page_from_freelist+0x3a1/0x640 [<ffffffff810e01af>] __alloc_pages_nodemask+0x10f/0x6b0 ... In this particular case: 1) HPET returns 3ed00000 as memory region base, but it is not in reserved ranges reported by the BIOS (excerpt): BIOS-e820: 0000000000100000 - 00000000af6cf000 (usable) BIOS-e820: 00000000af6cf000 - 00000000afdcf000 (reserved) 2) there is no IRQ resource reported by HPET method. On the other hand, the Intel HPET specs (1.0a) says (3.2.5.1): _CRS ( // Report 1K of memory consumed by this Timer Block memory range consumed // Optional: only used if BIOS allocates Interrupts [1] IRQs consumed ) [1] For case where Timer Block is configured to consume IRQ0/IRQ8 AND Legacy 8254/Legacy RTC hardware still exists, the device objects associated with 8254 & RTC devices should not report IRQ0/IRQ8 as "consumed resources". So in theory we should check whether if it is the case and use those interrupts instead. Anyway the address reported by the BIOS here is bogus, so non-presence of IRQ doesn't mean the "optional" part in point 2). Since I got no reply previously, fix this by simply unmapping the space when IRQ is not found and memory region was mapped previously. It would be probably more safe to walk the resources again and unmap appropriately depending on type. But as we now use only ioremap for both 2 memory resource types, it is not necessarily needed right now. Addresses https://bugzilla.novell.com/show_bug.cgi?id=629908Reported-by:
Olaf Hering <olaf@aepfle.de> Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Acked-by:
-
Bob Liu authored
Simple code for reducing list_empty(&source) check. Signed-off-by:
Bob Liu <lliubbo@gmail.com> Acked-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Acked-by:
Wu Fengguang <fengguang.wu@intel.com> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: Mel Gorman <mel@csn.ul.ie> Signed-off-by:
-
Bob Liu authored
If not_managed is true all pages will be putback to lru, so break the loop earlier to skip other pages isolate. Signed-off-by:
-
