History log of /openbmc/linux/arch/xtensa/kernel/entry.S (Results 226 – 250 of 765)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 49e41801 10-Jan-2019 James Morris <james.morris@microsoft.com>

Merge tag 'v5.0-rc1' into next-general

Linux 5.0-rc1

Sync to pick up LSM stacking work (which is based on -rc1).


# 3eb0930a 08-Jan-2019 Jani Nikula <jani.nikula@intel.com>

Merge drm/drm-next into drm-intel-next-queued

Generally catch up with 5.0-rc1, and specifically get the changes:

96d4f267e40f ("Remove 'type' argument from access_ok() function")
0b2c8f8b6b0c ("i91

Merge drm/drm-next into drm-intel-next-queued

Generally catch up with 5.0-rc1, and specifically get the changes:

96d4f267e40f ("Remove 'type' argument from access_ok() function")
0b2c8f8b6b0c ("i915: fix missing user_access_end() in page fault exception case")
594cc251fdd0 ("make 'user_access_begin()' do 'access_ok()'")

Signed-off-by: Jani Nikula <jani.nikula@intel.com>

show more ...


# d538d94f 04-Jan-2019 Michael Ellerman <mpe@ellerman.id.au>

Merge branch 'master' into fixes

We have a fix to apply on top of commit 96d4f267e40f ("Remove 'type'
argument from access_ok() function"), so merge master to get it.


# 9ef10340 29-Dec-2018 Linus Torvalds <torvalds@linux-foundation.org>

Merge tag 'xtensa-20181228' of git://github.com/jcmvbkbc/linux-xtensa

Pull Xtensa updates from Max Filippov:

- switch to generated syscall table

- switch ptrace to regsets, use regsets for core

Merge tag 'xtensa-20181228' of git://github.com/jcmvbkbc/linux-xtensa

Pull Xtensa updates from Max Filippov:

- switch to generated syscall table

- switch ptrace to regsets, use regsets for core dumps

- complete tracehook implementation

- add syscall tracepoints support

- add jumplabels support

- add memtest support

- drop unused/duplicated code from entry.S, ptrace.c, coprocessor.S,
elf.h and syscall.h

- clean up warnings caused by WSR/RSR macros

- clean up DTC warnings about SPI controller node names in xtfpga.dtsi

- simplify coprocessor.S

- get rid of explicit 'l32r' instruction usage in assembly

* tag 'xtensa-20181228' of git://github.com/jcmvbkbc/linux-xtensa: (25 commits)
xtensa: implement jump_label support
xtensa: implement syscall tracepoints
xtensa: implement tracehook functions and enable HAVE_ARCH_TRACEHOOK
xtensa: enable CORE_DUMP_USE_REGSET
xtensa: implement TIE regset
xtensa: implement task_user_regset_view
xtensa: call do_syscall_trace_{enter,leave} selectively
xtensa: use NO_SYSCALL instead of -1
xtensa: define syscall_get_arch()
Move EM_XTENSA to uapi/linux/elf-em.h
xtensa: support memtest
xtensa: don't use l32r opcode directly
xtensa: xtfpga.dtsi: fix dtc warnings about SPI
xtensa: don't clear cpenable unconditionally on release
xtensa: simplify coprocessor.S
xtensa: clean up WSR*/RSR*/get_sr/set_sr
xtensa: drop unused declarations from elf.h
xtensa: clean up syscall.h
xtensa: drop unused coprocessor helper functions
xtensa: drop custom PTRACE_{PEEK,POKE}{TEXT,DATA}
...

show more ...


# 3aee3e25 15-Nov-2018 Max Filippov <jcmvbkbc@gmail.com>

xtensa: call do_syscall_trace_{enter,leave} selectively

Check whether calls to do_syscall_trace_{enter,leave} are necessary in
the system_call function. Define _TIF_WORK_MASK to a bitmask of flags
t

xtensa: call do_syscall_trace_{enter,leave} selectively

Check whether calls to do_syscall_trace_{enter,leave} are necessary in
the system_call function. Define _TIF_WORK_MASK to a bitmask of flags
that reuire the calls. Fix comment.

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>

show more ...


# 6a986984 09-Nov-2018 Max Filippov <jcmvbkbc@gmail.com>

xtensa: use NO_SYSCALL instead of -1

For the sake of clarity define macro NO_SYSCALL and use it for
setting/checking struct pt_regs::syscall field.

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>


# 8ed3a542 15-Nov-2018 Max Filippov <jcmvbkbc@gmail.com>

xtensa: drop fast_syscall_kernel

There must be no xtensa-specific syscalls from the kernel code: register
spilling uses call+entry sequence and atomics have proper function
implementations. Drop fas

xtensa: drop fast_syscall_kernel

There must be no xtensa-specific syscalls from the kernel code: register
spilling uses call+entry sequence and atomics have proper function
implementations. Drop fast_syscall_xtensa.

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>

show more ...


# a86067f5 13-Nov-2018 Firoz Khan <firoz.khan@linaro.org>

xtensa: add __NR_syscalls along with __NR_syscall_count

__NR_syscall_count macro holds the number of system call
exist in xtensa architecture. We have to change the value
of __NR_syscall_count, if w

xtensa: add __NR_syscalls along with __NR_syscall_count

__NR_syscall_count macro holds the number of system call
exist in xtensa architecture. We have to change the value
of __NR_syscall_count, if we add or delete a system call.

One of the patch in this patch series has a script which
will generate a uapi header based on syscall.tbl file.
The syscall.tbl file contains the total number of system
calls information. So we have two option to update __NR-
_syscall_count value.

1. Update __NR_syscall_count in asm/unistd.h manually by
counting the no.of system calls. No need to update __NR-
_syscall_count until we either add a new system call or
delete existing system call.

2. We can keep this feature it above mentioned script,
that will count the number of syscalls and keep it in
a generated file. In this case we don't need to expli-
citly update __NR_syscall_count in asm/unistd.h file.

The 2nd option will be the recommended one. For that, I
added the __NR_syscalls macro in uapi/asm/unistd.h.
The macro __NR_syscalls also added for making the name
convention same across all architecture. While __NR_syscalls
isn't strictly part of the uapi, having it as part of the
generated header to simplifies the implementation. We also
need to enclose this macro with #ifdef __KERNEL__ to avoid
side effects.

Signed-off-by: Firoz Khan <firoz.khan@linaro.org>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
[Max: Drop __NR_syscall_count completely, use __NR_syscalls instead]

show more ...


# 415d2b33 20-Aug-2018 Jiri Kosina <jkosina@suse.cz>

Merge branch 'for-4.19/cougar' into for-linus

New device support for hid-cougar


# a3479c7f 24-Jul-2018 Andreas Gruenbacher <agruenba@redhat.com>

Merge branch 'iomap-write' into linux-gfs2/for-next

Pull in the gfs2 iomap-write changes: Tweak the existing code to
properly support iomap write and eliminate an unnecessary special case
in gfs2_bl

Merge branch 'iomap-write' into linux-gfs2/for-next

Pull in the gfs2 iomap-write changes: Tweak the existing code to
properly support iomap write and eliminate an unnecessary special case
in gfs2_block_map. Implement iomap write support for buffered and
direct I/O. Simplify some of the existing code and eliminate code that
is no longer used:

gfs2: Remove gfs2_write_{begin,end}
gfs2: iomap direct I/O support
gfs2: gfs2_extent_length cleanup
gfs2: iomap buffered write support
gfs2: Further iomap cleanups

This is based on the following changes on the xfs 'iomap-4.19-merge'
branch:

iomap: add private pointer to struct iomap
iomap: add a page_done callback
iomap: generic inline data handling
iomap: complete partial direct I/O writes synchronously
iomap: mark newly allocated buffer heads as new
fs: factor out a __generic_write_end helper

Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>

show more ...


# c74a7469 23-Jul-2018 Rodrigo Vivi <rodrigo.vivi@intel.com>

Merge drm/drm-next into drm-intel-next-queued

We need a backmerge to get DP_DPCD_REV_14 before we push other
i915 changes to dinq that could break compilation.

Signed-off-by: Rodrigo Vivi <rodrigo.

Merge drm/drm-next into drm-intel-next-queued

We need a backmerge to get DP_DPCD_REV_14 before we push other
i915 changes to dinq that could break compilation.

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

show more ...


# d5e748ff 23-Jul-2018 Benjamin Herrenschmidt <benh@kernel.crashing.org>

Merge remote-tracking branch 'gpio/ib-aspeed' into upstream-ready

Merge the GPIO tree "ib-aspeed" topic branch which contains pre-requisites
for subsequent changes. This branch is also in gpio "next

Merge remote-tracking branch 'gpio/ib-aspeed' into upstream-ready

Merge the GPIO tree "ib-aspeed" topic branch which contains pre-requisites
for subsequent changes. This branch is also in gpio "next".

show more ...


# 6b16f5d1 28-Jun-2018 Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

Merge tag 'v4.18-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into fbdev-for-next

Linux 4.18-rc2


# 57b54d74 25-Jun-2018 James Morris <james.morris@microsoft.com>

Merge tag 'v4.18-rc2' into next-general

Merge to Linux 4.18-rc2 for security subsystem developers.


# 7731b8bc 22-Jun-2018 Thomas Gleixner <tglx@linutronix.de>

Merge branch 'linus' into x86/urgent

Required to queue a dependent fix.


# 050e9baa 13-Jun-2018 Linus Torvalds <torvalds@linux-foundation.org>

Kbuild: rename CC_STACKPROTECTOR[_STRONG] config variables

The changes to automatically test for working stack protector compiler
support in the Kconfig files removed the special STACKPROTECTOR_AUTO

Kbuild: rename CC_STACKPROTECTOR[_STRONG] config variables

The changes to automatically test for working stack protector compiler
support in the Kconfig files removed the special STACKPROTECTOR_AUTO
option that picked the strongest stack protector that the compiler
supported.

That was all a nice cleanup - it makes no sense to have the AUTO case
now that the Kconfig phase can just determine the compiler support
directly.

HOWEVER.

It also meant that doing "make oldconfig" would now _disable_ the strong
stackprotector if you had AUTO enabled, because in a legacy config file,
the sane stack protector configuration would look like

CONFIG_HAVE_CC_STACKPROTECTOR=y
# CONFIG_CC_STACKPROTECTOR_NONE is not set
# CONFIG_CC_STACKPROTECTOR_REGULAR is not set
# CONFIG_CC_STACKPROTECTOR_STRONG is not set
CONFIG_CC_STACKPROTECTOR_AUTO=y

and when you ran this through "make oldconfig" with the Kbuild changes,
it would ask you about the regular CONFIG_CC_STACKPROTECTOR (that had
been renamed from CONFIG_CC_STACKPROTECTOR_REGULAR to just
CONFIG_CC_STACKPROTECTOR), but it would think that the STRONG version
used to be disabled (because it was really enabled by AUTO), and would
disable it in the new config, resulting in:

CONFIG_HAVE_CC_STACKPROTECTOR=y
CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
CONFIG_CC_STACKPROTECTOR=y
# CONFIG_CC_STACKPROTECTOR_STRONG is not set
CONFIG_CC_HAS_SANE_STACKPROTECTOR=y

That's dangerously subtle - people could suddenly find themselves with
the weaker stack protector setup without even realizing.

The solution here is to just rename not just the old RECULAR stack
protector option, but also the strong one. This does that by just
removing the CC_ prefix entirely for the user choices, because it really
is not about the compiler support (the compiler support now instead
automatially impacts _visibility_ of the options to users).

This results in "make oldconfig" actually asking the user for their
choice, so that we don't have any silent subtle security model changes.
The end result would generally look like this:

CONFIG_HAVE_CC_STACKPROTECTOR=y
CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
CONFIG_STACKPROTECTOR=y
CONFIG_STACKPROTECTOR_STRONG=y
CONFIG_CC_HAS_SANE_STACKPROTECTOR=y

where the "CC_" versions really are about internal compiler
infrastructure, not the user selections.

Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

show more ...


# 552c69b3 02-May-2018 John Johansen <john.johansen@canonical.com>

Merge tag 'v4.17-rc3' into apparmor-next

Linux v4.17-rc3

Merge in v4.17 for LSM updates

Signed-off-by: John Johansen <john.johansen@canonical.com>


# 664b0bae 04-Apr-2018 Dmitry Torokhov <dmitry.torokhov@gmail.com>

Merge branch 'next' into for-linus

Prepare input updates for 4.17 merge window.


# c6380ecd 08-Mar-2018 Dmitry Torokhov <dmitry.torokhov@gmail.com>

Merge tag 'v4.16-rc4' into next

Sync up with mainline to bring in RAVE MFD device core.


# 5fe9cfbe 07-Mar-2018 Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

Merge tag 'v4.16-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into fbdev-for-next

Linux 4.16-rc4


# bba73071 01-Mar-2018 Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

Merge drm-next into drm-intel-next-queued (this time for real)

To pull in the HDCP changes, especially wait_for changes to drm/i915
that Chris wants to build on top of.

Signed-off-by: Joonas Lahtin

Merge drm-next into drm-intel-next-queued (this time for real)

To pull in the HDCP changes, especially wait_for changes to drm/i915
that Chris wants to build on top of.

Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

show more ...


# a02633e9 21-Feb-2018 James Morris <jmorris@namei.org>

Merge tag 'v4.16-rc2' into next-general

Sync to Linux 4.16-rc2 for developers to work against.


# d4da404f 16-Feb-2018 Sean Paul <seanpaul@chromium.org>

Merge airlied/drm-next into drm-misc-next

Backmerge 4.15 and hdcp topic branch

Signed-off-by: Sean Paul <seanpaul@chromium.org>


# 6dee6ae9 16-Feb-2018 Thomas Gleixner <tglx@linutronix.de>

Merge tag 'irqchip-4.16-2' of git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/urgent

Pull irqchip updates for 4.16-rc2 from Marc Zyngier

- A MIPS GIC fix for spurious, mas

Merge tag 'irqchip-4.16-2' of git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/urgent

Pull irqchip updates for 4.16-rc2 from Marc Zyngier

- A MIPS GIC fix for spurious, masked interrupts
- A fix for a subtle IPI bug in GICv3
- Do not probe GICv3 ITSs that are marked as disabled
- Multi-MSI support for GICv2m
- Various cleanups

show more ...


# 191db1ce 14-Feb-2018 Mark Brown <broonie@kernel.org>

Merge branch 'topic/component-platform' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into asoc-samsung


12345678910>>...31