- 25 Jun, 2006 40 commits
-
-
Raphael Assenat authored
This patch adds support for the v3020 RTC from EM Microelectronic. The v3020 RTC is designed to be connected on a bus using only one data bit. Since any data bit may be used, it is necessary to specify this to the driver by passing a struct v3020_platform_data pointer (see include/linux/rtc-v3020.h) to the driver. Part of the following code comes from the kernel patchs produced by Compulab for their products. The original file (available here: http://raph.people.8d.com/misc/emv3020.c) was released under the terms of the GPL license. [akpm@osdl.org: cleanups] Signed-off-by:
Raphael Assenat <raph@raphnet.net> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Jean Delvare authored
Rtc driver documentation update * Mention the max-user-freq control file. * Add missing header in example code. Signed-off-by:
Jean Delvare <khali@linux-fr.org> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by:
-
Raphael Assenat authored
Add support for the MAX6902 SPI RTC chip. Tested on a pxa2xx cpu. The compulab code comes from the kernel patch the produce for their cn-x255 board. (inside a zip file on the http://www.compulab.co.il/x255/html/x255-developer.htm) The original file (drivers/char/max6902.c) was GPL, which is of course an appropriate licence: /* * max6902.c * * Driver for MAX6902 RTC * * Copyright (C) 2004 Compulab Ltd. * * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as * published by the Free Software Foundation. * * */ For reference, you can get the original file here: http://raph.people.8d.com/misc/max6902.c [akpm@osdl.org: cleanups] Signed-off-by:
-
Alessandro Zummo authored
Centralize CAP_SYS_XXX checks to avoid duplicate code and missing checks in the drivers. Signed-off-by:
Alessandro Zummo <a.zummo@towertech.it> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp> Signed-off-by:
-
Alessandro Zummo authored
Remove commented capability checks and add some others. Signed-off-by:
-
G. Liakhovetski authored
A port of the driver for the pcf8583 i2c rtc controller to the generic RTC framework by Alessandro Zummo. Based on drivers/acorn/char/{pcf8583.[hc],i2c.c}. Hopefully, acorn can be converted too to use this driver in the future. Signed-off-by:G. Liakhovetski <gl@dsa-ac.de> Signed-off-by:
-
Atsushi Nemoto authored
Import genrtc's RTC UIE emulation (CONFIG_GEN_RTC_X) to rtc-dev driver with slight adjustments/refinements. This makes UIE-less rtc drivers work better with programs doing read/poll on /dev/rtc, such as hwclock. This emulation should not harm rtc drivers with UIE support, since rtc_dev_ioctl() calls underlaying rtc driver's ioctl() first. Signed-off-by:
Atsushi Nemoto <anemo@mba.ocn.ne.jp> Acked-by:
-
David Brownell authored
This is an "RTC-framework" driver for DS1307 and similar RTC chips, It should be a full replacement for the existing ds1337.c driver (using the older RTC glue), giving a net increase in the number of RTC chips that work out-of-the-box. There's a whole cluster of RTCs that are very similar, but the 1337 driver was a bit too picky to work with most of them. Still no support for RTC alarm IRQs (on chips that support them). Signed-off-by:
David Brownell <dbrownell@users.sourceforge.net> Signed-off-by:
James Chapman <jchapman@katalix.com> Signed-off-by:
-
Jesper Juhl authored
sysrq SAK is described as being something you should mistake for SAK from c2 compliant systems - whoops. What's meant is that it should *not* be mistaken as such. Signed-off-by:
Jesper Juhl <jesper.juhl@gmail.com> Signed-off-by:
-
Jan Engelhardt authored
Currently, enabling/disabling printk timestamps is only possible through reboot (bootparam) or recompile. I normally do not run with timestamps (since syslog handles that in a good manner), but for measuring small kernel delays (e.g. irq probing - see parport thread) I needed subsecond precision, but then again, just for some minutes rather than all kernel messages to come. The following patch adds a module_param() with which the timestamps can be en-/disabled in a live system through /sys/modules/printk/parameters/printk_time. Signed-off-by:
Jan Engelhardt <jengelh@gmx.de> Signed-off-by:
-
Wu Fengguang authored
In radix_tree_tag_get(), return normalized value of 0/1, as indicated by its comment. Signed-off-by:
Wu Fengguang <wfg@mail.ustc.edu.cn> Signed-off-by:
-
Davide Libenzi authored
A few days ago Arjan signaled a lockdep red flag on epoll locks, and precisely between the epoll's device structure lock (->lock) and the wait queue head lock (->lock). Like I explained in another email, and directly to Arjan, this can't happen in reality because of the explicit check at eventpoll.c:592, that does not allow to drop an epoll fd inside the same epoll fd. Since lockdep is working on per-structure locks, it will never be able to know of policies enforced in other parts of the code. It was decided time ago of having the ability to drop epoll fds inside other epoll fds, that triggers a very trick wakeup operations (due to possibly reentrant callback-driven wakeups) handled by the ep_poll_safewake() function. While looking again at the code though, I noticed that all the operations done on the epoll's main structure wait queue head (->wq) are already protected by the epoll lock (->lock), so that locked-style functions can be used to manipulate the ->wq member. This makes both a lock-acquire save, and lockdep happy. Running totalmess on my dual opteron for a while did not reveal any problem so far: http://www.xmailserver.org/totalmess.cSigned-off-by:
Davide Libenzi <davidel@xmailserver.org> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Alexey Dobriyan authored
Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Cc: Paul Clements <Paul.Clements@steeleye.com> Cc: Jens Axboe <axboe@suse.de> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Valerie Henson authored
This patch makes EXT2_DEBUG work again. Due to lack of proper include file, EXT2_DEBUG was undefined in bitmap.c and ext2_count_free() is left out. Moved to balloc.c and removed bitmap.c entirely. Second, debug versions of ext2_count_free_{inodes/blocks} reacquires superblock lock. Moved lock into callers. Signed-off-by:Val Henson <val_henson@linux.intel.com> Signed-off-by:
-
Alexey Dobriyan authored
Why is it marked unused when in fact it's used? Signed-off-by:
-
Andrew Morton authored
On UP, this: cpumask_t mask = node_to_cpumask(numa_node_id()); for_each_cpu_mask(cpu, mask) does this: mm/readahead.c: In function `node_readahead_aging': mm/readahead.c:850: warning: unused variable `mask' which is unpleasantly fixed by this: Acked-by:Paul Jackson <pj@sgi.com> Signed-off-by:
-
H. Peter Anvin authored
Make makes sysctl non-optional unless EMBEDDED is set. There are a number of interfaces exposed via sysctl, enough that it has to be considered core kernel functionality at this point. Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
-
Ingo Molnar authored
Add WARN_ON_ONCE(cond) to print once-per-bootup messages. [rostedt@goodmis.org: improve code generation] Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Arjan van de Ven <arjan@linux.intel.com> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
H. Peter Anvin authored
Make procfs non-optional unless EMBEDDED is set, just like sysfs. procfs is already de facto required for a large subset of Linux functionality. Signed-off-by:
-
Randy Dunlap authored
Put short function description for read_cache_pages() on one line as needed by kernel-doc. Signed-off-by:
Randy Dunlap <rdunlap@xenotime.net> Signed-off-by:
-
Mingming Cao authored
Convert the ext3 in-kernel filesystem blocks to ext3_fsblk_t. Convert the rest of all unsigned long type in-kernel filesystem blocks to ext3_fsblk_t, and replace the printk format string respondingly. Signed-off-by:
Mingming Cao <cmm@us.ibm.com> Signed-off-by:
-
Mingming Cao authored
Some of the in-kernel ext3 block variable type are treated as signed 4 bytes int type, thus limited ext3 filesystem to 8TB (4kblock size based). While trying to fix them, it seems quite confusing in the ext3 code where some blocks are filesystem-wide blocks, some are group relative offsets that need to be signed value (as -1 has special meaning). So it seem saner to define two types of physical blocks: one is filesystem wide blocks, another is group-relative blocks. The following patches clarify these two types of blocks in the ext3 code, and fix the type bugs which limit current 32 bit ext3 filesystem limit to 8TB. With this series of patches and the percpu counter data type changes in the mm tree, we are able to extend exts filesystem limit to 16TB. This work is also a pre-request for the recent >32 bit ext3 work, and makes the kernel to able to address 48 bit ext3 block a lot easier: Simply redefine ext3_fsblk_t from unsigned long to sector_t and redefine the format string for ext3 filesystem block corresponding. Two RFC with a series patches have been posted to ext2-devel list and have been reviewed and discussed: http://marc.theaimsgroup.com/?l=ext2-devel&m=114722190816690&w=2 http://marc.theaimsgroup.com/?l=ext2-devel&m=114784919525942&w=2 Patches are tested on both 32 bit machine and 64 bit machine, <8TB ext3 and >8TB ext3 filesystem(with the latest to be released e2fsprogs-1.39). Tests includes overnight fsx, tiobench, dbench and fsstress. This patch: Defines ext3_fsblk_t and ext3_grpblk_t, and the printk format string for filesystem wide blocks. This patch classifies all block group relative blocks, and ext3_fsblk_t blocks occurs in the same function where used to be confusing before. Also include kernel bug fixes for filesystem wide in-kernel block variables. There are some fileystem wide blocks are treated as int/unsigned int type in the kernel currently, especially in ext3 block allocation and reservation code. This patch fixed those bugs by converting those variables to ext3_fsblk_t(unsigned long) type. Signed-off-by:
-
Randy Dunlap authored
Fix section warning: WARNING: drivers/scsi/megaraid/megaraid_mbox.o - Section mismatch: reference to .init.text: from .text between 'megaraid_probe_one' (at offset 0x171e) and 'megaraid_queue_command' Signed-off-by:
-
Randy.Dunlap authored
From: Randy Dunlap <rdunlap@xenotime.net> Fix section mismatch in wd7000 driver: WARNING: drivers/scsi/wd7000.o - Section mismatch: reference to .init.text: from .text after 'wd7000_detect' (at offset 0xa5d) WARNING: drivers/scsi/wd7000.o - Section mismatch: reference to .init.text: from .text after 'wd7000_detect' (at offset 0xab6) WARNING: drivers/scsi/wd7000.o - Section mismatch: reference to .init.text: from .text after 'wd7000_detect' (at offset 0xb67 Signed-off-by:
-
Ben Dooks authored
Driver for the simple parallel port interface on the Asix AX88796 chip on an platform_bus. [akpm@osdl.org: x86_64 build fix] Signed-off-by:
Ben Dooks <ben-linux@fluff.org> Signed-off-by:
-
Matt Helsley authored
copy_process() appears to be the only caller of acct_clear_integrals() and does not pass in NULL task pointers. Remove the unecessary check. Signed-off-by:
Matt Helsley <matthltc@us.ibm.com> Signed-off-by:
-
NeilBrown authored
As described in a previous patch and documented in mm/filemap.h, copy_from_user_inatomic* shouldn't zero out the tail of the buffer after an incomplete copy. This patch implements that change for i386. For the _nocache version, a new __copy_user_intel_nocache is defined similar to copy_user_zeroio_intel_nocache, and this is ultimately used for the copy. For the regular version, __copy_from_user_ll_nozero is defined which uses __copy_user and __copy_user_intel - the later needs casts to reposition the __user annotations. If copy_from_user_atomic is given a constant length of 1, 2, or 4, then we do still zero the destintion on failure. This didn't seem worth the effort of fixing as the places where it is used really don't care. Signed-off-by:
Neil Brown <neilb@suse.de> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: William Lee Irwin III <wli@holomorphy.com> Signed-off-by:
-
NeilBrown authored
The problem is that when we write to a file, the copy from userspace to pagecache is first done with preemption disabled, so if the source address is not immediately available the copy fails *and* *zeros* *the* *destination*. This is a problem because a concurrent read (which admittedly is an odd thing to do) might see zeros rather that was there before the write, or what was there after, or some mixture of the two (any of these being a reasonable thing to see). If the copy did fail, it will immediately be retried with preemption re-enabled so any transient problem with accessing the source won't cause an error. The first copying does not need to zero any uncopied bytes, and doing so causes the problem. It uses copy_from_user_atomic rather than copy_from_user so the simple expedient is to change copy_from_user_atomic to *not* zero out bytes on failure. The first of these two patches prepares for the change by fixing two places which assume copy_from_user_atomic does zero the tail. The two usages are very similar pieces of code which copy from a userspace iovec into one or more page-cache pages. These are changed to remove the assumption. The second patch changes __copy_from_user_inatomic* to not zero the tail. Once these are accepted, I will look at similar patches of other architectures where this is important (ppc, mips and sparc being the ones I can find). This patch: There is a problem with __copy_from_user_inatomic zeroing the tail of the buffer in the case of an error. As it is called in atomic context, the error may be transient, so it results in zeros being written where maybe they shouldn't be. In the usage in filemap, this opens a window for a well timed read to see data (zeros) which is not consistent with any ordering of reads and writes. Most cases where __copy_from_user_inatomic is called, a failure results in __copy_from_user being called immediately. As long as the latter zeros the tail, the former doesn't need to. However in *copy_from_user_iovec implementations (in both filemap and ntfs/file), it is assumed that copy_from_user_inatomic will zero the tail. This patch removes that assumption, so that after this patch it will be safe for copy_from_user_inatomic to not zero the tail. This patch also adds some commentary to filemap.h and asm-i386/uaccess.h. After this patch, all architectures that might disable preempt when kmap_atomic is called need to have their __copy_from_user_inatomic* "fixed". This includes - powerpc - i386 - mips - sparc Signed-off-by:
-
Andreas Mohr authored
constify a medium-large CRC code table. Signed-off-by:
Andreas Mohr <andi@lisas.de> Signed-off-by:
-
Andreas Mohr authored
Signed-off-by:
-
Chris Wright authored
This is redundant with check in wakeup_kswapd. Signed-off-by:
Chris Wright <chrisw@sous-sol.org> Acked-by:
Christoph Lameter <clameter@sgi.com> Signed-off-by:
-
David Wilder authored
Cc: Vivek Goyal <vgoyal@in.ibm.com> Signed-off-by:
-
Jesper Juhl authored
Do a *partial* CodingStyle cleanup, correct some spelling in printk()'s && convert C++ comments to C comments - in moxa driver. Signed-off-by:
-
Jesper Juhl authored
Remove pointless check of 'tty' argument vs NULL from moxa driver. Signed-off-by:
-
Jesper Juhl authored
Signed-off-by:
Alan Cox <alan@redhat.com> Signed-off-by:
-
Theodore Ts'o authored
This was reported as Debian bug #336604. Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Signed-off-by:
-
Theodore Ts'o authored
Signed-off-by:
-
Theodore Ts'o authored
The variable i is guaranteed to be the same as db_count given the previous for loop. So get rid of it since it's dead code. Signed-off-by:
-
Mingming Cao authored
If ext3 filesystem is larger than 2TB, and sector_t is a u32 (i.e. CONFIG_LBD not defined in the kernel), the calculation of the disk sector will overflow. Add check at ext3_fill_super() and ext3_group_extend() to prevent mount/remount/resize >2TB ext3 filesystem if sector_t size is 4 bytes. Verified this patch on a 32 bit platform without CONFIG_LBD defined (sector_t is 32 bits long), mount refuse to mount a 10TB ext3. Signed-off-by: Mingming Cao<cmm@us.ibm.com> Acked-by:
Andreas Dilger <adilger@clusterfs.com> Signed-off-by:
-
Andrew Morton authored
schedule_on_each_cpu() presently does a large kmalloc - 96 kbytes on 1024 CPU 64-bit. Rework it so that we do one 8192-byte allocation and then a pile of tiny ones, via alloc_percpu(). This has a much higher chance of success (100% in the current VM). This also has the effect of reducing the memory requirements from NR_CPUS*n to num_possible_cpus()*n. Cc: Christoph Lameter <clameter@engr.sgi.com> Cc: Andi Kleen <ak@muc.de> Signed-off-by:
-
