summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* nfsd: stop translating EAGAIN to nfserr_dropitJ. Bruce Fields2011-01-041-1/+2
| | | | | | | | | We no longer need this. Also, EWOULDBLOCK is generally a synonym for EAGAIN, but that may not be true on all architectures, so map it as well. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* svcrpc: simpler request droppingJ. Bruce Fields2011-01-044-2/+5
| | | | | | | | | | | | | | Currently we use -EAGAIN returns to determine when to drop a deferred request. On its own, that is error-prone, as it makes us treat -EAGAIN returns from other functions specially to prevent inadvertent dropping. So, use a flag on the request instead. Returning an error on request deferral is still required, to prevent further processing, but we no longer need worry that an error return on its own could result in a drop. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* svcrpc: avoid double reply caused by deferral raceJ. Bruce Fields2011-01-041-7/+11
| | | | | | | | | | | | | | | | | | | | | | | Commit d29068c431599fa "sunrpc: Simplify cache_defer_req and related functions." asserted that cache_check() could determine success or failure of cache_defer_req() by checking the CACHE_PENDING bit. This isn't quite right. We need to know whether cache_defer_req() created a deferred request, in which case sending an rpc reply has become the responsibility of the deferred request, and it is important that we not send our own reply, resulting in two different replies to the same request. And the CACHE_PENDING bit doesn't tell us that; we could have succesfully created a deferred request at the same time as another thread cleared the CACHE_PENDING bit. So, partially revert that commit, to ensure that cache_check() returns -EAGAIN if and only if a deferred request has been created. Signed-off-by: J. Bruce Fields <bfields@redhat.com> Acked-by: NeilBrown <neilb@suse.de>
* nfsd: don't drop requests on -ENOMEMJ. Bruce Fields2011-01-041-1/+1
| | | | | | | | | We never want to drop a request if we could return a JUKEBOX/DELAY error instead; so, convert to nfserr_jukebox and let nfsd_dispatch() convert that to a dropit error as a last resort if JUKEBOX/DELAY is unavailable (as in the NFSv2 case). Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* nfsd: declare several functions of nfs4callback as staticKirill A. Shutemov2011-01-041-3/+4
| | | | | | | | | setup_callback_client(), nfsd4_release_cb() and nfsd4_process_cb_update() do not have users outside the translation unit. Let's declare it as static. Signed-off-by: Kirill A. Shutemov <kirill@shutemov.name> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* SUNRPC: Remove more code when NFSD_DEPRECATED is not configuredJ. Bruce Fields2011-01-042-0/+15
| | | | | | Signed-off-by: NeilBrown <neilb@suse.de> [bfields@redhat.com: moved svcauth_unix_purge outside ifdef's.] Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* svcrpc: modifying valid sunrpc cache entries is racyJ. Bruce Fields2011-01-041-2/+1
| | | | | | | | | | | | | | | | Once a sunrpc cache entry is VALID, we should be replacing it (and allowing any concurrent users to destroy it on last put) instead of trying to update it in place. Otherwise someone referencing the ip_map we're modifying here could try to use the m_client just as we're putting the last reference. The bug should only be seen by users of the legacy nfsd interfaces. (Thanks to Neil for suggestion to use sunrpc_invalidate.) Reviewed-by: NeilBrown <neilb@suse.de> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* nfsd4: fix oops on secinfo_no_name result encodingMi Jinlong2010-12-291-4/+17
| | | | | | | | | | | | | The secinfo_no_name code oopses on encoding with BUG: unable to handle kernel NULL pointer dereference at 00000044 IP: [<e2bd239a>] nfsd4_encode_secinfo+0x1c/0x1c1 [nfsd] We should implement a nfsd4_encode_secinfo_no_name() instead using nfsd4_encode_secinfo(). Signed-off-by: Mi Jinlong <mijinlong@cn.fujitsu.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* nfsd4: implement secinfo_no_nameJ. Bruce Fields2010-12-174-2/+48
| | | | | | Implementation of this operation is mandatory for NFSv4.1. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* nfsd4: move guts of nfsd4_lookupp into helperJ. Bruce Fields2010-12-171-6/+10
| | | | | | We'll reuse this code in secinfo_no_name. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* nfsd4: 4.1 SECINFO should consume filehandleJ. Bruce Fields2010-12-171-0/+3
| | | | | | | | See the referenced spec language; an attempt by a 4.1 client to use the current filehandle after a secinfo call should result in a NOFILEHANDLE error. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* net/sunrpc/auth_gss/gss_krb5_crypto.c: Use normal negative error value returnJoe Perches2010-12-171-1/+1
| | | | | | | | | And remove unnecessary double semicolon too. No effect to code, as test is != 0. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* net: sunrpc: kill unused macrosShan Wei2010-12-173-5/+0
| | | | | | | These macros never be used for several years. Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* nfs: add missed CONFIG_NFSD_DEPRECATEDbookjovi@gmail.com2010-12-171-0/+2
| | | | | | | | | | these pieces of code only make sense when CONFIG_NFSD_DEPRECATED enabled Signed-off-by: Jovi Zhang <bookjovi@gmail.com> fs/nfsd/nfsctl.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* sunrpc: svc_sock_names should hold ref to socket being closed.NeilBrown2010-12-171-4/+6
| | | | | | | | | | | | Currently svc_sock_names calls svc_close_xprt on a svc_sock to which it does not own a reference. As soon as svc_close_xprt sets XPT_CLOSE, the socket could be freed by a separate thread (though this is a very unlikely race). It is safer to hold a reference while calling svc_close_xprt. Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* sunrpc: remove xpt_poolNeilBrown2010-12-172-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | The xpt_pool field is only used for reporting BUGs. And it isn't used correctly. In particular, when it is cleared in svc_xprt_received before XPT_BUSY is cleared, there is no guarantee that either the compiler or the CPU might not re-order to two assignments, just setting xpt_pool to NULL after XPT_BUSY is cleared. If a different cpu were running svc_xprt_enqueue at this moment, it might see XPT_BUSY clear and then xpt_pool non-NULL, and so BUG. This could be fixed by calling smp_mb__before_clear_bit() before the clear_bit. However as xpt_pool isn't really used, it seems safest to simply remove xpt_pool. Another alternate would be to change the clear_bit to clear_bit_unlock, and the test_and_set_bit to test_and_set_bit_lock. Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* nfsd: fix offset printk's in nfsd3 read/writeJ. Bruce Fields2010-12-171-4/+4
| | | | | | | | Thanks to dysbr01@ca.com for noticing that the debugging printk in the v3 write procedure can print >2GB offsets as negative numbers: https://bugzilla.kernel.org/show_bug.cgi?id=23342 Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* nfsd4: fix mixed 4.0/4.1 handling, 4.1 rebootJ. Bruce Fields2010-12-172-21/+17
| | | | | | | | | | | | | Instead of failing to find client entries which don't match the minorversion, we should be finding them, then either erroring out or expiring them as appropriate. This also fixes a problem which would cause the 4.1 server to fail to recognize clients after a second reboot. Reported-by: Casey Bodley <cbodley@citi.umich.edu> Reviewed-by: Benny Halevy <bhalevy@panasas.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* nfsd4: replace unintuitive match_clientid_establishmentJ. Bruce Fields2010-12-171-10/+4
| | | | | Reviewed-by: Benny Halevy <bhalevy@panasas.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* Merge commit 'v2.6.37-rc6' into for-2.6.38J. Bruce Fields2010-12-171251-9881/+19921
|\
| * Linux 2.6.37-rc6v2.6.37-rc6Linus Torvalds2010-12-151-1/+1
| |
| * Merge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6Linus Torvalds2010-12-151-0/+1
| |\ | | | | | | | | | | | | * git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: ghash-intel - ghash-clmulni-intel_glue needs err.h
| | * crypto: ghash-intel - ghash-clmulni-intel_glue needs err.hRandy Dunlap2010-12-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add missing header file: arch/x86/crypto/ghash-clmulni-intel_glue.c:256: error: implicit declaration of function 'IS_ERR' arch/x86/crypto/ghash-clmulni-intel_glue.c:257: error: implicit declaration of function 'PTR_ERR' Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * | Merge branch 'for_linus' of ↵Linus Torvalds2010-12-154-4/+18
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 * 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4: ext4: fix typo which broke '..' detection in ext4_find_entry() ext4: Turn off multiple page-io submission by default
| | * | ext4: fix typo which broke '..' detection in ext4_find_entry()Aaro Koskinen2010-12-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There should be a check for the NUL character instead of '0'. Fortunately the only thing that cares about this is NFS serving, which is why we didn't notice this in the merge window testing. Reported-by: Phil Carmody <ext-phil.2.carmody@nokia.com> Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
| | * | ext4: Turn off multiple page-io submission by defaultTheodore Ts'o2010-12-143-3/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Jon Nelson has found a test case which causes postgresql to fail with the error: psql:t.sql:4: ERROR: invalid page header in block 38269 of relation base/16384/16581 Under memory pressure, it looks like part of a file can end up getting replaced by zero's. Until we can figure out the cause, we'll roll back the change and use block_write_full_page() instead of ext4_bio_write_page(). The new, more efficient writing function can be used via the mount option mblk_io_submit, so we can test and fix the new page I/O code. To reproduce the problem, install postgres 8.4 or 9.0, and pin enough memory such that the system just at the end of triggering writeback before running the following sql script: begin; create temporary table foo as select x as a, ARRAY[x] as b FROM generate_series(1, 10000000 ) AS x; create index foo_a_idx on foo (a); create index foo_b_idx on foo USING GIN (b); rollback; If the temporary table is created on a hard drive partition which is encrypted using dm_crypt, then under memory pressure, approximately 30-40% of the time, pgsql will issue the above failure. This patch should fix this problem, and the problem will come back if the file system is mounted with the mblk_io_submit mount option. Reported-by: Jon Nelson <jnelson@jamponi.net> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
| * | | xen: Provide a variant of __RING_SIZE() that is an integer constant expressionJeremy Fitzhardinge2010-12-153-5/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Without this, gcc 4.5 won't compile xen-netfront and xen-blkfront, where this is being used to specify array sizes. Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Cc: Jens Axboe <axboe@kernel.dk> Cc: David Miller <davem@davemloft.net> Cc: Stable Kernel <stable@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
| * | | MAINTAINERS: update MSM git treeDaniel Walker2010-12-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The MSM main git tree has changed over to this new address. Signed-off-by: Daniel Walker <dwalker@codeaurora.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
| * | | install_special_mapping skips security_file_mmap check.Tavis Ormandy2010-12-152-4/+17
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The install_special_mapping routine (used, for example, to setup the vdso) skips the security check before insert_vm_struct, allowing a local attacker to bypass the mmap_min_addr security restriction by limiting the available pages for special mappings. bprm_mm_init() also skips the check, and although I don't think this can be used to bypass any restrictions, I don't see any reason not to have the security check. $ uname -m x86_64 $ cat /proc/sys/vm/mmap_min_addr 65536 $ cat install_special_mapping.s section .bss resb BSS_SIZE section .text global _start _start: mov eax, __NR_pause int 0x80 $ nasm -D__NR_pause=29 -DBSS_SIZE=0xfffed000 -f elf -o install_special_mapping.o install_special_mapping.s $ ld -m elf_i386 -Ttext=0x10000 -Tbss=0x11000 -o install_special_mapping install_special_mapping.o $ ./install_special_mapping & [1] 14303 $ cat /proc/14303/maps 0000f000-00010000 r-xp 00000000 00:00 0 [vdso] 00010000-00011000 r-xp 00001000 00:19 2453665 /home/taviso/install_special_mapping 00011000-ffffe000 rwxp 00000000 00:00 0 [stack] It's worth noting that Red Hat are shipping with mmap_min_addr set to 4096. Signed-off-by: Tavis Ormandy <taviso@google.com> Acked-by: Kees Cook <kees@ubuntu.com> Acked-by: Robert Swiecki <swiecki@google.com> [ Changed to not drop the error code - akpm ] Reviewed-by: James Morris <jmorris@namei.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
| * | Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wqLinus Torvalds2010-12-142-3/+13
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq: workqueue: It is likely that WORKER_NOT_RUNNING is true MAINTAINERS: Add workqueue entry workqueue: check the allocation of system_unbound_wq
| | * | workqueue: It is likely that WORKER_NOT_RUNNING is trueSteven Rostedt2010-12-141-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Running the annotate branch profiler on three boxes, including my main box that runs firefox, evolution, xchat, and is part of the distcc farm, showed this with the likelys in the workqueue code: correct incorrect % Function File Line ------- --------- - -------- ---- ---- 96 996253 99 wq_worker_sleeping workqueue.c 703 96 996247 99 wq_worker_waking_up workqueue.c 677 The likely()s in this case were assuming that WORKER_NOT_RUNNING will most likely be false. But this is not the case. The reason is (and shown by adding trace_printks and testing it) that most of the time WORKER_PREP is set. In worker_thread() we have: worker_clr_flags(worker, WORKER_PREP); [ do work stuff ] worker_set_flags(worker, WORKER_PREP, false); (that 'false' means not to wake up an idle worker) The wq_worker_sleeping() is called from schedule when a worker thread is putting itself to sleep. Which happens most of the time outside of that [ do work stuff ]. The wq_worker_waking_up is called by the wakeup worker code, which is also callod outside that [ do work stuff ]. Thus, the likely and unlikely used by those two functions are actually backwards. Remove the annotation and let gcc figure it out. Acked-by: Tejun Heo <tj@kernel.org> Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Tejun Heo <tj@kernel.org>
| | * | MAINTAINERS: Add workqueue entryTejun Heo2010-12-141-0/+9
| | | | | | | | | | | | | | | | Signed-off-by: Tejun Heo <tj@kernel.org>
| | * | workqueue: check the allocation of system_unbound_wqHitoshi Mitake2010-11-261-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I found a trivial bug on initialization of workqueue. Current init_workqueues doesn't check the result of allocation of system_unbound_wq, this should be checked like other queues. Signed-off-by: Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: David Howells <dhowells@redhat.com> Signed-off-by: Tejun Heo <tj@kernel.org>
| * | | Merge branch 'for-linus' of git://neil.brown.name/mdLinus Torvalds2010-12-142-20/+21
| |\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 'for-linus' of git://neil.brown.name/md: md: protect against NULL reference when waiting to start a raid10. md: fix bug with re-adding of partially recovered device. md: fix possible deadlock in handling flush requests. md: move code in to submit_flushes. md: remove handling of flush_pending in md_submit_flush_data
| | * | | md: protect against NULL reference when waiting to start a raid10.NeilBrown2010-12-092-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we fail to start a raid10 for some reason, we call md_unregister_thread to kill the thread that was created. Unfortunately md_thread() will then make one call into the handler (raid10d) even though md_wakeup_thread has not been called. This is not safe and as md_unregister_thread is called after mddev->private has been set to NULL, it will definitely cause a NULL dereference. So fix this at both ends: - md_thread should only call the handler if THREAD_WAKEUP has been set. - raid10 should call md_unregister_thread before setting things to NULL just like all the other raid modules do. This is applicable to 2.6.35 and later. Cc: stable@kernel.org Reported-by: "Citizen" <citizen_lee@thecus.com> Signed-off-by: NeilBrown <neilb@suse.de>
| | * | | md: fix bug with re-adding of partially recovered device.NeilBrown2010-12-091-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With v0.90 metadata, a hot-spare does not become a full member of the array until recovery is complete. So if we re-add such a device to the array, we know that all of it is as up-to-date as the event count would suggest, and so it a bitmap-based recovery is possible. However with v1.x metadata, the hot-spare immediately becomes a full member of the array, but it record how much of the device has been recovered. If the array is stopped and re-assembled recovery starts from this point. When such a device is hot-added to an array we currently lose the 'how much is recovered' information and incorrectly included it as a full in-sync member (after bitmap-based fixup). This is wrong and unsafe and could corrupt data. So be more careful about setting saved_raid_disk - which is what guides the re-adding of devices back into an array. The new code matches the code in slot_store which does a similar thing, which is encouraging. This is suitable for any -stable kernel. Reported-by: "Dailey, Nate" <Nate.Dailey@stratus.com> Cc: stable@kernel.org Signed-off-by: NeilBrown <neilb@suse.de>
| | * | | md: fix possible deadlock in handling flush requests.NeilBrown2010-12-091-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As recorded in https://bugzilla.kernel.org/show_bug.cgi?id=24012 it is possible for a flush request through md to hang. This is due to an interaction between the recursion avoidance in generic_make_request, the insistence in md of only having one flush active at a time, and the possibility of dm (or md) submitting two flush requests to a device from the one generic_make_request. If a generic_make_request call into dm causes two flush requests to be queued (as happens if the dm table has two targets - they get one each), these two will be queued inside generic_make_request. Assume they are for the same md device. The first is processed and causes 1 or more flush requests to be sent to lower devices. These get queued within generic_make_request too. Then the second flush to the md device gets handled and it blocks waiting for the first flush to complete. But it won't complete until the two lower-device requests complete, and they haven't even been submitted yet as they are on the generic_make_request queue. The deadlock can be broken by using a separate thread to submit the requests to lower devices. md has such a thread readily available: md_wq. So use it to submit these requests. Reported-by: Giacomo Catenazzi <cate@cateee.net> Tested-by: Giacomo Catenazzi <cate@cateee.net> Signed-off-by: NeilBrown <neilb@suse.de>
| | * | | md: move code in to submit_flushes.NeilBrown2010-12-091-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | submit_flushes is called from exactly one place. Move the code that is before and after that call into submit_flushes. This has not functional change, but will make the next patch smaller and easier to follow. Signed-off-by: NeilBrown <neilb@suse.de>
| | * | | md: remove handling of flush_pending in md_submit_flush_dataNeilBrown2010-12-091-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | None of the functions called between setting flush_pending to 1, and atomic_dec_and_test can change flush_pending, or will anything running in any other thread (as ->flush_bio is not NULL). So the atomic_dec_and_test will always succeed. So remove the atomic_sec and the atomic_dec_and_test. Signed-off-by: NeilBrown <neilb@suse.de>
| * | | | dw_spi: Fix missing final read in some polling situationsMajor Lee2010-12-141-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is a possibility that the last word of a transaction will be lost if data is not ready. Re-read in poll_transfer() to solve this issue when poll_mode is enabled. Verified on SPI touch screen device. Signed-off-by: Major Lee <major_lee@wistron.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
| * | | | i2c_intel_mid: Fix slash in sysfs nameAlan Cox2010-12-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This gets caught by the new sanity check code. Instead of the slash use a different symbol. This was originally found by Major Lee who proposed a rather more complex patch which changed the name according to the chip type. On the basis that we are in a late -rc and making Linus grumpy isn't always a good idea (however fun) this is a simple alternative. Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
| * | | | Merge branch 'sh-fixes-for-linus' of ↵Linus Torvalds2010-12-143-2/+5
| |\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6 * 'sh-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6: sh: wire up accept4 syscall (non-multiplexed path) sh: Enable deprecated IRQ chip APIs for MFD and GPIOLIB drivers.
| | * | | | sh: wire up accept4 syscall (non-multiplexed path)Carmelo AMOROSO2010-12-142-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Carmelo Amoroso <carmelo.amoroso@st.com> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
| | * | | | sh: Enable deprecated IRQ chip APIs for MFD and GPIOLIB drivers.Paul Mundt2010-12-131-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are still quite a number of MFD and GPIO expander drivers that are using the old irq_chip APIs that haven't had a chance to update during the .37 cycle, resulting in allyes/modconfig errors on some configurations. Mark Brown has done most of the legwork to get these fixed up in .38, so this should just be a .37 stop-gap that we can drop at the end of the .38 merge window. Reported-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
| * | | | | Merge branch 'omap-fixes-for-linus' of ↵Linus Torvalds2010-12-149-37/+79
| |\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6 * 'omap-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6: OMAP2: PRCM: fix some SHIFT macros that were actually bitmasks OMAP2+: PM/serial: fix console semaphore acquire during suspend OMAP1: SRAM: fix size for OMAP1611 SoCs arm: omap2: io: fix clk_get() error check arm: plat-omap: counter_32k: use IS_ERR() instead of NULL check omap: nand: remove hardware ECC as default omap: zoom: wl1271 slot is MMC_CAP_POWER_OFF_CARD omap: PM debug: fix wake-on-timer debugfs dependency
| | * | | | | OMAP2: PRCM: fix some SHIFT macros that were actually bitmasksPaul Walmsley2010-12-101-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After Charu's GPIO hwmod patches, GPIO initialization on N800 emits the following messages for all GPIO banks: omap_hwmod: gpio1: cannot be enabled (3) This is due to OMAP24XX_ST_GPIOS_SHIFT being defined as a bitmask. Fix this and also fix two other macros that had the same problem. Thanks to Tony Lindgren <tony@atomide.com> for originally reporting this bug. Signed-off-by: Paul Walmsley <paul@pwsan.com Cc: Charulatha Varadarajan <charu@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
| | * | | | | OMAP2+: PM/serial: fix console semaphore acquire during suspendKevin Hilman2010-12-092-10/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 0d8e2d0dad98a693bad88aea6876ac8b94ad95c6 (OMAP2+: PM/serial: hold console semaphore while OMAP UARTs are disabled) added use of the console semaphore to protect UARTs from being accessed after disabled during idle, but this causes problems in suspend. During suspend, the console semaphore is acquired by the console suspend method (console_suspend()) so the try_acquire_console_sem() will always fail and suspend will be aborted. To fix, introduce a check so the console semaphore is only attempted during idle, and not during suspend. Also use the same check so that the console semaphore is not prematurely released during resume. Thanks to Paul Walmsley for suggesting adding the same check during resume. Cc: Paul Walmsley <paul@pwsan.com> Tested-by: Jean Pihet <j-pihet@ti.com> Tested-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
| | * | | | | OMAP1: SRAM: fix size for OMAP1611 SoCsKevin Hilman2010-12-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Kernel was failing to boot on omap1611 based OSK boards due to mis-configured SRAM size. Existing code was using a hard-coded value for 250k, which was then rounded down by PAGE_SIZE. Increasing this to 256k allows kernel to boot on omap1611 SoCs. Problem reported by and initial fix suggested by Tim Bird. Thanks to Tony Lindgren for helping diagnose the problem to being specific to OMAP1611 and not affecting OMAP1610/OMAP1623. Reported-by: Tim Bird <tim.bird@am.sony.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
| | * | | | | arm: omap2: io: fix clk_get() error checkAaro Koskinen2010-12-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | clk_get() return value should be checked with IS_ERR(). Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
| | * | | | | arm: plat-omap: counter_32k: use IS_ERR() instead of NULL checkVasiliy Kulikov2010-12-061-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | clk_get() returns ERR_PTR() on error, not NULL. Signed-off-by: Vasiliy Kulikov <segoon@openwall.com> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> [tony@atomide.com: updated to include err.h to compile on omap1] Signed-off-by: Tony Lindgren <tony@atomide.com>
OpenPOWER on IntegriCloud