linux.git/arch/sparc/kernel/Makefile, branch v2.6.26 Linux kernel source tree sparc: Add kgdb support. 2008-04-29T09:38:50+00:00 David S. Miller davem@davemloft.net 2008-04-29T09:38:50+00:00 e2fdd7fd99dd68b77caaf2a2272b75b5da890de7 Current limitations: 1) On SMP single stepping has some fundamental issues, shared with other sw single-step architectures such as mips and arm. 2) On 32-bit sparc we don't support SMP kgdb yet. That requires some reworking of the IPI mechanisms and infrastructure on that platform. Signed-off-by: David S. Miller <davem@davemloft.net> 
Current limitations:

1) On SMP single stepping has some fundamental issues,
   shared with other sw single-step architectures such
   as mips and arm.

2) On 32-bit sparc we don't support SMP kgdb yet.  That
   requires some reworking of the IPI mechanisms and
   infrastructure on that platform.

Signed-off-by: David S. Miller <davem@davemloft.net>
[SPARC]: Remove SunOS and Solaris binary support. 2008-04-21T22:10:15+00:00 David S. Miller davem@davemloft.net 2008-04-20T09:14:23+00:00 ec98c6b9b47df6df1c1fa6cf3d427414f8c2cf16 As per Documentation/feature-removal-schedule.txt Signed-off-by: David S. Miller <davem@davemloft.net> 
As per Documentation/feature-removal-schedule.txt

Signed-off-by: David S. Miller <davem@davemloft.net>
Generic semaphore implementation 2008-04-17T14:42:34+00:00 Matthew Wilcox matthew@wil.cx 2008-03-08T02:55:58+00:00 64ac24e738823161693bf791f87adc802cf529ff Semaphores are no longer performance-critical, so a generic C implementation is better for maintainability, debuggability and extensibility. Thanks to Peter Zijlstra for fixing the lockdep warning. Thanks to Harvey Harrison for pointing out that the unlikely() was unnecessary. Signed-off-by: Matthew Wilcox <willy@linux.intel.com> Acked-by: Ingo Molnar <mingo@elte.hu> 
Semaphores are no longer performance-critical, so a generic C
implementation is better for maintainability, debuggability and
extensibility.  Thanks to Peter Zijlstra for fixing the lockdep
warning.  Thanks to Harvey Harrison for pointing out that the
unlikely() was unnecessary.

Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
Acked-by: Ingo Molnar <mingo@elte.hu>
[SPARC]: Fix link errors with gcc-4.3 2008-03-03T23:01:05+00:00 David S. Miller davem@davemloft.net 2008-03-03T23:01:05+00:00 f0e98c387e61de00646be31fab4c2fa0224e1efb Reported by Adrian Bunk. Just like in changeset a3f9985843b674cbcb58f39fab8416675e7ab842 ("[SPARC64]: Move kernel unaligned trap handlers into assembler file.") we have to move the assembler bits into a seperate asm file because as far as the compiler is concerned these inline bits we're doing in unaligned.c are unreachable. Signed-off-by: David S. Miller <davem@davemloft.net> 
Reported by Adrian Bunk.

Just like in changeset a3f9985843b674cbcb58f39fab8416675e7ab842
("[SPARC64]: Move kernel unaligned trap handlers into assembler
file.") we have to move the assembler bits into a seperate
asm file because as far as the compiler is concerned
these inline bits we're doing in unaligned.c are unreachable.

Signed-off-by: David S. Miller <davem@davemloft.net>
[PATCH] sort the devres mess out 2007-02-11T19:18:07+00:00 Al Viro viro@ftp.linux.org.uk 2007-02-11T15:41:31+00:00 5ea8176994003483a18c8fed580901e2125f8a83 * Split the implementation-agnostic stuff in separate files. * Make sure that targets using non-default request_irq() pull kernel/irq/devres.o * Introduce new symbols (HAS_IOPORT and HAS_IOMEM) defaulting to positive; allow architectures to turn them off (we needed these symbols anyway for dependencies of quite a few drivers). * protect the ioport-related parts of lib/devres.o with CONFIG_HAS_IOPORT. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
* Split the implementation-agnostic stuff in separate files.
* Make sure that targets using non-default request_irq() pull
  kernel/irq/devres.o
* Introduce new symbols (HAS_IOPORT and HAS_IOMEM) defaulting to positive;
  allow architectures to turn them off (we needed these symbols anyway for
  dependencies of quite a few drivers).
* protect the ioport-related parts of lib/devres.o with CONFIG_HAS_IOPORT.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[SPARC]: Port of_device layer and make ebus use it. 2006-06-24T06:15:47+00:00 David S. Miller davem@sunset.davemloft.net 2006-06-23T22:55:17+00:00 fd5314311634245172d40ccb418d89dac91d6ad6 Signed-off-by: David S. Miller <davem@davemloft.net> 
Signed-off-by: David S. Miller <davem@davemloft.net>
[SPARC]: Port sparc64 in-kernel device tree code to sparc32. 2006-06-24T06:15:45+00:00 David S. Miller davem@sunset.davemloft.net 2006-06-23T22:53:31+00:00 942a6bdd1c4d2419a42be77ba1c964e4ba8dae9e Signed-off-by: David S. Miller <davem@davemloft.net> 
Signed-off-by: David S. Miller <davem@davemloft.net>
[SPARC]: Add sun4m LED driver. 2005-11-07T22:08:04+00:00 Lars Kotthoff metalhead@metalhead.ws 2005-11-07T22:08:04+00:00 ee1858d3122dedd2e82a61b6ab56b229aefd9447 This is a forward port of a 2.4.x sun4m LED driver written by Lars Kotthoff. Signed-off-by: Lars Kotthoff <metalhead@metalhead.ws> Signed-off-by: David S. Miller <davem@davemloft.net> 
This is a forward port of a 2.4.x sun4m LED driver written by Lars
Kotthoff.

Signed-off-by: Lars Kotthoff <metalhead@metalhead.ws>
Signed-off-by: David S. Miller <davem@davemloft.net>
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!