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: NMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

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: NMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

Puts the content of arch/Kconfig in the "General setup" menu.

Linus:

> Should it come with a re-duplication of it's content into each
> architecture, which was the case previously ? The oprofile and kprobes
> menu entries were litteraly cut and pasted from one architecture to
> another. Should we put its content in init/Kconfig then ?

I don't think it's a good idea to go back to making it per-architecture,
although that extensive "depends on <list-of-archiectures-here>" might
indicate that there certainly is room for cleanup there.

And I don't think it's wrong keeping it in kernel/Kconfig.xyz per se, I
just think it's wrong to (a) lump the code together when it really doesn't
necessarily need to and (b) show it to users as some kind of choice that
is tied together (whether it then has common code or not).

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...

Sam Ravnborg:

Stuff it into a new file: arch/Kconfig
We can then extend this file to include all the 'trailing'
Kconfig things that are anyway equal for all ARCHs.

But it should be kept clean - so if we introduce such a file
then we should use ARCH_HAS_whatever in the arch specific Kconfig
files to enable stuff that is not shared.

[...]

The above suggestion is actually not exactly the best way to do it...
First the naming..
A quick grep shows following usage today (in Kconfig files)
ARCH_HAS        51
ARCH_SUPPORTS   4
HAVE_ARCH       7

ARCH_HAS is the clear winner.

In the common Kconfig file do:

config FOO
        depends on ARCH_HAS_FOO
        bool "bla bla"

config ARCH_HAS_FOO
        def_bool n

In the arch specific Kconfig file in a suitable place do:

config SUITABLE_OPTION
        select ARCH_HAS_FOO

The naming of ARCH_HAS_ is fixed and shall be:
ARCH_HAS_<config option it will enable>

Only a single line added pr. architecture.
And we will end up with a (maybe even commented) list of trivial selects.

- Yet another update :

Moving to HAVE_* now.
Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

The conflicting commit for
move-kconfiginstrumentation-to-arch-kconfig-and-init-kconfig.patch
is the ARM fix from Linus :

commit 38ad9aeb

He just seemed to agree that my approach (just putting the missing ARM
config options in arch/arm/Kconfig) works too. The main advantage it has
is that it is smaller, does not need a cleanup in the future and does
not break the following patches unnecessarily.

It's just been discussed here

http://lkml.org/lkml/2008/1/15/267

However, Linus might prefer to stay with his own patch and I would
totally understand it that late in the release cycle. Therefore I submit
this for the next release cycle.
Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
CC: Russell King <rmk+lkml@arm.linux.org.uk>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

We have had warnings for a long time about select of unknow symbol
but the warnings does not really makes sense since we may
select a symbol that is relevant and defined in one
arch but not in another arch.
And as long as we do not use a common set of Kconfig files
for all archs lets just ignore this case.

Previously we have used this to find bad uses of
select but we need a more relaible method to do so.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Cc: Roman Zippel <zippel@linux-m68k.org>

Michal Zachar <mgzachar@mail.t-com.sk> reported that
menuconfig did not save the new config when loading
an alternate config unless he altered it manually.

Mark config as changed upon load of alternate config fixed this.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Roman Zippel <zippel@linux-m68k.org>

Including additional fixes from Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NGeert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

Commit 312b1485 made __INIT_REFOK expand
into .section .section ".ref.text", "ax".  Since the assembler doesn't
tolerate stuttering in the source that broke all MIPS builds.

Since with this change Sam downgraded __INIT_REFOK to just a backward
compat thing and there being only a single use in the MIPS arch code the
best solution is to delete both of __INIT_REFOK and __INITDATA_REFOK (which
was equally broken) being unused anyway these can be deleted.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

We have too many section mismatches detected at the moment.
So silence modpost and prevent the option from being
set in a typical allyesconfig build.

Tell the user how to see all the deteils in the summary
message from modpost.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

* git://git.kernel.org/pub/scm/linux/kernel/git/bart/ide-2.6: (95 commits)
  ide-tape: remove idetape_config_t typedef
  ide-tape: remove mtio.h related comments
  ide-tape: make function name more accurate
  ide-tape: remove unused sense packet commands.
  ide-tape: use generic byteorder macros
  ide-tape: remove EXPERIMENTAL driver status
  ide-tape: use generic scsi commands
  ide-tape: remove struct idetape_block_size_page_t
  ide-tape: remove structs os_partition_t, os_dat_entry_t, os_dat_t
  ide-tape: remove struct idetape_parameter_block_descriptor_t
  ide-tape: remove struct idetape_medium_partition_page_t
  ide-tape: remove struct idetape_data_compression_page_t
  ide-tape: remove struct idetape_inquiry_result_t
  ide-tape: remove struct idetape_capabilities_page_t
  ide-tape: remove IDETAPE_DEBUG_BUGS
  ide-tape: remove IDETAPE_DEBUG_INFO
  ide-tape: dump gcw fields on error in idetape_identify_device()
  ide-tape: remove struct idetape_mode_parameter_header_t
  ide-tape: remove struct idetape_request_sense_result_t
  ide-tape: remove dead code
  ...

