This patch adds profiling support to the sparc architecture. It is a
copy of the sparc64 implementation.
Signed-off-by: NMartin Habets <errandir_news@mph.eclipse.co.uk>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

- remove __{,test_and_}{set,clear,change}_bit() and test_bit()
- remove ffz()
- remove __ffs()
- remove sched_find_first_bit()
- remove ffs()
- remove generic_fls()
- remove generic_fls64()
- remove generic_hweight{32,16,8}()
- remove find_{next,first}{,_zero}_bit()
- remove ext2_{set,clear,test,find_first_zero,find_next_zero}_bit()
- remove ext2_{set,clear}_bit_atomic()
- remove minix_{test,set,test_and_clear,test,find_first_zero}_bit()
Signed-off-by: NAkinobu Mita <mita@miraclelinux.com>
Cc: William Lee Irwin III <wli@holomorphy.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Todo items:
 - IRQ_INPROGRESS flag - use sparc64 irq buckets, or generic irq_desc?
 - sun4d
 - re-indent large chunks of sun4m_smp.c
 - some places assume sequential cpu numbering (i.e. 0,1 instead of 0,2)

Last I checked (with 2.6.14), random programs segfault with dual
HyperSPARC.  And with SuperSPARC II's, it seems stable but will
eventually die from a write lock error (wrong lock owner or something).

I haven't tried the HyperSPARC + highmem combination recently, so that
may still be a problem.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Configurable 16-bit UID and friends support

This allows turning off the legacy 16 bit UID interfaces on embedded platforms.

   text    data     bss     dec     hex filename
3330172  529036  190556 4049764  3dcb64 vmlinux-baseline
3328268  529040  190556 4047864  3dc3f8 vmlinux

From: Adrian Bunk <bunk@stusta.de>

    UID16 was accidentially disabled for !EMBEDDED.
Signed-off-by: NMatt Mackall <mpm@selenic.com>
Signed-off-by: NAdrian Bunk <bunk@stusta.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Introduce a Kconfig symbol SPARC that is defined on both the sparc and
sparc64 architectures.

This symbol makes some dependencies more readable.
Signed-off-by: NAdrian Bunk <bunk@stusta.de>
Signed-off-by: NDavid 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: NLars Kotthoff <metalhead@metalhead.ws>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Breakage noted by Al Viro.

It breaks non-PCI builds, it's probably better to have a more
direct implementation on sparc32, and which driver actually
needs this is still questionable.

We can resolve this in 2.6.15
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This helps some PCI stuff build.
Signed-off-by: NTom 'spot' Callaway <tcallawa@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Remove some duplicated items due to the inclusion of the general
drivers/Kconfig file. These are now taken from drivers/char/Kconfig,
and can be turned off there as well (which is desirable sometimes).
Signed-off-by: NMartin Habets <errandir_news@mph.eclipse.co.uk>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Sanitized and fixed floppy dependencies: split the messy dependencies for
BLK_DEV_FD by introducing a new symbol (ARCH_MAY_HAVE_PC_FDC), making
BLK_DEV_FD depend on that one and taking declarations of ARCH_MAY_HAVE_PC_FDC
to arch/*/Kconfig.  While we are at it, fixed several obvious cases when
BLK_DEV_FD should have been excluded (architectures lacking asm/floppy.h
are *not* going to have floppy.c compile, let alone work).

If you can come up with better name for that ("this architecture might
have working PC-compatible floppy disk controller"), you are more than
welcome - just s/ARCH_MAY_HAVE_PC_FDC/your_prefered_name/g in the patch
below...
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Create a new top-level menu named "Networking" thus moving
net related options and protocol selection way from the drivers
menu and up on the top-level where they belong.

To implement this all architectures has to source "net/Kconfig" before
drivers/*/Kconfig in their Kconfig file. This change has been
implemented for all architectures.

Device drivers for ordinary NIC's are still to be found
in the Device Drivers section, but Bluetooth, IrDA and ax25
are located with their corresponding menu entries under the new
networking menu item.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Something reverted most of the arch/sparc/Kconfig changes, leaving
arch/sparc/ unconfigurable.  This patch re-removes the parts made redundant
by drivers/Kconfig in addition to a mysterious, spurious second instance of
source "mm/Kconfig".  cvs strikes again?
Signed-off-by: NWilliam Irwin <wli@holomorphy.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Kconfig is spitting out massive numbers of errors and so on.  This patch
switches arch/sparc/Kconfig to use drivers/Kconfig so those stop.
Signed-off-by: NWilliam Irwin <wli@holomorphy.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

For all architectures, this just means that you'll see a "Memory Model"
choice in your architecture menu.  For those that implement DISCONTIGMEM,
you may eventually want to make your ARCH_DISCONTIGMEM_ENABLE a "def_bool
y" and make your users select DISCONTIGMEM right out of the new choice
menu.  The only disadvantage might be if you have some specific things that
you need in your help option to explain something about DISCONTIGMEM.
Signed-off-by: NDave Hansen <haveblue@us.ibm.com>
Signed-off-by: NAdrian Bunk <bunk@stusta.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

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!