13 Mar, 2010

40 commits

  • All the architectures properly set NEED_DMA_MAP_STATE now so we can safely
    add linux/pci-dma.h to linux/pci.h and remove the linux/pci-dma.h
    inclusion in arch's asm/pci.h

    Signed-off-by: FUJITA Tomonori
    Acked-by: Arnd Bergmann
    Cc: Jesse Barnes
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    FUJITA Tomonori
     
  • Signed-off-by: FUJITA Tomonori
    Acked-by: Mikael Starvik
    Cc: Jesse Barnes
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    FUJITA Tomonori
     
  • Signed-off-by: FUJITA Tomonori
    Cc: Chris Zankel
    Cc: Jesse Barnes
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    FUJITA Tomonori
     
  • Signed-off-by: FUJITA Tomonori
    Acked-by: David S. Miller
    Cc: Jesse Barnes
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    FUJITA Tomonori
     
  • Signed-off-by: FUJITA Tomonori
    Acked-by: Paul Mundt
    Cc: Jesse Barnes
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    FUJITA Tomonori
     
  • Signed-off-by: FUJITA Tomonori
    Cc: Benjamin Herrenschmidt
    Cc: Jesse Barnes
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    FUJITA Tomonori
     
  • Signed-off-by: FUJITA Tomonori
    Acked-by: Kyle McMartin
    Cc: Helge Deller
    Cc: James Bottomley
    Cc: Jesse Barnes
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    FUJITA Tomonori
     
  • Signed-off-by: FUJITA Tomonori
    Cc: Ralf Baechle
    Cc: Jesse Barnes
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    FUJITA Tomonori
     
  • Signed-off-by: FUJITA Tomonori
    Cc: Tony Luck
    Cc: Jesse Barnes
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    FUJITA Tomonori
     
  • Signed-off-by: FUJITA Tomonori
    Acked-by: David Howells
    Cc: Jesse Barnes
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    FUJITA Tomonori
     
  • Signed-off-by: FUJITA Tomonori
    Acked-by: Russell King
    Cc: Jesse Barnes
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    FUJITA Tomonori
     
  • Signed-off-by: FUJITA Tomonori
    Cc: Richard Henderson
    Cc: Ivan Kokshaysky
    Acked-by: Matt Turner
    Cc: Jesse Barnes
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    FUJITA Tomonori
     
  • Signed-off-by: FUJITA Tomonori
    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Cc: "H. Peter Anvin"
    Cc: Jesse Barnes
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    FUJITA Tomonori
     
  • This patch adds include/linux/pci-dma.h that defines the pci_unmap state
    API:

    DECLARE_PCI_UNMAP_ADDR(ADDR_NAME)
    DECLARE_PCI_UNMAP_LEN(LEN_NAME)
    pci_unmap_addr(PTR, ADDR_NAME)
    pci_unmap_addr_set(PTR, ADDR_NAME, VAL)
    pci_unmap_len(PTR, LEN_NAME)
    pci_unmap_len_set(PTR, LEN_NAME, VAL)

    This enables us to remove lots of the duplication in architecture
    implementations since there are only two ways to define the API.

    If architectures define CONFIG_NEED_DMA_MAP_STATE, they get the real
    definition of pci_unmap state API. If not, they get the noop definition.

    In the long term, it's better to replace the API with the generic device
    model API such as DECLARE_DMA_UNMAP_ADDR. We can map the API to the
    generic one (like dma-mapping-compat.h does). This patch also makes the
    migration process easier. We can remove this file after the migration.

    It might be simpler to add the API to include/linux/pci.h but looks it's
    already too large. We'll remove pci-dma.h after finishing moving to the
    generic device model. So I put the API to a separate file.

    Signed-off-by: FUJITA Tomonori
    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Cc: "H. Peter Anvin"
    Cc: Richard Henderson
    Cc: Ivan Kokshaysky
    Cc: Matt Turner
    Acked-by: Russell King
    Acked-by: David Howells
    Cc: Tony Luck
    Cc: Ralf Baechle
    Cc: Kyle McMartin
    Cc: Helge Deller
    Cc: James Bottomley
    Cc: Benjamin Herrenschmidt
    Cc: Paul Mundt
    Cc: David S. Miller
    Cc: Chris Zankel
    Acked-by: Arnd Bergmann
    Cc: Jesse Barnes
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    FUJITA Tomonori
     
  • dma_sync_single_for_cpu/for_device supports a partial sync so there is no
    point to have dma_sync_single_range (also dma_sync_single was obsoleted
    long ago, replaced with dma_sync_single_for_cpu/for_device).

    There is no user of dma_sync_single_range() in mainline and only Alpha
    architecture supports dma_sync_single_range(). So it's unlikely that
    someone out of the tree uses it.

    Signed-off-by: FUJITA Tomonori
    Cc: Jeff Dike
    Acked-by: David S. Miller
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    FUJITA Tomonori
     
  • dma_sync_single_for_cpu/for_device supports a partial sync so there is no
    point to have dma_sync_single_range (also dma_sync_single was obsoleted
    long ago, replaced with dma_sync_single_for_cpu/for_device).

    There is no user of dma_sync_single_range() in mainline and only Alpha
    architecture supports dma_sync_single_range(). So it's unlikely that
    someone out of the tree uses it.

    Signed-off-by: FUJITA Tomonori
    Cc: Richard Henderson
    Cc: Ivan Kokshaysky
    Acked-by: Matt Turner
    Acked-by: David S. Miller
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    FUJITA Tomonori
     
  • dma_sync_single_for_cpu/for_device supports a partial sync so there is no
    point to have dma_sync_single_range (also dma_sync_single was obsoleted
    long ago, replaced with dma_sync_single_for_cpu/for_device).

    There is no user of dma_sync_single_range() in mainline and only Alpha
    architecture supports dma_sync_single_range(). So it's unlikely that
    someone out of the tree uses it.

    Signed-off-by: FUJITA Tomonori
    Acked-by: David Miller
    Acked-by: James Bottomley
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    FUJITA Tomonori
     
  • This adds the description of the following eight function:

    dma_sync_single_for_cpu
    pci_dma_sync_single_for_cpu
    dma_sync_single_for_device
    pci_dma_sync_single_for_device
    dma_sync_sg_for_cpu
    pci_dma_sync_sg_for_cpu
    dma_sync_sg_for_device
    pci_dma_sync_sg_for_device

    It was unclear that the API permits a partial sync (some network drivers
    already do though). I made it clear that the sync_single API can do a
    partial sync but the sync_sg API can't.

    We could do a partial sync with the sync_sg API too, however, it's
    difficult for driver writers to correctly use the sync_sg API for a
    partial sync since the scatterlists passed in to the mapping API can't be
    modified. It's unlikely that driver writers want to do a partial sync
    with the sync_sg API (because the sync_sg API are usually used for block
    drivers). So I think that it's better to forbid a partial sync with the
    sync_sg API.

    Signed-off-by: FUJITA Tomonori
    Acked-by: David Miller
    Acked-by: James Bottomley
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    FUJITA Tomonori
     
  • dma_sync_single(), pci_dma_sync_single(), dma_sync_sg(), and
    pci_dma_sync_sg() are deprecated. We should not advertise them.

    Signed-off-by: FUJITA Tomonori
    Acked-by: David S. Miller
    Acked-by: Joerg Roedel
    Cc: James Bottomley
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    FUJITA Tomonori
     
  • Add support to scrub DRAM using the e752x integrated memory scrubbing
    engine. The e7320/7520/e7525 chipsets support scrubbing at one rate while
    the i3100 chipset supports a normal and fast rate.

    A similar patch was originally sent back in 2008:
    http://sourceforge.net/mailarchive/forum.php?thread_name=1204835866.25206.70.camel@localhost.localdomain&forum_name=bluesmoke-devel

    This version has the following updates:
    - Use 16-bit PCI config cycles to access MCHSCRB register
    e7320/7520/e7525 docs say register is 16bits wide, i3100 says 8. I
    tested 16bits on the i3100 to be safe.
    - Recalcuate and round actual scrub rates

    The changes have been tested on an i3100-based board.

    Signed-off-by: Peter Tyser
    Signed-off-by: Doug Thompson
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Peter Tyser
     
  • FSB parity is only supported on the Xeon processor. Previously it was
    incorrectly enabled for the Celeron as well.

    Signed-off-by: Konstantin Olifer
    Signed-off-by: Doug Thompson
    Cc: Peter Tyser
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Konstantin Olifer
     
  • Use resource_size() instead of arithmetic.

    Signed-off-by: H Hartley Sweeten
    Signed-off-by: Doug Thompson
    Acked-by: Dave Jiang
    Cc: Peter Tyser
    Cc: Kumar Gala
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    H Hartley Sweeten
     
  • Add the ability to detect the specific data line or ECC line which failed
    when printing out SDRAM single-bit errors. An example of a single-bit
    SDRAM ECC error is below:

    EDAC MPC85xx MC1: Err Detect Register: 0x80000004
    EDAC MPC85xx MC1: Faulty data bit: 59
    EDAC MPC85xx MC1: Expected Data / ECC: 0x7f80d000_409effa0 / 0x6d
    EDAC MPC85xx MC1: Captured Data / ECC: 0x7780d000_409effa0 / 0x6d
    EDAC MPC85xx MC1: Err addr: 0x00031ca0
    EDAC MPC85xx MC1: PFN: 0x00000031

    Knowning which specific data or ECC line caused an error can be useful in
    tracking down hardware issues such as improperly terminated signals, loose
    pins, etc.

    Note that this feature is only currently enabled for 64-bit wide data
    buses, 32-bit wide bus support should be added.

    I don't have any 32-bit wide systems to test on. If someone has one and
    is willing to give this patch a shot with the check for a 64-bit data bus
    removed it would be much appreciated and I can re-submit with both 32 and
    64 bit buses supported.

    Signed-off-by: Peter Tyser
    Signed-off-by: Doug Thompson
    Cc: Kumar Gala
    Cc: Dave Jiang
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Peter Tyser
     
  • With a 64-bit wide data bus only the lowest 8-bits of the ECC syndrome are
    relevant. With a 32-bit wide data bus only the lowest 16-bits are
    relevant on most architectures.

    Without this change, the ECC syndrome displayed can be mildly confusing,
    eg:

    EDAC MPC85xx MC1: syndrome: 0x25252525

    When in reality the ECC syndrome is 0x25.

    A variety of Freescale manuals say a variety of different things about how
    to decode the CAPTURE_ECC (syndrome) register. I don't have a system with
    a 32-bit bus to test on, but I believe the change is correct. It'd be
    good to get an ACK from someone at Freescale about this change though.

    Signed-off-by: Peter Tyser
    Signed-off-by: Doug Thompson
    Cc: Kumar Gala
    Cc: Dave Jiang
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Peter Tyser
     
  • Remove INIT_NSPROXY(), use C99 initializer.
    Remove INIT_IPC_NS(), INIT_NET_NS() while I'm at it.

    Note: headers trim will be done later, now it's quite pointless because
    results will be invalidated by merge window.

    Signed-off-by: Alexey Dobriyan
    Acked-by: Serge Hallyn
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Alexey Dobriyan
     
  • zap_pid_ns_processes() uses force_sig(SIGKILL) to ensure SIGKILL will be
    delivered to sub-namespace inits as well. This is correct, but we are
    going to change force_sig_info() semantics. See
    http://bugzilla.kernel.org/show_bug.cgi?id=15395#c31

    We can use send_sig_info(SEND_SIG_NOINFO) instead, since
    614c517d7c00af1b26ded20646b329397d6f51a1 ("signals: SEND_SIG_NOINFO should
    be considered as SI_FROMUSER()") SEND_SIG_NOINFO means "from user" and
    therefore send_signal() will get the correct from_ancestor_ns = T flag.

    Signed-off-by: Oleg Nesterov
    Acked-by: Serge Hallyn
    Acked-by: Linus Torvalds
    Acked-by: Roland McGrath
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Oleg Nesterov
     
  • There is no need for linux/ipmi_smi.h to include itself.

    Signed-off-by: Corey Minyard
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Corey Minyard
     
  • Actually use the slave_addrs module parameter if it is specified, and make
    things consistent about passing zero in for the slave address for the
    default.

    Signed-off-by: Bela Lubkin
    Signed-off-by: Corey Minyard
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Bela Lubkin
     
  • In some cases kipmid can use a lot of CPU. This adds a way to tune the
    CPU used by kipmid to help in those cases. By setting kipmid_max_busy_us
    to a value between 100 and 500, it is possible to bring down kipmid CPU
    load to practically 0 without loosing too much ipmi throughput
    performance. Not setting the value, or setting the value to zero,
    operation is unaffected.

    Signed-off-by: Martin Wilck
    Signed-off-by: Corey Minyard
    Cc: Jean Delvare
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Martin Wilck
     
  • Make sure compiler won't do weird things with limits. E.g. fetching them
    twice may return 2 different values after writable limits are implemented.

    I.e. either use rlimit helpers added in
    3e10e716abf3c71bdb5d86b8f507f9e72236c9cd ("resource: add helpers for
    fetching rlimits") or ACCESS_ONCE if not applicable.

    Signed-off-by: Jiri Slaby
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jiri Slaby
     
  • Remove unneeded initialization in tty_audit_fork(). It is called only via
    copy_signal() and is useless after the kmem_cache_zalloc() was used.

    Signed-off-by: Veaceslav Falico
    Cc: Roland McGrath
    Cc: Oleg Nesterov
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Veaceslav Falico
     
  • Remove unneeded initializations in thread_group_cputime_init() and in
    posix_cpu_timers_init_group(). They are useless after kmem_cache_zalloc()
    was used in copy_signal().

    Signed-off-by: Veaceslav Falico
    Acked-by: Oleg Nesterov
    Cc: Roland McGrath
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Veaceslav Falico
     
  • Kill unused functions taskstats_tgid_init() and acct_init_pacct() because
    we don't use them anywhere after using kmem_cache_zalloc() in
    copy_signal().

    Signed-off-by: Veaceslav Falico
    Cc: Roland McGrath
    Cc: Oleg Nesterov
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Veaceslav Falico
     
  • Use kmem_cache_zalloc() on signal creation and remove unneeded
    initialization lines in copy_signal().

    Signed-off-by: Veaceslav Falico
    Acked-by: Oleg Nesterov
    Cc: Roland McGrath
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Veaceslav Falico
     
  • Use the generic ptrace_resume code for PTRACE_SYSCALL, PTRACE_CONT,
    PTRACE_KILL and PTRACE_SINGLESTEP. This implies defining
    arch_has_single_step in and implementing the
    user_enable_single_step and user_disable_single_step functions, which also
    causes the breakpoint information to be cleared on fork, which could be
    considered a bug fix.

    Also the TIF_SYSCALL_TRACE thread flag is now cleared on PTRACE_KILL which
    it previously wasn't, which is consistent with all architectures using the
    modern ptrace code.

    The old code only disables the breakpoints on PTRACE_KILL, while after
    this patch this also happens for PTRACE_CONT and PTRACE_SYSCALL which
    matches the behaviour of the other architetures. I think this is a
    bugfixes, but please double verify this is correct.

    Signed-off-by: Christoph Hellwig
    Cc: Oleg Nesterov
    Cc: Roland McGrath
    Cc: Hirokazu Takata
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Hellwig
     
  • Use the generic ptrace_resume code for PTRACE_SYSCALL, PTRACE_CONT,
    PTRACE_KILL and PTRACE_SINGLESTEP. This implies defining
    arch_has_single_step in and implementing the
    user_enable_single_step and user_disable_single_step functions, which also
    causes the breakpoint information to be cleared on fork, which could be
    considered a bug fix.

    Also the TIF_SYSCALL_TRACE thread flag is now cleared on PTRACE_KILL which
    it previously wasn't which is consistent with all architectures using the
    modern ptrace code.

    The way breakpoints are disabled is entirely inconsistent currently, I
    tried to make some sense of it, but I suspect all of the content of
    ptrace_disable should be moved into user_disable_single_step, this
    defintively needs some revisting as the current patch changes behaviour in
    not quite designed ways.

    Signed-off-by: Christoph Hellwig
    Cc: Oleg Nesterov
    Cc: Roland McGrath
    Cc: Mikael Starvik
    Cc: Jesper Nilsson
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Hellwig
     
  • Use the generic ptrace_resume code for PTRACE_SYSCALL, PTRACE_CONT and
    PTRACE_KILL. This also makes PTRACE_SINGLESTEP return -EIO while it
    previously succeeded despite not actually causing any kind of single
    stepping.

    Also the TIF_SYSCALL_TRACE thread flag is now cleared on PTRACE_KILL which
    it previously wasn't which is consistent with all architectures using the
    modern ptrace code.

    Signed-off-by: Christoph Hellwig
    Cc: Oleg Nesterov
    Cc: Roland McGrath
    Cc: Mikael Starvik
    Cc: Jesper Nilsson
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Hellwig
     
  • Use the generic ptrace_resume code for PTRACE_SYSCALL, PTRACE_CONT,
    PTRACE_KILL and PTRACE_SINGLESTEP. This implies defining
    arch_has_single_step in and implementing the
    user_enable_single_step and user_disable_single_step functions, which also
    causes the breakpoint information to be cleared on fork, which could be
    considered a bug fix.

    Also the TIF_SYSCALL_TRACE thread flag is now cleared on PTRACE_KILL which
    it previously wasn't which is consistent with all architectures using the
    modern ptrace code.

    Signed-off-by: Christoph Hellwig
    Cc: Oleg Nesterov
    Cc: Roland McGrath
    Cc: Chris Zankel
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Hellwig
     
  • Use the generic ptrace_resume code for PTRACE_SYSCALL, PTRACE_CONT,
    PTRACE_KILL and PTRACE_SINGLESTEP. This implies defining
    arch_has_single_step in and implementing the
    user_enable_single_step and user_disable_single_step functions, which also
    causes the breakpoint information to be cleared on fork, which could be
    considered a bug fix.

    Also the TIF_SYSCALL_TRACE thread flag is now cleared on PTRACE_KILL which
    it previously wasn't which is consistent with all architectures using the
    modern ptrace code.

    XXX: I'm not sure arch_has_single_step() is placed in the exactly correct
    location, please verify in which of the ptrace headers it should really
    be.

    Signed-off-by: Christoph Hellwig
    Cc: Oleg Nesterov
    Cc: Roland McGrath
    Cc: Jeff Dike
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Hellwig
     
  • Use the generic ptrace_resume code for PTRACE_SYSCALL, PTRACE_CONT and
    PTRACE_KILL.

    Also the TIF_SYSCALL_TRACE thread flag is now cleared on PTRACE_KILL which
    it previously wasn't which is consistent with all architectures using the
    modern ptrace code.

    Signed-off-by: Christoph Hellwig
    Cc: Oleg Nesterov
    Cc: Roland McGrath
    Acked-by: Ralf Baechle
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Hellwig