Allow to specify CR14, logout area, external damage code
and failed storage address.
Since more then one machine check can be indicated to the guest at
a time we need to combine all indication bits with already pending
requests.
Signed-off-by: Jens Freimann <jfrei@linux.vnet.ibm.com>
Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Reviewed-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
This patch adapts handling of local interrupts to be more compliant with
the z/Architecture Principles of Operation and introduces a data
structure
which allows more efficient handling of interrupts.
* get rid of li->active flag, use bitmap instead
* Keep interrupts in a bitmap instead of a list
* Deliver interrupts in the order of their priority as defined in the
PoP
* Use a second bitmap for sigp emergency requests, as a CPU can have
one request pending from every other CPU in the system.
Signed-off-by: Jens Freimann <jfrei@linux.vnet.ibm.com>
Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Reviewed-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
The 32bit external interrupt parameter is only valid for timing-alert and
service-signal interrupts.
Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
In preparation for the rework of the local interrupt injection code,
factor out injection routines from kvm_s390_inject_vcpu().
Signed-off-by: Jens Freimann <jfrei@linux.vnet.ibm.com>
Reviewed-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Define get_guest_storage_key which can be used to get the value of a guest
storage key. This compliments the functionality provided by the helper function
set_guest_storage_key. Both functions are needed for live migration of s390
guests that use storage keys.
Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
Reviewed-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
list_for_each_entry_safe() is necessary if list objects are deleted from
the list while traversing it. Not the case here, so we can use the base
list_for_each_entry variant.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Pull "Samsung driver update for v3.19" from Kukjin Kim:
- Change samsung serial dependencies for exynos7 (ARMv8)
* tag 'samsung-driver' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung:
serial: samsung: Fix serial config dependencies for exynos7
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Pull "Samsung PM 3rd updates for v3.19" from Kukjin Kim:
- exynos3250
: add PMU support
- PMU refactoring
: move restart code into PMU driver
: move restart code for exynos440 into clk driver
- use u8 for val[] in struct exynos_pmu_conf
Note that this branch is based on tags/samsung-exynos-v3.19
* tag 'samsung-pm-3' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung:
ARM: EXYNOS: use u8 for val[] in struct exynos_pmu_conf
ARM: EXYNOS: move restart code into pmu driver
clk: exynos5440: move restart code into clock driver
ARM: EXYNOS: add exynos3250 PMU support
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Without sorting this list is completely unreadable for ARCH=arm.
Signed-off-by: Konstantin Khlebnikov <k.khlebnikov@samsung.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Pull "Samsung exynos updates in arch/arm/mach-exynos/ for v3.19" from Kukjin Kim:
- add SOC_EXYNOS4415 config to be used in audio driver
- add support platform driver for exynos PMU
- move PMU specific definitions from common.h to exynos-pmu.h
- for exynos5420, add support PMU and Suspend-to-RAM
use MCPM call backs and call regulator core suspend prepare
and finish functions
NOTE:
including v3.19-next/non-critical-fixes, v3.19-next/cleanup-samsung
and v3.19-next/pm-samsung-2 branches
* tag 'samsung-exynos-v3.19' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung:
ARM: EXYNOS: Call regulator core suspend prepare and finish functions
ARM: EXYNOS: Use MCPM call-backs to support S2R on exynos5420
ARM: EXYNOS: Add Suspend-to-RAM support for exynos5420
ARM: EXYNOS: Add PMU support for exynos5420
ARM: EXYNOS: Move PMU specific definitions from common.h
ARM: EXYNOS: Add platform driver support for Exynos PMU
ARM: EXYNOS: Add support for exynos4415 SoC
ARM: EXYNOS: fix typo in static struct name "exynos5_list_diable_wfi_wfe"
ARM: EXYNOS: Fix CPU idle clock down after CPU off
ARM: EXYNOS: Remove unneeded __ref annotation for cpu_die function
ARM: EXYNOS: Move code from hotplug.c to platsmp.c
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Pull "Samsung 2nd cleanup for v3.19" from Kukjin Kim:
- remove unused static iomapping for exynos SoCs
: remove unused static iomapping from exynos4/5_iodesc table,
and related macros from mach/map.h and plat/map-s5p.h.
* tag 'samsung-cleanup-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung:
ARM: EXYNOS: Remove unused static iomapping
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Pull "Samsung non-critical-fixes for v3.19" from Kukjin Kim:
- fix typo in static struct name "exynos5_list_diable_wfi_wfe"
: it should be "exynos5_list_disable_wfi_wfe"
* tag 'samsung-fixes-v3.19' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung:
ARM: EXYNOS: fix typo in static struct name "exynos5_list_diable_wfi_wfe"
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
This is a specific implementation, <asm/unaligned.h> is the
multiplexer that has the arch-specific knowledge of which
of the implementations needs to be used, so include that.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
In 3-to-8 mux mode for the CS pins we need to set the PERI_SEL bit in the
control register. Currently the driver never sets this bit even when
configured for 3-to-8 mux mode. This patch adds code which sets the bit
during device initialization when necessary.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Harini Katakam <harinik@xilinx.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
When an NFC-DEP target receives an ATN PDU, its
supposed to respond with a similar ATN PDU.
When the Target receives an I PDU with the PNI
one less than the current PNI and the last PDU
sent was an ATN PDU, the Target is to resend the
last non-ATN PDU that it has sent. This is
described in section 14.12.3.4 of the NFC Digital
Protocol Spec.
The digital layer's NFC-DEP code doesn't implement
this so add that support.
Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com>
Tested-by: Thierry Escande <thierry.escande@linux.intel.com>
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
The xmax volume should be corrected to ARRAY_SIZE(volume_map)-1, otherwise,
the xmax value will be mapped to 0 wrongly.
Signed-off-by: Jie Yang <yang.jie@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
When an NFC-DEP Initiator times out when waiting for
a DEP_RES from the Target, its supposed to send an
ATN to the Target. The Target should respond to the
ATN with a similar ATN PDU and the Initiator can then
resend the last non-ATN PDU that it sent. No more
than 'N(retry,atn)' are to be send where
2 <= 'N(retry,atn)' <= 5. If the Initiator had just
sent a NACK PDU when the timeout occurred, it is to
continue sending NACKs until 'N(retry,nack)' NACKs
have been send. This is described in section
14.12.5.6 of the NFC-DEP Digital Protocol Spec.
The digital layer's NFC-DEP code doesn't implement
this so add that support.
The value chosen for 'N(retry,atn)' is 2.
Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com>
Tested-by: Thierry Escande <thierry.escande@linux.intel.com>
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
When an NFC-DEP Target receives a NACK PDU with
a PNI equal to 1 less than the current PNI, it
is supposed to re-send the last PDU. This is
implied in section 14.12.5.4 of the NFC Digital
Protocol Spec.
The digital layer's NFC-DEP code doesn't implement
Target-side NACK handing so add it. The last PDU
that was sent is saved in the 'nfc_digital_dev'
structure's 'saved_skb' member. The skb will have
an additional reference taken to ensure that the skb
isn't freed when the driver performs a kfree_skb()
on the skb. The length of the skb/PDU is also saved
so the length can be restored when re-sending the PDU
in the skb (the driver will perform an skb_pull() so
an skb_push() needs to be done to restore the skb's
data pointer/length).
Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com>
Tested-by: Thierry Escande <thierry.escande@linux.intel.com>
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
When an NFC-DEP Initiator receives a frame with
an incorrect CRC or with a parity error, and the
frame is at least 4 bytes long, its supposed to
send a NACK to the Target. The Initiator can
send up to 'N(retry,nack)' consecutive NACKs
where 2 <= 'N(retry,nack)' <= 5. When the limit
is exceeded, a PROTOCOL EXCEPTION is raised.
Any other type of transmission error is to be
ignored and the Initiator should continue
waiting for a new frame. This is described
in section 14.12.5.4 of the NFC Digital Protocol
Spec.
The digital layer's NFC-DEP code doesn't implement
any of this so add it. This support diverges from
the spec in two significant ways:
a) NACKs will be sent for ANY error reported by the
driver except a timeout. This is done because
there is currently no way for the digital layer
to distinguish a CRC or parity error from any
other type of error reported by the driver.
b) All other errors will cause a PROTOCOL EXCEPTION
even frames with CRC errors that are less than 4
bytes.
The value chosen for 'N(retry,nack)' is 2.
Targets do not send NACK PDUs.
Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com>
Tested-by: Thierry Escande <thierry.escande@linux.intel.com>
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
When the peer in an NFC-DEP exchange has a
packet to send that is larger than the local
maximum payload, it sets the 'MI' bit in the
'I' PDU. This indicates that NFC-DEP chaining
is to occur.
When such a PDU is received, the local side
responds with an 'ACK' PDU and this continues
until the peer sends an 'I' PDU with the 'MI'
bit cleared. This indicates that the chaining
sequence is complete and the entire packet has
been transferred.
Receiving chained PDUs is currently not supported
by the digital layer so add that support. When a
chaining sequence is initiated by the peer, the
digital layer will allocate an skb large enough
to hold 8 maximum sized frame payloads. The maximum
payload can range from 64 to 254 bytes so 8 * 254 =
2032 seems like a reasonable compromise between
potentially wasting memory and constantly reallocating
new, larger skbs.
Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com>
Tested-by: Thierry Escande <thierry.escande@linux.intel.com>
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
When the NFC-DEP code is given a packet to send
that is larger than the peer's maximum payload,
its supposed to set the 'MI' bit in the 'I' PDU's
Protocol Frame Byte (PFB). Setting this bit
indicates that NFC-DEP chaining is to occur.
When NFC-DEP chaining is progress, sender 'I' PDUs
are acknowledged with 'ACK' PDUs until the last 'I'
PDU in the chain (which has the 'MI' bit cleared)
is responded to with a normal 'I' PDU. This can
occur while in Initiator mode or in Target mode.
Sender NFC-DEP chaining is currently not implemented
in the digital layer so add that support. Unfortunately,
since sending a frame may require writing the CRC to the
end of the data, the relevant data part of the original
skb must be copied for each intermediate frame.
Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com>
Tested-by: Thierry Escande <thierry.escande@linux.intel.com>
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
The maximum payload for NFC-DEP exchanges (i.e., the
number of bytes between SoD and EoD) is negotiated
using the ATR_REQ, ATR_RES, and PSL_REQ commands.
The valid maximum lengths are 64, 128, 192, and 254
bytes.
Currently, NFC-DEP code assumes that both sides are
always using 254 byte maximums and ignores attempts
by the peer to change it. Instead, implement the
negotiation code, enforce the local maximum when
receiving data from the peer, and don't send payloads
that exceed the remote's maximum. The default local
maximum is 254 bytes.
Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com>
Tested-by: Thierry Escande <thierry.escande@linux.intel.com>
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
NFC-DEP DEP_REQ and DEP_RES exchanges using 'I'
and 'ACK/NACK' PDUs have a sequence number called
the Packet Number Information (PNI). The PNI
is incremented (modulo 4) after every DEP_REQ/
DEP_RES pair and should be verified by the digital
layer code. That verification isn't always done,
though, so add code to make sure that it is done.
Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com>
Tested-by: Thierry Escande <thierry.escande@linux.intel.com>
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
When in Target mode, the Initiator specifies whether
subsequent DEP_REQ and DEP_RES frames will include
a DID byte by the value passed in the ATR_REQ. If
the DID value in the ATR_REQ is '0' then no DID
byte will be included. If the DID value is between
'1' and '14' then a DID byte containing the same
value must be included in subsequent DEP_REQ and
DEP_RES frames. Any other DID value is invalid.
This is specified in sections 14.8.1.2 and 14.8.2.2
of the NFC Digital Protocol Spec.
Checking the DID value (if it should be there at all),
is not currently supported by the digital layer's
NFC-DEP code. Add this support by remembering the
DID value in the ATR_REQ, checking the DID value of
received DEP_REQ frames (if it should be there at all),
and including the remembered DID value in DEP_RES
frames when appropriate.
Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com>
Tested-by: Thierry Escande <thierry.escande@linux.intel.com>
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
When in Initiator mode, the digital layer's
NFC-DEP code always sets the Device ID (DID)
value in the ATR_REQ to '0'. This means that
subsequent DEP_REQ and DEP_RES frames must
never include a DID byte. This is specified
in sections 14.8.1.1 and 14.8.2.1 of the NFC
Digital Protocol Spec.
Currently, the digital layer's NFC-DEP code
doesn't enforce this rule so add code to ensure
that there is no DID byte in DEP_RES frames.
Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com>
Tested-by: Thierry Escande <thierry.escande@linux.intel.com>
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Rearrange some of the code in digital_in_recv_dep_res()
and digital_tg_recv_dep_req() so the initial code looks
similar. The real reason is prepare the code for some
upcoming patches that require these changes.
Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com>
Tested-by: Thierry Escande <thierry.escande@linux.intel.com>
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
When digital_in_send_cmd() or digital_tg_send_cmd()
fail, they do not free the skb that was passed to
them so the routine that allocated the skb should
free it. Currently, there are several routines in
the NFC-DEP code that don't do this so make them.
Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com>
Tested-by: Thierry Escande <thierry.escande@linux.intel.com>
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Pull "temporarily disable rk3288-smp" from Heiko Stuebner:
Disable smp again on rk3288 temporarily to make Olof's boottest
run again, until the patches for using the physical architected
timers got accepted.
* tag 'v3.19-rockchip-dts3' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip:
ARM: dts: rockchip: temporarily disable smp on rk3288
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The dma_mask and coherent_dma_mask need to be set or DMA memory allocations
will fail with error messages like this:
ep93xx-dma ep93xx-dma-m2p: coherent DMA mask is unset
ep93xx-dma ep93xx-dma-m2m: coherent DMA mask is unset
Add the missing information to the ep93xx-dma-m2p and ep93xx-dma-m2m
devices.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Reported-by: Jeremy Moles <cubicool@gmail.com>
Tested-by: Alexander Sverdlin <subaparts@yandex.ru>
Cc: Ryan Mallon <rmallon@gmail.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
When injecting a floating interrupt and no CPU is idle we
kick one CPU to do an external exit. In case of I/O we
should trigger an I/O exit instead. This does not matter
for Linux guests as external and I/O interrupts are
enabled/disabled at the same time, but play safe anyway.
The same holds true for machine checks. Since there is no
special exit, just reuse the generic stop exit. The injection
code inside the VCPU loop will recheck anyway and rearm the
proper exits (e.g. control registers) if necessary.
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: Thomas Huth <thuth@linux.vnet.ibm.com>
Reviewed-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
A couple of our interception handlers rewind the PSW to the beginning
of the instruction to run the intercepted instruction again during the
next SIE entry. This normally works fine, but there is also the
possibility that the instruction did not get run directly but via an
EXECUTE instruction.
In this case, the PSW does not point to the instruction that caused the
interception, but to the EXECUTE instruction! So we've got to rewind the
PSW to the beginning of the EXECUTE instruction instead.
This is now accomplished with a new helper function kvm_s390_rewind_psw().
Signed-off-by: Thomas Huth <thuth@linux.vnet.ibm.com>
Reviewed-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
This patch includes two small fixes for the PFMF handler: First, the
start address for PFMF has to be masked according to the current
addressing mode, which is now done with kvm_s390_logical_to_effective().
Second, the protection exceptions have a lower priority than the
specification exceptions, so the check for low-address protection
has to be moved after the last spot where we inject a specification
exception.
Signed-off-by: Thomas Huth <thuth@linux.vnet.ibm.com>
Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
This patch adds the ahci_st.c driver found on STMicroelectronics
stih41x consumer electronics SoC's into the STI arch section
of the maintainers file.
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Maxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
This option has been marked for deprecation and removal for
a little more than two years, but it's not been very clearly
signalled since it was always possible to just select it.
Make it unselectable now to signal anyone who's still using
it after all this time more clearly. They can still get it
back, but only by patching the kernel.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Replace the ARCH_NR_GPIOS-sized static array of GPIO descriptors by
dynamically-allocated arrays for each GPIO chip.
This change makes gpio_to_desc() perform in O(n) (where n is the number
of GPIO chips registered) instead of O(1), however since n is rarely
bigger than 1 or 2 no noticeable performance issue is expected.
Besides this provides more incentive for GPIO consumers to move to the
gpiod interface. One could use a O(log(n)) structure to link the GPIO
chips together, but considering the low limit of n the hypothetical
performance benefit is probably not worth the added complexity.
This patch uses kcalloc() in gpiochip_add(), which removes the ability
to add a chip before kcalloc() can operate. I am not aware of such
cases, but if someone bisects up to this patch then I will be proven
wrong...
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
gpiolib's gpiod_get_direction() function returns the EINVAL error
if .get_direction callback is not defined.
The patch implements the callback for mxs chip which is useful
for debugging.
Inspired by arch/arm/mach-at91/gpio.c
On the moment the patch is required to get the patch
"serial: mxs-auart: enable PPS support" working.
It is planned to introduce new mctrl_gpio helpers to avoid
gpiod_get_direction() function.
Signed-off-by: Janusz Uzycki <j.uzycki@elproma.com.pl>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Use dynamic allocation of GPIOs instead of looking at the gpio%u alias
in DT.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
secure_computing() is called first in syscall_trace_enter() so that
a system call will be aborted quickly without doing succeeding syscall
tracing if seccomp rules want to deny that system call.
On compat task, syscall numbers for system calls allowed in seccomp mode 1
are different from those on normal tasks, and so _NR_seccomp_xxx_32's need
to be redefined.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
SIGSYS is primarily used in secure computing to notify tracer of syscall
events. This patch allows signal handler on compat task to get correct
information with SA_SIGINFO specified when this signal is delivered.
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Those values (__NR_seccomp_*) are used solely in secure_computing()
to identify mode 1 system calls. If compat system calls have different
syscall numbers, asm/seccomp.h may override them.
Acked-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
If tracer modifies a syscall number to -1, this traced system call should
be skipped with a return value specified in x0.
This patch implements this semantics.
Please note:
* syscall entry tracing and syscall exit tracing (ftrace tracepoint and
audit) are always executed, if enabled, even when skipping a system call
(that is, -1).
In this way, we can avoid a potential bug where audit_syscall_entry()
might be called without audit_syscall_exit() at the previous system call
being called, that would cause OOPs in audit_syscall_entry().
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
[will: fixed up conflict with blr rework]
Signed-off-by: Will Deacon <will.deacon@arm.com>
