Here the kworker is waiting on msdos_sb_info::s_lock which is held by
tar which is in turn waiting for a buffer which is locked waiting to be
flushed, but this operation is plugged in the kworker.
The lock is a normal struct mutex, so tsk_is_pi_blocked() will always
return false on !RT and thus the behaviour changes for RT.
It seems that the intent here is to skip blk_flush_plug() in the case
where a non-preemptible lock (such as a spinlock) has been converted to
a rtmutex on RT, which is the case covered by the SM_RTLOCK_WAIT
schedule flag. But sched_submit_work() is only called from schedule()
which is never called in this scenario, so the check can simply be
deleted.
Looking at the history of the -rt patchset, in fact this change was
present from v5.9.1-rt20 until being dropped in v5.13-rt1 as it was part
of a larger patch [1] most of which was replaced by commit b4bfa3fcfe3b
("sched/core: Rework the __schedule() preempt argument").
As described in [1]:
The schedule process must distinguish between blocking on a regular
sleeping lock (rwsem and mutex) and a RT-only sleeping lock (spinlock
and rwlock):
- rwsem and mutex must flush block requests (blk_schedule_flush_plug())
even if blocked on a lock. This can not deadlock because this also
happens for non-RT.
There should be a warning if the scheduling point is within a RCU read
section.
- spinlock and rwlock must not flush block requests. This will deadlock
if the callback attempts to acquire a lock which is already acquired.
Similarly to being preempted, there should be no warning if the
scheduling point is within a RCU read section.
and with the tsk_is_pi_blocked() in the scheduler path, we hit the first
issue.
Vincent Guittot [Fri, 8 Jul 2022 15:44:01 +0000 (17:44 +0200)]
sched/fair: fix case with reduced capacity CPU
The capacity of the CPU available for CFS tasks can be reduced because of
other activities running on the latter. In such case, it's worth trying to
move CFS tasks on a CPU with more available capacity.
The rework of the load balance has filtered the case when the CPU is
classified to be fully busy but its capacity is reduced.
Check if CPU's capacity is reduced while gathering load balance statistic
and classify it group_misfit_task instead of group_fully_busy so we can
try to move the load on another CPU.
Reported-by: David Chen <david.chen@nutanix.com> Reported-by: Zhang Qiao <zhangqiao22@huawei.com> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by: David Chen <david.chen@nutanix.com> Tested-by: Zhang Qiao <zhangqiao22@huawei.com> Link: https://lkml.kernel.org/r/20220708154401.21411-1-vincent.guittot@linaro.org
After this; e1 is attached to an unmapped rb and a subsequent
perf_mmap() will loop forever more:
again:
mutex_lock(&e->mmap_mutex);
if (event->rb) {
...
if (!atomic_inc_not_zero(&e->rb->mmap_count)) {
...
mutex_unlock(&e->mmap_mutex);
goto again;
}
}
The loop in perf_mmap_close() holds e2->mmap_mutex, while the attach
in perf_event_set_output() holds e1->mmap_mutex. As such there is no
serialization to avoid this race.
Change perf_event_set_output() to take both e1->mmap_mutex and
e2->mmap_mutex to alleviate that problem. Additionally, have the loop
in perf_mmap() detach the rb directly, this avoids having to wait for
the concurrent perf_mmap_close() to get around to doing it to make
progress.
Merge tag 'arm-soc/for-5.19/devicetree-arm64-fixes' of https://github.com/Broadcom/stblinux into arm/fixes
This pull request contains Broadcom ARM64-based SoCs Device Tree fixes
for 5.19, please pull the following:
- William corrects the BCM4906 DTS to have an armv8-timer Device Tree,
necessary for booting, and fixes the BCM4908 DTS to have a proper
'enable-method' and 'cpu-release-addr' properties for the kernel to boot
when using u-boot
* tag 'arm-soc/for-5.19/devicetree-arm64-fixes' of https://github.com/Broadcom/stblinux:
arm64: dts: broadcom: bcm4908: Fix cpu node for smp boot
arm64: dts: broadcom: bcm4908: Fix timer node for BCM4906 SoC
ALSA: hda/realtek - Fix headset mic problem for a HP machine with alc221
On a HP 288 Pro G2 MT (X9W02AV), the front mic could not be detected.
In order to get it working, the pin configuration needs to be set
correctly, and the ALC221_FIXUP_HP_288PRO_MIC_NO_PRESENCE fixup needs
to be applied.
Jiang Jian [Wed, 22 Jun 2022 10:42:17 +0000 (18:42 +0800)]
USB: serial: fix repeated word "the" in comments
There is a repeated word "the" in two comments that should be replaced
or removed.
Signed-off-by: Jiang Jian <jiangjian@cdjrlc.com>
[ johan: replace one "the" with "that", merge the two cleanups, amend
commit message ] Signed-off-by: Johan Hovold <johan@kernel.org>
Jeremy Szu [Wed, 13 Jul 2022 02:27:04 +0000 (10:27 +0800)]
ALSA: hda/realtek: fix mute/micmute LEDs for HP machines
The HP ProBook 440/450 G9 and EliteBook 640/650 G9 have multiple
motherboard design and they are using different subsystem ID of audio
codec. Add the same quirk for other MBs.
Ben Skeggs [Wed, 1 Jun 2022 10:46:03 +0000 (20:46 +1000)]
drm/nouveau/fifo: rip out cevent, never used
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Wed, 1 Jun 2022 10:46:03 +0000 (20:46 +1000)]
drm/nouveau/device: remove pwrsrc notify in favour of a direct call to clk
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Wed, 1 Jun 2022 10:46:01 +0000 (20:46 +1000)]
drm/nouveau/nvkm: rip out event uapi
Userspace never ended up using this to be clever about dealing with
channel death, and it won't be, not like this anyway.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs [Wed, 1 Jun 2022 10:46:00 +0000 (20:46 +1000)]
drm/nouveau/nvif: add wrapper for open-coded nvif_object_constructed()
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
When building with Clang we encounter these warnings:
| drivers/net/ethernet/qlogic/qed/qed_dev.c:416:30: error: format
| specifies type 'char' but the argument has type 'u32' (aka 'unsigned
| int') [-Werror,-Wformat] i);
-
| drivers/net/ethernet/qlogic/qed/qed_dev.c:630:13: error: format
| specifies type 'char' but the argument has type 'int' [-Werror,-Wformat]
| p_llh_info->num_ppfid - 1);
For the first warning, `i` is a u32 which is much wider than the format
specifier `%hhd` describes. This results in a loss of bits after 2^7.
The second warning involves implicit integer promotion as the resulting
type of addition cannot be smaller than an int.
example:
``
uint8_t a = 4, b = 7;
int size = sizeof(a + b - 1);
printf("%d\n", size);
// output: 4
```
See more:
(https://wiki.sei.cmu.edu/confluence/display/c/INT02-C.+Understand+integer+conversion+rules)
"Integer types smaller than int are promoted when an operation is
performed on them. If all values of the original type can be represented
as an int, the value of the smaller type is converted to an int;
otherwise, it is converted to an unsigned int."
Jakub Kicinski [Wed, 13 Jul 2022 03:36:00 +0000 (20:36 -0700)]
Merge branch 'bnxt_en-5-bug-fixes'
Michael Chan says:
====================
bnxt_en: 5 Bug fixes
This patchset fixes various issues, including SRIOV error unwinding,
one error recovery path, live patch reporting, XDP transmit path,
and PHC clock reading.
====================
The upper 32-bit PHC register is not latched when reading the lower
32-bit PHC register. Current code leaves a small window where we may
not read correct higher order bits if the lower order bits are just about
to wrap around.
This patch fixes this by reading higher order bits twice and makes
sure that final value is correctly paired with its lower 32 bits.
Fixes: 30e96f487f64 ("bnxt_en: Do not read the PTP PHC during chip reset") Cc: Richard Cochran <richardcochran@gmail.com> Signed-off-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Michael Chan [Tue, 12 Jul 2022 02:26:17 +0000 (22:26 -0400)]
bnxt_en: Fix and simplify XDP transmit path
Fix the missing length hint in the TX BD for the XDP transmit path. The
length hint is required on legacy chips.
Also, simplify the code by eliminating the first_buf local variable.
tx_buf contains the same value. The opaque value only needs to be set
on the first BD. Fix this also for correctness.
Fixes: a7559bc8c17c ("bnxt: support transmit and free of aggregation buffers") Reviewed-by: Andy Gospodarek <andrew.gospodarek@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Michael Chan [Tue, 12 Jul 2022 02:26:15 +0000 (22:26 -0400)]
bnxt_en: Fix bnxt_reinit_after_abort() code path
bnxt_reinit_after_abort() is called during ifup when a previous
FW reset sequence has aborted or a previous ifup has failed after
detecting FW reset. In all cases, it is safe to assume that a
previous FW reset has completed and the driver may not have fully
reinitialized.
Prior to this patch, it is assumed that the
FUNC_DRV_IF_CHANGE_RESP_FLAGS_HOT_FW_RESET_DONE flag will always be
set by the firmware in bnxt_hwrm_if_change(). This may not be true if
the driver has already attempted to register with the firmware. The
firmware may not set the RESET_DONE flag again after the driver has
registered, assuming that the driver has seen the flag already.
Fix it to always go through the FW reset initialization path if
the BNXT_STATE_FW_RESET_DET flag is set. This flag is always set
by the driver after successfully going through bnxt_reinit_after_abort().
Fixes: 6882c36cf82e ("bnxt_en: attempt to reinitialize after aborted reset") Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
bnxt_en: reclaim max resources if sriov enable fails
If bnxt_sriov_enable() fails after some resources have been reserved
for the VFs, the current code is not unwinding properly and the
reserved resources become unavailable afterwards. Fix it by
properly unwinding with a call to bnxt_hwrm_func_qcaps() to
reset all maximum resources.
Also, add the missing bnxt_ulp_sriov_cfg() call to let the RDMA
driver know to abort.
Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.") Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Lorenzo Bianconi [Mon, 11 Jul 2022 23:07:51 +0000 (16:07 -0700)]
igb: add xdp frags support to ndo_xdp_xmit
Add the capability to map non-linear xdp frames in XDP_TX and
ndo_xdp_xmit callback.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Tested-by: Chandan Kumar Rout <chandanx.rout@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Link: https://lore.kernel.org/r/20220711230751.3124415-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
====================
mptcp: Support changes to initial subflow priority
This series updates the in-kernel MPTCP path manager to allow changes to
subflow priority for the first subflow created for each MPTCP connection
(the one created with the MP_CAPABLE handshake).
Patches 1 and 2 do some refactoring to simplify the new functionality.
Patch 3 introduces the new feature to change the initial subflow
priority and send the MP_PRIO header on that subflow.
Patch 4 cleans up code related to tracking endpoint ids on the initial
subflow.
Patch 5 adds a selftest to confirm that subflow priorities are updated
as expected.
====================
Paolo Abeni [Mon, 11 Jul 2022 19:16:33 +0000 (12:16 -0700)]
selftests: mptcp: add MPC backup tests
Add a couple of test-cases covering the newly introduced
features - priority update for the MPC subflow.
Reviewed-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Paolo Abeni [Mon, 11 Jul 2022 19:16:32 +0000 (12:16 -0700)]
mptcp: more accurate MPC endpoint tracking
Currently the id accounting for the ID 0 subflow is not correct:
at creation time we mark (correctly) as unavailable the endpoint
id corresponding the MPC subflow source address, while at subflow
removal time set as available the id 0.
With this change we track explicitly the endpoint id corresponding
to the MPC subflow so that we can mark it as available at removal time.
Additionally this allow deleting the initial subflow via the NL PM
specifying the corresponding endpoint id.
Reviewed-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Paolo Abeni [Mon, 11 Jul 2022 19:16:31 +0000 (12:16 -0700)]
mptcp: allow the in kernel PM to set MPC subflow priority
Any local endpoints configured on the address matching the
MPC subflow are currently ignored.
Specifically, setting a backup flag on them has no effect
on the first subflow, as the MPC handshake can't carry such
info.
This change refactors the MPC endpoint id accounting to
additionally fetch the priority info from the relevant endpoint
and eventually trigger the MP_PRIO handshake as needed.
As a result, the MPC subflow now switches to backup priority
after that the MPTCP socket is fully established, according
to the local endpoint configuration.
Reviewed-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Paolo Abeni [Mon, 11 Jul 2022 19:16:30 +0000 (12:16 -0700)]
mptcp: address lookup improvements
When looking-up a socket address in the endpoint list, we
must prefer port-based matches over address only match.
Ensure that port-based endpoints are listed first, using
head insertion for them. Additionally be sure that only
port-based endpoints carry a non zero port number.
Reviewed-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Paolo Abeni [Mon, 11 Jul 2022 19:16:29 +0000 (12:16 -0700)]
mptcp: introduce and use mptcp_pm_send_ack()
The in-kernel PM has a bit of duplicate code related to ack
generation. Create a new helper factoring out the PM-specific
needs and use it in a couple of places.
As a bonus, mptcp_subflow_send_ack() is not used anymore
outside its own compilation unit and can become static.
Reviewed-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Yonglong Li [Mon, 11 Jul 2022 09:47:18 +0000 (17:47 +0800)]
tcp: make retransmitted SKB fit into the send window
current code of __tcp_retransmit_skb only check TCP_SKB_CB(skb)->seq
in send window, and TCP_SKB_CB(skb)->seq_end maybe out of send window.
If receiver has shrunk his window, and skb is out of new window, it
should retransmit a smaller portion of the payload.
Diana Wang [Mon, 11 Jul 2022 09:30:48 +0000 (11:30 +0200)]
nfp: support TX VLAN ctag insert in NFDK
Add support for TX VLAN ctag insert
which may be configured via ethtool.
e.g.
# ethtool -K $DEV tx-vlan-offload on
The NIC supplies VLAN insert information as packet metadata.
The fields of this VLAN metadata including vlan_proto and vlan tag.
Configuration control bit NFP_NET_CFG_CTRL_TXVLAN_V2 is to
signal availability of ctag-insert features of the firmware.
NFDK is used to communicate via PCIE to NFP-3800 based NICs
while NFD3 is used for other NICs supported by the NFP driver.
This features is currently implemented only for NFD3 and
this patch adds support for it with NFDK.
ndtest: Cleanup all of blk namespace specific code
With the nd_namespace_blk and nd_blk_region infrastructures being removed,
the ndtest still has some references to the old code. So the
compilation fails as below,
../tools/testing/nvdimm/test/ndtest.c:204:25: error: ‘ND_DEVICE_NAMESPACE_BLK’ undeclared here (not in a function); did you mean ‘ND_DEVICE_NAMESPACE_IO’?
204 | .type = ND_DEVICE_NAMESPACE_BLK,
| ^~~~~~~~~~~~~~~~~~~~~~~
| ND_DEVICE_NAMESPACE_IO
../tools/testing/nvdimm/test/ndtest.c: In function ‘ndtest_create_region’:
../tools/testing/nvdimm/test/ndtest.c:630:17: error: ‘ndbr_desc’ undeclared (first use in this function); did you mean ‘ndr_desc’?
630 | ndbr_desc.enable = ndtest_blk_region_enable;
| ^~~~~~~~~
| ndr_desc
../tools/testing/nvdimm/test/ndtest.c:630:17: note: each undeclared identifier is reported only once for each function it appears in
../tools/testing/nvdimm/test/ndtest.c:630:36: error: ‘ndtest_blk_region_enable’ undeclared (first use in this function)
630 | ndbr_desc.enable = ndtest_blk_region_enable;
| ^~~~~~~~~~~~~~~~~~~~~~~~
../tools/testing/nvdimm/test/ndtest.c:631:35: error: ‘ndtest_blk_do_io’ undeclared (first use in this function); did you mean ‘ndtest_blk_mmio’?
631 | ndbr_desc.do_io = ndtest_blk_do_io;
| ^~~~~~~~~~~~~~~~
| ndtest_blk_mmio
The current patch removes the specific code to cleanup all obsolete
references.
Dave Airlie [Wed, 13 Jul 2022 00:55:52 +0000 (10:55 +1000)]
Merge tag 'drm-msm-next-2022-07-10' of https://gitlab.freedesktop.org/drm/msm into drm-next
Next for v5.20
GPU:
- a619 support
- Fix for unclocked GMU register access
- Devcore dump enhancements
Core:
- client utilization via fdinfo support
- fix fence rollover issue
- gem: Lockdep false-positive warning fix
- gem: Switch to pfn mappings
DPU:
- constification of HW catalog
- support for using encoder as CRC source
- WB support on sc7180
- WB resolution fixes
DP:
- dropped custom bulk clock implementation
- made dp_bridge_mode_valid() return MODE_CLOCK_HIGH where applicable
- fix link retraining on resolution change
MDP5:
- MSM8953 perf data
HDMI:
- YAML'ification of schema
- dropped obsolete GPIO support
- misc cleanups
Jane Chu [Thu, 30 Jun 2022 18:28:02 +0000 (12:28 -0600)]
pmem: fix a name collision
Kernel test robot detected name collision when compiled on 'um'
architecture. Rename "to_phys()" to "pmem_to_phys()".
>> drivers/nvdimm/pmem.c:48:20: error: conflicting types for 'to_phys'; have 'phys_addr_t(struct pmem_device *, phys_addr_t)' {aka 'long long unsigned int(struct pmem_device *, long long unsigned int)'}
48 | static phys_addr_t to_phys(struct pmem_device *pmem, phys_addr_t offset)
| ^~~~~~~
In file included from arch/um/include/asm/page.h:98,
from arch/um/include/asm/thread_info.h:15,
from include/linux/thread_info.h:60,
from include/asm-generic/preempt.h:5,
from ./arch/um/include/generated/asm/preempt.h:1,
arch/um/include/shared/mem.h:12:29: note: previous definition of 'to_phys' with type 'long unsigned int(void *)'
12 | static inline unsigned long to_phys(void *virt)
| ^~~~~~~
Fixes: 9409c9b6709e (pmem: refactor pmem_clear_poison()) Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Jane Chu <jane.chu@oracle.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20220630182802.3250449-1-jane.chu@oracle.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
bpf: Make non-preallocated allocation low priority
GFP_ATOMIC doesn't cooperate well with memcg pressure so far, especially
if we allocate too much GFP_ATOMIC memory. For example, when we set the
memcg limit to limit a non-preallocated bpf memory, the GFP_ATOMIC can
easily break the memcg limit by force charge. So it is very dangerous to
use GFP_ATOMIC in non-preallocated case. One way to make it safe is to
remove __GFP_HIGH from GFP_ATOMIC, IOW, use (__GFP_ATOMIC |
__GFP_KSWAPD_RECLAIM) instead, then it will be limited if we allocate
too much memory. There's a plan to completely remove __GFP_ATOMIC in the
mm side[1], so let's use GFP_NOWAIT instead.
We introduced BPF_F_NO_PREALLOC is because full map pre-allocation is
too memory expensive for some cases. That means removing __GFP_HIGH
doesn't break the rule of BPF_F_NO_PREALLOC, but has the same goal with
it-avoiding issues caused by too much memory. So let's remove it.
This fix can also apply to other run-time allocations, for example, the
allocation in lpm trie, local storage and devmap. So let fix it
consistently over the bpf code
When building with Clang we encounter these warnings:
| drivers/net/ethernet/netronome/nfp/nfp_app.c:233:99: error: format
| specifies type 'unsigned char' but the argument has underlying type
| 'unsigned int' [-Werror,-Wformat] nfp_err(pf->cpp, "unknown FW app ID
| 0x%02hhx, driver too old or support for FW not built in\n", id);
-
| drivers/net/ethernet/netronome/nfp/nfp_main.c:396:11: error: format
| specifies type 'unsigned char' but the argument has type 'int'
| [-Werror,-Wformat] serial, interface >> 8, interface & 0xff);
Correct format specifier for `id` is `%x` since the default type for the
`nfp_app_id` enum is `unsigned int`. The second warning is also solved
by using the `%x` format specifier as the expressions involving
`interface` are implicity promoted to integers (%x is used to maintain
hexadecimal representation).
Song Liu [Wed, 6 Jul 2022 00:26:12 +0000 (17:26 -0700)]
bpf, x86: fix freeing of not-finalized bpf_prog_pack
syzbot reported a few issues with bpf_prog_pack [1], [2]. This only happens
with multiple subprogs. In jit_subprogs(), we first call bpf_int_jit_compile()
on each sub program. And then, we call it on each sub program again. jit_data
is not freed in the first call of bpf_int_jit_compile(). Similarly we don't
call bpf_jit_binary_pack_finalize() in the first call of bpf_int_jit_compile().
If bpf_int_jit_compile() failed for one sub program, we will call
bpf_jit_binary_pack_finalize() for this sub program. However, we don't have a
chance to call it for other sub programs. Then we will hit "goto out_free" in
jit_subprogs(), and call bpf_jit_free on some subprograms that haven't got
bpf_jit_binary_pack_finalize() yet.
At this point, bpf_jit_binary_pack_free() is called and the whole 2MB page is
freed erroneously.
Fix this with a custom bpf_jit_free() for x86_64, which calls
bpf_jit_binary_pack_finalize() if necessary. Also, with custom
bpf_jit_free(), bpf_prog_aux->use_bpf_prog_pack is not needed any more,
remove it.
Fixes: 1022a5498f6f ("bpf, x86_64: Use bpf_jit_binary_pack_alloc")
[1] https://syzkaller.appspot.com/bug?extid=2f649ec6d2eea1495a8f
[2] https://syzkaller.appspot.com/bug?extid=87f65c75f4a72db05445 Reported-by: syzbot+2f649ec6d2eea1495a8f@syzkaller.appspotmail.com Reported-by: syzbot+87f65c75f4a72db05445@syzkaller.appspotmail.com Signed-off-by: Song Liu <song@kernel.org> Link: https://lore.kernel.org/r/20220706002612.4013790-1-song@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
====================
dt-bindings: net: convert sff,sfp to dtschema
This patch set converts the sff,sfp to dtschema.
The first patch does a somewhat mechanical conversion without changing
anything else beside the format in which the dt binding is presented.
In the second patch we rename some dt nodes to be generic. The last two
patches change the GPIO related properties so that they uses the -gpios
preferred suffix. This way, all the DTBs are passing the validation
against the sff,sfp.yaml binding.
====================
arch: arm64: dts: marvell: rename the sfp GPIO properties
Rename the GPIO related sfp properties to include the preffered -gpios
suffix. Also, with this change the dtb_check will no longer complain
when trying to verify the DTS against the sff,sfp.yaml binding.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
arch: arm64: dts: lx2160a-clearfog-itx: rename the sfp GPIO properties
Rename the 'mod-def0-gpio' property to 'mod-def0-gpios' so that we use
the preferred -gpios suffix. Also, with this change the dtb_check will
not complain when trying to verify the DTS against the sff,sfp.yaml
binding.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Merge tag 'trace-v5.19-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
Pull tracing fixes from Steven Rostedt:
"Fixes and minor clean ups for tracing:
- Fix memory leak by reverting what was thought to be a double free.
A static tool had gave a false positive that a double free was
possible in the error path, but it was actually a different
location that confused the static analyzer (and those of us that
reviewed it).
- Move use of static buffers by ftrace_dump() to a location that can
be used by kgdb's ftdump(), as it needs it for the same reasons.
- Clarify in the Kconfig description that function tracing has
negligible impact on x86, but may have a bit bigger impact on other
architectures.
- Remove unnecessary extra semicolon in trace event.
- Make a local variable static that is used in the fprobes sample
- Use KSYM_NAME_LEN for length of function in kprobe sample and get
rid of unneeded macro for the same purpose"
* tag 'trace-v5.19-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
samples: Use KSYM_NAME_LEN for kprobes
fprobe/samples: Make sample_probe static
blk-iocost: tracing: atomic64_read(&ioc->vtime_rate) is assigned an extra semicolon
ftrace: Be more specific about arch impact when function tracer is enabled
tracing: Fix sleeping while atomic in kdb ftdump
tracing/histograms: Fix memory leak problem
Roman Gushchin [Mon, 11 Jul 2022 16:28:27 +0000 (09:28 -0700)]
bpf: reparent bpf maps on memcg offlining
The memory consumed by a bpf map is always accounted to the memory
cgroup of the process which created the map. The map can outlive
the memory cgroup if it's used by processes in other cgroups or
is pinned on bpffs. In this case the map pins the original cgroup
in the dying state.
For other types of objects (slab objects, non-slab kernel allocations,
percpu objects and recently LRU pages) there is a reparenting process
implemented: on cgroup offlining charged objects are getting
reassigned to the parent cgroup. Because all charges and statistics
are fully recursive it's a fairly cheap operation.
For efficiency and consistency with other types of objects, let's do
the same for bpf maps. Fortunately thanks to the objcg API, the
required changes are minimal.
Please, note that individual allocations (slabs, percpu and large
kmallocs) already have the reparenting mechanism. This commit adds
it to the saved map->memcg pointer by replacing it to map->objcg.
Because dying cgroups are not visible for a user and all charges are
recursive, this commit doesn't bring any behavior changes for a user.
KVM: selftests: Provide valid inputs for MONITOR/MWAIT regs
Provide valid inputs for RAX, RCX, and RDX when testing whether or not
KVM injects a #UD on MONITOR/MWAIT. SVM has a virtualization hole and
checks for _all_ faults before checking for intercepts, e.g. MONITOR with
an unsupported RCX will #GP before KVM gets a chance to intercept and
emulate.
KVM: selftests: Test MONITOR and MWAIT, not just MONITOR for quirk
Fix a copy+paste error in monitor_mwait_test by switching one of the two
"monitor" instructions to an "mwait". The intent of the test is very
much to verify the quirk handles both MONITOR and MWAIT.
KVM: x86: Query vcpu->vcpu_idx directly and drop its accessor, again
Read vcpu->vcpu_idx directly instead of bouncing through the one-line
wrapper, kvm_vcpu_get_idx(), and drop the wrapper. The wrapper is a
remnant of the original implementation and serves no purpose; remove it
(again) before it gains more users.
kvm_vcpu_get_idx() was removed in the not-too-distant past by commit 4eeef2424153 ("KVM: x86: Query vcpu->vcpu_idx directly and drop its
accessor"), but was unintentionally re-introduced by commit a54d806688fe
("KVM: Keep memslots in tree-based structures instead of array-based ones"),
likely due to a rebase goof. The wrapper then managed to gain users in
KVM's Xen code.
KVM: x86/mmu: Replace UNMAPPED_GVA with INVALID_GPA for gva_to_gpa()
The result of gva_to_gpa() is physical address not virtual address,
it is odd that UNMAPPED_GVA macro is used as the result for physical
address. Replace UNMAPPED_GVA with INVALID_GPA and drop UNMAPPED_GVA
macro.
a ksym BPF iterator would be useful as it would allow more flexible
interactions with kernel symbols than are currently supported; it could
for example create more efficient map representations for lookup,
speed up symbol resolution etc.
The idea was initially discussed here [1].
Changes since v5 [2]:
- no need to add kallsym_iter to bpf_iter.h as it has existed in kernels
for a long time so will by in vmlinux.h for older kernels too, unlike
struct bpf_iter__ksym (Yonghong, patch 2)
Changes since v4 [3]:
- add BPF_ITER_RESCHED to improve responsiveness (Hao, patch 1)
- remove pr_warn to be consistent with other iterators (Andrii, patch 1)
- add definitions to bpf_iter.h to ensure iter tests build on older
kernels (Andrii, patch 2)
Changes since v3 [4]:
- use late_initcall() to register iter; means we are both consistent
with other iters and can encapsulate all iter-specific code in
kallsyms.c in CONFIG_BPF_SYSCALL (Alexei, Yonghong, patch 1).
Changes since v2 [5]:
- set iter->show_value on initialization based on current creds
and use it in selftest to determine if we show values
(Yonghong, patches 1/2)
- inline iter registration into kallsyms_init (Yonghong, patch 1)
Changes since RFC [6]:
- change name of iterator (and associated structures/fields) to "ksym"
(Andrii, patches 1, 2)
- remove dependency on CONFIG_PROC_FS; it was used for other BPF
iterators, and I assumed it was needed because of seq ops but I
don't think it is required on digging futher (Andrii, patch 1)
Alan Maguire [Tue, 12 Jul 2022 12:31:45 +0000 (13:31 +0100)]
selftests/bpf: add a ksym iter subtest
add subtest verifying BPF ksym iter behaviour. The BPF ksym
iter program shows an example of dumping a format different to
/proc/kallsyms. It adds KIND and MAX_SIZE fields which represent the
kind of symbol (core kernel, module, ftrace, bpf, or kprobe) and
the maximum size the symbol can be. The latter is calculated from
the difference between current symbol value and the next symbol
value.
The key benefit for this iterator will likely be supporting in-kernel
data-gathering rather than dumping symbol details to userspace and
parsing the results.
Alan Maguire [Tue, 12 Jul 2022 12:31:44 +0000 (13:31 +0100)]
bpf: add a ksym BPF iterator
add a "ksym" iterator which provides access to a "struct kallsym_iter"
for each symbol. Intent is to support more flexible symbol parsing
as discussed in [1].
Andrzej Hajda [Fri, 24 Jun 2022 11:35:28 +0000 (13:35 +0200)]
drm/i915/selftests: fix subtraction overflow bug
On some machines hole_end can be small enough to cause subtraction
overflow. On the other side (addr + 2 * min_alignment) can overflow
in case of mock tests. This patch should handle both cases.
Chris Wilson [Fri, 8 Jul 2022 14:20:11 +0000 (16:20 +0200)]
drm/i915/gem: Look for waitboosting across the whole object prior to individual waits
We employ a "waitboost" heuristic to detect when userspace is stalled
waiting for results from earlier execution. Under latency sensitive work
mixed between the gpu/cpu, the GPU is typically under-utilised and so
RPS sees that low utilisation as a reason to downclock the frequency,
causing longer stalls and lower throughput. The user left waiting for
the results is not impressed.
On applying commit 047a1b877ed4 ("dma-buf & drm/amdgpu: remove dma_resv
workaround") it was observed that deinterlacing h264 on Haswell
performance dropped by 2-5x. The reason being that the natural workload
was not intense enough to trigger RPS (using HW evaluation intervals) to
upclock, and so it was depending on waitboosting for the throughput.
Commit 047a1b877ed4 ("dma-buf & drm/amdgpu: remove dma_resv workaround")
changes the composition of dma-resv from keeping a single write fence +
multiple read fences, to a single array of multiple write and read
fences (a maximum of one pair of write/read fences per context). The
iteration order was also changed implicitly from all-read fences then
the single write fence, to a mix of write fences followed by read
fences. It is that ordering change that belied the fragility of
waitboosting.
Currently, a waitboost is inspected at the point of waiting on an
outstanding fence. If the GPU is backlogged such that we haven't yet
stated the request we need to wait on, we force the GPU to upclock until
the completion of that request. By changing the order in which we waited
upon requests, we ended up waiting on those requests in sequence and as
such we saw that each request was already started and so not a suitable
candidate for waitboosting.
Instead of asking whether to boost each fence in turn, we can look at
whether boosting is required for the dma-resv ensemble prior to waiting
on any fence, making the heuristic more robust to the order in which
fences are stored in the dma-resv.
Chris Wilson [Tue, 12 Jul 2022 15:21:33 +0000 (16:21 +0100)]
drm/i915/gt: Serialize TLB invalidates with GT resets
Avoid trying to invalidate the TLB in the middle of performing an
engine reset, as this may result in the reset timing out. Currently,
the TLB invalidate is only serialised by its own mutex, forgoing the
uncore lock, but we can take the uncore->lock as well to serialise
the mmio access, thereby serialising with the GDRST.
Tested on a NUC5i7RYB, BIOS RYBDWi35.86A.0380.2019.0517.1530 with
i915 selftest/hangcheck.
Chris Wilson [Tue, 12 Jul 2022 15:21:32 +0000 (16:21 +0100)]
drm/i915/gt: Serialize GRDOM access between multiple engine resets
Don't allow two engines to be reset in parallel, as they would both
try to select a reset bit (and send requests to common registers)
and wait on that register, at the same time. Serialize control of
the reset requests/acks using the uncore->lock, which will also ensure
that no other GT state changes at the same time as the actual reset.
Cc: stable@vger.kernel.org # v4.4 and upper Reported-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Andi Shyti <andi.shyti@intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Acked-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/e0a2d894e77aed7c2e36b0d1abdc7dbac3011729.1657639152.git.mchehab@kernel.org
(cherry picked from commit 336561a914fc0c6f1218228718f633b31b7af1c3) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Matthew Auld [Mon, 11 Jul 2022 08:58:59 +0000 (09:58 +0100)]
drm/i915/ttm: fix sg_table construction
If we encounter some monster sized local-memory page that exceeds the
maximum sg length (UINT32_MAX), ensure that don't end up with some
misaligned address in the entry that follows, leading to fireworks
later. Also ensure we have some coverage of this in the selftests.
v2(Chris):
- Use round_down consistently to avoid udiv errors
v3(Nirmoy):
- Also update the max_segment in the selftest
Fixes: f701b16d4cc5 ("drm/i915/ttm: add i915_sg_from_buddy_resource") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6379 Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Nirmoy Das <nirmoy.das@linux.intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220711085859.24198-1-matthew.auld@intel.com
(cherry picked from commit bc99f1209f19fefa3ee11e77464ccfae541f4291) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
And in release_reference() we dereference vma->vm to get to the
vm gt pointer, leading to a use-after free.
However, __i915_vm_release() grabs the vm->mutex so the vm won't be
destroyed before vma->vm->mutex is released, so extract the gt pointer
under the vm->mutex to avoid the vma->vm dereference in
release_references().
v2: Fix a typo in the commit message (Andi Shyti)
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5944 Fixes: e1a7ab4fca0c ("drm/i915: Remove the vm open count") Cc: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Acked-by: Nirmoy Das <nirmoy.das@intel.con> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220620123659.381772-1-thomas.hellstrom@linux.intel.com
(cherry picked from commit 1926a6b75954fc1a8b44d10bd0c67db957b78cf7) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
drm/i915/guc: ADL-N should use the same GuC FW as ADL-S
The only difference between the ADL S and P GuC FWs is the HWConfig
support. ADL-N does not support HWConfig, so we should use the same
binary as ADL-S, otherwise the GuC might attempt to fetch a config
table that does not exist. ADL-N is internally identified as an ADL-P,
so we need to special-case it in the FW selection code.
Fixes: 7e28d0b26759 ("drm/i915/adl-n: Enable ADL-N platform") Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Tejas Upadhyay <tejas.upadhyay@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220621233005.3952293-1-daniele.ceraolospurio@intel.com
(cherry picked from commit 971e4a9781742aaad1587e25fd5582b2dd595ef8) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Hangyu Hua [Fri, 24 Jun 2022 13:04:06 +0000 (06:04 -0700)]
drm/i915: fix a possible refcount leak in intel_dp_add_mst_connector()
If drm_connector_init fails, intel_connector_free will be called to take
care of proper free. So it is necessary to drop the refcount of port
before intel_connector_free.
Andrzej Hajda [Fri, 24 Jun 2022 11:35:28 +0000 (13:35 +0200)]
drm/i915/selftests: fix subtraction overflow bug
On some machines hole_end can be small enough to cause subtraction
overflow. On the other side (addr + 2 * min_alignment) can overflow
in case of mock tests. This patch should handle both cases.
Use atomic_try_cmpxchg instead of atomic_cmpxchg (*ptr, old, new) == old
in blkcg_unuse_delay, blkcg_set_delay and blkcg_clear_delay and
atomic64_try_cmpxchg in blkcg_scale_delay. x86 CMPXCHG instruction
returns success in ZF flag, so this change saves a compare after cmpxchg
(and related move instruction in front of cmpxchg).
Also, atomic_try_cmpxchg implicitly assigns old *ptr value to "old" when
cmpxchg fails, enabling further code simplifications.
Use atomic_try_cmpxchg instead of atomic_cmpxchg (*ptr, old, new) == old
in check_scale_change and atomic64_try_cmpxchg in blkcg_iolatency_done_bio.
x86 CMPXCHG instruction returns success in ZF flag, so this change saves a
compare after cmpxchg (and related move instruction in front of cmpxchg).
Chris Wilson [Fri, 8 Jul 2022 14:20:13 +0000 (16:20 +0200)]
drm/i915/gt: Only kick the signal worker if there's been an update
One impact of commit 047a1b877ed4 ("dma-buf & drm/amdgpu: remove
dma_resv workaround") is that it stores many, many more fences. Whereas
adding an exclusive fence used to remove the shared fence list, that
list is now preserved and the write fences included into the list. Not
just a single write fence, but now a write/read fence per context. That
causes us to have to track more fences than before (albeit half of those
are redundant), and we trigger more interrupts for multi-engine
workloads.
As part of reducing the impact from handling more signaling, we observe
we only need to kick the signal worker after adding a fence iff we have
good cause to believe that there is work to be done in processing the
fence i.e. we either need to enable the interrupt or the request is
already complete but we don't know if we saw the interrupt and so need
to check signaling.
Chris Wilson [Fri, 8 Jul 2022 14:20:12 +0000 (16:20 +0200)]
drm/i915: Bump GT idling delay to 2 jiffies
In monitoring a transcode pipeline that is latency sensitive (it waits
between submitting frames, and each frame requires work on rcs/vcs/vecs
engines), it is found that it took longer than a single jiffy for it to
sustain its workload. Allowing an extra jiffy headroom for the userspace
prevents us from prematurely parking and having to exit powersaving
immediately.
Chris Wilson [Fri, 8 Jul 2022 14:20:11 +0000 (16:20 +0200)]
drm/i915/gem: Look for waitboosting across the whole object prior to individual waits
We employ a "waitboost" heuristic to detect when userspace is stalled
waiting for results from earlier execution. Under latency sensitive work
mixed between the gpu/cpu, the GPU is typically under-utilised and so
RPS sees that low utilisation as a reason to downclock the frequency,
causing longer stalls and lower throughput. The user left waiting for
the results is not impressed.
On applying commit 047a1b877ed4 ("dma-buf & drm/amdgpu: remove dma_resv
workaround") it was observed that deinterlacing h264 on Haswell
performance dropped by 2-5x. The reason being that the natural workload
was not intense enough to trigger RPS (using HW evaluation intervals) to
upclock, and so it was depending on waitboosting for the throughput.
Commit 047a1b877ed4 ("dma-buf & drm/amdgpu: remove dma_resv workaround")
changes the composition of dma-resv from keeping a single write fence +
multiple read fences, to a single array of multiple write and read
fences (a maximum of one pair of write/read fences per context). The
iteration order was also changed implicitly from all-read fences then
the single write fence, to a mix of write fences followed by read
fences. It is that ordering change that belied the fragility of
waitboosting.
Currently, a waitboost is inspected at the point of waiting on an
outstanding fence. If the GPU is backlogged such that we haven't yet
stated the request we need to wait on, we force the GPU to upclock until
the completion of that request. By changing the order in which we waited
upon requests, we ended up waiting on those requests in sequence and as
such we saw that each request was already started and so not a suitable
candidate for waitboosting.
Instead of asking whether to boost each fence in turn, we can look at
whether boosting is required for the dma-resv ensemble prior to waiting
on any fence, making the heuristic more robust to the order in which
fences are stored in the dma-resv.
Chris Wilson [Tue, 12 Jul 2022 15:21:33 +0000 (16:21 +0100)]
drm/i915/gt: Serialize TLB invalidates with GT resets
Avoid trying to invalidate the TLB in the middle of performing an
engine reset, as this may result in the reset timing out. Currently,
the TLB invalidate is only serialised by its own mutex, forgoing the
uncore lock, but we can take the uncore->lock as well to serialise
the mmio access, thereby serialising with the GDRST.
Tested on a NUC5i7RYB, BIOS RYBDWi35.86A.0380.2019.0517.1530 with
i915 selftest/hangcheck.
Chris Wilson [Tue, 12 Jul 2022 15:21:32 +0000 (16:21 +0100)]
drm/i915/gt: Serialize GRDOM access between multiple engine resets
Don't allow two engines to be reset in parallel, as they would both
try to select a reset bit (and send requests to common registers)
and wait on that register, at the same time. Serialize control of
the reset requests/acks using the uncore->lock, which will also ensure
that no other GT state changes at the same time as the actual reset.
Cc: stable@vger.kernel.org # v4.4 and upper Reported-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Andi Shyti <andi.shyti@intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Acked-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/e0a2d894e77aed7c2e36b0d1abdc7dbac3011729.1657639152.git.mchehab@kernel.org
Zheng Yejian [Thu, 30 Jun 2022 01:31:52 +0000 (09:31 +0800)]
tracing/histograms: Simplify create_hist_fields()
When I look into implements of create_hist_fields(), I think there can be
following two simplifications:
1. If something wrong happened in parse_var_defs(), free_var_defs() would
have been called in it, so no need goto free again after calling it;
2. After calling create_key_fields(), regardless of the value of 'ret', it
then always runs into 'out: ', so the judge of 'ret' is redundant.
Merge tag 'arm-soc/for-5.20/defconfig-arm64' of https://github.com/Broadcom/stblinux into arm/defconfig
This pull request contains Broadcom ARM64-based SoCs defconfig changes
for 5.10, please pull the following:
- Nicolas enables CONFIG_DRM_V3D in order for the Raspberry Pi 4 systems
to load the proper GPU module driver
- William enables the newly introduced CONFIG_ARCH_BCMBCA 64-bit ARM
counterpart to support the newly added BCA SocS
* tag 'arm-soc/for-5.20/defconfig-arm64' of https://github.com/Broadcom/stblinux:
arm64: defconfig: Enable DRM_V3D
arm64: defconfig: enable bcmbca soc support
Merge tag 'arm-soc/for-5.20/defconfig' of https://github.com/Broadcom/stblinux into arm/defconfig
This pull request contains ARM SoCs defconfig changes for 5.20, please
pull the following:
- Peter enables CONFIG_DRM_V3D in order for the Raspberry Pi 4 systems
to load the proper GPU module driver
- William updates the multi_v7_defconfig to replace the enabling of
CONFIG_ARCH_BCM_63XX with CONFIG_ARCH_BCMBCA which is how this platform
is now supported
* tag 'arm-soc/for-5.20/defconfig' of https://github.com/Broadcom/stblinux:
ARM: multi_v7_defconfig: Update configs for BCM63138
ARM: configs: Enable DRM_V3D
Sibi Sankar [Tue, 5 Jul 2022 11:32:01 +0000 (17:02 +0530)]
dt-bindings: remoteproc: qcom: Convert SC7180 MSS bindings to YAML
Add a separate YAML binding to act as a superset of the PAS and non-PAS
compatible for SC7180 MSS PIL. This also serves as a way to increase
readability.
Merge tag 'imx-defconfig-5.20' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/defconfig
i.MX defconfig update for 5.20:
- Enable i.MX93 clock and pinctrl driver in arm64 defconfig.
- Enable gpio-fan driver in arm64 defconfig, as it's needed by
phyBOARD-Polis-i.MX8M Mini board.
* tag 'imx-defconfig-5.20' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
arm64: defconfig: Enable gpio-fan support
arm64: defconfig: enable i.MX93 clk & pinctrl
Sibi Sankar [Tue, 5 Jul 2022 11:32:00 +0000 (17:02 +0530)]
dt-bindings: remoteproc: qcom: Convert SC7280 MSS bindings to YAML
Add a separate YAML binding to act as a superset of the PAS and non-PAS
compatible for SC7280 MSS PIL. This also serves as a way to increase
readability.
Merge tag 'qcom-drivers-for-5.20' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/drivers
Qualcomm driver updates for v5.20
This introduces a new driver that requests interconnect bandwidth based
on throughput measurements of the bwmon hardware blocks found associated
with, among other things, the CPU subsystem on many Qualcomm platforms.
It introduces support for the SCM wrapper driver to vote for
interconnect bandwidth for operations that needs bandwidth to the crypto
engine. This ensures both performance and guards against issues caused
by lacking votes for this path.
The socinfo driver gains knowledge about the SC7180P SoC.
It contains a range of fixes for spelling mistakes, refcount leaks in
various drivers and removes some redundant code from the apr remove
path.
The SCM DT bindings are updated to declare support for QCS404, SM6125
and SDX65.
The command db driver has a strncpy() converted to strscpy_pad() and
then back again with proper documentation to why this was the right API.
* tag 'qcom-drivers-for-5.20' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
soc: qcom: icc-bwmon: Add bandwidth monitoring driver
dt-bindings: interconnect: qcom,msm8998-cpu-bwmon: add BWMON device
soc/qcom: Make QCOM_RPMPD select PM_GENERIC_DOMAINS/_OF
soc: qcom: aoss: Fix refcount leak in qmp_cooling_devices_register
soc: qcom: llcc: Fix syntax errors in comments
soc: qcom: ocmem: Fix refcount leak in of_get_ocmem
dt-bindings: soc: qcom,wcnss: remove unneeded ref for names
firmware: qcom_scm: Add bw voting support to the SCM interface
dt-bindings: firmware: qcom-scm: Add interconnects property
soc: qcom: cmd-db: replace strscpy_pad() with strncpy()
dt-bindings: firmware: scm: Add compatible for SDX65
dt-bindings: arm: qcom: switch maintainer to Bjorn
soc: qcom: rpmhpd: fix typos in comment
soc: qcom: correct kerneldoc
soc: qcom: cmd-db: replace strncpy() with strscpy_pad()
firmware: qcom_scm-legacy: correct kerneldoc
dt-bindings: firmware: document Qualcomm QCS404 and SM6125 SCM
soc: qcom: apr: Drop redundant check in .remove()
firmware: qcom_scm: drop unexpected word "the"
soc: qcom: socinfo: Add an ID for sc7180P
Merge tag 'arm-soc/for-5.20/drivers' of https://github.com/Broadcom/stblinux into arm/drivers
This pull request contains Broadcom SoC drivers updatse for 5.20, please
pull the following:
- Julia fixes a typo in the Broadcom STB legacy power management code
- Liang fixes a device_node reference count leak in the Broadcom STB BIU
driver code error path(s)
- Nicolas and Stefan provide updates to the BCM2835 power management
driver allowing its use on BCM2711 (Raspberry Pi 4) and to enable the
use of the V3D GPU driver on such platforms. This is a merge of an
immutable branch from Lee Jones' MFD tree
- William removes the use of CONFIG_ARCH_BCM_63XX which is removed and
replaces the dependencies with CONFIG_ARCH_BCMBCA which is how all of
the DSL/PON SoCs from Broadcom are now supported in the upstream
kernel.
* tag 'arm-soc/for-5.20/drivers' of https://github.com/Broadcom/stblinux:
tty: serial: bcm63xx: bcmbca: Replace ARCH_BCM_63XX with ARCH_BCMBCA
spi: bcm63xx-hsspi: bcmbca: Replace ARCH_BCM_63XX with ARCH_BCMBCA
clk: bcm: bcmbca: Replace ARCH_BCM_63XX with ARCH_BCMBCA
hwrng: bcm2835: bcmbca: Replace ARCH_BCM_63XX with ARCH_BCMBCA
phy: brcm-sata: bcmbca: Replace ARCH_BCM_63XX with ARCH_BCMBCA
i2c: brcmstb: bcmbca: Replace ARCH_BCM_63XX with ARCH_BCMBCA
ata: ahci_brcm: bcmbca: Replace ARCH_BCM_63XX with ARCH_BCMBCA
soc: bcm: bcm2835-power: Bypass power_on/off() calls
soc: bcm: bcm2835-power: Add support for BCM2711's RPiVid ASB
soc: bcm: bcm2835-power: Resolve ASB register macros
soc: bcm: bcm2835-power: Refactor ASB control
mfd: bcm2835-pm: Add support for BCM2711
mfd: bcm2835-pm: Use 'reg-names' to get resources
soc: bcm: brcmstb: biuctrl: Add missing of_node_put()
soc: bcm: brcmstb: pm: pm-arm: fix typo in comment
projects / people / ms / linux.git / log
