docs: submitting-patches: Fix crossref to 'The canonical patch format'
The reference to `explicit_in_reply_to` is pointless as when the
reference was added in the form of "#15" [1], Section 15) was "The
canonical patch format".
The reference of "#15" had not been properly updated in a couple of
reorganizations during the plain-text SubmittingPatches era.
Fix it by using `the_canonical_patch_format`.
[1]: 2ae19acaa50a ("Documentation: Add "how to write a good patch summary" to SubmittingPatches")
Signed-off-by: Akira Yokosawa <akiyks@gmail.com> Fixes: 5903019b2a5e ("Documentation/SubmittingPatches: convert it to ReST markup") Fixes: 9b2c76777acc ("Documentation/SubmittingPatches: enrich the Sphinx output") Cc: Jonathan Corbet <corbet@lwn.net> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: stable@vger.kernel.org # v4.9+ Link: https://lore.kernel.org/r/64e105a5-50be-23f2-6cae-903a2ea98e18@gmail.com Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Andy Shevchenko [Thu, 14 Apr 2022 13:15:59 +0000 (16:15 +0300)]
iio: imu: adis16480: Improve getting the optional clocks
The extended clocks are optional and may not be present for some
configurations supported by this driver. Nevertheless, in case
the clock is provided but some error happens during its getting,
that error handling should be done properly.
Use devm_clk_get_optional() API and report possible errors using
dev_err_probe() to handle properly -EPROBE_DEFER error.
Colin Ian King [Mon, 18 Apr 2022 13:46:03 +0000 (14:46 +0100)]
staging: iio: ad2s1210: remove redundant assignment to variable negative
Variable negative is being assigned a value that is never read, it is
being re-assigned later. The assignment is redundant and can be removed.
Cleans up clang scan build warning:
drivers/staging/iio/resolver/ad2s1210.c:502:3: warning: Value stored
to 'negative' is never read [deadcode.DeadStores]
iio: adc: sc27xx: structure adjustment and optimization
Introduce one variant device data structure to be compatible
with SC2731 PMIC since it has different scale and ratio calculation
and so on. also rename the SC27xx to SC2731 for some definition
and function.
iio: adc: sc27xx: Fine tune the scale calibration values
Small adjustment the scale calibration value for the sc2731,
use new name sc2731_[big|small]_scale_graph_calib, and remove
the origin [big|small]_scale_graph_calib struct for unused.
iio: proximity: stk3310: Export near level property for proximity sensor
This makes the value from which an object should be considered "near"
available to userspace. This hardware-dependent value should be set
in the device-tree.
Miaoqian Lin [Tue, 12 Apr 2022 06:42:09 +0000 (06:42 +0000)]
iio: proximity: vl53l0x: Fix return value check of wait_for_completion_timeout
wait_for_completion_timeout() returns unsigned long not int.
It returns 0 if timed out, and positive if completed.
The check for <= 0 is ambiguous and should be == 0 here
indicating timeout which is the only error case.
Miaoqian Lin [Tue, 12 Apr 2022 06:51:45 +0000 (06:51 +0000)]
iio: adc: stmpe-adc: Fix wait_for_completion_timeout return value check
wait_for_completion_timeout() returns unsigned long not long.
it returns 0 if timed out, and positive if completed.
The check for <= 0 is ambiguous and should be == 0 here
indicating timeout which is the only error case
Fixes: e813dde6f833 ("iio: stmpe-adc: Use wait_for_completion_timeout") Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Reviewed-by: Philippe Schenker <philippe.schenker@toradex.com> Link: https://lore.kernel.org/r/20220412065150.14486-1-linmq006@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
iio: adc: Kconfig: Make RZG2L_ADC depend on ARCH_RZG2L
ADC block is common on Renesas RZ/G2L and RZ/V2L SoC's, so instead of
adding dependency for each SoC's add dependency on ARCH_RZG2L. The
ARCH_RZG2L config option is already selected by ARCH_R9A07G044 and
ARCH_R9A07G054.
Add device bindings for asm330lhhx IMU sensor.
Use lsm6dsr as fallback device for asm330lhhx since it implements all
the features currently supported by asm330lhhx.
Add support to STM ASM330LHHX (acc + gyro) automotive Mems sensor.
The ASM330LHHX sensor can use LSM6DSR as fallback device since it
implements all the ASM330LHHX features currently implemented in
st_lsm6dsx.
Miquel Raynal [Mon, 7 Feb 2022 14:38:40 +0000 (15:38 +0100)]
iio: core: Clarify the modes
As part of a previous discussion with Jonathan Cameron [1], it appeared
necessary to clarify the meaning of each mode so that new developers
could understand better what they should use or not use and when.
The idea of renaming these modes as been let aside because naming is a
big deal and requires a lot of thinking. So for now let's focus on
correctly explaining what each mode implies.
Merge tag 'platform-drivers-x86-v5.18-3' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86
Pull x86 platform driver fixes from Hans de Goede:
"Highlights:
- asus-wmi bug-fixes
- intel-sdsu bug-fixes
- build (warning) fixes
- couple of hw-id additions"
* tag 'platform-drivers-x86-v5.18-3' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86:
platform/x86/intel: pmc/core: change pmc_lpm_modes to static
platform/x86/intel/sdsi: Fix bug in multi packet reads
platform/x86/intel/sdsi: Poll on ready bit for writes
platform/x86/intel/sdsi: Handle leaky bucket
platform/x86: intel-uncore-freq: Prevent driver loading in guests
platform/x86: gigabyte-wmi: added support for B660 GAMING X DDR4 motherboard
platform/x86: dell-laptop: Add quirk entry for Latitude 7520
platform/x86: asus-wmi: Fix driver not binding when fan curve control probe fails
platform/x86: asus-wmi: Potential buffer overflow in asus_wmi_evaluate_method_buf()
tools/power/x86/intel-speed-select: fix build failure when using -Wl,--as-needed
Merge tag 'regulator-fix-v5.18-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fix from Mark Brown:
"A minor fix for the DT binding documentation of the rt5190a driver"
* tag 'regulator-fix-v5.18-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: dt-bindings: Revise the rt5190a buck/ldo description
// Send 2 data segments
+0 write(4, ..., 2000) = 2000
+0 > P. 1:2001(2000) ack 1
// TLP
+.022 > P. 1001:2001(1000) ack 1
// Continue to send 8 data segments
+0 write(4, ..., 10000) = 10000
+0 > P. 2001:10001(8000) ack 1
// RTO
+.188 > . 1:1001(1000) ack 1
// The original data is acked and new data is sent(F-RTO step 2.b)
+0 < . 1:1(0) ack 2001 win 257
+0 > P. 10001:12001(2000) ack 1
// D-SACK caused by TLP is regarded as a dupack, this results in
// the incorrect judgment of "loss was real"(F-RTO step 3.a)
+.022 < . 1:1(0) ack 2001 win 257 <sack 1001:2001,nop,nop>
// Never-retransmitted data(3001:4001) are acked and
// expect to switch to open state(F-RTO step 3.b)
+0 < . 1:1(0) ack 4001 win 257
+0 %{ assert tcpi_ca_state == 0, tcpi_ca_state }%
Fixes: e33099f96d99 ("tcp: implement RFC5682 F-RTO") Signed-off-by: Pengcheng Yang <yangpc@wangsu.com> Acked-by: Neal Cardwell <ncardwell@google.com> Tested-by: Neal Cardwell <ncardwell@google.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://lore.kernel.org/r/1650967419-2150-1-git-send-email-yangpc@wangsu.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Darrick J. Wong [Tue, 26 Apr 2022 01:38:24 +0000 (18:38 -0700)]
xfs: rename xfs_*alloc*_log_count to _block_count
These functions return the maximum number of blocks that could be logged
in a particular transaction. "log count" is confusing since there's a
separate concept of a log (operation) count in the reservation code, so
let's change it to "block count" to be less confusing.
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de>
Darrick J. Wong [Tue, 26 Apr 2022 01:38:15 +0000 (18:38 -0700)]
xfs: rewrite xfs_reflink_end_cow to use intents
Currently, the code that performs CoW remapping after a write has this
odd behavior where it walks /backwards/ through the data fork to remap
extents in reverse order. Earlier, we rewrote the reflink remap
function to use deferred bmap log items instead of trying to cram as
much into the first transaction that we could. Now do the same for the
CoW remap code. There doesn't seem to be any performance impact; we're
just making better use of code that we added for the benefit of reflink.
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de>
Darrick J. Wong [Tue, 26 Apr 2022 01:38:14 +0000 (18:38 -0700)]
xfs: reduce transaction reservations with reflink
Before to the introduction of deferred refcount operations, reflink
would try to cram refcount btree updates into the same transaction as an
allocation or a free event. Mainline XFS has never actually done that,
but we never refactored the transaction reservations to reflect that we
now do all refcount updates in separate transactions. Fix this to
reduce the transaction reservation size even farther, so that between
this patch and the previous one, we reduce the tr_write and tr_itruncate
sizes by 66%.
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de>
Darrick J. Wong [Tue, 26 Apr 2022 01:38:14 +0000 (18:38 -0700)]
xfs: reduce the absurdly large log operation count
Back in the early days of reflink and rmap development I set the
transaction reservation sizes to be overly generous for rmap+reflink
filesystems, and a little under-generous for rmap-only filesystems.
Since we don't need *eight* transaction rolls to handle three new log
intent items, decrease the logcounts to what we actually need, and amend
the shadow reservation computation function to reflect what we used to
do so that the minimum log size doesn't change.
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de>
Darrick J. Wong [Tue, 26 Apr 2022 01:38:13 +0000 (18:38 -0700)]
xfs: report "max_resp" used for min log size computation
Move the tracepoint that computes the size of the transaction used to
compute the minimum log size into xfs_log_get_max_trans_res so that we
only have to compute this stuff once.
Leave xfs_log_get_max_trans_res as a non-static function so that xfs_db
can call it to report the results of the userspace computation of the
same value to diagnose mkfs/kernel misinteractions.
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de>
Darrick J. Wong [Tue, 26 Apr 2022 01:38:13 +0000 (18:38 -0700)]
xfs: create shadow transaction reservations for computing minimum log size
Every time someone changes the transaction reservation sizes, they
introduce potential compatibility problems if the changes affect the
minimum log size that we validate at mount time. If the minimum log
size gets larger (which should be avoided because doing so presents a
serious risk of log livelock), filesystems created with old mkfs will
not mount on a newer kernel; if the minimum size shrinks, filesystems
created with newer mkfs will not mount on older kernels.
Therefore, enable the creation of a shadow log reservation structure
where we can "undo" the effects of tweaks when computing minimum log
sizes. These shadow reservations should never be used in practice, but
they insulate us from perturbations in minimum log size.
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de>
Darrick J. Wong [Tue, 26 Apr 2022 01:37:15 +0000 (18:37 -0700)]
xfs: stop artificially limiting the length of bunmap calls
In commit e1a4e37cc7b6, we clamped the length of bunmapi calls on the
data forks of shared files to avoid two failure scenarios: one where the
extent being unmapped is so sparsely shared that we exceed the
transaction reservation with the sheer number of refcount btree updates
and EFI intent items; and the other where we attach so many deferred
updates to the transaction that we pin the log tail and later the log
head meets the tail, causing the log to livelock.
We avoid triggering the first problem by tracking the number of ops in
the refcount btree cursor and forcing a requeue of the refcount intent
item any time we think that we might be close to overflowing. This has
been baked into XFS since before the original e1a4 patch.
A recent patchset fixed the second problem by changing the deferred ops
code to finish all the work items created by each round of trying to
complete a refcount intent item, which eliminates the long chains of
deferred items (27dad); and causing long-running transactions to relog
their intent log items when space in the log gets low (74f4d).
Because this clamp affects /any/ unmapping request regardless of the
sharing factors of the component blocks, it degrades the performance of
all large unmapping requests -- whereas with an unshared file we can
unmap millions of blocks in one go, shared files are limited to
unmapping a few thousand blocks at a time, which causes the upper level
code to spin in a bunmapi loop even if it wasn't needed.
This also eliminates one more place where log recovery behavior can
differ from online behavior, because bunmapi operations no longer need
to requeue. The fstest generic/447 was created to test the old fix, and
it still passes with this applied.
Partial-revert-of: e1a4e37cc7b6 ("xfs: try to avoid blowing out the transaction reservation when bunmaping a shared extent")
Depends: 27dada070d59 ("xfs: change the order in which child and parent defer ops ar finished")
Depends: 74f4d6a1e065 ("xfs: only relog deferred intent items if free space in the log gets low") Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de>
Darrick J. Wong [Tue, 26 Apr 2022 22:29:54 +0000 (15:29 -0700)]
xfs: count EFIs when deciding to ask for a continuation of a refcount update
A long time ago, I added to XFS the ability to use deferred reference
count operations as part of a transaction chain. This enabled us to
avoid blowing out the transaction reservation when the blocks in a
physical extent all had different reference counts because we could ask
the deferred operation manager for a continuation, which would get us a
clean transaction.
The refcount code asks for a continuation when the number of refcount
record updates reaches the point where we think that the transaction has
logged enough full btree blocks due to refcount (and free space) btree
shape changes and refcount record updates that we're in danger of
overflowing the transaction.
We did not previously count the EFIs logged to the refcount update
transaction because the clamps on the length of a bunmap operation were
sufficient to avoid overflowing the transaction reservation even in the
worst case situation where every other block of the unmapped extent is
shared.
Unfortunately, the restrictions on bunmap length avoid failure in the
worst case by imposing a maximum unmap length of ~3000 blocks, even for
non-pathological cases. This seriously limits performance when freeing
large extents.
Therefore, track EFIs with the same counter as refcount record updates,
and use that information as input into when we should ask for a
continuation. This enables the next patch to drop the clumsy bunmap
limitation.
Depends: 27dada070d59 ("xfs: change the order in which child and parent defer ops ar finished")
Depends: 74f4d6a1e065 ("xfs: only relog deferred intent items if free space in the log gets low") Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de>
Darrick J. Wong [Tue, 26 Apr 2022 01:37:06 +0000 (18:37 -0700)]
xfs: speed up write operations by using non-overlapped lookups when possible
Reverse mapping on a reflink-capable filesystem has some pretty high
overhead when performing file operations. This is because the rmap
records for logically and physically adjacent extents might not be
adjacent in the rmap index due to data block sharing. As a result, we
use expensive overlapped-interval btree search, which walks every record
that overlaps with the supplied key in the hopes of finding the record.
However, profiling data shows that when the index contains a record that
is an exact match for a query key, the non-overlapped btree search
function can find the record much faster than the overlapped version.
Try the non-overlapped lookup first when we're trying to find the left
neighbor rmap record for a given file mapping, which makes unwritten
extent conversion and remap operations run faster if data block sharing
is minimal in this part of the filesystem.
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de>
firmware: arm_scmi: Support optee shared memory in the optee transport
Add support for TEE shared memory in optee scmi transport. When using
tee shared memory, scmi optee transport manages SCMI messages using
msg protocol(from msg.c) in shared memory, whereas smt(from shmem.c)
protocol is used with static IOMEM based shared buffers.
Add SCMI v3.1 voltage protocol support for asynchronous VOLTAGE_LEVEL_SET
command.
Note that, if a voltage domain is advertised to support the asynchronous
version of VOLTAGE_LEVEL_SET, the command will be issued asynchronously
unless explicitly requested to use the synchronous version by setting the
mode to SCMI_VOLTAGE_LEVEL_SET_SYNC when calling voltage_ops->level_set.
The SCMI regulator driver level_set invocation has been left unchanged
so that it will transparently use the asynchronous version if available.
Cristian Marussi [Wed, 30 Mar 2022 15:05:51 +0000 (16:05 +0100)]
firmware: arm_scmi: Add checks for min/max limits in PERFORMANCE_LIMITS_SET
Starting with SCMI v3.1, the PERFORMANCE_LIMITS_SET command allows a user
to request only one between max and min ranges to be changed, while leaving
the other untouched if set to zero in the request. Anyway SCMI v3.1 states
also explicitly that you cannot leave both of those unchanged (zeroed) when
issuing such command, so add a proper check for this condition.
Link: https://lore.kernel.org/r/20220330150551.2573938-23-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
[sudeep.holla: Dropped check for v3.0 and above to make the check
unconditional, updated the subject accordingly] Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Cristian Marussi [Wed, 30 Mar 2022 15:05:42 +0000 (16:05 +0100)]
firmware: arm_scmi: Add iterators for multi-part commands
SCMI specification defines some commands as optionally issued over multiple
messages in order to overcome possible limitations in payload size enforced
by the configured underlyinng transport.
Introduce some common protocol helpers to provide a unified solution for
issuing such SCMI multi-part commands.
The clock_enable_latency field in CLOCK_ATTRIBUTES response message has
been added only since SCMI v3.1. Use the advertised SCMI clock protocol
version as a proper condition check for parsing it, instead of the bare
message length lookup.
firmware: arm_scmi: Set clock latency to U32_MAX if it is not supported
As per the spec, the clock_enable_delay is the worst case latency
incurred by the platform to enable the clock. The value of 0 indicates
that the platform doesn't support the same and must be considered as
maximum latency for practical purposes.
Currently the value of 0 is assigned as is and is propogated to the clock
framework which can assume that the clock can support atomic enable operation.
Cristian Marussi [Wed, 30 Mar 2022 15:05:40 +0000 (16:05 +0100)]
firmware: arm_scmi: Add SCMI v3.1 protocol extended names support
Using the common protocol helper implementation add support for all new
SCMIv3.1 extended names commands related to all protocols with the
exception of SENSOR_AXIS_GET_NAME.
Cristian Marussi [Wed, 30 Mar 2022 15:05:39 +0000 (16:05 +0100)]
firmware: arm_scmi: Introduce a common SCMI v3.1 .extended_name_get helper
Introduce a new set of common protocol operations bound to the protocol
handle structure so that can be invoked by the protocol implementation code
even when protocols are built as distinct loadable kernel module without
the need of exporting new symbols, like already done with scmi_xfer_ops.
Add at first, as new common protocol helper, an .extended_name_get helper
which will ease implementation and will avoid code duplication when adding
new SCMIv3.1 per-protocol _NAME_GET commands.
Cristian Marussi [Wed, 30 Mar 2022 15:05:38 +0000 (16:05 +0100)]
firmware: arm_scmi: Split protocol specific definitions in a dedicated header
Move some SCMI protocol specific definitions from common.h into a the new
dedicated protocols.h header so that SCMI protocols core code can include
only what it needs; this is going to be useful to avoid the risk of growing
indefinitely the dimension of common.h, especially when introducing some
common protocols helper functions.
Header common.h will continue to be included by SCMI core and transport
layers.
Cristian Marussi [Wed, 30 Mar 2022 15:05:37 +0000 (16:05 +0100)]
firmware: arm_scmi: Remove unneeded NULL termination of clk name
The string array 'name' inside struct scmi_clock_info holds the clock name
which was successfully retrieved by querying the SCMI platform, unless the
related underlying SCMI command failed.
Anyway, such scmi_clock_info structure is allocated using devm_kcalloc()
which in turn internally appends a __GFP_ZERO flag to its invocation:
as a consequence the string 'name' field does not need to be zeroed when
we fail to get the clock name via SCMI, it is already NULL terminated.
When CLOCK_RATE_SET command is issued in asynchronous mode the delayed
response CLOCK_RATE_SET_COMPLETE comes back once the SCMI platform has
effectively operated the requested change: such delayed response carries
also the clock ID and the final clock rate that has been set.
As an aid to debug issues, check that the clock ID in the delayed
response matches the expected one and debug print the rate value.
Cristian Marussi [Wed, 30 Mar 2022 15:05:35 +0000 (16:05 +0100)]
firmware: arm_scmi: Make name_get operations return a const
A few protocol operations are available that returns a pointer to an
internal character array representing resource name. Make those functions
return a const pointer to such array.
Move away from a statically allocated array for holding the current set of
protocols implemented by the platform in favour of allocating it
dynamically based on the number of protocols effectively advertised by the
platform via BASE protocol exchanges.
While at that, rectify the BASE_DISCOVER_LIST_PROTOCOLS loop iterations to
terminate only when a number of protocols equal to the advertised ones has
been received, instead of looping till the platform returns no more
protocols descriptors. This new behaviour is better compliant with the
specification and it has been tested to work equally well against an SCMI
stack running on top of an official SCP firmware on a JUNO board.
Do not blindly trust SCMI platform response about list of implemented
protocols, instead validate the reported length of the list of protocols
against the real payload size of the message reply.
Link: https://lore.kernel.org/r/20220330150551.2573938-5-cristian.marussi@arm.com Fixes: b6f20ff8bd94 ("firmware: arm_scmi: add common infrastructure and support for base protocol") Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
[sudeep.holla: Added early break if loop_num_ret = 0 and simplified calc_list_sz
calculation] Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Dan Carpenter [Thu, 28 Apr 2022 09:38:25 +0000 (12:38 +0300)]
cxl/mbox: fix logical vs bitwise typo
This should be bitwise & instead of &&.
Fixes: 6179045ccc0c ("cxl/mbox: Block immediate mode in SET_PARTITION_INFO command") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/YmpgkbbQ1Yxu36uO@kili Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Mark Brown [Wed, 27 Apr 2022 18:19:54 +0000 (19:19 +0100)]
selftests/arm64: Fix O= builds for the floating point tests
Currently the arm64 floating point tests don't support out of tree builds
due to two quirks of the kselftest build system. One is that when building
a program from multiple files we shouldn't separately compile the main
program to an object file as that will result in the pattern rule not
matching when adjusted for the output directory. The other is that we also
need to include $(OUTPUT) in the names of the binaries when specifying the
dependencies in order to ensure that they get picked up with O=.
Rewrite the dependencies for the executables to fix these issues. The
kselftest build system will ensure OUTPUT is always defined.
Mark Brown [Wed, 27 Apr 2022 18:19:51 +0000 (19:19 +0100)]
selftests/arm64: Use TEST_GEN_PROGS_EXTENDED in the FP Makefile
The kselftest lib.mk provides a default all target which builds additional
programs from TEST_GEN_PROGS_EXTENDED, use that rather than using
TEST_PROGS_EXTENDED which is for programs that don't need to be built like
shell scripts. Leave fpsimd-stress and sve-stress there since they are
scripts.
Fix the following coccicheck warnings:
tools/testing/selftests/arm64/mte/check_child_memory.c:110:25-26:
WARNING: Use ARRAY_SIZE
tools/testing/selftests/arm64/mte/check_child_memory.c:88:24-25:
WARNING: Use ARRAY_SIZE
tools/testing/selftests/arm64/mte/check_child_memory.c:90:20-21:
WARNING: Use ARRAY_SIZE
tools/testing/selftests/arm64/mte/check_child_memory.c:147:24-25:
WARNING: Use ARRAY_SIZE
`ARRAY_SIZE` macro is defined in tools/testing/selftests/kselftest.h.
Mark Brown [Tue, 19 Apr 2022 11:22:47 +0000 (12:22 +0100)]
selftests/arm64: Add a testcase for handling of ZA on clone()
Add a small testcase that attempts to do a clone() with ZA enabled and
verifies that it remains enabled with the same contents. We only check
one word in one horizontal vector of ZA since there's already other tests
that check for data corruption more broadly, we're just looking to make
sure that ZA is still enabled and it looks like the data got copied.
Mark Brown [Tue, 19 Apr 2022 11:22:46 +0000 (12:22 +0100)]
kselftest/arm64: Add SME support to syscall ABI test
For every possible combination of SVE and SME vector length verify that for
each possible value of SVCR after a syscall we leave streaming mode and ZA
is preserved. We don't need to take account of any streaming/non streaming
SVE vector length changes in the assembler code since the store instructions
will handle the vector length for us. We log if the system supports FA64 and
only try to set FFR in streaming mode if it does.
Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Shuah Khan <skhan@linuxfoundation.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20220419112247.711548-39-broonie@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Mark Brown [Tue, 19 Apr 2022 11:22:45 +0000 (12:22 +0100)]
kselftest/arm64: Add coverage for the ZA ptrace interface
Add some basic coverage for the ZA ptrace interface, including walking
through all the vector lengths supported in the system. Unlike SVE
doing syscalls does not discard the ZA state so when we set data in ZA
we run the child process briefly, having it add one to each byte in ZA
in order to validate that both the vector size and data are being read
and written as expected when the process runs.
Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Shuah Khan <skhan@linuxfoundation.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20220419112247.711548-38-broonie@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Mark Brown [Tue, 19 Apr 2022 11:22:44 +0000 (12:22 +0100)]
kselftest/arm64: Add streaming SVE to SVE ptrace tests
In order to allow ptrace of streaming mode SVE registers we have added a
new regset for streaming mode which in isolation offers the same ABI as
regular SVE with a different vector type. Add this to the array of regsets
we handle, together with additional tests for the interoperation of the
two regsets.
Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Shuah Khan <skhan@linuxfoundation.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20220419112247.711548-37-broonie@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Mark Brown [Tue, 19 Apr 2022 11:22:43 +0000 (12:22 +0100)]
kselftest/arm64: signal: Add SME signal handling tests
Add test cases for the SME signal handing ABI patterned off the SVE tests.
Due to the small size of the tests and the differences in ABI (especially
around needing to account for both streaming SVE and ZA) there is some code
duplication here.
We currently cover:
- Reporting of the vector length.
- Lack of support for changing vector length.
- Presence and size of register state for streaming SVE and ZA.
As with the SVE tests we do not yet have any validation of register
contents.
Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Shuah Khan <skhan@linuxfoundation.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20220419112247.711548-36-broonie@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Mark Brown [Tue, 19 Apr 2022 11:22:42 +0000 (12:22 +0100)]
kselftest/arm64: Add stress test for SME ZA context switching
Add a stress test for context switching of the ZA register state based on
the similar tests Dave Martin wrote for FPSIMD and SVE registers. The test
loops indefinitely writing a data pattern to ZA then reading it back and
verifying that it's what was expected.
Unlike the other tests we manually assemble the SME instructions since at
present no released toolchain has SME support integrated.
Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Shuah Khan <skhan@linuxfoundation.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20220419112247.711548-35-broonie@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Mark Brown [Tue, 19 Apr 2022 11:22:41 +0000 (12:22 +0100)]
kselftest/arm64: signal: Handle ZA signal context in core code
As part of the generic code for signal handling test cases we parse all
signal frames to make sure they have at least the basic form we expect
and that there are no unexpected frames present in the signal context.
Add coverage of the ZA signal frame to this code.
Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Shuah Khan <skhan@linuxfoundation.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20220419112247.711548-34-broonie@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Mark Brown [Tue, 19 Apr 2022 11:22:40 +0000 (12:22 +0100)]
kselftest/arm64: sme: Provide streaming mode SVE stress test
One of the features of SME is the addition of streaming mode, in which we
have access to a set of streaming mode SVE registers at the SME vector
length. Since these are accessed using the SVE instructions let's reuse
the existing SVE stress test for testing with a compile time option for
controlling the few small differences needed:
- Enter streaming mode immediately on starting the program.
- In streaming mode FFR is removed so skip reading and writing FFR.
Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Shuah Khan <skhan@linuxfoundation.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20220419112247.711548-33-broonie@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
projects / people / ms / linux.git / log
