linux-toradex.git/drivers/char/efirtc.c, branch v3.2.6 Linux kernel for Apalis and Colibri modules efirtc: explicitly set llseek to no_llseek 2009-12-16T15:19:59+00:00 John Kacur jkacur@redhat.com 2009-12-16T00:46:06+00:00 f29627c2a3df5732af84bc217df26d1c311f5112 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> 
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>
rtc: Remove BKL from efirtc 2009-10-14T15:36:51+00:00 Thomas Gleixner tglx@linutronix.de 2009-10-10T13:14:03+00:00 a5ee6dc9ebe8fc2640ee3fbf2c340bd853e2fd36 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> 
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>
drivers/char/efirtc.c: removed duplicated #include 2008-08-04T23:59:56+00:00 Huang Weiyi weiyi.huang@gmail.com 2008-08-02T13:10:23+00:00 c2d5cedadcd3976cfc1fa5590e3a73a059c6401a 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> 
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>
efirtc: push down the BKL 2008-07-25T17:53:43+00:00 Alan Cox alan@lxorguk.ukuu.org.uk 2008-07-25T08:48:12+00:00 76528a42e2c5199a1208909318a9c9948d25d0b7 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> 
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>
efirtc: BKL pushdown 2008-06-20T20:05:56+00:00 Arnd Bergmann arnd@arndb.de 2008-05-20T17:15:52+00:00 89c7de08c5fc059c4f6231571416d9bc0bbc91d4 Signed-off-by: Arnd Bergmann <arnd@arndb.de> 
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
drivers/char/: Spelling fixes 2008-02-03T15:11:42+00:00 Joe Perches joe@perches.com 2008-02-03T15:11:42+00:00 8dfba4d71b77bca83a6f9943fc8e53439310cffd Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Adrian Bunk <bunk@kernel.org> 
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
[PATCH] make more file_operation structs static 2006-07-03T22:26:59+00:00 Arjan van de Ven arjan@infradead.org 2006-07-03T07:24:21+00:00 62322d2554d2f9680c8ace7bbf1f97d8fa84ad1a 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> 
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>
Linux-2.6.12-rc2 2005-04-16T22:20:36+00:00 Linus Torvalds torvalds@ppc970.osdl.org 2005-04-16T22:20:36+00:00 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 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! 
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!