Alex Elder [Tue, 19 Jul 2022 18:10:16 +0000 (13:10 -0500)]
net: ipa: add a transaction committed list
We currently put a transaction on the pending list when it has
been committed. But until the channel's doorbell rings, these
transactions aren't actually "owned" by the hardware yet.
Add a new "committed" state (and list), to represent transactions
that have been committed but not yet sent to hardware. Define
"pending" to mean committed transactions that have been sent
to hardware but have not yet completed.
Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Alex Elder [Tue, 19 Jul 2022 19:16:39 +0000 (14:16 -0500)]
net: ipa: add an endpoint device attribute group
Create a new attribute group meant to provide a single place that
defines endpoint IDs that might be needed by user space. Not all
defined endpoints are presented, and only those that are defined
will be made visible.
The new attributes use "extended" device attributes to hold endpoint
IDs, which is a little more compact and efficient. Reimplement the
existing modem endpoint ID attribute files using common code.
selftests: net: af_unix: Fix a build error of unix_connect.c.
This patch fixes a build error reported in the link. [0]
unix_connect.c: In function ‘unix_connect_test’:
unix_connect.c:115:55: error: expected identifier before ‘(’ token
#define offsetof(type, member) ((size_t)&((type *)0)->(member))
^
unix_connect.c:128:12: note: in expansion of macro ‘offsetof’
addrlen = offsetof(struct sockaddr_un, sun_path) + variant->len;
^~~~~~~~
We can fix this by removing () around member, but checkpatch will complain
about it, and the root cause of the build failure is that I followed the
warning and fixed this in the v2 -> v3 change of the blamed commit. [1]
CHECK: Macro argument 'member' may be better as '(member)' to avoid precedence issues
#33: FILE: tools/testing/selftests/net/af_unix/unix_connect.c:115:
+#define offsetof(type, member) ((size_t)&((type *)0)->member)
To avoid this warning, let's use offsetof() defined in stddef.h instead.
Fixes: e95ab1d85289 ("selftests: net: af_unix: Test connect() with different netns.") Reported-by: kernel test robot <lkp@intel.com> Suggested-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com> Link: https://lore.kernel.org/r/20220720005750.16600-1-kuniyu@amazon.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
====================
Netfilter/IPVS updates for net-next
The following patchset contains Netfilter/IPVS updates for net-next:
1) Simplify nf_ct_get_tuple(), from Jackie Liu.
2) Add format to request_module() call, from Bill Wendling.
3) Add /proc/net/stats/nf_flowtable to monitor in-flight pending
hardware offload objects to be processed, from Vlad Buslov.
4) Missing rcu annotation and accessors in the netfilter tree,
from Florian Westphal.
5) Merge h323 conntrack helper nat hooks into single object,
also from Florian.
6) A batch of update to fix sparse warnings treewide,
from Florian Westphal.
7) Move nft_cmp_fast_mask() where it used, from Florian.
8) Missing const in nf_nat_initialized(), from James Yonan.
9) Use bitmap API for Maglev IPVS scheduler, from Christophe Jaillet.
10) Use refcount_inc instead of _inc_not_zero in flowtable,
from Florian Westphal.
11) Remove pr_debug in xt_TPROXY, from Nathan Cancellor.
* git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-next:
netfilter: xt_TPROXY: remove pr_debug invocations
netfilter: flowtable: prefer refcount_inc
netfilter: ipvs: Use the bitmap API to allocate bitmaps
netfilter: nf_nat: in nf_nat_initialized(), use const struct nf_conn *
netfilter: nf_tables: move nft_cmp_fast_mask to where its used
netfilter: nf_tables: use correct integer types
netfilter: nf_tables: add and use BE register load-store helpers
netfilter: nf_tables: use the correct get/put helpers
netfilter: x_tables: use correct integer types
netfilter: nfnetlink: add missing __be16 cast
netfilter: nft_set_bitmap: Fix spelling mistake
netfilter: h323: merge nat hook pointers into one
netfilter: nf_conntrack: use rcu accessors where needed
netfilter: nf_conntrack: add missing __rcu annotations
netfilter: nf_flow_table: count pending offload workqueue tasks
net/sched: act_ct: set 'net' pointer when creating new nf_flow_table
netfilter: conntrack: use correct format characters
netfilter: conntrack: use fallthrough to cleanup
====================
Jakub Kicinski [Thu, 21 Jul 2022 00:54:46 +0000 (17:54 -0700)]
Merge tag 'mlx5-updates-2022-07-17' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux
Saeed Mahameed says:
====================
mlx5-updates-2022-07-17
1) Add resiliency for lost completions for PTP TX port timestamp
2) Report Header-data split state via ethtool
3) Decouple HTB code from main regular TX code
* tag 'mlx5-updates-2022-07-17' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux:
net/mlx5: CT: Remove warning of ignore_flow_level support for non PF
net/mlx5e: Add resiliency for PTP TX port timestamp
net/mlx5: Expose ts_cqe_metadata_size2wqe_counter
net/mlx5e: HTB, move htb functions to a new file
net/mlx5e: HTB, change functions name to follow convention
net/mlx5e: HTB, remove priv from htb function calls
net/mlx5e: HTB, hide and dynamically allocate mlx5e_htb structure
net/mlx5e: HTB, move stats and max_sqs to priv
net/mlx5e: HTB, move section comment to the right place
net/mlx5e: HTB, move ids to selq_params struct
net/mlx5e: HTB, reduce visibility of htb functions
net/mlx5e: Fix mqprio_rl handling on devlink reload
net/mlx5e: Report header-data split state through ethtool
====================
This newly-added assertion checks that there aren't any incore data
structures hanging off the incore fork when we're trying to reset its
contents. From the call trace, it is evident that iget was trying to
construct an incore inode from the ondisk inode, but the attr fork
verifier failed and we were trying to undo all the memory allocations
that we had done earlier.
The three assertions in xfs_ifork_zap_attr check that the caller has
already called xfs_idestroy_fork, which clearly has not been done here.
As the zap function then zeroes the pointers, we've effectively leaked
the memory.
The shortest change would have been to insert an extra call to
xfs_idestroy_fork, but it makes more sense to bundle the _idestroy_fork
call into _zap_attr, since all other callsites call _idestroy_fork
immediately prior to calling _zap_attr. IOWs, it eliminates one way to
fail.
Note: This change only applies cleanly to 2ed5b09b3e8f, since we just
reworked the attr fork lifetime. However, I think this memory leak has
existed since 0f45a1b20cd8, since the chain xfs_iformat_attr_fork ->
xfs_iformat_local -> xfs_init_local_fork will allocate
ifp->if_u1.if_data, but if xfs_ifork_verify_local_attr fails,
xfs_iformat_attr_fork will free i_afp without freeing any of the stuff
hanging off i_afp. The solution for older kernels I think is to add the
missing call to xfs_idestroy_fork just prior to calling kmem_cache_free.
Found by fuzzing a.sfattr.hdr.totsize = lastbit in xfs/399.
Fixes: 2ed5b09b3e8f ("xfs: make inode attribute forks a permanent part of struct xfs_inode")
Probably-Fixes: 0f45a1b20cd8 ("xfs: improve local fork verification") Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Dave Chinner <dchinner@redhat.com>
fs/xfs/scrub/repair.c:539:19: warning: variable 'agno' set but not used [-Wunused-but-set-variable]
Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: sunliming <sunliming@kylinos.cn> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Dave Chinner [Tue, 19 Jul 2022 01:20:37 +0000 (18:20 -0700)]
xfs: xfs_buf cache destroy isn't RCU safe
Darrick and Sachin Sant reported that xfs/435 and xfs/436 would
report an non-empty xfs_buf slab on module remove. This isn't easily
to reproduce, but is clearly a side effect of converting the buffer
caceh to RUC freeing and lockless lookups. Sachin bisected and
Darrick hit it when testing the patchset directly.
Turns out that the xfs_buf slab is not destroyed when all the other
XFS slab caches are destroyed. Instead, it's got it's own little
wrapper function that gets called separately, and so it doesn't have
an rcu_barrier() call in it that is needed to drain all the rcu
callbacks before the slab is destroyed.
Fix it by removing the xfs_buf_init/terminate wrappers that just
allocate and destroy the xfs_buf slab, and move them to the same
place that all the other slab caches are set up and destroyed.
Reported-and-tested-by: Sachin Sant <sachinp@linux.ibm.com> Fixes: 298f34224506 ("xfs: lockless buffer lookup") Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de>
Dan Carpenter [Mon, 18 Jul 2022 17:13:48 +0000 (10:13 -0700)]
xfs: delete unnecessary NULL checks
These NULL check are no long needed after commit 2ed5b09b3e8f ("xfs:
make inode attribute forks a permanent part of struct xfs_inode").
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Xiaole He [Mon, 18 Jul 2022 17:13:47 +0000 (10:13 -0700)]
xfs: fix comment for start time value of inode with bigtime enabled
The 'ctime', 'mtime', and 'atime' for inode is the type of
'xfs_timestamp_t', which is a 64-bit type:
/* fs/xfs/libxfs/xfs_format.h begin */
typedef __be64 xfs_timestamp_t;
/* fs/xfs/libxfs/xfs_format.h end */
When the 'bigtime' feature is disabled, this 64-bit type is splitted
into two parts of 32-bit, one part is encoded for seconds since
1970-01-01 00:00:00 UTC, the other part is encoded for nanoseconds
above the seconds, this two parts are the type of
'xfs_legacy_timestamp' and the min and max time value of this type are
defined as macros 'XFS_LEGACY_TIME_MIN' and 'XFS_LEGACY_TIME_MAX':
'XFS_LEGACY_TIME_MIN' is the min time value of the
'xfs_legacy_timestamp', that is -(2^31) seconds relative to the
1970-01-01 00:00:00 UTC, it can be converted to human-friendly time
value by 'date' command:
/* command begin */
[root@~]# date --utc -d '@0' +'%Y-%m-%d %H:%M:%S'
1970-01-01 00:00:00
[root@~]# date --utc -d "@`echo '-(2^31)'|bc`" +'%Y-%m-%d %H:%M:%S'
1901-12-13 20:45:52
[root@~]#
/* command end */
When 'bigtime' feature is enabled, this 64-bit type becomes a 64-bit
nanoseconds counter, with the start time value is the min time value of
'xfs_legacy_timestamp'(start time means the value of 64-bit nanoseconds
counter is 0). We have already caculated the min time value of
'xfs_legacy_timestamp', that is 1901-12-13 20:45:52 UTC, but the comment
for the start time value of inode with 'bigtime' feature enabled writes
the value is 1901-12-31 20:45:52 UTC:
/* fs/xfs/libxfs/xfs_format.h begin */
/*
* XFS Timestamps
* ==============
* When the bigtime feature is enabled, ondisk inode timestamps become an
* unsigned 64-bit nanoseconds counter. This means that the bigtime inode
* timestamp epoch is the start of the classic timestamp range, which is
* Dec 31 20:45:52 UTC 1901. ...
...
*/
/* fs/xfs/libxfs/xfs_format.h end */
That is a typo, and this patch corrects the typo, from 'Dec 31' to
'Dec 13'.
Suggested-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Xiaole He <hexiaole@kylinos.cn> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Pablo suggested "a patch to remove these pr_debug calls". This patch has
some other beneficial collateral as it also silences multiple Clang
-Wformat warnings that were present in the pr_debug calls.
diff from v1 -> v2:
* converted if statement one-liner style
* x == NULL is now !x
Suggested-by: Pablo Neira Ayuso <pablo@netfilter.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Justin Stitt <justinstitt@google.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
kmap() is being deprecated in favor of kmap_local_page().
Two main problems with kmap(): (1) It comes with an overhead as mapping
space is restricted and protected by a global lock for synchronization and
(2) it also requires global TLB invalidation when the kmap’s pool wraps
and it might block when the mapping space is fully utilized until a slot
becomes available.
With kmap_local_page() the mappings are per thread, CPU local, can take
page faults, and can be called from any context (including interrupts).
Tasks can be preempted and, when scheduled to run again, the kernel
virtual addresses are restored and still valid.
kmap_local_page() is faster than kmap() in kernels with HIGHMEM enabled.
Since the use of kmap_local_page() in module_gzip_decompress() and in
module_xz_decompress() is safe (i.e., it does not break the strict rules
of use), it should be preferred over kmap().
Therefore, replace kmap() with kmap_local_page().
Tested on a QEMU/KVM x86_32 VM with 4GB RAM, booting kernels with
HIGHMEM64GB enabled. Modules compressed with XZ or GZIP decompress
properly.
Cc: Matthew Wilcox <willy@infradead.com> Suggested-by: Ira Weiny <ira.weiny@intel.com> Signed-off-by: Fabio M. De Francesco <fmdefrancesco@gmail.com> Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
Documentation: process: Update email client instructions for Thunderbird
The instructions don't match with the current Thunderbird interface.
Clarification on using external extensions.
New information on how to avoid writing HTML emails.
Tell user to restart Thunderbird after modifications.
A few weeks ago, QEMU switched docs/specs/fw_cfg.txt to be
docs/specs/fw_cfg.rst, so update the reference in the kernel docs to
reflect this. Also add a link to the online documentation to make it
easier to find.
ASoC: Makefile: Fix simultaneous build of KUNIT tests
Using obj-$() := instead of obj-$() += leads to the latter assignment
overwriting earlier value. Fix this by using incremental assignment to
add additional objects to build.
drm/amdgpu: Protect the amdgpu_bo_list list with a mutex v2
Protect the struct amdgpu_bo_list with a mutex. This is used during command
submission in order to avoid buffer object corruption as recorded in
the link below.
v2 (chk): Keep the mutex looked for the whole CS to avoid using the
list from multiple CS threads at the same time.
Suggested-by: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <Alexander.Deucher@amd.com> Cc: Andrey Grodzovsky <Andrey.Grodzovsky@amd.com> Cc: Vitaly Prosyak <Vitaly.Prosyak@amd.com> Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2048 Signed-off-by: Luben Tuikov <luben.tuikov@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Tested-by: Luben Tuikov <luben.tuikov@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
apparmor: correct config reference to intended one
Commit 5bfcbd22ee4e ("apparmor: Enable tuning of policy paranoid load for
embedded systems") introduces the config SECURITY_APPARMOR_PARANOID_LOAD,
but then refers in the code to SECURITY_PARANOID_LOAD; note the missing
APPARMOR in the middle.
Correct this to the introduced and intended config option.
Fixes: 5bfcbd22ee4e ("apparmor: Enable tuning of policy paranoid load for embedded systems") Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
drm/amd/display: Create a file dedicated to planes
[Why]
The amdgpu_dm file contains most of the code that works as an interface
between DRM API and DC. As a result, this file becomes very large since
it comprises multiple abstractions such as plane manipulation.
[How]
This commit extracts the plane code to its specific file named
amdgpu_dm_plane. This change does not change anything inside the
functions; the only exception is converting some static functions to a
global function.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Reviewed-by: Harry Wentland <Harry.Wentland@amd.com> Acked-by: Alan Liu <HaoPing.Liu@amd.com> Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Wayne Lin [Wed, 20 Jul 2022 19:11:56 +0000 (15:11 -0400)]
drm/amd/display: Add tags for indicating mst progress status
[Why & How]
In order to leverage igt tool to maintain mst feature, expose new
debugfs entry "mst_progress_status".
In our dm flow, record down the result of each phase of mst and user
can examine the mst result by checking whether each phase get completed
successfully.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Reviewed-by: Hersen Wu <hersenxs.wu@amd.com> Acked-by: Alan Liu <HaoPing.Liu@amd.com> Signed-off-by: Wayne Lin <Wayne.Lin@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why & How]
Add "is_mst_connector" debugfs entry to help distinguish whether
a connector is in a mst topology or not.
Access it with the following command:
cat /sys/kernel/debug/dri/0/DP-X/is_mst_connector
Result:
- "root" stands for the root connector of the topology
- "branch" stands for branch device of the topology
- "end" stands for leaf node connector of the topology
- "no" stands for the connector is not a device of a mst topology
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Reviewed-by: Hersen Wu <hersenxs.wu@amd.com> Acked-by: Alan Liu <HaoPing.Liu@amd.com> Signed-off-by: Wayne Lin <Wayne.Lin@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Wayne Lin [Tue, 17 Aug 2021 10:14:42 +0000 (18:14 +0800)]
drm/amd/display: fix trigger_hotplug to support mst case
[Why & How]
Correct few problems below to have debugfs trigger_hotplug entry
supports mst case
* Adjust the place for acquiring the hpd_lock. We'll also access
dc_link when simulate unplug
* When detect the connector is a mst root, call
reset_cur_dp_mst_topology() to simulate unplug
* Don't support hotplug caused by CSN message since we can't change
mst topology info directly. We can't simulate that
* Clean up redundant code
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Reviewed-by: Hersen Wu <hersenxs.wu@amd.com> Acked-by: Alan Liu <HaoPing.Liu@amd.com> Signed-off-by: Wayne Lin <Wayne.Lin@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Wayne Lin [Wed, 22 Jun 2022 02:59:01 +0000 (10:59 +0800)]
drm/amd/display: Expose function reset_cur_dp_mst_topology
[Why & How]
Need to leverage this function out of dc_link.c. Change it to public.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Reviewed-by: Hersen Wu <hersenxs.wu@amd.com> Acked-by: Alan Liu <HaoPing.Liu@amd.com> Signed-off-by: Wayne Lin <Wayne.Lin@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Alvin Lee [Tue, 27 Jul 2021 22:32:45 +0000 (18:32 -0400)]
drm/amd/display: Update in dml
Update DML to configure drr_display in vba struct.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Reviewed-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Acked-by: Alan Liu <HaoPing.Liu@amd.com> Signed-off-by: Alvin Lee <Alvin.Lee2@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Jun Lei [Wed, 25 Sep 2019 13:45:49 +0000 (09:45 -0400)]
drm/amd/display: Remove unused variable
Remove an unused variable "remove_disconnect_edp" which was a workaround
bit.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Acked-by: Alan Liu <HaoPing.Liu@amd.com> Signed-off-by: Jun Lei <Jun.Lei@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Wayne Lin [Wed, 10 Mar 2021 15:40:01 +0000 (23:40 +0800)]
drm/amd/display: Support vertical interrupt 0 for all dcn ASIC
[Why]
When CONFIG_DRM_AMD_SECURE_DISPLAY is enabled, it will try
to register vertical interrupt 0 for specific task.
Currently, only dcn10 have defined relevant info for vertical interrupt
0. If we enable CONFIG_DRM_AMD_SECURE_DISPLAY for other dcn ASIC, will
get DC_IRQ_SOURCE_INVALID while calling dc_interrupt_to_irq_source() and
cause pointer errors.
[How]
Add support of vertical interrupt 0 for all dcn ASIC.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Acked-by: Alan Liu <HaoPing.Liu@amd.com> Signed-off-by: Wayne Lin <Wayne.Lin@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Alex Sierra [Tue, 17 May 2022 17:19:06 +0000 (12:19 -0500)]
drm/amdgpu: remove acc_size from reserve/unreserve mem
TTM used to track the "acc_size" of all BOs internally. We needed to
keep track of it in our memory reservation to avoid TTM running out
of memory in its own accounting. However, that "acc_size" accounting
has since been removed from TTM. Therefore we don't really need to
track it any more.
Signed-off-by: Alex Sierra <alex.sierra@amd.com> Reviewed-by: Philip Yang <philip.yang@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amdgpu: Protect the amdgpu_bo_list list with a mutex v2
Protect the struct amdgpu_bo_list with a mutex. This is used during command
submission in order to avoid buffer object corruption as recorded in
the link below.
v2 (chk): Keep the mutex looked for the whole CS to avoid using the
list from multiple CS threads at the same time.
Suggested-by: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <Alexander.Deucher@amd.com> Cc: Andrey Grodzovsky <Andrey.Grodzovsky@amd.com> Cc: Vitaly Prosyak <Vitaly.Prosyak@amd.com> Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2048 Signed-off-by: Luben Tuikov <luben.tuikov@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Tested-by: Luben Tuikov <luben.tuikov@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/msm/dp: make eDP panel as the first connected connector
Some userspace presumes that the first connected connector is the main
display, where it's supposed to display e.g. the login screen. For
laptops, this should be the main panel.
This patch call drm_helper_move_panel_connectors_to_head() after
drm_bridge_connector_init() to make sure eDP stay at head of
connected connector list. This fixes unexpected corruption happen
at eDP panel if eDP is not placed at head of connected connector
list.
Changes in v2:
-- move drm_helper_move_panel_connectors_to_head() to
dpu_kms_drm_obj_init()
Changes in v4:
-- move drm_helper_move_panel_connectors_to_head() to msm_drm_init()
Signed-off-by: Kuogee Hsieh <quic_khsieh@quicinc.com> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Tested-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Fixes: ef7837ff091c ("drm/msm/dp: Add DP controllers for sc7280")
Patchwork: https://patchwork.freedesktop.org/patch/492581/ Link: https://lore.kernel.org/r/1657135928-31195-1-git-send-email-quic_khsieh@quicinc.com Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Rob Herring [Tue, 19 Jul 2022 21:51:34 +0000 (15:51 -0600)]
ASoC: dt-bindings: sgtl5000: Add missing type to 'micbias-voltage-m-volts'
'micbias-voltage-m-volts' is missing a type definition. '-m-volts' is
not a standard unit (should be '-microvolt'). As the property is already
in use, add a type reference.
They were updated in kernel/bpf/trampoline.c to fix another build
issue. We should to do the same for include/linux/bpf.h header.
Fixes: 3908fcddc65d ("bpf: fix lsm_cgroup build errors on esoteric configs") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Stanislav Fomichev <sdf@google.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Martin KaFai Lau <kafai@fb.com> Link: https://lore.kernel.org/bpf/20220720155220.4087433-1-sdf@google.com
Input: deactivate MT slots when inhibiting or suspending devices
When inhibiting or suspending a device we are sending release events for
all currently held keys and buttons, however we retain active MT slot
state, which causes issues with gesture recognition when we resume or
uninhibit.
Let's fix it by introducing, in addition to input_dev_release_keys(),
nput_mt_release_slots() that will deactivate all currently active slots.
We should not be passing synthetic events (such as autorepeat events)
out of order with the events coming from the hardware device, but rather
add them to pending events and flush them all at once.
This also fixes an issue with timestamps for key release events carrying
stale data from the previous autorepeat event.
Add support for Xiaomi Mi Mix2s (polaris) handsets.
Currently working features:
- UFS
- Touchscreen
- USB 2
- Bluetooth
- Wi-Fi
- GPU
- Venus
- Display (need jdi-fhd-nt35596s panel driver, which I have sent a
patch but it haven't been into upstream yet)
Jason Gunthorpe [Wed, 20 Jul 2022 00:02:49 +0000 (21:02 -0300)]
vfio: Replace the iommu notifier with a device list
Instead of bouncing the function call to the driver op through a blocking
notifier just have the iommu layer call it directly.
Register each device that is being attached to the iommu with the lower
driver which then threads them on a linked list and calls the appropriate
driver op at the right time.
Currently the only use is if dma_unmap() is defined.
Also, fully lock all the debugging tests on the pinning path that a
dma_unmap is registered.
Jason Gunthorpe [Wed, 20 Jul 2022 00:02:48 +0000 (21:02 -0300)]
vfio: Replace the DMA unmapping notifier with a callback
Instead of having drivers register the notifier with explicit code just
have them provide a dma_unmap callback op in their driver ops and rely on
the core code to wire it up.
Suggested-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Tony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/1-v4-681e038e30fd+78-vfio_unmap_notif_jgg@nvidia.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
watchqueue: make sure to serialize 'wqueue->defunct' properly
When the pipe is closed, we mark the associated watchqueue defunct by
calling watch_queue_clear(). However, while that is protected by the
watchqueue lock, new watchqueue entries aren't actually added under that
lock at all: they use the pipe->rd_wait.lock instead, and looking up
that pipe happens without any locking.
The watchqueue code uses the RCU read-side section to make sure that the
wqueue entry itself hasn't disappeared, but that does not protect the
pipe_info in any way.
So make sure to actually hold the wqueue lock when posting watch events,
properly serializing against the pipe being torn down.
On a machine with the LBR format LBR_FORMAT_EIP_FLAGS2, when the TSX is
disabled, a TSX quirk is required to access LBR from registers.
The lbr_from_signext_quirk_needed() is introduced to determine whether
the TSX quirk should be applied. However, the
lbr_from_signext_quirk_needed() is invoked before the
intel_pmu_lbr_init(), which parses the LBR format information. Without
the correct LBR format information, the TSX quirk never be applied.
Move the lbr_from_signext_quirk_needed() into the intel_pmu_lbr_init().
Checking x86_pmu.lbr_has_tsx in the lbr_from_signext_quirk_needed() is
not required anymore.
Both LBR_FORMAT_EIP_FLAGS2 and LBR_FORMAT_INFO have LBR_TSX flag, but
only the LBR_FORMAT_EIP_FLAGS2 requirs the quirk. Update the comments
accordingly.
Fixes: 1ac7fd8159a8 ("perf/x86/intel/lbr: Support LBR format V7") Reported-by: Vince Weaver <vincent.weaver@maine.edu> Signed-off-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20220714182630.342107-1-kan.liang@linux.intel.com
WARNING: CPU: 0 PID: 0 at arch/x86/kernel/alternative.c:557 apply_returns (arch/x86/kernel/alternative.c:557 (discriminator 1))
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.19.0-rc4-00008-gee88d363d156 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-4 04/01/2014
RIP: 0010:apply_returns (arch/x86/kernel/alternative.c:557 (discriminator 1))
Code: ff ff 74 cb 48 83 c5 04 49 39 ee 0f 87 81 fe ff ff e9 22 ff ff ff 0f 0b 48 83 c5 04 49 39 ee 0f 87 6d fe ff ff e9 0e ff ff ff <0f> 0b 48 83 c5 04 49 39 ee 0f 87 59 fe ff ff e9 fa fe ff ff 48 89
The warning happened when apply_returns() failed to convert "JMP
__x86_return_thunk" to RET. It was instead a JMP to nowhere, due to the
thunk relocation not getting resolved.
That rodata.o code is objcopy'd to .rodata, and later memcpy'd, so
relocations don't work (and are apparently silently ignored).
LKDTM is only used for testing, so the naked RET should be fine. So
just disable return thunks for that file.
While at it, disable objtool and KCSAN for the file.
Fixes: 0b53c374b9ef ("x86/retpoline: Use -mfunction-return") Reported-by: kernel test robot <oliver.sang@intel.com> Debugged-by: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lore.kernel.org/lkml/Ys58BxHxoDZ7rfpr@xsang-OptiPlex-9020/
x86/bugs: Warn when "ibrs" mitigation is selected on Enhanced IBRS parts
IBRS mitigation for spectre_v2 forces write to MSR_IA32_SPEC_CTRL at
every kernel entry/exit. On Enhanced IBRS parts setting
MSR_IA32_SPEC_CTRL[IBRS] only once at boot is sufficient. MSR writes at
every kernel entry/exit incur unnecessary performance loss.
When Enhanced IBRS feature is present, print a warning about this
unnecessary performance loss.
Eric Snowberg [Wed, 20 Jul 2022 16:40:27 +0000 (12:40 -0400)]
lockdown: Fix kexec lockdown bypass with ima policy
The lockdown LSM is primarily used in conjunction with UEFI Secure Boot.
This LSM may also be used on machines without UEFI. It can also be
enabled when UEFI Secure Boot is disabled. One of lockdown's features
is to prevent kexec from loading untrusted kernels. Lockdown can be
enabled through a bootparam or after the kernel has booted through
securityfs.
If IMA appraisal is used with the "ima_appraise=log" boot param,
lockdown can be defeated with kexec on any machine when Secure Boot is
disabled or unavailable. IMA prevents setting "ima_appraise=log" from
the boot param when Secure Boot is enabled, but this does not cover
cases where lockdown is used without Secure Boot.
To defeat lockdown, boot without Secure Boot and add ima_appraise=log to
the kernel command line; then:
spi: dt-bindings: qcom,spi-geni-qcom: allow three interconnects
Recent Qualcomm Geni SPI nodes, e.g. on SM8450, come also with three
interconnects. This fixes dtbs_check warnings like:
sm8450-qrd.dtb: spi@a98000: interconnects: [[46, 1, 0, 46, 4, 0], [47, 2, 0, 48, 12, 0], [49, 1, 0, 50, 1, 0]] is too long
sm8450-qrd.dtb: spi@a98000: interconnect-names: ['qup-core', 'qup-config', 'qup-memory'] is too long
Fixes: 5bdcae1fe1c5 ("spi: dt-bindings: qcom,spi-geni-qcom: convert to dtschema") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220720163841.7283-1-krzysztof.kozlowski@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
Adding FIU NPCM8XX support to NPCM FIU driver.
NPCM8XX FIU supports four controllers.
As part of adding NPCM8XX support:
- Add NPCM8XX specific compatible string.
- Using an internal burst configuration register instead of a GCR
register.
- Support FIU1 controller.
gpio: gpio-mm: Implement and utilize register structures
Reduce magic numbers and improve code readability by implementing and
utilizing named register data structures. The GPIO-MM device features an
Intel 8255 compatible GPIO interface, so the i8255 GPIO module is
selected and utilized as well.
Tested-by: Fred Eckert <Frede@cmslaser.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: William Breathitt Gray <william.gray@linaro.org> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
gpio: 104-idi-48: Implement and utilize register structures
Reduce magic numbers and improve code readability by implementing and
utilizing named register data structures. The 104-IDI-48 device features
an Intel 8255 compatible GPIO interface, so the i8255 GPIO module is
selected and utilized as well.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Cc: John Hentges <jhentges@accesio.com> Cc: Jay Dolan <jay.dolan@accesio.com> Signed-off-by: William Breathitt Gray <william.gray@linaro.org> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
gpio: 104-dio-48e: Implement and utilize register structures
Reduce magic numbers and improve code readability by implementing and
utilizing named register data structures. The 104-DIO-48E device
features an Intel 8255 compatible GPIO interface, so the i8255 GPIO
module is selected and utilized as well.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Cc: John Hentges <jhentges@accesio.com> Cc: Jay Dolan <jay.dolan@accesio.com> Signed-off-by: William Breathitt Gray <william.gray@linaro.org> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
gpio: i8255: Introduce the Intel 8255 interface library module
Exposes consumer library functions providing support for interfaces
compatible with the venerable Intel 8255 Programmable Peripheral
Interface (PPI).
The Intel 8255 PPI first appeared in the early 1970s, initially for the
Intel 8080 and later appearing in the original IBM-PC. The popularity of
the original Intel 8255 chip led to many subsequent variants and clones
of the interface in various chips and integrated circuits. Although
still popular, interfaces compatible with the Intel 8255 PPI are
nowdays typically found embedded in larger VLSI processing chips and
FPGA components rather than as discrete ICs.
A CONFIG_GPIO_I8255 Kconfig option is introduced by this patch. Modules
wanting access to these i8255 library functions should select this
Kconfig option, and import the I8255 symbol namespace.
Tested-by: Fred Eckert <Frede@cmslaser.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Cc: John Hentges <jhentges@accesio.com> Cc: Jay Dolan <jay.dolan@accesio.com> Cc: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: William Breathitt Gray <william.gray@linaro.org> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
gpio: 104-idio-16: Implement and utilize register structures
Reduce magic numbers and improve code readability by implementing and
utilizing named register data structures.
Tested-by: Fred Eckert <Frede@cmslaser.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Cc: John Hentges <jhentges@accesio.com> Cc: Jay Dolan <jay.dolan@accesio.com> Signed-off-by: William Breathitt Gray <william.gray@linaro.org> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Make it possible to handle not only single-, but also multi-
segment iterators in copy_oldmem_iter() callback. Change the
semantics of called functions to match the iterator model -
instead of an error code the exact number of bytes copied is
returned.
The swap page used to copy data to user space is adopted for
kernel space too. That does not bring any performance impact.
s390/crash: use static swap buffer for copy_to_user_real()
Currently a temporary page-size buffer is allocated for copying
oldmem to user space. That limits copy_to_user_real() operation
only to stages when virtual memory is available and still makes
it possible to fail while the system is being dumped.
Instead of reallocating single page on each copy_oldmem_page()
iteration use a statically allocated buffer.
This also paves the way for a further memcpy_real() rework where
no swap buffer is needed altogether.
s390/crash: remove redundant panic() on save area allocation failure
Make save_area_alloc() return classic NULL on allocation failure.
The only caller smp_save_dump_cpus() does check the return value
already and panics if NULL is returned.
Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
Since commit 461e0da7ddbb ("s390: remove broken hibernate / power
management support") there are no users of tprot() left. Remove
the function itself as well.
Acked-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
projects / people / ms / linux.git / log
