2
0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-12-25 13:43:55 +08:00
Commit Graph

11 Commits

Author SHA1 Message Date
Al Viro
2e7718cf7f rtc: single_open() leaks
Cc: stable@vger.kernel.org
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-05-05 00:12:29 -04:00
David Howells
788416bcee efirtc: Don't use create_proc_read_entry()
Don't use create_proc_read_entry() as that is deprecated, but rather use
proc_create_data() and seq_file instead.

Signed-off-by: David Howells <dhowells@redhat.com>
cc: Arnd Bergmann <arnd@arndb.de>
cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-04-29 15:41:55 -04:00
David Howells
9ffc93f203 Remove all #inclusions of asm/system.h
Remove all #inclusions of asm/system.h preparatory to splitting and killing
it.  Performed with the following command:

perl -p -i -e 's!^#\s*include\s*<asm/system[.]h>.*\n!!' `grep -Irl '^#\s*include\s*<asm/system[.]h>' *`

Signed-off-by: David Howells <dhowells@redhat.com>
2012-03-28 18:30:03 +01:00
John Kacur
f29627c2a3 efirtc: explicitly set llseek to no_llseek
Now that we've removed the BKL here, let's explicitly set llseek to
no_llseek since the default llseek is not used here.

The default_llseek function still contains the BKL.  When we are auditing
code to see if we can remove the BKL, this is one of the hidden
considerations we need to take into account.  i.e., is there
syncronization between code that has the BKL and llseek.

At the same time we remove the BKL it would be a good idea to do indicate
when no llseek function is required, so we don't have to revisit this code
again, when we are trying to determine if we can remove the BKL from the
default_llseek.

Signed-off-by: John Kacur <jkacur@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-12-16 07:19:59 -08:00
Thomas Gleixner
a5ee6dc9eb rtc: Remove BKL from efirtc
BKL locking came to efirtc via the big BKL push down, but the access
to the efi functions is protected by efi_rtc_lock already.

Remove it.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
LKML-Reference: <20091010153350.046644063@linutronix.de>
2009-10-14 17:36:51 +02:00
Huang Weiyi
c2d5cedadc drivers/char/efirtc.c: removed duplicated #include
Removed duplicated include <linux/smp_lock.h> in
drivers/char/efirtc.c.

Signed-off-by: Huang Weiyi <weiyi.huang@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-08-04 16:59:56 -07:00
Alan Cox
76528a42e2 efirtc: push down the BKL
Push it down as far as the EFI method calls.  Someone who knows EFI can do
the other bits.  Also fix another wrong unknown ioctl return.

Signed-off-by: Alan Cox <alan@redhat.com>
Cc: Joe Perches <joe@perches.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-07-25 10:53:43 -07:00
Arnd Bergmann
89c7de08c5 efirtc: BKL pushdown
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2008-06-20 14:05:56 -06:00
Joe Perches
8dfba4d71b drivers/char/: Spelling fixes
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
2008-02-03 17:11:42 +02:00
Arjan van de Ven
62322d2554 [PATCH] make more file_operation structs static
Mark the static struct file_operations in drivers/char as const.  Making
them const prevents accidental bugs, and moves them to the .rodata section
so that they no longer do any false sharing; in addition with the proper
debug option they are then protected against corruption..

[akpm@osdl.org: build fix]
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-07-03 15:26:59 -07:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
2005-04-16 15:20:36 -07:00