Current code returns 0 if fails to read clock-frequency DT property,
fix it. Also add checking return value of clk_prepare_enable and
propagate return value of devm_request_irq.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Pull Ceph fixes from Sage Weil:
"There is a fix for CephFS and RBD when used within containers/namespaces,
and a fix for the address learning the client is supposed to do when
initially talking to the Ceph cluster.
There are also two patches updating MAINTAINERS. One breaks out the
common Ceph code shared by fs/ceph and drivers/block/rbd.c into a
separate entry with the appropriate maintainers listed. The second
adds a second reference to the github tree where the Ceph client
development takes place (before it is pushed to korg and then to you).
The goal here is to move closer to a situation where Ilya Dryomov or
one of the other maintainers can push things to you if I am
unavailable. Ilya has done most of the work preparing branches for
upstream recently; you should not be surprised to hear from him if I
am trapped in some internet-less wasteland or hit by a bus or
something. In the meantime, we'll work on getting him added to the
kernel web of trust"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client:
MAINTAINERS: add secondary tree for ceph modules
MAINTAINERS: update ceph entries
libceph: treat sockaddr_storage with uninitialized family as blank
libceph: enable ceph in a non-default network namespace
This fbdev restore mode was another corner case that was now
calling frontbuffer flip and flush and making we miss
screen updates with PSR enabled.
So let's also add the invalidate hack here while we don't have
a reliable dirty fbdev op.
v2: As pointed by Paulo: removed seg fault risk, used fb_helper
when possible and put brackets on if.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Testcase: igt/kms_fbcon_fbt/psr
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
fbdev_set_par is called when fbcon is taking over control.
In the past frontbuffer was being invalidated on
set_to_gtt_domain, but it moved to set_domain fixing that case,
but left this behind and broken in
commit 031b698a77
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Jun 26 19:35:16 2015 +0200
drm/i915: Unconditionally do fb tracking invalidate in set_domain
Note that even before this commit it wasn't perfect since the
invalidate was omitted if the fbcon was already in the GTT domain,
which it usually was.
Since we are also invalidating in other fbdev cases this one
was masked here. At least until now that I found this corner
case: On boot with plymouth doing a splash screen
when returning to the console frontbuffer wans't being invalidated
causing missed screen updates with PSR enabled.
So this patch fixes this issue.
v2: Make invalidate directly and unconditionally and
fix commit message indicating the set_domain fix
as pointed out by Daniel.
v3: Remove unecessary if(obj) added by mistake
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Try to clarify commit message a bit and make it clear the
referenced commit made this worse.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Idle frames the number of identical frames needed
before panel can enter PSR.
There are some panels that requires up to minimum of 4 idle
frames available on the market. For these cases usually
VBT should be used to configure the number of idle frames,
but unfortunately this isn't always true and VBT isn't being
set at all.
Let's trust VBT when it is set + 1 and use minimum of 4 + 1
when VBT isn't set. "+1" covers the "of-by-one" case.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
By Spec we should only mask memup and hotplug detection
for hardware tracking cases. However we always masked
LPSP because with power well always enabled on audio
PSR was never being activated and residency was always
zeroed.
Apparently audio driver is tying power well management
and runtime PM for some reason. But with audio runtime
PM working or with audio completely out of picture
we should remove this mask, otherwise we have a high
risk of miss screen updates as faced by Matthew.
WARNING: With this patch if snd_intel_hda driver is
running and not releasing power well properly PSR will
constant Exit and Performance Counter will be 0.
But the best thing of this patch is that with one more
HW tracking working the risks of missed blank screen
are minimized at most.
This affects just core platforms where PSR exit are also
helped by HW tracking: Haswell, Broadwell and Skylake
for now.
v2: Fix commit message explanation. It has nothing to do
with runtime PM on i915 as previously advertised.
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Instead of accessing it directly, as it uses EXPORT_SYMBOL, that has
no meaning in tools/perf and because we removed the stubs for it, i.e.
we removed the tools/include/linux/export.h file.
This fixes the build for the detached tarball sources cases and removes
one more source of entanglement with the kernel sources.
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/n/tip-oyqx541o7apa2cskjhcxi6nx@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The python binding build process was still looking at the kernel
rbtree.c file, so, when doing a in-tree build it would work, but when
creating a tarball using tools/perf/MANIFEST as the contents list and
then trying to build the resulting detached sources, it failed.
Fix it by removing one level of indirection from rbtree.c in the
tools/perf/util/python-ext-sources file.
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/n/tip-8u83c2k5guyhxdlkaaqis8k4@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The FITRIM ioctl has the same arguments on 32-bit and 64-bit
architectures, so we can add it to the list of compatible ioctls and
drop it from compat_ioctl method of various filesystems.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Ted Ts'o <tytso@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
At present we don't create efficient ebitmaps when importing NetLabel
category bitmaps. This can present a problem when comparing ebitmaps
since ebitmap_cmp() is very strict about these things and considers
these wasteful ebitmaps not equal when compared to their more
efficient counterparts, even if their values are the same. This isn't
likely to cause problems on 64-bit systems due to a bit of luck on
how NetLabel/CIPSO works and the default ebitmap size, but it can be
a problem on 32-bit systems.
This patch fixes this problem by being a bit more intelligent when
importing NetLabel category bitmaps by skipping over empty sections
which should result in a nice, efficient ebitmap.
Cc: stable@vger.kernel.org # 3.17
Signed-off-by: Paul Moore <pmoore@redhat.com>
The firmware class uevent function accessed the "fw_priv->buf" buffer
without the proper locking and testing for NULL. This is an old bug
(looks like it goes back to 2012 and commit 1244691c73: "firmware
loader: introduce firmware_buf"), but for some reason it's triggering
only now in 4.2-rc1.
Shuah Khan is trying to bisect what it is that causes this to trigger
more easily, but in the meantime let's just fix the bug since others are
hitting it too (at least Ingo reports having seen it as well).
Reported-and-tested-by: Shuah Khan <shuahkh@osg.samsung.com>
Acked-by: Ming Lei <ming.lei@canonical.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Reading page fault handler code I've noticed that under right
circumstances kernel would map anonymous pages into file mappings: if
the VMA doesn't have vm_ops->fault() and the VMA wasn't fully populated
on ->mmap(), kernel would handle page fault to not populated pte with
do_anonymous_page().
Let's change page fault handler to use do_anonymous_page() only on
anonymous VMA (->vm_ops == NULL) and make sure that the VMA is not
shared.
For file mappings without vm_ops->fault() or shred VMA without vm_ops,
page fault on pte_none() entry would lead to SIGBUS.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Oleg Nesterov <oleg@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Willy Tarreau <w@1wt.eu>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The Ceph kernel code is primarily developed in the github tree, and only
pushed to the korg tree before going to Linus. If Sage is unavailable and
another maintainer needs to push something upstream, pull requests may
originate from the github tree instead of Sage's korg tree.
Signed-off-by: Sage Weil <sage@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
- The Ceph common code is used by both fs/ceph and drivers/block/rbd.
Add a separate maintainers entry.
- Add Ilya as libceph maintainer and cephfs submaintainer.
- Attribute Documentation/ABI/testing/sysfs-bus-rbd to rbd.
- ceph-devel@vger.kernel.org should be L, not M in rbd entry.
Signed-off-by: Sage Weil <sage@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
addr_is_blank() should return true if family is neither AF_INET nor
AF_INET6. This is what its counterpart entity_addr_t::is_blank_ip() is
doing and it is the right thing to do: in process_banner() we check if
our address is blank and if it is "learn" it from our peer. As it is,
we never learn our address and always send out a blank one. This goes
way back to ceph.git commit dd732cbfc1c9 ("use sockaddr_storage; and
some ipv6 support groundwork") from 2009.
While at at, do not open-code ipv6_addr_any() and use INADDR_ANY
constant instead of 0.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Reviewed-by: Sage Weil <sage@redhat.com>
Grab a reference on a network namespace of the 'rbd map' (in case of
rbd) or 'mount' (in case of ceph) process and use that to open sockets
instead of always using init_net and bailing if network namespace is
anything but init_net. Be careful to not share struct ceph_client
instances between different namespaces and don't add any code in the
!CONFIG_NET_NS case.
This is based on a patch from Hong Zhiguo <zhiguohong@tencent.com>.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Reviewed-by: Sage Weil <sage@redhat.com>
Reported by the kbuild test robot.
Regression introduced by:
commit fdbff9282c
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Jun 18 11:23:24 2015 +0200
drm/i915: Clear fb_tracking.busy_bits also for synchronous flips
(I reviewed this commit, so it's also my fault)
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reported by the kbuild test robot.
Regression introduced by:
commit de152b627e
Author: Rodrigo Vivi <rodrigo.vivi@intel.com>
Date: Tue Jul 7 16:28:51 2015 -0700
drm/i915: Add origin to frontbuffer tracking flush
(I reviewed this commit, so it's also my fault)
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cayman does not have vce. There were a few places in the
shared cayman/TV code where we were trying to do vce stuff.
v2: remove -ENOENT check
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Otherwise we try to clear BO_VAs without an address.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=91141
Signed-off-by: Christian König <christian.koenig@amd.com>
Test-by: hadack@gmx.de
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
We need to allways add the VM clear duplicate of the BO_VA,
no matter what the old status was.
Signed-off-by: Christian König <christian.koenig@amd.com>
Test-by: hadack@gmx.de
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Grigori Goronzy <greg@chown.ath.cx>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Everything is evicted from VRAM before suspend, so we need to make
sure all BOs are unpinned and re-pinned after resume. Fixes broken
mouse cursor after resume introduced by commit b9729b17.
[Michel Dänzer: Add pinning BOs on resume]
v2:
[Alex Deucher: merge cursor unpin into fb unpin loop]
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=100541
Cc: stable@vger.kernel.org
Reviewed-by: Christian König <christian.koenig@amd.com> (v1)
Signed-off-by: Grigori Goronzy <greg@chown.ath.cx>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Take a GEM reference for and pin the new cursor BO, unpin and drop the
GEM reference for the old cursor BO in radeon_crtc_cursor_set2, and use
radeon_crtc->cursor_addr in radeon_set_cursor.
This fixes radeon_cursor_reset accidentally incrementing the cursor BO
pin count, and cleans up the code a little.
Cc: stable@vger.kernel.org
Reviewed-by: Grigori Goronzy <greg@chown.ath.cx>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
When we started adding extra stuff per array entry, growing the size of
those entries to more than sizeof(pid_t), we had to convert those sizeof
operations to the more robust sizeof(map->map[0]) idiom, that is future
proof, i.e. if/when we add more stuff to those entries, that expression
will produce the new per-entry size.
And besides that, we need to zero out those extra fields, that sometimes
may not get filled, like when we couldn't care less about the comms,
since we don't need those, but since we will try freeing it at
thread_map__delete(), we better fix it.
That is why a thread_map__realloc() was provided.
But that method wasn't used in thread_map__new_by_uid(), fix it.
Reported-by: Ingo Molnar <mingo@kernel.org>
Fixes: 792402fd5c ("perf thrad_map: Add comm string into array")
Fixes: 9d7e8c3a96 ("perf tools: Add thread_map__(alloc|realloc) helpers")
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/n/tip-6a0swlm6m8lnu3wpjv284hkb@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Let's do a frontbuffer flush on dirty fb.
To be used for DIRTYFB drm ioctl.
This patch solves the biggest PSR known issue, that is
missed screen updates during boot, mainly when there is a splash
screen involved like Plymouth.
Previously PSR was being invalidated by fbdev and Plymounth
was taking control with PSR yet invalidated and could get screen
updates normally. However with some atomic modeset changes
Pymouth modeset over ioctl was now causing frontbuffer flushes
making PSR gets back to work while it cannot track the
screen updates and exit properly.
By adding this flush on dirtyfb we properly track frontbuffer
writes and properly exit PSR.
Actually all mmap_wc users should call this dirty callback
in order to have a proper frontbuffer tracking.
In the future it can be extended to return 0 if the whole
screen has being flushed or the number of rects flushed
as Chris suggested.
v2: Remove ORIGIN_FB_DIRTY and use ORIGIN_GTT instead since dirty
callback is just called after few screen updates and not on
everyone as pointed by Daniel.
v3: Use flush instead of invalidate since flush means
invalidate + flush and dirty means drawn had finished and
it can be flushed.
v4: Remove PSR from subject since it is purely frontbuffer tracking
change and that can be useful for FBC as well.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Fix alignment as spotted by Paulo.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since flush actually means invalidate + flush we need to force psr
exit on PSR flush.
On Core platforms there is no way to disable hw tracking and
do the pure sw tracking so we simulate it by fully disable psr and
reschedule a enable back.
So a good idea is to minimize sequential disable/enable in cases we
know that HW tracking like when flush has been originated by a flip.
Also flip had just invalidated it already.
It also uses origin to minimize the a bit the amount of
disable/enabled, mainly when flip already had invalidated.
With this patch in place it is possible to do a flush on dirty areas
properly in a following patch.
v2: Remove duplicated exit on HSW+Sprites as pointed out by Paulo.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The Kodi/XBMC developers want to transcode NV12 to RGB with OpenGL
shaders, importing the two source planes through
EGL_EXT_image_dma_buf_import. That requires importing the Y plane as an
R8 EGLImage and the UV plane as either an RG88 or GR88 EGLImage.
CC: Peter Frühberger <peter.fruehberger@gmail.com>
Cc: Rainer Hochecker <rainer.hochecker@onlinehome.de>
Cc: Benjamin Widawsky <benjamin.widawsky@intel.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Signed-off-by: Chad Versace <chad.versace@intel.com>
The IRQCHIP_DECLARE macro migrated to 'include/linux/irqchip.h'.
See commit 91e20b5040
("irqchip: Move IRQCHIP_DECLARE macro to include/linux/irqchip.h").
This patch removes the inclusions of private header 'drivers/irqchip/irqchip.h'
and if necessary replaces them with inclusions of 'include/linux/irqchip.h'.
Signed-off-by: Joel Porquet <joel@porquet.org>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
ARCompact/ARCv2 ISA provide that any instructions which deals with
bitpos/count operand ASL, LSL, BSET, BCLR, BMSK .... will only consider
lower 5 bits. i.e. auto-clamp the pos to 0-31.
ARC Linux bitops exploited this fact by NOT explicitly masking out upper
bits for @nr operand in general, saving a bunch of AND/BMSK instructions
in generated code around bitops.
While this micro-optimization has worked well over years it is NOT safe
as shifting a number with a value, greater than native size is
"undefined" per "C" spec.
So as it turns outm EZChip ran into this eventually, in their massive
muti-core SMP build with 64 cpus. There was a test_bit() inside a loop
from 63 to 0 and gcc was weirdly optimizing away the first iteration
(so it was really adhering to standard by implementing undefined behaviour
vs. removing all the iterations which were phony i.e. (1 << [63..32])
| for i = 63 to 0
| X = ( 1 << i )
| if X == 0
| continue
So fix the code to do the explicit masking at the expense of generating
additional instructions. Fortunately, this can be mitigated to a large
extent as gcc has SHIFT_COUNT_TRUNCATED which allows combiner to fold
masking into shift operation itself. It is currently not enabled in ARC
gcc backend, but could be done after a bit of testing.
Fixes STAR 9000866918 ("unsafe "undefined behavior" code in kernel")
Reported-by: Noam Camus <noamc@ezchip.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
With up-to-date FPGA builds ARC cores are supposed to correctly operate
even with 90 MHz clock (which is a target frequency for AXS103 release).
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: arc-linux-dev@synopsys.com
Currently pdd is validate after dereferencing it, which is
not correct, Thus validate pdd before its first use.
Signed-off-by: Maninder Singh <maninder1.s@samsung.com>
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
Replace lw/sw and various arithmetic instructions with macros so the
code can work on 64-bit kernels as well.
Cc: <stable@vger.kernel.org> # 3.16+
Reviewed-by: Paul Burton <paul.burton@imgtec.com>
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: stable@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/10591/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
In preparation for 64-bit CPS support, we replace KSEG0 with CKSEG0
so 64-bit kernels can be supported.
Cc: <stable@vger.kernel.org> # 3.16+
Reviewed-by: Paul Burton <paul.burton@imgtec.com>
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: stable@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/10590/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The cps-vec code assumes O32 ABI and uses t4-t7 in quite a few places. This
breaks the build on 64-bit. As a result of which, use the pseudo-registers
ta0-ta3 to make the code compatible with 64-bit.
Cc: <stable@vger.kernel.org> # 3.16+
Reviewed-by: Paul Burton <paul.burton@imgtec.com>
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: stable@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/10589/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
mips32r2 is a subset of mips64r2, so we replace mips32r2 with mips64r2
in preparation for 64-bit CPS support.
Cc: <stable@vger.kernel.org> # 3.16+
Reviewed-by: Paul Burton <paul.burton@imgtec.com>
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: stable@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/10588/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The PTR_LA macro will pick the correct "la" or "dla" macro to
load an address to a register. This gets rids of the following
warnings (and others) when building a 64-bit CPS kernel:
arch/mips/kernel/cps-vec.S:63: Warning: la used to load 64-bit address
arch/mips/kernel/cps-vec.S:159: Warning: la used to load 64-bit address
arch/mips/kernel/cps-vec.S:220: Warning: la used to load 64-bit address
arch/mips/kernel/cps-vec.S:240: Warning: la used to load 64-bit address
[...]
Cc: <stable@vger.kernel.org> # 3.16+
Reviewed-by: Paul Burton <paul.burton@imgtec.com>
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: stable@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/10587/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Commit 1d8f1f5a78 ("MIPS: smp-cps: hotplug support") added hotplug
support in the SMP/CPS implementation but it introduced a few build problems
on 64-bit kernels due to pointer being casted to and from 'int' C types. We
fix this problem by using 'unsigned long' instead which should match the size
of the pointers in 32/64-bit kernels. Finally, we fix the comment since the
CM base address is loaded to v1($3) instead of v0.
Fixes the following build problems:
arch/mips/kernel/smp-cps.c: In function 'wait_for_sibling_halt':
arch/mips/kernel/smp-cps.c:366:17: error: cast from pointer to integer of
different size [-Werror=pointer-to-int-cast]
[...]
arch/mips/kernel/smp-cps.c: In function 'cps_cpu_die':
arch/mips/kernel/smp-cps.c:427:13: error: cast to pointer
from integer of different size [-Werror=int-to-pointer-cast]
cc1: all warnings being treated as errors
Fixes: 1d8f1f5a78 ("MIPS: smp-cps: hotplug support")
Cc: <stable@vger.kernel.org> # 3.16+
Reviewed-by: Paul Burton <paul.burton@imgtec.com>
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: stable@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/10586/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Commit 5f9f41c474 ("MIPS: kernel: Prepare
the JR instruction for emulation on MIPS R6") added support for
emulating the JR instruction on MIPS R6 cores but that introduced a bug
which could be triggered when hitting a JALR opcode because the code used
the wrong field in the 'r_format' struct to determine the instruction
opcode. This lead to crashes because an emulated JALR instruction was
treated as a JR one when the R6 emulator was turned off.
Fixes: 5f9f41c474 ("MIPS: kernel: Prepare the JR instruction for emulation on MIPS R6")
Cc: <stable@vger.kernel.org> # 4.0+
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: stable@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/10583/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Commits f1b44067c1 ("MIPS: Emulate the
new MIPS R6 B{L,G}T{Z,}{AL,}C instructions") and commit
a8ff66f52d ("MIPS: Emulate the new MIPS
R6 B{L,G}E{Z,}{AL,}C instructions") added support for emulating various
branch compact instructions. However, it missed the case for those which
use the old BLEZL and BGTZL opcodes leading to random crashes when the R6
emulator is disabled. We fix this by ensuring that the 'rt' field is not
zero which is always true for these branch compact instructions.
Fixes: f1b44067c1 ("MIPS: Emulate the new MIPS R6 B{L,G}T{Z,}{AL,}C instructions")
Fixes: a8ff66f52d ("MIPS: Emulate the new MIPS R6 B{L,G}E{Z,}{AL,}C instructions")
Cc: <stable@vger.kernel.org> # 4.0+
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: Markos Chandras <markos.chandras@imgtec.com>
Patchwork: https://patchwork.linux-mips.org/patch/10582/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
