- 23 4月, 2008 4 次提交
-
-
由 Mike Frysinger 提交于
Signed-off-by: NMike Frysinger <vapier.adi@gmail.com> Signed-off-by: NBryan Wu <cooloney@kernel.org>
-
由 Bernd Schmidt 提交于
Bug: CONFIG_MPU doesn't seem to handle access to ASYNC/IO Memory well http://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_item_id=3912Signed-off-by: NBernd Schmidt <bernds_cb1@t-online.de> Signed-off-by: NBryan Wu <cooloney@kernel.org>
-
由 Bernd Schmidt 提交于
There were a couple of problems with the way the trace buffer state is saved/restored in assembly. The DEBUG_HWTRACE_SAVE/RESTORE macros save a value to the stack, which is not immediately obvious; the CPLB exception code needed changes to load the correct value of the stack pointer. The other problem is that the SAVE/RESTORE macros weren't pushing and popping the value downwards on the stack, but rather moving it _upwards_, which is of course completely broken. We also need to make sure there's a matching DEBUG_HWTRACE_RESTORE in the error case of the CPLB handler. Signed-off-by: NBernd Schmidt <bernds_cb1@t-online.de> Signed-off-by: NBryan Wu <cooloney@kernel.org>
-
由 Bernd Schmidt 提交于
[Blackfin] arch: fix up - CONFIG_BLKFIN_WT was renamed CONFIG_BFIN_WT while the MPU code was out-of-tree. Signed-off-by: NBernd Schmidt <bernds_cb1@t-online.de> Signed-off-by: NBryan Wu <cooloney@kernel.org>
-
- 26 3月, 2008 9 次提交
-
-
由 Robin Getz 提交于
grab locks when not atomic - this fixes the issues sometimes seen when using magic sysrq. Signed-off-by: NRobin Getz <rgetz@blackfin.uclinux.org> Signed-off-by: NBryan Wu <cooloney@kernel.org>
-
由 Robin Getz 提交于
Sometimes when we crash, current is not valid, (has been written over), so the existing code causes a invalid read during exception context - which is a unrecoverable double fault. This fixes this. Signed-off-by: NRobin Getz <rgetz@blackfin.uclinux.org> Signed-off-by: NBryan Wu <cooloney@kernel.org>
-
由 Bryan Wu 提交于
Signed-off-by: NBryan Wu <cooloney@kernel.org>
-
由 Mike Frysinger 提交于
Signed-off-by: NMike Frysinger <vapier.adi@gmail.com> Signed-off-by: NBryan Wu <cooloney@kernel.org>
-
由 Mike Frysinger 提交于
[Blackfin] arch: dump the stack before printing out an error otherwise the stack dump is useless as it shows us tracing through printk Signed-off-by: NMike Frysinger <vapier.adi@gmail.com> Signed-off-by: NBryan Wu <cooloney@kernel.org>
-
由 Mike Frysinger 提交于
Signed-off-by: NMike Frysinger <vapier.adi@gmail.com> Signed-off-by: NBryan Wu <cooloney@kernel.org>
-
由 Yi Li 提交于
[Blackfin] arch: add code to initialize globals declared in linux/bootmem.h: max_pfn, max_low_pfn, min_low_pfn. Signed-off-by: NYi Li <yi.li@analog.com> Signed-off-by: NBryan Wu <cooloney@kernel.org>
-
由 Bernd Schmidt 提交于
Since r3658 | vapier | 2007-09-12 16:26:11 +0200 (Wed, 12 Sep 2007) | 1 line add more common defines for output sections we've had a new line, NOTES, in our linker script, which causes upstream binutils to complain about "missing phdr". Currently the only other arch that uses NOTES is i386, and the patch which added it also added PHDRS { text PT_LOAD FLAGS(5); /* R_E */ data PT_LOAD FLAGS(7); /* RWE */ note PT_NOTE FLAGS(0); /* ___ */ } and a few other modifications to use ":text" and ":data" to the linker script. It seems that we don't need NOTES at all, so just remove it. Signed-off-by: NBernd Schmidt <bernds_cb1@t-online.de> Signed-off-by: NBryan Wu <cooloney@kernel.org>
-
由 Mike Frysinger 提交于
Signed-off-by: NBryan Wu <cooloney@kernel.org>
-
- 07 3月, 2008 2 次提交
-
-
由 Mike Frysinger 提交于
Signed-off-by: NMike Frysinger <vapier.adi@gmail.com> Signed-off-by: NBryan Wu <cooloney@kernel.org>
-
由 Mike Frysinger 提交于
[Blackfin] arch: add missing __user marking to ss_sp member of signalstack and a few userspace system functions Signed-off-by: NMike Frysinger <vapier.adi@gmail.com> Signed-off-by: NBryan Wu <cooloney@kernel.org>
-
- 29 2月, 2008 3 次提交
-
-
由 Mike Frysinger 提交于
Signed-off-by: NMike Frysinger <vapier.adi@gmail.com> Signed-off-by: NBryan Wu <cooloney@kernel.org>
-
由 Mike Frysinger 提交于
Signed-off-by: NMike Frysinger <vapier.adi@gmail.com> Signed-off-by: NBryan Wu <cooloney@kernel.org>
-
由 Vitja Makarov 提交于
This patch enables Hight-Res Timers and tickless kernel Signed-off-by: NVitja Makarov <vitja.makarov@gmail.com> Signed-off-by: NMichael Hennerich <michael.hennerich@analog.com> Signed-off-by: NBryan Wu <cooloney@kernel.org>
-
- 23 4月, 2008 1 次提交
-
-
由 Dean Nelson 提交于
Move XPC and XPNET from arch/ia64/sn/kernel to drivers/misc/sgi-xp. Signed-off-by: NDean Nelson <dcn@sgi.com> Signed-off-by: NTony Luck <tony.luck@intel.com>
-
- 22 4月, 2008 7 次提交
-
-
由 Jeff Garzik 提交于
- remove unused 'irq' argument from pfm_do_interrupt_handler() - remove pointless cast to void* - add KERN_xxx prefix to printk() - remove braces around singleton C statement - in tioce_provider.c, start tioce_dma_consistent() and tioce_error_intr_handler() function declarations in column 0 This change's main purpose is to prepare for the patchset in jgarzik/misc-2.6.git#irq-remove, that explores removal of the never-used 'irq' argument in each interrupt handler. Signed-off-by: NJeff Garzik <jgarzik@redhat.com> Signed-off-by: NTony Luck <tony.luck@intel.com>
-
由 Hidetoshi Seto 提交于
There are many notify_die() and almost all take same style with ia64_mca_spin(). This patch defines macros and replace them all, to reduce lines and to improve readability. Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Signed-off-by: NTony Luck <tony.luck@intel.com>
-
由 Hidetoshi Seto 提交于
There are 3 hooks in MCA handler, but this DIE_MCA_MONARCH_PROCESS event does not notified other than for the first monarch. Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Signed-off-by: NTony Luck <tony.luck@intel.com>
-
由 Hidetoshi Seto 提交于
While testing with CONFIG_VIRT_CPU_ACCOUNTING=y, I found that I occasionally get very huge system time in some threads. So I dug the issue and finally noticed that it was caused because of an interrupt which interrupt in the following window: > [arch/ia64/kernel/entry.S: (!CONFIG_PREEMPT && CONFIG_VIRT_CPU_ACCOUNTING)] > > ENTRY(ia64_leave_syscall) > : > (pUStk) rsm psr.i > cmp.eq pLvSys,p0=r0,r0 // pLvSys=1: leave from syscall > (pUStk) cmp.eq.unc p6,p0=r0,r0 // p6 <- pUStk > .work_processed_syscall: > adds r2=PT(LOADRS)+16,r12 > (pUStk) mov.m r22=ar.itc // fetch time at leave > adds r18=TI_FLAGS+IA64_TASK_SIZE,r13 > ;; > <<< window: from here >>> > (p6) ld4 r31=[r18] // load current_thread_info()->flags > ld8 r19=[r2],PT(B6)-PT(LOADRS) > adds r3=PT(AR_BSPSTORE)+16,r12 > ;; > mov r16=ar.bsp > ld8 r18=[r2],PT(R9)-PT(B6) > (p6) and r15=TIF_WORK_MASK,r31 // any work other than TIF_SYSCALL_TRACE? > ;; > ld8 r23=[r3],PT(R11)-PT(AR_BSPSTORE) > (p6) cmp4.ne.unc p6,p0=r15, r0 // any special work pending? > (p6) br.cond.spnt .work_pending_syscall > ;; > ld8 r9=[r2],PT(CR_IPSR)-PT(R9) > ld8 r11=[r3],PT(CR_IIP)-PT(R11) > (pNonSys) break 0 // bug check: we shouldn't be here if pNonSys is TRUE! > ;; > invala > <<< window: to here >>> > rsm psr.i | psr.ic // turn off interrupts and interruption collection If pUStk is true, it means we are going to return user mode, hence we fetch ar.itc to get time at leave from system. It seems that it is not possible to interrupt the window if pUStk is true, because interrupts are disabled early. And also disabling interrupt makes sense because it is safe for referring current_thread_info()->flags. However interrupting the window while pUStk is true was possible. The route was: ia64_trace_syscall -> .work_pending_syscall_end -> .work_processed_syscall Only in case entering the window from this route, interrupts are enabled during in the window even if pUStk is true. I suppose interrupts must be disabled here anyway if pUStk is true. I'm not sure but afraid that what kind of bad effect were there, other than crazy system time which I found. FYI, there was a commit 6f6d7582 that points out a bug at same point(exit of ia64_trace_syscall) in 2006. It can be said that there was an another bug. Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Signed-off-by: NTony Luck <tony.luck@intel.com>
-
由 Adrian Bunk 提交于
This patch removes the no longer used export of kmap_atomic_to_page. Signed-off-by: NAdrian Bunk <bunk@kernel.org> Signed-off-by: NDavid Howells <dhowells@redhat.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Tobias Klauser 提交于
The C99 specification states in section 6.11.5: The placement of a storage-class specifier other than at the beginning of the declaration specifiers in a declaration is an obsolescent feature. Signed-off-by: NTobias Klauser <tklauser@distanz.ch> Signed-off-by: NJesper Juhl <jesper.juhl@gmail.com>
-
由 David S. Miller 提交于
As per Documentation/feature-removal-schedule.txt Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 21 4月, 2008 14 次提交
-
-
由 Bjorn Helgaas 提交于
Use the generic pci_enable_resources() instead of the arch-specific code. Unlike this arch-specific code, the generic version: - checks PCI_NUM_RESOURCES (11), not DEVICE_COUNT_RESOURCE (12), resources - skips resources that have neither IORESOURCE_IO nor IORESOURCE_MEM set - skips ROM resources unless IORESOURCE_ROM_ENABLE is set - checks for resource collisions with "!r->parent" Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Acked-by: NKyle McMartin <kyle@mcmartin.ca> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Bjorn Helgaas 提交于
Use the generic pci_enable_resources() instead of the arch-specific code. Unlike this arch-specific code, the generic version: - checks PCI_NUM_RESOURCES (11), not 6, resources - skips resources that have neither IORESOURCE_IO nor IORESOURCE_MEM set - skips ROM resources unless IORESOURCE_ROM_ENABLE is set - checks for resource collisions with "!r->parent", not IORESOURCE_UNSET Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Bjorn Helgaas 提交于
Use the generic pci_enable_resources() instead of the arch-specific code. The generic version is functionally equivalent, but uses dev_printk. Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Bjorn Helgaas 提交于
Use the generic pci_enable_resources() instead of the arch-specific code. Unlike this arch-specific code, the generic version: - does not check for a NULL dev pointer - skips resources that have neither IORESOURCE_IO nor IORESOURCE_MEM set Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Bjorn Helgaas 提交于
Use the generic pci_enable_resources() instead of the arch-specific code. Unlike this arch-specific code, the generic version: - skips resources unless requested in "mask" - skips ROM resources unless IORESOURCE_ROM_ENABLE is set - checks for resource collisions with "!r->parent" Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Bjorn Helgaas 提交于
Use the generic pci_enable_resources() instead of the arch-specific code. Unlike this arch-specific code, the generic version: - checks for resource collisions with "!r->parent" Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Bjorn Helgaas 提交于
The "pci=routeirq" option was added in 2004, and I don't get any valid reports anymore. The option is still mentioned in kernel-parameters.txt. Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Gary Hade 提交于
The PCI bus names included in /proc/iomem and /proc/ioports are of the form 'PCI Bus #XX' where XX is the bus number. This patch changes the naming to 'PCI Bus XXXX:YY' where XXXX is the domain number and YY is the bus number. For example, PCI bus 14 in domain 0 will show as 'PCI Bus 0000:14' instead of 'PCI Bus #14'. This change makes the naming consistent with other architectures such as ia64 where multiple PCI domain support has been around longer. Signed-off-by: NGary Hade <garyhade@us.ibm.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Greg Kroah-Hartman 提交于
This function was obviously never being used since early 2.5 days as any device that it would try to remove would never really be removed from the system due to the PCI device list being held in the driver core, not the general list of PCI devices. As we have not had a single report of a problem here in 4 years, I think it's safe to remove now. Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Greg Kroah-Hartman 提交于
This lets us check if the device is really added to the driver core or not, which is what we need when walking some of the bus lists. The flag is there in anticipation of getting rid of the other PCI device list, which is what we used to check in this situation. Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Greg Kroah-Hartman 提交于
We currently keep 2 lists of PCI devices in the system, one in the driver core, and one all on its own. This second list is sorted at boot time, in "BIOS" order, to try to remain compatible with older kernels (2.2 and earlier days). There was also a "nosort" option to turn this sorting off, to remain compatible with even older kernel versions, but that just ends up being what we have been doing from 2.5 days... Unfortunately, the second list of devices is not really ever used to determine the probing order of PCI devices or drivers[1]. That is done using the driver core list instead. This change happened back in the early 2.5 days. Relying on BIOS ording for the binding of drivers to specific device names is problematic for many reasons, and userspace tools like udev exist to properly name devices in a persistant manner if that is needed, no reliance on the BIOS is needed. Matt Domsch and others at Dell noticed this back in 2006, and added a boot option to sort the PCI device lists (both of them) in a breadth-first manner to help remain compatible with the 2.4 order, if needed for any reason. This option is not going away, as some systems rely on them. This patch removes the sorting of the internal PCI device list in "BIOS" mode, as it's not needed at all anymore, and hasn't for many years. I've also removed the PCI flags for this from some other arches that for some reason defined them, but never used them. This should not change the ordering of any drivers or device probing. [1] The old-style pci_get_device and pci_find_device() still used this sorting order, but there are very few drivers that use these functions, as they are deprecated for use in this manner. If for some reason, a driver rely on the order and uses these functions, the breadth-first boot option will resolve any problem. Cc: Matt Domsch <Matt_Domsch@dell.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Greg Kroah-Hartman 提交于
This isn't needed, we can just walk the devices in bus order with no problems at all, as we really want to remove pci_get_device_reverse from the kernel tree. Acked-by: NMuli Ben-Yehuda <muli@il.ibm.com> Cc: Jon Mason <jdmason@kudzu.us> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Sebastian Siewior 提交于
The return parameter isn't used remove it. Signed-off-by: NSebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Jan Glauber 提交于
Exploit the System z10 hardware acceleration for SHA384. Signed-off-by: NJan Glauber <jang@linux.vnet.ibm.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-