Frederik Himpe reported an unkillable and un-straceable pan process.

Zero length iovecs can go into an infinite loop in writev, because the
iovec iterator does not always advance over them.

The sequence required to trigger this is not trivial. I think it
requires that a zero-length iovec be followed by a non-zero-length iovec
which causes a pagefault in the atomic usercopy. This causes the writev
code to drop back into single-segment copy mode, which then tries to
copy the 0 bytes of the zero-length iovec; a zero length copy looks like
a failure though, so it loops.

Put a test into iov_iter_advance to catch zero-length iovecs. We could
just put the test in the fallback path, but I feel it is more robust to
skip over zero-length iovecs throughout the code (iovec iterator may be
used in filesystems too, so it should be robust).
Signed-off-by: NNick Piggin <npiggin@suse.de>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6:
  ieee1394: sbp2: fix bogus s/g access change

Since this is used only in idetape_blkdev_ioctl(), remove the typedef and make
the struct function-local.

Bart:
- s/sizeof(struct idetape_config)/sizeof(config)/
Signed-off-by: NBorislav Petkov <bbpetkov@yahoo.de>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

Those are already in mtio.h.

Bart:
- undo 'unsigned int/unsigned long' -> 'uint/ulong' conversion
Signed-off-by: NBorislav Petkov <bbpetkov@yahoo.de>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

idetape_active_next_stage() was rather ambiguous wrt its purpose. Make that
more explicit and remove superfluous comment.
Signed-off-by: NBorislav Petkov <bbpetkov@yahoo.de>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

Signed-off-by: NBorislav Petkov <bbpetkov@yahoo.de>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

This is not a network driver.
Signed-off-by: NBorislav Petkov <bbpetkov@yahoo.de>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

ide-tape has depended on EXPERIMENTAL for ages. Change that since the driver is
being only maintained now.
Signed-off-by: NBorislav Petkov <bbpetkov@yahoo.de>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

Also, remove those which weren't used.
Signed-off-by: NBorislav Petkov <bbpetkov@yahoo.de>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

Signed-off-by: NBorislav Petkov <bbpetkov@yahoo.de>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

They seem just to sit there completely unused.
Signed-off-by: NBorislav Petkov <bbpetkov@yahoo.de>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

Also, shorten function name idetape_get_blocksize_from_block_descriptor() and
move its definition up thereby getting rid of its forward declaration.
Signed-off-by: NBorislav Petkov <bbpetkov@yahoo.de>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

There should be no functional changes resulting from this patch.
Signed-off-by: NBorislav Petkov <bbpetkov@yahoo.de>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

There should be no functional changes resulting from this patch.
Signed-off-by: NBorislav Petkov <bbpetkov@yahoo.de>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

There should be no functional changes resulting from this patch.
Signed-off-by: NBorislav Petkov <bbpetkov@yahoo.de>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

All those 2-byte values denoting the different capabilities are being written to
the local copy of the caps buffer without being converted to big endian for
simplicity of usage and shorter code later.  Also, we add some comments stating
which are the fields of the caps page in question in order to alleviate the
cryptic pointer casting exercises as in e.g. idetape_get_mode_sense_results().

There should be no functional changes resulting from this patch.

Bart:
- remove two needless "!!"
Signed-off-by: NBorislav Petkov <bbpetkov@yahoo.de>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

Signed-off-by: NBorislav Petkov <bbpetkov@yahoo.de>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

The device capabilities are probed for during device initialization so this
info is available through proc/ioctl() und it is redundant here.
Signed-off-by: NBorislav Petkov <bbpetkov@yahoo.de>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

Cc: Borislav Petkov <bbpetkov@yahoo.de>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

Bart:
- remove 'capabilities->speed' chunk
- re-add brackets to block_descrp assignment
Signed-off-by: NBorislav Petkov <bbpetkov@yahoo.de>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

Bart:
- remove unnecessary comment change
- remove two needless "!!"
Signed-off-by: NBorislav Petkov <bbpetkov@yahoo.de>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

Signed-off-by: NBorislav Petkov <bbpetkov@yahoo.de>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

Also, cleanup whitespace and update comments.

Bart:
- remove reference to drivers/block/ide.c
- move driver documentation to Documentation/ide/ide-tape.txt
Signed-off-by: NBorislav Petkov <bbpetkov@yahoo.de>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

No reason to use ide_init_hwif_ports() in ide-cs (as a nice side-effect
this makes ide-cs work on archs that don't define IDE_ARCH_OBSOLETE_INIT).
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

* Move check_dma_crc() to ide-dma.c and add inline version for
  CONFIG_BLK_DEV_IDEDMA=n case.

* Rename check_dma_crc() to ide_check_dma_crc().
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

While at it:

* Remove needless '!drive->crc_count' check.
Acked-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

Acked-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

Acked-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

Acked-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

Acked-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>