Let each supported chip select the appropirate SYS_HAS_CPU_BMIPS*
option for its embedded processor, so support will be conditionally
included.
Signed-off-by: Jonas Gorski <jogo@openwrt.org>
Signed-off-by: John Crispin <blogic@openwrt.org>
Patchwork: http://patchwork.linux-mips.org/patch/6250/
Use the return value for guarding further SMP setup.
Signed-off-by: Jonas Gorski <jogo@openwrt.org>
Signed-off-by: John Crispin <blogic@openwrt.org>
Patchwork: http://patchwork.linux-mips.org/patch/6249/
Add a helper similar to the generic register_XXX_smp_ops() for bmips.
Register SMP UP ops in case of BMIPS32/3300.
Signed-off-by: Jonas Gorski <jogo@openwrt.org>
Signed-off-by: John Crispin <blogic@openwrt.org>
Patchwork: http://patchwork.linux-mips.org/patch/6248/
Codewise there is no difference between these two, so it does not make
sense to treat them differently. Also chip families having one of these
tend to have the other.
Signed-off-by: Jonas Gorski <jogo@openwrt.org>
Signed-off-by: John Crispin <blogic@openwrt.org>
Patchwork: http://patchwork.linux-mips.org/patch/6247/
As they are MIPS32 CPUs they do support the prefetch opcode.
Signed-off-by: Jonas Gorski <jogo@openwrt.org>
Signed-off-by: John Crispin <blogic@openwrt.org>
Patchwork: http://patchwork.linux-mips.org/patch/6243/
All BMIPS CPUs support HIGHMEM, so it should be selected by CPU_BMIPS.
Signed-off-by: Jonas Gorski <jogo@openwrt.org>
Signed-off-by: John Crispin <blogic@openwrt.org>
Patchwork: http://patchwork.linux-mips.org/patch/6242/
Instead of treating each flavour as an exclusive CPU to select, make
BMIPS the only option and let SYS_HAS_CPU_BMIPS* decide for which
flavours to include support.
Run tested on BMIPS3300 and BMIPS4350, only build tested for BMIPS4380
and BMIPS5000.
Signed-off-by: Jonas Gorski <jogo@openwrt.org>
Signed-off-by: John Crispin <blogic@openwrt.org>
Patchwork: http://patchwork.linux-mips.org/patch/6240/
Allow building for all bmips cpus at the same time by changing ifdefs
to checks for the cpu type, or adding appropriate checks to the
assembly.
Since BMIPS43XX and BMIPS5000 require different IPI implementations,
split the SMP ops into one for each, so the runtime overhead is only
at registration time for them.
Signed-off-by: Jonas Gorski <jogo@openwrt.org>
Signed-off-by: John Crispin <blogic@openwrt.org>
Patchwork: http://patchwork.linux-mips.org/patch/6241/
Add guards around the enum to allow including cpu.h from assembly.
Signed-off-by: Jonas Gorski <jogo@openwrt.org>
Signed-off-by: John Crispin <blogic@openwrt.org>
Patchwork: http://patchwork.linux-mips.org/patch/6238/
BCM3368 has the same shared TLB as BCM6358.
Signed-off-by: Jonas Gorski <jogo@openwrt.org>
Signed-off-by: John Crispin <blogic@openwrt.org>
Patchwork: http://patchwork.linux-mips.org/patch/6239/
Properly set up the HSSPI clock rate depending on the SoC's PLL rate.
Signed-off-by: Jonas Gorski <jogo@openwrt.org>
Signed-off-by: John Crispin <blogic@openwrt.org>
Patchwork: http://patchwork.linux-mips.org/patch/6177/
open/release operations require userspace transitions to keep track
of the open count and to perform any FS-specific setup. However,
for some purely read-only FSs which don't need to perform any setup
at open/release time, we can avoid the performance overhead of
calling into userspace for open/release calls.
This patch adds the necessary support to the fuse kernel modules to prevent
open/release operations from hitting in userspace. When the client returns
ENOSYS, we avoid sending the subsequent release to userspace, and also
remember this so that future opens also don't trigger a userspace
operation.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Various read operations (e.g. readlink, readdir) invalidate the cached
attrs for atime changes. This patch adds a new function
'fuse_invalidate_atime', which checks for a read-only super block and
avoids the attr invalidation in that case.
Signed-off-by: Andrew Gallagher <andrewjcg@fb.com>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
As noticed by Coverity the "num != 0" condition never triggers. Instead it
should check for a complete page.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Having this struct in module memory could Oops when if the module is
unloaded while the buffer still persists in a pipe.
Since sock_pipe_buf_ops is essentially the same as fuse_dev_pipe_buf_steal
merge them into nosteal_pipe_buf_ops (this is the same as
default_pipe_buf_ops except stealing the page from the buffer is not
allowed).
Reported-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: stable@vger.kernel.org
Fixes the following build error and warning when OF is not defined:
sound/soc/samsung/smdk_wm8994.c:191:23: error: ‘samsung_wm8994_of_match’ undeclared (first use in this function)
sound/soc/samsung/smdk_wm8994.c:47:32: warning: ‘smdk_board_data’ defined but not used [-Wunused-variable]
of_match_ptr() is used so that samsung_wm8994_of_match gets dropped (as unused)
by the compiler when OF is not defined.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
Fixes the following error introduced by commit eca3b01d08
("ASoC: switch over to use snd_soc_register_component() on s3c i2s"):
sound/soc/samsung/s3c-i2s-v2.c:732:32: error: ‘drv’ undeclared (first use in this function)
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Recent changes through commits c67d0f2926 ("ARM: s3c24xx: get rid
of custom <mach/gpio.h>"), b0161caa72 ("ARM: S3C[24|64]xx: move includes
back under <mach/> scope"), 364374121b ("ARM: s3c24xx: explicit
dependency on <plat/gpio-cfg.h>") and 41c3548e6d ("ARM: s3c64xx: get rid
of custom <mach/gpio.h>") caused build regressions due to broken
dependencies. Fix the following errors by including the necessary header
files explicitly:
sound/soc/samsung/h1940_uda1380.c:56:3: error: implicit declaration of function ‘S3C2410_GPG’
sound/soc/samsung/h1940_uda1380.c:149:18: error: ‘S3C_GPIO_END’ undeclared (first use in this function)
sound/soc/samsung/h1940_uda1380.c:234:21: error: ‘S3C_GPIO_END’ undeclared (first use in this function)
sound/soc/samsung/h1940_uda1380.c:270:12: error: ‘S3C_GPIO_END’ undeclared (first use in this function)
sound/soc/samsung/neo1973_wm8753.c:239:2: error: implicit declaration of function ‘S3C2410_GPJ’
sound/soc/samsung/rx1950_uda1380.c:67:3: error: implicit declaration of function ‘S3C2410_GPG’
sound/soc/samsung/s3c2412-i2s.c:86:2: error: implicit declaration of function ‘s3c_gpio_cfgall_range’
sound/soc/samsung/s3c2412-i2s.c:86:2: error: implicit declaration of function ‘S3C2410_GPE’
sound/soc/samsung/s3c2412-i2s.c:86:2: error: implicit declaration of function ‘S3C_GPIO_SFN’
sound/soc/samsung/s3c2412-i2s.c:87:10: error: ‘S3C_GPIO_PULL_NONE’ undeclared
sound/soc/samsung/s3c24xx-i2s.c:394:2: error: implicit declaration of function ‘s3c_gpio_cfgall_range’
sound/soc/samsung/s3c24xx-i2s.c:394:2: error: implicit declaration of function ‘S3C2410_GPE’
sound/soc/samsung/s3c24xx-i2s.c:394:2: error: implicit declaration of function ‘S3C_GPIO_SFN’
sound/soc/samsung/s3c24xx-i2s.c:395:10: error: ‘S3C_GPIO_PULL_NONE’ undeclared
sound/soc/samsung/smartq_wm8987.c:112:3: error: implicit declaration of function ‘S3C64XX_GPL’
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
Fix the function name of comment of __flush_dcache_area,
because __flush_dcache_area is the correct name. Also,
the missing variable 'size' is added to the comment.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Use 'ubfm' for the bitfield move instruction; thus, single
instruction can be used instead of two instructions, when
getting the minimum D-cache line size from CTR_EL0 register.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
With b8668fd0a7 "s390/uapi: change struct statfs[64] member types
to unsigned values" the size of a couple of struct statfs64 member got
incorrectly changed from 64 to 32 bit for 32 bit builds.
Fix this by changing the type of couple of struct statfs64 members from
unsigned long to unsigned long long.
The definition of struct compat_statfs64 was correct however.
Cc: stable@vger.kernel.org # v3.10+
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Remove some dead uaccess extern declarations and also make some functions
static, since they are only used locally.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
If get_fs() == USER_DS we better test if current->mm is not zero before
walking page tables.
The page table walk code would try to lock mm->page_table_lock, however
if mm is zero this might crash.
Now it is arguably incorrect trying to access userspace if current->mm
is zero, however we have seen that and s390 would be the only architecture
which would crash in such a case.
So we better make the page table walk code a bit more robust and report
always a fault instead.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Get rid of this link error:
arch/s390/built-in.o: In function `smp_prepare_cpus':
(.init.text+0x301e): undefined reference to `dump_save_area_create'
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
During parsing of the sizes array the pointer to the particular
string is lost. Keep it by using an extra pointer to store the end
position of the parsed string. Keeping these parameters accessible
can be helpful for debugging purposes and for userspace reading
the parameters at runtime via sysfs. Also this will ensure that the
memory is freed at module unload time.
Reported-by: Michael Veigel <veigel@de.ibm.com>
Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
This part of the ep11 patch should not have been merged.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Add the generic "lnxhvc" terminal ID to automatically assign a HVC terminal when
connecting to the HVC IUCV terminal device driver. The terminal device driver
tries to find a free (not connected) HVC terminal to satisfy the incoming
connection request.
With this improvement, you do not longer need to guess which HVC terminal is
free, that is, not connected. Also you can still connect to a particular HVC
terminal by using its associated terminal ID.
Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Add device attributes to display details about the connection status
of HVC IUCV terminals.
Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
drivers/tty/hvc/hvc_iucv.c:131:25: warning: symbol 'hvc_iucv_get_private' was not
declared. Should it be static?
Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
When creating the virtual unit record (UR) device, specify the parent
CCW device.
Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
A couple of years ago all the "L: lkml" email list entries in
MAINTAINERS were removed and replaced with a 'the rest' entry
at the end of the file - under the theory that this is unnecessary
duplication and that people would find it intuitive:
b5472cddbe MAINTAINERS: remove L: linux-kernel@vger.kernel.org from all but "THE REST"
So it turns out that it's all but intuitive, not all people
use scripts/get_maintainer.pl to extract maintainer contact info,
some people read the MAINTAINERS file and see the lack of 'L:' entries
of various lkml-only subsystems and are sending patches to the
maintainers only, without Cc:-ing lkml. They arguably have a point.
In hindsight removing all the "L: lkml" entries was probably not
an overly good idea, not all mechanic duplication should be eliminated:
in files read by humans it's useful to have 'at a glance' summary for
all email addresses important to a subsystem's maintenance, in a single
place, without too many imported rules and assumptions.
So, to make the lkml fallback really apparent, add back 'L: lkml'
entries to all subsystem entries whose workflow I'm involved in.
This should at minimum be a per subsystem policy thing.
Acked-by: Peter Zijlstra <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Joe Perches <joe@perches.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Link: http://lkml.kernel.org/n/tip-lhzlymtgmmv5bMuwsb5zyoYo@git.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
It looks like GCC will always emit an object that is marked with an
explicit section, although the documentation doesn't say that and we
possibly shouldn't be relying on it.
Clang does *not* do so, so add __attribute__((used)) to make sure.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Link: http://lkml.kernel.org/r/1389180083-23249-2-git-send-email-David.Woodhouse@intel.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Improve the debuggability of relocations output. When trying to compare
the output between different linkers, it's handy to be able to see the
section names in output.
Signed-off-by: Michael Davidson <md@google.com>
Link: http://lkml.kernel.org/r/20140121203223.GA12649@www.outflux.net
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Nothing's changed here; we just need to bump the generation check.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch adds NODE_MAPPING which is similar as META_MAPPING introduced by
Gu Zheng.
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Signed-off-by: Jaegeuk Kim <jaegeuk.kim@samsung.com>
As the orphan_blocks may be max to 504, so it is not security
and rigorous to store such a large array in the kernel stack
as Dan Carpenter said.
In fact, grab_meta_page has locked the page in the page cache,
and we can use find_get_page() to fetch the page safely in the
downstream, so we can remove the page array directly.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com>
Signed-off-by: Jaegeuk Kim <jaegeuk.kim@samsung.com>
Introduce help function META_MAPPING() to get the cache meta blocks'
address space.
Signed-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com>
Signed-off-by: Jaegeuk Kim <jaegeuk.kim@samsung.com>
If a dentry page is updated, we should call mark_inode_dirty to add the inode
into the dirty list, so that its dentry pages are flushed to the disk.
Otherwise, the inode can be evicted without flush.
Signed-off-by: Jaegeuk Kim <jaegeuk.kim@samsung.com>
Since an old pageflip will keep its scanout buffer object pinned until
it has executed its unpin task on the common workqueue, we can clog up
our GGTT with stale pinned objects. As we cannot flush those workqueues
without dropping our locks, we have to resort to falling back to
userspace and telling them to repeat the operation in order to have a
chance to run our workqueues and free up the required memory. If we
fail, then we are forced to report ENOSPC back to userspace causing the
operation to fail and best-case scenario is that it introduces temporary
corruption.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jon Bloomfield <jon.bloomfield@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On older generations (gen2, gen3) the GPU requires fences for many
operations, such as blits. The display hardware also requires fences for
scanouts and this leads to a situation where an arbitrary number of
fences may be pinned by old scanouts following a pageflip but before we
have executed the unpin workqueue. This is unpredictable by userspace
and leads to random EDEADLK when submitting an otherwise benign
execbuffer. However, we can detect when we have an outstanding flip and
so cause userspace to wait upon their completion before finally
declaring that the system is starved of fences. This is really no worse
than forcing the GPU to stall waiting for older execbuffer to retire and
release their fences before we can reallocate them for the next
execbuffer.
v2: move the test for a pending fb unpin to a common routine for
later reuse during eviction
Reported-and-tested-by: dimon@gmx.net
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73696
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jon Bloomfield <jon.bloomfield@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Atm after a failed link training we disable the DP port. This can happen
during a modeset-enable or a DP link re-establishment. The latter can be
a problem and we shouldn't disable the DP port, see the previous patch for
the reasoning. In the former case the right thing would be to disable
the DP port, but also the rest of the pipe.
As a stop-gap solution leave the DP port enabled in both cases. It is an
improvement on its own (avoiding HW lock ups) and the proper solution
for the first case requires a bigger change, so let's keep that on the
TODO list.
v2:
- fix explanation of change impact (Chris)
Suggested-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
