Commit b6506981f8 ("ARM: unwind: support unwinding across multiple
stacks") updated the logic in the ARM unwinder to widen the bounds
within which SP is assumed to be valid, in order to allow the unwind to
traverse from the IRQ stack to the task stack. This is necessary, as
otherwise, unwinds started from the IRQ stack would terminate in the IRQ
exception handler, making stacktraces substantially less useful.
This turns out to be a mistake, as it breaks asynchronous unwinding
across exceptions, when the exception is taken before the stack frame is
consistent with the unwind info. For instance, in the following
backtrace:
...
generic_handle_arch_irq from call_with_stack+0x18/0x20
call_with_stack from __irq_svc+0x80/0x98
Exception stack(0xc7093e20 to 0xc7093e68)
3e20: b6a94a88 c7093ea0 00000008 00000000 c7093ea0 b7e127d0 00000051 c9220000
3e40: b6a94a88 b6a94a88 00000004 0002b000 0036b570 c7093e70 c040ca2c c0994a90
3e60: 20070013 ffffffff
__irq_svc from __copy_to_user_std+0x20/0x378
...
we need to apply the following unwind directives:
0xc099720c <__copy_to_user_std+0x1c>: @0xc295d1d4
Compact model index: 1
0x9b vsp = r11
0xb1 0x0d pop {r0, r2, r3}
0x84 0x81 pop {r4, r11, r14}
0xb0 finish
which tell us to switch to the frame pointer register R11 and proceed
with the unwind from that. However, having been interrupted 0x20 bytes
into the function:
c09971f0 <__copy_to_user_std>:
c09971f0: e59f3350 ldr r3, [pc, #848]
c09971f4: e243c001 sub ip, r3, #1
c09971f8: e05cc000 subs ip, ip, r0
c09971fc: 228cc001 addcs ip, ip, #1
c0997200: 205cc002 subscs ip, ip, r2
c0997204: 33a00000 movcc r0, #0
c0997208: e320f014 csdb
c099720c: e3a03000 mov r3, #0
c0997210: e92d481d push {r0, r2, r3, r4, fp, lr}
c0997214: e1a0b00d mov fp, sp
c0997218: e2522004 subs r2, r2, #4
the value for R11 recovered from the previous frame (__irq_svc) will be
a snapshot of its value before the exception was taken (0x0002b000),
which occurred at address __copy_to_user_std+0x20 (0xc0997210), when R11
had not been assigned its value yet.
This means we can never assume that the SP values recovered from the
stack or from the frame pointer are ever safe to use, given the need to
do asynchronous unwinding, and the only robust approach is to revert to
the previous approach, which is to derive bounds for SP based on the
initial value, and never update them.
We can make an exception, though: now that the IRQ stack switch is
guaranteed to occur in call_with_stack(), we can implement a special
case for this function, and use a different set of bounds based on the
knowledge that it will always unwind from R11 rather than SP. As
call_with_stack() is a hand-rolled assembly routine, this is guaranteed
to remain that way.
So let's do a partial revert of b6506981f8, and drop all manipulations
for sp_low and sp_high based on the information collected during the
unwind itself. To support call_with_stack(), set sp_low and sp_high
explicitly to values derived from R11 when we unwind that function.
The only downside is that, while unwinding an overflow of the vmap'ed
stack will work fine as before, we will no longer be able to produce a
backtrace that unwinds the overflow stack itself across the exception
that was raised due to the faulting access to the guard region. However,
this only affects exceptions caused by problems in the stack overflow
handling code itself, in which case the remaining backtrace is not that
relevant.
Fixes: b6506981f8 ("ARM: unwind: support unwinding across multiple stacks")
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
After simplifying the stack switch code in the IRQ exception handler by
deferring the actual stack switch to call_with_stack(), we no longer
need to special case the way we dump the exception stack, since it will
always be at the top of whichever stack was active when the exception
was taken.
So revert this special handling for the ARM unwinder.
This reverts commit 4ab6827081.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
The IRQ stacks series made some changes to the unwinder, to permit
unwinding across different stacks. This is needed because otherwise, the
call stack would terminate at the point where the stack switch between
the task stack and the IRQ stack occurs, which would defeat any
diagnostics that rely on timer interrupts, such as RCU stall detection.
Unfortunately, getting the unwind annotations correct turns out to be
difficult, given that this now involves a frame pointer which needs to
point into the right location in the task stack when unwinding from the
IRQ stack. Getting this wrong for an exception handling routine results
in the stack pointer to be unwound from the wrong location, causing any
subsequent unwind attempts to cause all kinds of issues, as reported by
Naresh here [0].
So let's simplify this, by deferring the stack switch to
call_with_stack(), which already has the correct unwind annotations, and
removing all the complicated handling of the stack frame from the IRQ
exception entrypoint itself.
[0] https://lore.kernel.org/all/CA+G9fYtpy8VgK+ag6OsA9TDrwi5YGU4hu7GM8xwpO7v6LrCD4Q@mail.gmail.com/
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
purge_persistent_grants() is scanning the grants list for persistent
grants being no longer in use by the backend. When having found such a
grant, it will be set to "invalid" and pushed to the tail of the list.
Instead of pushing it directly to the end of the list, add it first to
a temporary list, avoiding to scan those entries again in the main
list traversal. After having finished the scan, append the temporary
list to the grant list.
Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Link: https://lore.kernel.org/r/20220311103527.12931-1-jgross@suse.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Jonathan Lemon says:
====================
ptp: ocp: support for new firmware
This series contains support for new firmware features for
the timecard.
v1 -> v2: roundup() is not 32-bit safe, use DIV_ROUND_UP_ULL
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Add sysfs nodes for the frequency generator and signal counters.
Update SMA selector lists for these, and also add the new
'None', 'VCC' 'GND' selectors.
Signed-off-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The timecard now has 4 general purpose timestampers.
Signed-off-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Input signals can be steered to any of the frequency counters.
The counter measures the frequency over a number of seconds:
echo 0 > freq1/seconds = turns off measurement
echo 1 > freq1/seconds = sets period & turns on measurment.
Signed-off-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The signal generators can be programmed either via the sysfs
file or through a PTP_CLK_REQ_PEROUT ioctl request.
Signed-off-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Newer firmware provides 4 programmable signal generators, add
support for those here. The signal generators provide the
ability to set the period, duty cycle, phase offset, and polarity,
with new values defaulting to prior values.
The period and phase offset are specified in nanoseconds.
E.g: period [duty [phase [polarity]]]
echo 500000000 > signal # 1/2 second period
echo 1000000 40 100 > signal # 1ms period, 40% on, offset 100ns
echo 0 > signal # turn off generator
Signed-off-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add the ability to group sysfs nodes behind a firmware feature
check. This way non-present sysfs attributes are omitted on
older firmware, which does not have newer features.
This will be used in the upcoming patches which adds more
features to the timecard.
Signed-off-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
As there are may be 2 GNSS outputs, rename the first one for clarity.
This also works around a parsing issue when specifying selectors.
Signed-off-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This adds support for the "IN: None" selector, which disables
the input on a sma pin. This should be compatible with old firmware
(the firmware will ignore it if not supported).
Signed-off-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Assuming the firmware allows it, the direction of each SMA connector
is no longer fixed. Handle remapping directions for each pin.
Signed-off-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Here are the USB-serial updates for 5.18-rc1, including:
- a new "simple driver" for some Nokia phones
- a fix for pl2303 GS type detection
- another pl2303 device id
Included is also a clean up.
All have been in linux-next with no reported issues.
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQQHbPq+cpGvN/peuzMLxc3C7H1lCAUCYisTsAAKCRALxc3C7H1l
CLyHAQDU72G3kyrPkckbrVyhUGnCK875XEZHb+L7Z7OcbLACuAD/aXJg9qg64swI
veJ+HlxgUFi2oLq7AQOU8D9nlUPggAY=
=eZIY
-----END PGP SIGNATURE-----
Merge tag 'usb-serial-5.18-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-next
Johan writes:
USB-serial updates for 5.18-rc1
Here are the USB-serial updates for 5.18-rc1, including:
- a new "simple driver" for some Nokia phones
- a fix for pl2303 GS type detection
- another pl2303 device id
Included is also a clean up.
All have been in linux-next with no reported issues.
* tag 'usb-serial-5.18-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial:
USB: serial: usb_wwan: remove redundant assignment to variable i
USB: serial: pl2303: fix GS type detection
USB: serial: pl2303: add IBM device IDs
USB: serial: simple: add Nokia phone driver
When doing manual injection of the frame, it is required to check if the
TX FIFO is ready to accept the next word of the frame. For this we are
using 'readx_poll_timeout_atomic', the only problem is that before it
actually checks the status, is determining the time when to finish polling
the status. Which seems to be an expensive operation.
Therefore check the status of the TX FIFO before calling
'readx_poll_timeout_atomic'.
Doing this will improve the TX bitrate by ~70%. Because 99% the FIFO is
ready by that time. The measurements were done using iperf3.
Before:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.03 sec 55.2 MBytes 46.2 Mbits/sec 0 sender
[ 5] 0.00-10.04 sec 53.8 MBytes 45.0 Mbits/sec receiver
After:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.10 sec 95.0 MBytes 78.9 Mbits/sec 0 sender
[ 5] 0.00-10.11 sec 95.0 MBytes 78.8 Mbits/sec receiver
Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Remove dev_err() messages after platform_get_irq*() failures.
platform_get_irq() already prints an error.
Generated by: scripts/coccinelle/api/platform_get_irq.cocci
Signed-off-by: Yihao Han <hanyihao@vivo.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit bf08824a0f ("flow_dissector: Add support for HSR") added support for
HSR within the flow dissector. However, it only works for HSR in version
1. Version 0 uses a different Ether Type. Add support for it.
Reported-by: Anthony Harivel <anthony.harivel@linutronix.de>
Signed-off-by: Kurt Kanzenbach <kurt@linutronix.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
It is not recommened to use platform_get_resource(pdev, IORESOURCE_IRQ)
for requesting IRQ's resources any more, as they can be not ready yet in
case of DT-booting.
platform_get_irq() instead is a recommended way for getting IRQ even if
it was not retrieved earlier.
It also makes code simpler because we're getting "int" value right away
and no conversion from resource to int is required.
Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn>
Signed-off-by: David S. Miller <davem@davemloft.net>
platform_get_resource(pdev, IORESOURCE_IRQ, ..) relies on static
allocation of IRQ resources in DT core code, this causes an issue
when using hierarchical interrupt domains using "interrupts" property
in the node as this bypasses the hierarchical setup and messes up the
irq chaining.
In preparation for removal of static setup of IRQ resource from DT core
code use platform_get_irq() for DT users only.
While at it propagate error code in emac_dev_stop() in case
platform_get_irq_optional() fails.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Convert am65-cpsw driver and am65-cpsw ethtool to use Phylink APIs
as described at Documentation/networking/sfp-phylink.rst. All calls
to Phy APIs are replaced with their equivalent Phylink APIs.
No functional change intended. Use Phylink instead of conventional
Phylib, in preparation to add support for SGMII/QSGMII modes.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Currently in case of target hardware restart, we just reconfig and
re-enable the security keys and enable the network queues to start
data traffic back from where it was interrupted.
Many ath10k wifi chipsets have sequence numbers for the data
packets assigned by firmware and the mac sequence number will
restart from zero after target hardware restart leading to mismatch
in the sequence number expected by the remote peer vs the sequence
number of the frame sent by the target firmware.
This mismatch in sequence number will cause out-of-order packets
on the remote peer and all the frames sent by the device are dropped
until we reach the sequence number which was sent before we restarted
the target hardware
In order to fix this, we trigger a sta disconnect, in case of target
hw restart. After this there will be a fresh connection and thereby
avoiding the dropping of frames by remote peer.
The right fix would be to pull the entire data path into the host
which is not feasible or would need lots of complex changes and
will still be inefficient.
Tested on ath10k using WCN3990, QCA6174
Signed-off-by: Youghandhar Chintala <youghand@codeaurora.org>
Link: https://lore.kernel.org/r/20220308115325.5246-2-youghand@codeaurora.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Today's implementation of csum_shift() leads to branching based on
parity of 'offset'
000002f8 <csum_block_add>:
2f8: 70 a5 00 01 andi. r5,r5,1
2fc: 41 a2 00 08 beq 304 <csum_block_add+0xc>
300: 54 84 c0 3e rotlwi r4,r4,24
304: 7c 63 20 14 addc r3,r3,r4
308: 7c 63 01 94 addze r3,r3
30c: 4e 80 00 20 blr
Use first bit of 'offset' directly as input of the rotation instead of
branching.
000002f8 <csum_block_add>:
2f8: 54 a5 1f 38 rlwinm r5,r5,3,28,28
2fc: 20 a5 00 20 subfic r5,r5,32
300: 5c 84 28 3e rotlw r4,r4,r5
304: 7c 63 20 14 addc r3,r3,r4
308: 7c 63 01 94 addze r3,r3
30c: 4e 80 00 20 blr
And change to left shift instead of right shift to skip one more
instruction. This has no impact on the final sum.
000002f8 <csum_block_add>:
2f8: 54 a5 1f 38 rlwinm r5,r5,3,28,28
2fc: 5c 84 28 3e rotlw r4,r4,r5
300: 7c 63 20 14 addc r3,r3,r4
304: 7c 63 01 94 addze r3,r3
308: 4e 80 00 20 blr
Seems like only powerpc benefits from a branchless implementation.
Other main architectures like ARM or X86 get better code with
the generic implementation and its branch.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: David S. Miller <davem@davemloft.net>
When e.g. a WARN_ON() is encountered, we attempt to unwind the current
thread. To do this, we set frame.pc to unwind_backtrace, which means it
points at the beginning of the function. However, the rest of the state
is initialised from within the function, which means the function
prologue has already been run.
This can be confusing, and with a recent patch from Ard, can result in
the unwinder misbehaving if we want to be strict about the PC value.
If we correctly initialise the state so it is self-consistent (in other
words, set frame.pc to the location we are initialising it) then we
eliminate this confusion, and avoid possible future issues.
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
1) Leon removes useless includes from both mlx5 and mlx4
2) Tariq adds node awareness to some object allocations
3) Gal Cleanups and improvements to EEPROM query
4) Paul adds Software steering to Connection Tracking, to speed up
CT Rules insertion.
Paul Blakey Says:
=================
To improve insertion rate, this series allows for using software
steering API directly instead of going through the fs_core layer.
This can be done for CT because it doesn't need fs_core layer extra
facilities, such as autogroups, FTE IDs and modifications (which require
a copy of the flow key/mask). Skipping fs_core layer also allows to
create the software steering objects (dr_* objects) ahead of time and
re-use them for multiple rules, whereas software steering under fs_core
creates them on the fly and discards them. This in turn increased insertion
rate.
The series first introduces a lightweight CT flow steering provider
with the first implementations using fs_core layer, and moves CT to use it.
The next patches implement a provider using software steering directly,
bypassing fs_core, and uses it if software steering is available.
=================
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEGhZs6bAKwk/OTgTpSD+KveBX+j4FAmIq/HEACgkQSD+KveBX
+j7gigf+NLLA+CVqKNRDJKzxsuXR1zgsUdrQDhrPMX5UiBF+eDzYKB2qNlnT7eMy
fjwT0bNbQodShDIYQr5FuS6QnCL+yvVvSpqSVR/7VL1TmZD5MD/IbcydsXQW+OI3
AewFhm29/OblBHVpCPoOLfzgaLf5iK4zPyqy4t2/lBxmpAKb0jddwM3/5MKTCBI1
mTjUwEjrax2Qt2kUiTzXualUd2KJOlDlUrWv7yJUO4irFx9PAm/RiX/XcOeSPhVx
iYua1sdrdOi9jUA6TW1PG1R3wajArSV7ifIn2CzxpblwjTOOe79h6sjXrl2499f0
yfG4BuYTy5WTeCuapGZYDvTx/sDIKA==
=4H+C
-----END PGP SIGNATURE-----
Merge tag 'mlx5-updates-2022-03-10' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux
Saeed Mahameed says:
====================
mlx5-updates-2022-03-10
1) Leon removes useless includes from both mlx5 and mlx4
2) Tariq adds node awareness to some object allocations
3) Gal Cleanups and improvements to EEPROM query
4) Paul adds Software steering to Connection Tracking, to speed up
CT Rules insertion.
Paul Blakey Says:
=================
To improve insertion rate, this series allows for using software
steering API directly instead of going through the fs_core layer.
This can be done for CT because it doesn't need fs_core layer extra
facilities, such as autogroups, FTE IDs and modifications (which require
a copy of the flow key/mask). Skipping fs_core layer also allows to
create the software steering objects (dr_* objects) ahead of time and
re-use them for multiple rules, whereas software steering under fs_core
creates them on the fly and discards them. This in turn increased insertion
rate.
The series first introduces a lightweight CT flow steering provider
with the first implementations using fs_core layer, and moves CT to use it.
The next patches implement a provider using software steering directly,
bypassing fs_core, and uses it if software steering is available.
=================
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
While commit 6a01afcf84 ("mac80211: mesh: Free ie data when leaving
mesh") fixed a memory leak on mesh leave / teardown it introduced a
potential memory corruption caused by a double free when rejoining the
mesh:
ieee80211_leave_mesh()
-> kfree(sdata->u.mesh.ie);
...
ieee80211_join_mesh()
-> copy_mesh_setup()
-> old_ie = ifmsh->ie;
-> kfree(old_ie);
This double free / kernel panics can be reproduced by using wpa_supplicant
with an encrypted mesh (if set up without encryption via "iw" then
ifmsh->ie is always NULL, which avoids this issue). And then calling:
$ iw dev mesh0 mesh leave
$ iw dev mesh0 mesh join my-mesh
Note that typically these commands are not used / working when using
wpa_supplicant. And it seems that wpa_supplicant or wpa_cli are going
through a NETDEV_DOWN/NETDEV_UP cycle between a mesh leave and mesh join
where the NETDEV_UP resets the mesh.ie to NULL via a memcpy of
default_mesh_setup in cfg80211_netdev_notifier_call, which then avoids
the memory corruption, too.
The issue was first observed in an application which was not using
wpa_supplicant but "Senf" instead, which implements its own calls to
nl80211.
Fixing the issue by removing the kfree()'ing of the mesh IE in the mesh
join function and leaving it solely up to the mesh leave to free the
mesh IE.
Cc: stable@vger.kernel.org
Fixes: 6a01afcf84 ("mac80211: mesh: Free ie data when leaving mesh")
Reported-by: Matthias Kretschmer <mathias.kretschmer@fit.fraunhofer.de>
Signed-off-by: Linus Lüssing <ll@simonwunderlich.de>
Tested-by: Mathias Kretschmer <mathias.kretschmer@fit.fraunhofer.de>
Link: https://lore.kernel.org/r/20220310183513.28589-1-linus.luessing@c0d3.blue
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There are no legacy rates on 60GHz or sub-1GHz band, so modify the check.
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: MeiChia Chiu <MeiChia.Chiu@mediatek.com>
Link: https://lore.kernel.org/r/20220308021645.16272-1-MeiChia.Chiu@mediatek.com
[Ghz -> GHz]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Previous memory allocations in this function already use GFP_KERNEL, so
use __dev_alloc_skb() and an explicit GFP_KERNEL instead of an implicit
GFP_ATOMIC.
This gives more opportunities of successful allocation.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/194a0e2ff00c3fae88cc9fba47431747360c8242.1645345378.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Fix the following coccicheck warning:
./drivers/net/wireless/mac80211_hwsim.c:1040:0-23: WARNING:
hwsim_fops_rx_rssi should be defined with
DEFINE_DEBUGFS_ATTRIBUTE
Signed-off-by: Yihao Han <hanyihao@vivo.com>
Link: https://lore.kernel.org/r/20220218070228.6210-1-hanyihao@vivo.com
[fix indentation]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Remove the loaded hisi_dma driver and reload it, the driver fails
to work properly. The following error is reported in the kernel log:
[ 1475.597609] hisi_dma 0000:7b:00.0: Failed to allocate MSI vectors!
[ 1475.604915] hisi_dma: probe of 0000:7b:00.0 failed with error -28
As noted in "The MSI Driver Guide HOWTO"[1], the number of MSI
interrupt must be a power of two. The Kunpeng DMA driver allocates 30
MSI interrupts. As a result, no space left on device is reported
when the driver is reloaded and allocates interrupt vectors from the
interrupt domain.
This patch changes the number of interrupt vectors allocated by
hisi_dma driver to 32 to avoid this problem.
[1] https://www.kernel.org/doc/html/latest/PCI/msi-howto.html
Fixes: e9f08b6525 ("dmaengine: hisilicon: Add Kunpeng DMA engine support")
Signed-off-by: Jie Hai <haijie1@huawei.com>
Acked-by: Zhou Wang <wangzhou1@hisilicon.com>
Link: https://lore.kernel.org/r/20220216072101.34473-1-haijie1@huawei.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
For spdx, /* */ for *.h, remove extra space
Replacements
configurarion to configuration
inerrupts to interrupts
chanels to channels
Signed-off-by: Tom Rix <trix@redhat.com>
Link: https://lore.kernel.org/r/20220309020056.1026106-1-trix@redhat.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Convert the MediaTek UART APDMA Controller binding to DT schema.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Link: https://lore.kernel.org/r/20220217095242.13761-1-angelogioacchino.delregno@collabora.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
CORESIGHT_DEV_TYPE_NONE/CORESIGHT_DEV_SUBTYPE_XXXX_NONE values are not used
any where. Actual enumeration can start from 0. Just drop these unused enum
values.
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Mike Leach <mike.leach@linaro.org>
Cc: Leo Yan <leo.yan@linaro.org>
Cc: coresight@lists.linaro.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
Link: https://lore.kernel.org/r/1645005118-10561-1-git-send-email-anshuman.khandual@arm.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
ETMv3 driver enables PID tracing by directly using perf config from
userspace, this means the tracer will capture PID packets from root
namespace but the profiling session runs in non-root PID namespace.
Finally, the recorded packets can mislead perf reporting with the
mismatched PID values.
This patch changes to only enable PID tracing for root PID namespace.
Note, the hardware supports VMID tracing from ETMv3.5, but the driver
never enables VMID trace, this patch doesn't handle VMID trace (bit 30
in ETMCR register) particularly.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/20220204152403.71775-5-leo.yan@linaro.org
As commented in the function ctxid_pid_store(), it can cause the PID
values mismatching between context ID tracing and PID allocated in a
non-root namespace.
For this reason, when a process runs in non-root PID namespace, the
driver doesn't allow PID tracing and returns failure when access
contextID related sysfs nodes.
VMID works for virtual contextID when the kernel runs in EL2 mode with
VHE; on the other hand, the driver doesn't prevent users from accessing
it when programs run in the non-root namespace. Thus this can lead
to same issues with contextID described above.
This patch imposes the checking on VMID related sysfs knobs and returns
failure if current process runs in non-root PID namespace.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/20220204152403.71775-3-leo.yan@linaro.org
Updates to the values and the index are protected via the spinlock.
Ensure we use the same lock to read the value safely.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/20220204152403.71775-2-leo.yan@linaro.org
Currently with the check present in the module initialisation, it shouts
on all the systems irrespective of presence of coresight trace buffer
extensions.
Similar to Arm SPE perf driver, move the check for kernel page table
isolation from EL0 to the device probe stage instead of the module
initialisation so that it complains only on the systems that support TRBE.
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Mike Leach <mike.leach@linaro.org>
Cc: Leo Yan <leo.yan@linaro.org>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: coresight@lists.linaro.org
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Link: https://lore.kernel.org/r/20220203190159.3145272-1-sudeep.holla@arm.com
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
The spec says this:
P0 tracing support field. The permitted values are:
0b00 Tracing of load and store instructions as P0 elements is not
supported.
0b11 Tracing of load and store instructions as P0 elements is
supported, so TRCCONFIGR.INSTP0 is supported.
All other values are reserved.
The value we are looking for is 0b11 so simplify this. The double read
and && was a bit obfuscated.
Suggested-by: Suzuki Poulose <suzuki.poulose@arm.com>
Signed-off-by: James Clark <james.clark@arm.com>
Link: https://lore.kernel.org/r/20220203115336.119735-2-james.clark@arm.com
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Replace acpi_bus_get_device() that is going to be dropped with
acpi_fetch_acpi_dev().
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lore.kernel.org/r/5790600.lOV4Wx5bFT@kreacher
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
device_register() calls device_initialize(),
according to doc of device_initialize:
Use put_device() to give up your reference instead of freeing
* @dev directly once you have called this function.
To prevent potential memleak, use put_device() for error handling.
Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
Fixes: 85e2414c51 ("coresight: syscfg: Initial coresight system configuration")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20220124124121.8888-1-linmq006@gmail.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
It's impossible to program a valid value for TRCCONFIGR.QE
when TRCIDR0.QSUPP==0b10. In that case the following is true:
Q element support is implemented, and only supports Q elements without
instruction counts. TRCCONFIGR.QE can only take the values 0b00 or 0b11.
Currently the low bit of QSUPP is checked to see if the low bit of QE can
be written to, but as you can see when QSUPP==0b10 the low bit is cleared
making it impossible to ever write the only valid value of 0b11 to QE.
0b10 would be written instead, which is a reserved QE value even for all
values of QSUPP.
The fix is to allow writing the low bit of QE for any non zero value of
QSUPP.
This change also ensures that the low bit is always set, even when the
user attempts to only set the high bit.
Signed-off-by: James Clark <james.clark@arm.com>
Reviewed-by: Mike Leach <mike.leach@linaro.org>
Fixes: d8c6696208 ("coresight-etm4x: Controls pertaining to the reset, mode, pe and events")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20220120113047.2839622-2-james.clark@arm.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
TRBE implementations affected by Arm erratum #1902691 might corrupt trace
data or deadlock, when it's being written into the memory. Workaround this
problem in the driver, by preventing TRBE initialization on affected cpus.
The firmware must have disabled the access to TRBE for the kernel on such
implementations. This will cover the kernel for any firmware that doesn't
do this already. This just updates the TRBE driver as required.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Suzuki Poulose <suzuki.poulose@arm.com>
Cc: coresight@lists.linaro.org
Cc: linux-doc@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
Link: https://lore.kernel.org/r/1643120437-14352-8-git-send-email-anshuman.khandual@arm.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
TRBE implementations affected by Arm erratum #2038923 might get TRBE into
an inconsistent view on whether trace is prohibited within the CPU. As a
result, the trace buffer or trace buffer state might be corrupted. This
happens after TRBE buffer has been enabled by setting TRBLIMITR_EL1.E,
followed by just a single context synchronization event before execution
changes from a context, in which trace is prohibited to one where it isn't,
or vice versa. In these mentioned conditions, the view of whether trace is
prohibited is inconsistent between parts of the CPU, and the trace buffer
or the trace buffer state might be corrupted.
Work around this problem in the TRBE driver by preventing an inconsistent
view of whether the trace is prohibited or not based on TRBLIMITR_EL1.E by
immediately following a change to TRBLIMITR_EL1.E with at least one ISB
instruction before an ERET, or two ISB instructions if no ERET is to take
place. This just updates the TRBE driver as required.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Suzuki Poulose <suzuki.poulose@arm.com>
Cc: coresight@lists.linaro.org
Cc: linux-doc@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
Link: https://lore.kernel.org/r/1643120437-14352-7-git-send-email-anshuman.khandual@arm.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
TRBE implementations affected by Arm erratum #2064142 might fail to write
into certain system registers after the TRBE has been disabled. Under some
conditions after TRBE has been disabled, writes into certain TRBE registers
TRBLIMITR_EL1, TRBPTR_EL1, TRBBASER_EL1, TRBSR_EL1 and TRBTRG_EL1 will be
ignored and not be effected.
Work around this problem in the TRBE driver by executing TSB CSYNC and DSB
just after the trace collection has stopped and before performing a system
register write to one of the affected registers. This just updates the TRBE
driver as required.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Suzuki Poulose <suzuki.poulose@arm.com>
Cc: coresight@lists.linaro.org
Cc: linux-doc@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
Link: https://lore.kernel.org/r/1643120437-14352-6-git-send-email-anshuman.khandual@arm.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
