Convert code away from ->read_proc/->write_proc interfaces. Switch to
proc_create()/proc_create_data() which make addition of proc entries
reliable wrt NULL ->proc_fops, NULL ->data and so on.
Problem with ->read_proc et al is described here commit
786d7e1612 "Fix rmmod/read/write races in
/proc entries"
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The commit f4780ca005 moves
swiotlb initialization before dma32_free_bootmem(). It's
supposed to fix a bug that the commit
75f1cdf1dd introduced, we
initialize SWIOTLB right after dma32_free_bootmem so we wrongly
steal memory area allocated for GART with broken BIOS earlier.
However, the above commit introduced another problem, which
likely breaks machines with huge amount of memory. Such a box
use the majority of DMA32_ZONE so there is no memory for
swiotlb.
With this patch, the x86 IOMMU initialization sequence are:
1. We set swiotlb to 1 in the case of (max_pfn > MAX_DMA32_PFN
&& !no_iommu). If swiotlb usage is forced by the boot option,
we go to the step 3 and finish (we don't try to detect IOMMUs).
2. We call the detection functions of all the IOMMUs. The
detection function sets x86_init.iommu.iommu_init to the IOMMU
initialization function (so we can avoid calling the
initialization functions of all the IOMMUs needlessly).
3. We initialize swiotlb (and set dma_ops to swiotlb_dma_ops) if
swiotlb is set to 1.
4. If the IOMMU initialization function doesn't need swiotlb
(e.g. the initialization is sucessful) then sets swiotlb to zero.
5. If we find that swiotlb is set to zero, we free swiotlb
resource.
Reported-by: Yinghai Lu <yinghai@kernel.org>
Reported-by: Roland Dreier <rdreier@cisco.com>
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
LKML-Reference: <20091215204729A.fujita.tomonori@lab.ntt.co.jp>
Tested-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Commit a2e2725541 added recvmmsg to a bunch of arches (including the
Blackfin entry.S), but didn't actually add the new __NR_ define for it.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The next commit will require the use of MODULE_SYMBOL_PREFIX in
.tmp_exports-asm.S. Currently it is mixed in with C structure
definitions in "asm/module.h". Move the definition of this arch option
into Kconfig, so it can be easily accessed by any code.
This also lets modpost.c use the same definition. Previously modpost
relied on a hardcoded list of architectures in mk_elfconfig.c.
A build test for blackfin, one of the two MODULE_SYMBOL_PREFIX archs,
showed the generated code was unchanged. vmlinux was identical save
for build ids, and an apparently randomized suffix on a single "__key"
symbol in the kallsyms data).
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Acked-by: Mike Frysinger <vapier@gentoo.org> (blackfin)
CC: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The Kconfigs for in-tree floating point emulation do not allow building
as modules. That leaves the Acorn FPEmulator module. I found two public
releases of this as a binary module for 2.1 and 2.2 kernels, optimized
for ARMV4.[1] If there is a resurgence of interest in this, the symbols
can always be re-exported.
This allows the EXPORT_SYMBOL_ALIAS() hack to be removed. The ulterior
motive here is that EXPORT_SYMBOL_ALIAS() makes it harder to sort the
resulting kernel symbol tables. Sorted symbol tables will allow faster
symbol resolution during module loading.
Note that fp_send_sigs() and fp_printk() are simply aliases for existing
exports and add no obvious value. Similarly fp_enter could easily be
renamed to kern_fp_enter at the point of definition. Therefore removing
EXPORT_SYMBOL_ALIAS will not serve as a material obstacle to re-adding
the exports should they be desired in future.
Build tested only.
[1] http://ftp.arm.linux.org.uk/pub/linux/arm/fpemulator/
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
CC: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Commit 023bf6f "linker script: unify usage of discard definition"
changed the linker scripts for all architectures except for ARM.
I can find no discussion about this ommision, so here are the changes
for ARM.
These changes are exactly parallel to the ia64 case.
"ia64 is notable because it first throws away some ia64 specific
subsections and then include the rest of the sections into the final
image, so those sections must be discarded before the inclusion."
Not boot-tested. In build testing, the modified linker script generated
an identical vmlinux file.
[I would like to be able to rely on this unified discard definition.
I want to sort the kernel symbol tables to allow faster symbol
resolution during module loading. The simplest way appears to be
to generate sorted versions from vmlinux.o, link them in to vmlinux,
_and discard the original unsorted tables_.
This work is driven by my x86 netbook, but it is implemented at a
generic level. It is possible it will benefit some ARM systems also.]
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by-without-testing: Tejun Heo <tj@kernel.org>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
For CONFIG_PARAVIRT, load_gs_index is an inline function (it's #defined
to native_load_gs_index otherwise).
Exporting an inline function breaks the new assembler-based alphabetical
sorted symbol list:
Today's linux-next build (x86_64 allmodconfig) failed like this:
.tmp_exports-asm.o: In function `__ksymtab_load_gs_index':
(__ksymtab_sorted+0x5b40): undefined reference to `load_gs_index'
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
To: x86@kernel.org
Cc: alan-jenkins@tuffmail.co.uk
Exporting an inline function breaks the new assembler-based alphabetical
sorted symbol list.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The Blackfin sched_clock() func is pretty much a duplicate of the common
version, so just punt it.
Reported-by: David Miller <davem@davemloft.net>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Normally there is no user-reserved memory after the DMA region which means
there is no user-reserved ICPLB coverage. So the DMA hole can be covered
by the large hole that is always added to cover up to the async bank. We
only need an explicit DMA whole when we also add an explicit mapping for
the user-reserved memory.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
- document simple global symbols
- convert printk to pr_*
- clean up spurious whitespace
- use min_t()
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The read_proc and write_proc interfaces are going to be removed in the
common kernel code.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The ADXL34x driver was updated to include orientation sensing, so have the
bf537-stamp use it by default.
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The error masks are only needed in the BF537 demux error code, so instead
of needing all the short peripheral defines in global space, push these
masks into the one file where they are actually needed. This fixes a
bunch of define collisions with common code (can/serial/etc...).
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Barry Song <barry.song@analog.com>
When testing PREEMPT_RT kernel on BF561-EZKit, the kernel blocks while
booting. When the kernel initializes the ethernet driver, it sleeps and
never wakes up.
The issue happens when the kernel waits for a timer for Core B to timeout
(the timers are per-cpu based: static DEFINE_PER_CPU(struct tvec_base *,
tvec_bases) = &boot_tvec_bases).
However, the ksoftirqd thread for Core B (note, the ksoftirqd thread is
also per-cpu based) cannot work properly, and the timers for Core B never
times out.
When ksoftirqd() for the first time runs on core B, it is possible core A
is still initializing core B (see smp_init() -> cpu_up() -> __cpu_up()).
So the "cpu_is_offline()" check may return true and ksoftirqd moves to
"wait_to_die".
So delay the core b start up until the per-cpu timers have been set up
fully.
Signed-off-by: Yi Li <yi.li@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
While fetching instructions at the boundary of L1 instruction SRAM, a false
External Memory Addressing Error might be triggered. We should ignore this
and continue on our way to avoid random crashes.
Because hardware errors are not exact in the Blackfin architecture, we need
to catch a few more common cases when the code flow changes and the signal
is finally delivered.
Signed-off-by: Barry Song <barry.song@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
These regions are either read-only and won't work anyways (bootrom), or
we don't want people screwing with them because they're shared between
all processes (fixed code).
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The NOMPU code already supported executing in the async banks, so this
brings the MPU code in line.
Signed-off-by: Barry Song <barry.song@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The point of this small chunk was to avoid anomaly 05000310. This never
really seemed to do what it was intended though -- no valid CPLBs exist
over the reserved memory, and there is often memory before it anyways (due
to the uClinux MTD and/or reserved DMA region). Plus, it doesn't address
the L1 instruction case.
So drop this chunk as it wastes memory and is affront to humanity.
Signed-off-by: Barry Song <barry.song@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
When working with 8 meg systems, forcing a 1 meg DMA chunk heavily cuts
into the available resources. So support smaller chunks to better cover
needs for these systems.
Signed-off-by: Barry Song <barry.song@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
While we're moving the BF54x code, have the BF54xM variants select the
normal BF54x values so that the rest of the Kconfig tree doesn't need to
check the BF54xM variant everytime it wants to check the BF54x.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
No point in returning to userspace just to have it immediately perform the
RTS step. We have to update the PC anyways, so do the RTS too.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
