This patch changes a dtsi file to contain the thermal data
on RK3288 and later SoCs. This data will
enable a thermal shutdown over 90C.
Signed-off-by: Caesar Wang <caesar.wang@rock-chips.com>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
New updates to the ftrace generic code had ftrace_stub not always being
called when ftrace is off. This causes the static tracer to always save
and restore functions. But it also showed that when function tracing is
running, the function graph tracer can not. We should always check to see
if function graph tracing is running even if the function tracer is running
too. The function tracer code is not the only one that uses the hook to
function mcount.
Cc: Markos Chandras <Markos.Chandras@imgtec.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
DCAN1 is routed to CAN port (J11) when Profile 1 is selected on the
profile selection switch.
Provide information for DCAN1 pins and node but keep it disabled
by default. User has to manually enable it if Profile 1 is chosen.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Add "raminit-syscon" property to specify the RAMINIT register.
Add clock information.
Rename can nodes from "d_can" to "can" to be compliant
with the ePAPR specs.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Use syscon regmap to expose the Control module register space.
This register space is shared between many users e.g. DCAN, USB, display, etc.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Add DCAN support for AM437x GP EVM with both DCAN instances.
[Roger Q] Updated output pin to not use pull up.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: George Cherian <george.cherian@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Use syscon regmap to expose the Control module register space.
This register space is shared between many users e.g. DCAN, USB, display, etc.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
The board has 2 CAN ports but only the first one can be used.
Enable the first CAN port.
WAKEUP0 pin doesn't have INPUT enable bit so we just disable
weak PULLs.
The second CAN port cannot be used without hardware modification
so we don't enable the second port.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
The board has 2 CAN ports but only the first one can be used.
Enable the first CAN port.
WAKEUP0 pin doesn't have INPUT enable bit so we just disable
weak PULLs.
The second CAN port cannot be used without hardware modification
so we don't enable the second port.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Display and DCAN drivers use syscon regmap to access some registers
in the CORE control area. Add the syscon regmap node for this
area.
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Nishanth Menon <nm@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
cs.base is declared as a __u64 variable and vector is a u32 so this
causes a static checker warning. The user indeed can set "sipi_vector"
to any u32 value in kvm_vcpu_ioctl_x86_set_vcpu_events(), but the
value should really have 8-bit precision only.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Create a new header, and hide the device assignment functions there.
Move struct kvm_assigned_dev_kernel to assigned-dev.c by modifying
arch/x86/kvm/iommu.c to take a PCI device struct.
Based on a patch by Radim Krcmar <rkrcmark@redhat.com>.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Fix the issue with the ISA bit being lost in fixups that jump to labels
placed just before a section switch. Such a switch leads to the ISA bit
being lost, because GAS concludes there is no code that follows and
therefore the label refers to data. Use the `.insn' pseudo-op to
convince the tool this is not the case.
This lack of label annotation leads to microMIPS compilation errors
like:
mips-linux-gnu-ld: arch/mips/built-in.o: .fixup+0x3b8: Unsupported jump between ISA modes; consider recompiling with interlinking enabled.
mips-linux-gnu-ld: final link failed: Bad value
Signed-off-by: Maciej W. Rozycki <macro@codesourcery.com>
Signed-off-by: Steven J. Hill <Steven.Hill@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/8483/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
In the microMIPS encoding some memory access instructions have their
immediate offset reduced to 12 bits only. That does not match the GCC
`R' constraint we use in some places to satisfy the requirement,
resulting in build failures like this:
{standard input}: Assembler messages:
{standard input}:720: Error: macro used $at after ".set noat"
{standard input}:720: Warning: macro instruction expanded into multiple instructions
Fix the problem by defining a macro, `GCC_OFF12_ASM', that expands to
the right constraint depending on whether microMIPS or standard MIPS
code is produced. Also apply the fix to where `m' is used as in the
worst case this change does nothing, e.g. where the pointer was already
in a register such as a function argument and no further offset was
requested, and in the best case it avoids an extraneous sequence of up
to two instructions to load the high 20 bits of the address in the LL/SC
loop. This reduces the risk of lock contention that is the higher the
more instructions there are in the critical section between LL and SC.
Strictly speaking we could just bulk-replace `R' with `ZC' as the latter
constraint adjusts automatically depending on the ISA selected.
However it was only introduced with GCC 4.9 and we keep supporing older
compilers for the standard MIPS configuration, hence the slightly more
complicated approach I chose.
The choice of a zero-argument function-like rather than an object-like
macro was made so that it does not look like a function call taking the
C expression used for the constraint as an argument. This is so as not
to confuse the reader or formatting checkers like `checkpatch.pl' and
follows previous practice.
Signed-off-by: Maciej W. Rozycki <macro@codesourcery.com>
Signed-off-by: Steven J. Hill <Steven.Hill@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/8482/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Only allow 32-bit microMIPS builds, we're not ready yet for 64-bit
microMIPS support.
QEMU does have support for the 64-bit microMIPS ISA and with minor
tweaks it is possible to have a 64-bit processor emulated there that
runs microMIPS code, so despite the lack of actual 64-bit microMIPS
hardware there is a way to run 64-bit microMIPS Linux, but it can all be
considered early development and we are not there yet. Userland tools
are lacking too, e.g. GCC produces bad code:
{standard input}: Assembler messages:
{standard input}:380: Warning: wrong size instruction in a 16-bit branch delay slot
And our build fails early on, so disable the configuration, for the sake
of automatic random config checkers if nothing else. Whoever needs to
experiment with 64-bit microMIPS support can revert this change easily.
Signed-off-by: Maciej W. Rozycki <macro@codesourcery.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/8481/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Fix:
arch/mips/kernel/signal.c: In function 'handle_signal':
arch/mips/kernel/signal.c:533:21: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
unsigned int tmp = (unsigned int)current->mm->context.vdso;
^
arch/mips/kernel/signal.c:536:9: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
vdso = (void *)tmp;
^
cc1: all warnings being treated as errors
when building a 64-bit kernel.
This is not really a supported configuration, but the cast is wrong
either way, Linux makes the assumption that sizeof(void *) equals
sizeof(unsigned long) and therefore the latter type is expected to be
used where integer operations have to be applied to pointers for some
reason.
Signed-off-by: Maciej W. Rozycki <macro@codesourcery.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/8480/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The microMIPS microassembler is only suitable for configurations where
the kernel itself is built to microMIPS machine code and not where only
user microMIPS software is supported. The former is controlled with the
CPU_MICROMIPS configuration setting, whereas SYS_SUPPORTS_MICROMIPS is
used for the latter.
Not only that, but with a given microMIPS vs standard MIPS kernel
configuration only one microassembler is needed, that matches the ISA
selected -- CP0.Config3.ISAOnExc is mandatory on microMIPS processors,
so there is never a need to mix microMIPS and standard MIPS code.
Consequently build only the microassembler that matches the ISA selected
for the kernel.
Signed-off-by: Maciej W. Rozycki <macro@codesourcery.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/8479/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Add missing microMIPS support to Malta. Currently the kernel only
enables support for the instruction set for the SEAD-3 board despite the
fact processor features have nothing to do with the board a processor is
installed in.
In this case there is no way to run microMIPS software in a fully
supported way under Linux on QEMU. QEMU supports the emulation of a
Malta board, but does not emulate SEAD-3. Linux supports running
microMIPS code on a SEAD-3 board, but hardcodes such support to off on
an emulated Malta board even if the processor selected has the microMIPS
instruction set implemented.
Adding support for the SEAD-3 to QEMU is a major project. Flipping a
bit in the kernel that shouldn't have been cleared in the first place is
a trivial effort. Thus the answer is plain...
Signed-off-by: Maciej W. Rozycki <macro@codesourcery.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/8478/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Building a 64bit kernel for the SGI O2 (IP32) and the SGI Indy (IP22) uses
the 'vmlinux.32' target, which converts the output 64-bit 'vmlinux' image
into a 32-bit wrapped image. This is needed for certain revisions of the
IP22 and IP32 ARCS PROMs to boot correctly, but this target is missing
from the 'archhelp' info that is emitted by 'make help'.
Signed-off-by: Joshua Kinard <kumba@gentoo.org>
Cc: Linux MIPS List <linux-mips@linux-mips.org>
Patchwork: https://patchwork.linux-mips.org/patch/7991/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
