- 12 Mar, 2010 40 commits
-
-
FUJITA Tomonori authored
Adds the following macros: DECLARE_DMA_UNMAP_ADDR(ADDR_NAME) DECLARE_DMA_UNMAP_LEN(LEN_NAME) dma_unmap_addr(PTR, ADDR_NAME) dma_unmap_addr_set(PTR, ADDR_NAME, VAL) dma_unmap_len(PTR, LEN_NAME) dma_unmap_len_set(PTR, LEN_NAME, VAL) The API corresponds to the pci_unmap state API. We'll move to this new generic API from the PCI specific API in the long term. As include/asm-generic/pci-dma-compat.h does, the pci_unmap API simply calls the new generic API for some time. Signed-off-by:
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: James Bottomley <James.Bottomley@suse.de> Cc: David S. Miller <davem@davemloft.net> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
FUJITA Tomonori authored
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:
Arnd Bergmann <arnd@arndb.de> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
FUJITA Tomonori authored
Signed-off-by:
Mikael Starvik <starvik@axis.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
FUJITA Tomonori authored
Signed-off-by:
-
FUJITA Tomonori authored
Signed-off-by:
David S. Miller <davem@davemloft.net> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
FUJITA Tomonori authored
Signed-off-by:
Paul Mundt <lethal@linux-sh.org> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
FUJITA Tomonori authored
Signed-off-by:
-
FUJITA Tomonori authored
Signed-off-by:
Kyle McMartin <kyle@mcmartin.ca> Cc: Helge Deller <deller@gmx.de> Cc: James Bottomley <James.Bottomley@suse.de> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
FUJITA Tomonori authored
Signed-off-by:
-
FUJITA Tomonori authored
Signed-off-by:
-
FUJITA Tomonori authored
Signed-off-by:
David Howells <dhowells@redhat.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
FUJITA Tomonori authored
Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
FUJITA Tomonori authored
Signed-off-by:
Matt Turner <mattst88@gmail.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
FUJITA Tomonori authored
Signed-off-by:
-
FUJITA Tomonori authored
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 authored
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 authored
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 authored
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:
James Bottomley <James.Bottomley@suse.de> Signed-off-by:
-
FUJITA Tomonori authored
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 authored
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:
Joerg Roedel <joro@8bytes.org> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by:
-
Peter Tyser authored
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 <ptyser@xes-inc.com> Signed-off-by:
Doug Thompson <dougthompson@xmission.com> Signed-off-by:
-
Konstantin Olifer authored
FSB parity is only supported on the Xeon processor. Previously it was incorrectly enabled for the Celeron as well. Signed-off-by:
Konstantin Olifer <kolifer@gmail.com> Signed-off-by:
-
H Hartley Sweeten authored
Use resource_size() instead of arithmetic. Signed-off-by:
H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by:
Dave Jiang <djiang@mvista.com> Cc: Peter Tyser <ptyser@xes-inc.com> Cc: Kumar Gala <galak@gate.crashing.org> Signed-off-by:
-
Peter Tyser authored
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 authored
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:
-
Alexey Dobriyan authored
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 <adobriyan@gmail.com> Acked-by:
Serge Hallyn <serue@us.ibm.com> Signed-off-by:
-
Oleg Nesterov authored
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 614c517d ("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 <oleg@redhat.com> Acked-by:
Roland McGrath <roland@redhat.com> Signed-off-by:
-
Corey Minyard authored
There is no need for linux/ipmi_smi.h to include itself. Signed-off-by:
Corey Minyard <minyard@acm.org> Signed-off-by:
-
Bela Lubkin authored
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 <blubkin@vmware.com> Signed-off-by:
-
Martin Wilck authored
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 <martin.wilck@ts.fujitsu.com> Signed-off-by:
Corey Minyard <cminyard@mvista.com> Cc: Jean Delvare <jdelvare@suse.de> Signed-off-by:
-
Jiri Slaby authored
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 3e10e716 ("resource: add helpers for fetching rlimits") or ACCESS_ONCE if not applicable. Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Signed-off-by:
-
Veaceslav Falico authored
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 <vfalico@redhat.com> Cc: Roland McGrath <roland@redhat.com> Cc: Oleg Nesterov <oleg@redhat.com> Signed-off-by:
-
Veaceslav Falico authored
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 authored
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 authored
Use kmem_cache_zalloc() on signal creation and remove unneeded initialization lines in copy_signal(). Signed-off-by:
-
Christoph Hellwig authored
Use the generic ptrace_resume code for PTRACE_SYSCALL, PTRACE_CONT, PTRACE_KILL and PTRACE_SINGLESTEP. This implies defining arch_has_single_step in <asm/ptrace.h> 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 <hch@lst.de> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Roland McGrath <roland@redhat.com> Cc: Hirokazu Takata <takata@linux-m32r.org> Signed-off-by:
-
Christoph Hellwig authored
Use the generic ptrace_resume code for PTRACE_SYSCALL, PTRACE_CONT, PTRACE_KILL and PTRACE_SINGLESTEP. This implies defining arch_has_single_step in <asm/ptrace.h> 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 authored
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 authored
Use the generic ptrace_resume code for PTRACE_SYSCALL, PTRACE_CONT, PTRACE_KILL and PTRACE_SINGLESTEP. This implies defining arch_has_single_step in <asm/ptrace.h> 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 authored
Use the generic ptrace_resume code for PTRACE_SYSCALL, PTRACE_CONT, PTRACE_KILL and PTRACE_SINGLESTEP. This implies defining arch_has_single_step in <asm/ptrace.h> 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:
-
