linux-toradex.git/arch/ppc/Kconfig, branch master

powerpc: Remove arch/ppc and include/asm-ppc

2008-06-10T11:40:22+00:00

All the maintained platforms are now in arch/powerpc, so the old
arch/ppc stuff can now go away.

Acked-by: Adrian Bunk 
Acked-by: Arnd Bergmann 
Acked-by: Becky Bruce 
Acked-by: Benjamin Herrenschmidt 
Acked-by: Geert Uytterhoeven 
Acked-by: Grant Likely 
Acked-by: Jochen Friedrich 
Acked-by: John Linn 
Acked-by: Jon Loeliger 
Acked-by: Josh Boyer 
Acked-by: Kumar Gala 
Acked-by: Olof Johansson 
Acked-by: Peter Korsgaard 
Acked-by: Scott Wood 
Acked-by: Sean MacLennan 
Acked-by: Segher Boessenkool 
Acked-by: Stefan Roese 
Acked-by: Stephen Neuendorffer 
Acked-by: Wolfgang Denk 
Signed-off-by: Paul Mackerras

[PPC] Remove mpc885ads and mpc86x ads boards from arch/ppc

2008-04-21T15:19:09+00:00

We have a board port in arch/powerpc so we dont need this one anymore.

Signed-off-by: Kumar Gala

[PPC] Remove mpc8272 ads board from arch/ppc

2008-04-21T15:19:09+00:00

We have a board port in arch/powerpc so we dont need this one anymore.

Signed-off-by: Kumar Gala

ide: introduce HAVE_IDE

2008-02-09T09:46:40+00:00

To allow flexible configuration of IDE introduce HAVE_IDE.
All archs except arm, um and s390 unconditionally select it.
For arm the actual configuration determine if IDE is supported.

This is a step towards introducing drivers/Kconfig for arm.

Signed-off-by: Sam Ravnborg 
Acked-by: Russell King - ARM Linux 
Acked-by: Bartlomiej Zolnierkiewicz

Move Kconfig.instrumentation to arch/Kconfig and init/Kconfig

2008-02-03T07:58:08+00:00

Move the instrumentation Kconfig to

arch/Kconfig for architecture dependent options
  - oprofile
  - kprobes

and

init/Kconfig for architecture independent options
  - profiling
  - markers

Remove the "Instrumentation Support" menu. Everything moves to "General setup".
Delete the kernel/Kconfig.instrumentation file.

Signed-off-by: Mathieu Desnoyers 
Cc: Linus Torvalds 
Cc: 
Signed-off-by: Sam Ravnborg

Add HAVE_KPROBES

2008-02-03T07:58:07+00:00

Linus:

On the per-architecture side, I do think it would be better to *not* have
internal architecture knowledge in a generic file, and as such a line like

        depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32

really shouldn't exist in a file like kernel/Kconfig.instrumentation.

It would be much better to do

        depends on ARCH_SUPPORTS_KPROBES

in that generic file, and then architectures that do support it would just
have a

        bool ARCH_SUPPORTS_KPROBES
                default y

in *their* architecture files. That would seem to be much more logical,
and is readable both for arch maintainers *and* for people who have no
clue - and don't care - about which architecture is supposed to support
which interface...

Changelog:

Actually, I know I gave this as the magic incantation, but now that I see
it, I realize that I should have told you to just use

        config KPROBES_SUPPORT
                def_bool y

instead, which is a bit denser.

We seem to use both kinds of syntax for these things, but this is really
what "def_bool" is there for...

- Use HAVE_KPROBES
- Use a select

- Yet another update :
Moving to HAVE_* now.

- Update ARM for kprobes support.

Signed-off-by: Mathieu Desnoyers 
Cc: Jeff Dike 
Cc: David Howells 
Cc: Ananth N Mavinakayanahalli 
Signed-off-by: Sam Ravnborg

Add HAVE_OPROFILE

2008-02-03T07:58:07+00:00

Linus:
On the per-architecture side, I do think it would be better to *not* have
internal architecture knowledge in a generic file, and as such a line like

        depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32

really shouldn't exist in a file like kernel/Kconfig.instrumentation.

It would be much better to do

        depends on ARCH_SUPPORTS_KPROBES

in that generic file, and then architectures that do support it would just
have a

        bool ARCH_SUPPORTS_KPROBES
                default y

in *their* architecture files. That would seem to be much more logical,
and is readable both for arch maintainers *and* for people who have no
clue - and don't care - about which architecture is supposed to support
which interface...

Changelog:

Actually, I know I gave this as the magic incantation, but now that I see
it, I realize that I should have told you to just use

        config ARCH_SUPPORTS_KPROBES
                def_bool y

instead, which is a bit denser.

We seem to use both kinds of syntax for these things, but this is really
what "def_bool" is there for...

Changelog :

- Moving to HAVE_*.
- Add AVR32 oprofile.

Signed-off-by: Mathieu Desnoyers 
Cc: Andrew Morton 
Cc: Haavard Skinnemoen 
Cc: David Howells 
Cc: Jeff Dike 
Cc: Ananth N Mavinakayanahalli 
Signed-off-by: Sam Ravnborg

[PPC] Remove 85xx from arch/ppc

2008-01-28T14:33:10+00:00

85xx exists in arch/powerpc as well as cuImage support to boot from
a u-boot that doesn't support device trees.

Signed-off-by: Kumar Gala

[PPC] Remove 83xx from arch/ppc

2008-01-28T14:33:09+00:00

83xx exists in arch/powerpc as well as cuImage support to boot from
a u-boot that doesn't support device trees.

Signed-off-by: Kumar Gala

Combine instrumentation menus in kernel/Kconfig.instrumentation

2007-10-19T18:53:54+00:00

Quoting Randy:

"It seems sad that this patch sources Kconfig.marker, a 7-line file,
20-something times.  Yes, you (we) don't want to put those 7 lines into
20-something different files, so sourcing is the right thing.

However, what you did for avr32 seems more on the right track to me: make
_one_ Instrumentation support menu that includes PROFILING, OPROFILE, KPROBES,
and MARKERS and then use (source) that in all of the arches."

Signed-off-by: Mathieu Desnoyers 
Acked-by: Randy Dunlap 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds