Age | Commit message (Collapse) | Author | Files | Lines |
|
Fix two bugs with the Intel HDA Realtek ALC233 sound codec
present in Intel NUC NUC8i7BEH and probably a few other similar
NUC models.
These codecs advertise a 4-level microphone input boost amplifier on
pin 0x19, but the highest two boost settings do not work correctly,
and produce only low analog noise that does not seem to contain any
discernible signal. There is an existing fixup for this exact problem
but for a different PCI subsystem ID, so we re-use that logic.
Changing the boost level also triggers a DC spike in the input signal
that bleeds off over about a second and overwhelms any input during
that time. Thankfully, the existing fixup has the side effect of
making the boost control show up in userspace as a mute/unmute switch,
and this keeps (e.g.) PulseAudio from fiddling with it during normal
input volume adjustments.
Finally, the NUC hardware has built-in inverted stereo mics. This
patch also enables the usual fixup for this so the two channels cancel
noise instead of the actual signal.
[ Re-ordered the quirk entry point by tiwai ]
Signed-off-by: Phil Calvin <[email protected]>
Cc: <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
|
|
We've got a report about the possible race in the user control element
counts (card->user_ctl_count), and it was confirmed that the race
wasn't serious in the old code up to 5.12. There, the value
modification itself was exclusive and protected via a write semaphore,
hence it's at most concurrent reads and evaluations before the
increment. Since it's only about the soft-limit to avoid the
exhausting memory usage, one-off isn't a big problem at all.
Meanwhile, the relevant code has been largely modified recently, and
now card->user_ctl_count was replaced with card->user_ctl_alloc_size,
and a few more places were added to access this field. And, in this
new code, it turned out to be more serious: the modifications are
scattered in various places, and a few of them are without protection.
It implies that it may lead to an inconsistent value by racy
accesses.
For addressing it, this patch extends the range covered by the
card->controls_rwsem write lock at snd_ctl_elem_add() so that the all
code paths that modify and refer to card->user_ctl_alloc_size are
protected by the rwsem properly.
The patch adds also comments in a couple of functions to indicate that
they are under the rwsem lock.
Fixes: 66c6d1ef86ff ("ALSA: control: Add memory consumption limit to user controls")
Link: https://lore.kernel.org/r/[email protected]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
|
|
Current riscv's kprobe handlers are run with both preemption and
interrupt enabled, this violates kprobe requirements. Fix this issue
by keeping interrupts disabled for BREAKPOINT exception.
Fixes: c22b0bcb1dd0 ("riscv: Add kprobes supported")
Cc: [email protected]
Signed-off-by: Jisheng Zhang <[email protected]>
Reviewed-by: Masami Hiramatsu <[email protected]>
[Palmer: add a comment]
Signed-off-by: Palmer Dabbelt <[email protected]>
|
|
Currently, the riscv's kprobes(powerred by ftrace) handler is
preemptible. Futher check indicates we miss something similar as the
commit c536aa1c5b17 ("kprobes/ftrace: Add recursion protection to the
ftrace callback"), so do similar modifications as the commit does.
Fixes: 829adda597fe ("riscv: Add KPROBES_ON_FTRACE supported")
Cc: [email protected]
Signed-off-by: Jisheng Zhang <[email protected]>
Reviewed-by: Steven Rostedt (VMware) <[email protected]>
Signed-off-by: Palmer Dabbelt <[email protected]>
|
|
These two functions are used to implement the kprobes feature so they
can't be kprobed.
Fixes: c22b0bcb1dd0 ("riscv: Add kprobes supported")
Cc: [email protected]
Signed-off-by: Jisheng Zhang <[email protected]>
Reviewed-by: Masami Hiramatsu <[email protected]>
Signed-off-by: Palmer Dabbelt <[email protected]>
|
|
There is a spelling mistake when SPARSEMEM Kconfig copy.
Fixes: a5406a7ff56e ("riscv: Correct SPARSEMEM configuration")
Cc: [email protected]
Signed-off-by: Kefeng Wang <[email protected]>
Signed-off-by: Palmer Dabbelt <[email protected]>
|
|
The "Register Offset Low" register of a "DVSEC Register Locator"
contains the 64K aligned offset for the registers along with the BAR
indicator and an id. The implementation was treating the "Register Block
Offset Low" field a value rather than as a pre-aligned component of the
64-bit offset. So, just mask, don't mask and shift (FIELD_GET).
The user visible result of this bug is that the driver fails to bind to
the device after none of the required blocks are found.
This was missed earlier because the primary development done in the QEMU
environment only uses 0 offsets, i.e. 0 shifted is still 0.
Fixes: 8adaf747c9f0 ("cxl/mem: Find device capabilities")
Reported-by: Vishal Verma <[email protected]>
Signed-off-by: Ben Widawsky <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Dan Williams <[email protected]>
|
|
Vinay Kumar Yadav says:
====================
chelsio/ch_ktls: chelsio inline tls driver bug fixes
This series of patches fix following bugs in Chelsio inline tls driver.
Patch1: kernel panic.
Patch2: connection close issue.
Patch3: tcb close call issue.
Patch4: unnecessary snd_una update.
====================
Signed-off-by: David S. Miller <[email protected]>
|
|
snd_una update should not be done when the same skb is being
sent out.chcr_short_record_handler() sends it again even
though SND_UNA update is already sent for the skb in
chcr_ktls_xmit(), which causes mismatch in un-acked
TCP seq number, later causes problem in sending out
complete record.
Fixes: 429765a149f1 ("chcr: handle partial end part of a record")
Signed-off-by: Vinay Kumar Yadav <[email protected]>
Signed-off-by: Rohit Maheshwari <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
HW doesn't need marking TCB closed. This TCB state change
sometimes causes problem to the new connection which gets
the same tid.
Fixes: 34aba2c45024 ("cxgb4/chcr : Register to tls add and del callback")
Signed-off-by: Vinay Kumar Yadav <[email protected]>
Signed-off-by: Rohit Maheshwari <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
When sge queue is full and chcr_ktls_xmit_wr_complete()
returns failure, skb is not freed if it is not the last tls record in
this skb, causes refcount never gets freed and tls_dev_del()
never gets called on this connection.
Fixes: 5a4b9fe7fece ("cxgb4/chcr: complete record tx handling")
Signed-off-by: Vinay Kumar Yadav <[email protected]>
Signed-off-by: Rohit Maheshwari <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Taking page refcount is not ideal and causes kernel panic
sometimes. It's better to take tx_ctx lock for the complete
skb transmit, to avoid page cleanup if ACK received in middle.
Fixes: 5a4b9fe7fece ("cxgb4/chcr: complete record tx handling")
Signed-off-by: Vinay Kumar Yadav <[email protected]>
Signed-off-by: Rohit Maheshwari <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux
Saeed Mahameed says:
====================
mlx5 fixes 2021-04-14
This series provides 3 small fixes to mlx5 driver.
Please pull and let me know if there is any problem.
====================
Signed-off-by: David S. Miller <[email protected]>
|
|
Fix this panic by adding more rules to calculate the value of @rss_size_max
which could be used in allocating the queues when bpf is loaded, which,
however, could cause the failure and then trigger the NULL pointer of
vsi->rx_rings. Prio to this fix, the machine doesn't care about how many
cpus are online and then allocates 256 queues on the machine with 32 cpus
online actually.
Once the load of bpf begins, the log will go like this "failed to get
tracking for 256 queues for VSI 0 err -12" and this "setup of MAIN VSI
failed".
Thus, I attach the key information of the crash-log here.
BUG: unable to handle kernel NULL pointer dereference at
0000000000000000
RIP: 0010:i40e_xdp+0xdd/0x1b0 [i40e]
Call Trace:
[2160294.717292] ? i40e_reconfig_rss_queues+0x170/0x170 [i40e]
[2160294.717666] dev_xdp_install+0x4f/0x70
[2160294.718036] dev_change_xdp_fd+0x11f/0x230
[2160294.718380] ? dev_disable_lro+0xe0/0xe0
[2160294.718705] do_setlink+0xac7/0xe70
[2160294.719035] ? __nla_parse+0xed/0x120
[2160294.719365] rtnl_newlink+0x73b/0x860
Fixes: 41c445ff0f48 ("i40e: main driver core")
Co-developed-by: Shujin Li <[email protected]>
Signed-off-by: Shujin Li <[email protected]>
Signed-off-by: Jason Xing <[email protected]>
Reviewed-by: Jesse Brandeburg <[email protected]>
Acked-by: Jesper Dangaard Brouer <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
I noticed a weird bug with this driver on Marvell CN9130 Customer
Reference Board.
Sometime after boot, the system locks with the following message:
[104.071363] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
The system does not respond afterwards, only warns about RCU stalls.
This first appeared with commit e5c02cf54154 ("i2c: mv64xxx: Add runtime
PM support").
With further experimentation I discovered that adding a delay into
mv64xxx_i2c_hw_init() fixes this issue. This function is called before
every xfer, due to how runtime PM works in this driver. It seems that in
order to work correctly, a delay is needed after the bus is reset in
this function.
Since there already is a known erratum with this controller needing a
delay, I assume that this is just another place this needs to be
applied. Therefore I apply the delay only if errata_delay is true.
Signed-off-by: Marek Behún <[email protected]>
Acked-by: Gregory CLEMENT <[email protected]>
Reviewed-by: Samuel Holland <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI fix from Rafael Wysocki:
"Restore the initrd-based ACPI table override functionality broken by
one of the recent fixes"
* tag 'acpi-5.12-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI: x86: Call acpi_boot_table_init() after acpi_table_upgrade()
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux
Pull gpio fix from Bartosz Golaszewski:
"A single fix for an older problem with the sysfs interface: do not
allow exporting GPIO lines which were marked invalid by the driver"
* tag 'gpio-fixes-for-v5.12-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
gpio: sysfs: Obey valid_mask
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid
Pull HID fixes from Jiri Kosina:
"The changes are all device/driver specific fixes:
- EV_KEY and EV_ABS regression fix for Wacom from Ping Cheng
- BIOS-specific quirk to fix some of the AMD_SFH-based systems, from
Hans de Goede
- other small error handling fixes and device ID additions"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid:
HID: wacom: set EV_KEY and EV_ABS only for non-HID_GENERIC type of devices
AMD_SFH: Add DMI quirk table for BIOS-es which don't set the activestatus bits
AMD_SFH: Add sensor_mask module parameter
AMD_SFH: Removed unused activecontrolstatus member from the amd_mp2_dev struct
HID: wacom: Assign boolean values to a bool variable
HID cp2112: fix support for multiple gpiochips
HID: alps: fix error return code in alps_input_configured()
HID: asus: Add support for 2021 ASUS N-Key keyboard
HID: google: add don USB id
|
|
After commit 2decad92f473 ("arm64: mte: Ensure TIF_MTE_ASYNC_FAULT is
set atomically"), LLVM's integrated assembler fails to build entry.S:
<instantiation>:5:7: error: expected assembly-time absolute expression
.org . - (664b-663b) + (662b-661b)
^
<instantiation>:6:7: error: expected assembly-time absolute expression
.org . - (662b-661b) + (664b-663b)
^
The root cause is LLVM's assembler has a one-pass design, meaning it
cannot figure out these instruction lengths when the .org directive is
outside of the subsection that they are in, which was changed by the
.arch_extension directive added in the above commit.
Apply the same fix from commit 966a0acce2fc ("arm64/alternatives: move
length validation inside the subsection") to the alternative_endif
macro, shuffling the .org directives so that the length validation
happen will always happen in the same subsections. alternative_insn has
not shown any issue yet but it appears that it could have the same issue
in the future so just preemptively change it.
Fixes: f7b93d42945c ("arm64/alternatives: use subsections for replacement sequences")
Cc: <[email protected]> # 5.8.x
Link: https://github.com/ClangBuiltLinux/linux/issues/1347
Signed-off-by: Nathan Chancellor <[email protected]>
Reviewed-by: Sami Tolvanen <[email protected]>
Tested-by: Sami Tolvanen <[email protected]>
Reviewed-by: Nick Desaulniers <[email protected]>
Tested-by: Nick Desaulniers <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Catalin Marinas <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
Pull input fixes from Dmitry Torokhov:
"Just a few driver fixes here"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
Input: elants_i2c - drop zero-checking of ABS_MT_TOUCH_MAJOR resolution
Input: elants_i2c - fix division by zero if firmware reports zero phys size
Input: nspire-keypad - enable interrupts only when opened
Input: i8042 - fix Pegatron C15B ID entry
Input: n64joy - fix return value check in n64joy_probe()
Input: s6sy761 - fix coordinate read bit shift
|
|
Recently, the sof_pcm_dai_link_fixup() function was
updated to match SSP config with the PCM hw_params
and set the current_config for the DAI widget.
But the sof_restore_pipelines() function still chooses the
default config for the DAI widget upon resuming. Fix this
to use the last used config when setting up the DAI widget
during resume.
Fixes: c943a586f6e49 ("ASoC: SOF: match SSP config with pcm hw params")
Reviewed-by: Kai Vehmanen <[email protected]>
Signed-off-by: Ranjani Sridharan <[email protected]>
Signed-off-by: Pierre-Louis Bossart <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
kabylake_ssp_fixup function uses snd_soc_dpcm to identify the
codecs DAIs. The HW parameters are changed based on the codec DAI of the
stream. The earlier approach to get snd_soc_dpcm was using container_of()
macro on snd_pcm_hw_params.
The structures have been modified over time and snd_soc_dpcm does not have
snd_pcm_hw_params as a reference but as a copy. This causes the current
driver to crash when used.
This patch changes the way snd_soc_dpcm is extracted. snd_soc_pcm_runtime
holds 2 dpcm instances (one for playback and one for capture). 2 codecs
on the SSP are dmic (capture) and speakers (playback). Based on the
stream direction, snd_soc_dpcm is extracted from snd_soc_pcm_runtime.
Tested for all use cases of the driver.
Based on similar fix in kbl_rt5663_rt5514_max98927.c
from Harsha Priya <[email protected]> and
Vamshi Krishna Gopal <[email protected]>
Cc: <[email protected]> # 5.4+
Signed-off-by: Lukasz Majczak <[email protected]>
Acked-by: Pierre-Louis Bossart <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
Kuninori Morimoto <[email protected]>:
Hi Mark
These patches adjusts to multi CPU/Codec on simple-card / audio-graph.
This is part of prepare for new audio-graph-card2.
Kuninori Morimoto (5):
ASoC: simple-card: remove unused variable from simple_parse_of()
ASoC: simple-card: use asoc_link_to_xxx() macro
ASoC: simple-card: use simple_props_to_xxx() macro
ASoC: audio-graph: use asoc_link_to_xxx() macro
ASoC: audio-graph: use simple_props_to_xxx() macro
sound/soc/generic/audio-graph-card.c | 43 +++++++++++++-----------
sound/soc/generic/simple-card.c | 50 +++++++++++++---------------
2 files changed, 47 insertions(+), 46 deletions(-)
--
2.25.1
|
|
Coccinelle noticed:
sound/soc/codecs/wcd934x.c:5041:7-32: ERROR: Threaded IRQ with no primary
handler requested without IRQF_ONESHOT
Signed-off-by: Guangqing Zhu <[email protected]>
Reviewed-by: Srinivas Kandagatla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
We shouldn't use dai_props->cpus/codecs directly,
because these are array now to supporting multi CPU/Codec/Platform.
This patch uses simple_props_to_xxx() macro for it.
Signed-off-by: Kuninori Morimoto <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
We shouldn't use dai_link->cpus/codecs/platforms directly,
because these are array now to supporting multi CPU/Codec/Platform.
This patch uses asoc_link_to_xxx() macro for it.
Signed-off-by: Kuninori Morimoto <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
We shouldn't use dai_props->cpus/codecs directly,
because these are array now to supporting multi CPU/Codec/Platform.
This patch uses simple_props_to_xxx() macro for it.
Signed-off-by: Kuninori Morimoto <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
We shouldn't use dai_link->cpus/codecs/platforms directly,
because these are array now to supporting multi CPU/Codec/Platform.
This patch uses asoc_link_to_xxx() macro for it.
Signed-off-by: Kuninori Morimoto <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
commit d9ffff696c5b4 ("ASoC: simple-card: Use snd_soc_of_parse_aux_devs()")
switched to use snd_soc_of_parse_aux_devs() on simple_parse_of().
Thus noone is using *top anymore. Let's cleanup unused variable.
Signed-off-by: Kuninori Morimoto <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
Display panel & power related fixes:
- Backlight fix (Lyude)
- Display watermark fix (Ville)
- VLV panel power fix (Hans)
Signed-off-by: Daniel Vetter <[email protected]>
From: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/YHg4nz/[email protected]
|
|
In the nft_offload there is the mate flow_dissector with no
ingress_ifindex but with ingress_iftype that only be used
in the software. So if the mask of ingress_ifindex in meta is
0, this meta check should be bypass.
Fixes: 6d65bc64e232 ("net/mlx5e: Add mlx5e_flower_parse_meta support")
Signed-off-by: wenxu <[email protected]>
Acked-by: Pablo Neira Ayuso <[email protected]>
Signed-off-by: Saeed Mahameed <[email protected]>
|
|
Change register setting from bit number to bit mask.
Fixes: b5ede32d3329 ("net/mlx5e: Add support for FEC modes based on 50G per lane links")
Signed-off-by: Aya Levin <[email protected]>
Reviewed-by: Eran Ben Elisha <[email protected]>
Signed-off-by: Saeed Mahameed <[email protected]>
|
|
Prevent setting of devlink traps on the uplink while in switchdev mode.
In this mode, it is the SW switch responsibility to handle both packets
with a mismatch in destination MAC or VLAN ID. Therefore, there are no
flow steering tables to trap undesirable packets and driver crashes upon
setting a trap.
Fixes: 241dc159391f ("net/mlx5: Notify on trap action by blocking event")
Signed-off-by: Aya Levin <[email protected]>
Reviewed-by: Moshe Shemesh <[email protected]>
Reviewed-by: Roi Dayan <[email protected]>
Reviewed-by: Tariq Toukan <[email protected]>
Signed-off-by: Saeed Mahameed <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue
Tony Nguyen says:
====================
Intel Wired LAN Driver Updates 2021-04-14
This series contains updates to ixgbe and ice drivers.
Alex Duyck fixes a NULL pointer dereference for ixgbe.
Yongxin Liu fixes an unbalanced enable/disable which was causing a call
trace with suspend for ixgbe.
Colin King fixes a potential infinite loop for ice.
====================
Signed-off-by: David S. Miller <[email protected]>
|
|
This reverts commit 9c63faaa931e443e7abbbee9de0169f1d4710546, which
introduces a suspend/resume regression on Jetson TX2 boards that can be
reproduced every time. Given that the issue that this was supposed to
fix only occurs very sporadically the safest course of action is to
revert before v5.12 and then we can have another go at fixing the more
rare issue in the next release (and perhaps backport it if necessary).
The root cause of the observed problem seems to be that when the system
is suspended, some packets are still in transit. When the descriptors
for these buffers are cleared on resume, the descriptors become invalid
and cause a fatal bus error.
Link: https://lore.kernel.org/r/[email protected]/
Reported-by: Jonathan Hunter <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Fix the following coccicheck warning:
./drivers/net/ethernet/cavium/liquidio/cn66xx_regs.h:413:6-28:
duplicated argument to & or |
The CN6XXX_INTR_M1UPB0_ERR here is duplicate.
Here should be CN6XXX_INTR_M1UNB0_ERR.
Signed-off-by: Wan Jiabing <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Commit a14d273ba159 ("net: macb: restore cmp registers on resume path")
introduces the restore of CMP registers on resume path. In case the IP
doesn't support type 2 screeners (zero on DCFG8 register) the
struct macb::rx_fs_list::list is not initialized and thus the
list_for_each_entry(item, &bp->rx_fs_list.list, list) loop introduced in
commit a14d273ba159 ("net: macb: restore cmp registers on resume path")
will access an uninitialized list leading to crash. Thus, initialize
the struct macb::rx_fs_list::list without taking into account if the
IP supports type 2 screeners or not.
Fixes: a14d273ba159 ("net: macb: restore cmp registers on resume path")
Signed-off-by: Claudiu Beznea <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
During cotable resize we pin the backup buffer to make sure the
trylock doesn't fail. We were never unpinning the backup buffer
resulting in every subsequent cotable resize trying to release a
pinned bo. After we copy the old backup to the new we can release
the pin.
Mob's are always pinned so we just have to make sure we unpin
them before releasing them.
Reviewed-by: Thomas Hellström (Intel) <[email protected]>
Fixes: d1a73c641afd ("drm/vmwgfx: Make sure we unpin no longer needed buffers")
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Zack Rusin <[email protected]>
|
|
Thomas has noticed that the lockdep was broken in vmwgfx. It
was broken during the pci initialization rework. This fixes
the breakage by making sure we initialize the locking code
before doing anything else. This was independently spotted
and fixed by Tetsuo Handa as well.
Reviewed-by: Martin Krastev <[email protected]>
Reviewed-by: Roland Scheidegger <[email protected]>
Cc: Tetsuo Handa <[email protected]>
Cc: [email protected]
Signed-off-by: Zack Rusin <[email protected]>
Fixes: 8772c0bb58bbf98a ("drm/vmwgfx: Cleanup pci resource allocation")
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
We were not correctly unpinning no longer needed buffers. In particular
vmw_buffer_object, which is internally often pinned on creation wasn't
unpinned on destruction and none of the internal MOB buffers were
unpinned before being put back. Technically this existed for a
long time but commit 57fcd550eb15 ("drm/ttm: Warn on pinning without
holding a reference") introduced a WARN_ON which was filling up the
kernel logs rather quickly.
Quite frankly internal usage of vmw_buffer_object and in general
pinning needs to be refactored in vmwgfx but for now this makes
it work.
Signed-off-by: Zack Rusin <[email protected]>
Reviewed-by: Martin Krastev <[email protected]>
Reviewed-by: Roland Scheidegger <[email protected]>
Fixes: 57fcd550eb15 ("drm/ttm: Warn on pinning without holding a reference")
Link: https://patchwork.freedesktop.org/patch/414984/?series=86052&rev=1
Cc: Huang Rui <[email protected]>
Cc: Christian König <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Christian Koenig <[email protected]>
Cc: [email protected]
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
Pull device mapper fix from Mike Snitzer:
"Fix DM verity target FEC support's RS roots IO to always be aligned.
This fixes a previous stable@ fix that overcorrected for a different
configuration that also resulted in misaligned roots IO"
* tag 'for-5.12/dm-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
dm verity fec: fix misaligned RS roots IO
|
|
This is a leftover of the below commit.
Fixes: 4f04256c983a ("net: vrf: Drop local rtable and rt6_info")
Signed-off-by: Nicolas Dichtel <[email protected]>
Acked-by: David Ahern <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Let's have all seg6 sysctl at the same place.
Fixes: a6dc6670cd7e ("ipv6: sr: Add documentation for seg_flowlabel sysctl")
Signed-off-by: Nicolas Dichtel <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Lijun Pan says:
====================
ibmvnic: correctly call NAPI APIs
This series correct some misuse of NAPI APIs in the driver.
====================
Signed-off-by: David S. Miller <[email protected]>
|
|
Remove the unnecessary napi_schedule() call in __ibmvnic_open() since
interrupt_rx() calls napi_schedule_prep/__napi_schedule during every
receive interrupt.
Fixes: ed651a10875f ("ibmvnic: Updated reset handling")
Signed-off-by: Lijun Pan <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
During adapter reset, do_reset/do_hard_reset calls ibmvnic_open(),
which will calls napi_schedule if previous state is VNIC_CLOSED
(i.e, the reset case, and "ifconfig down" case). So there is no need
for do_reset to call napi_schedule again at the end of the function
though napi_schedule will neglect the request if napi is already
scheduled.
Fixes: ed651a10875f ("ibmvnic: Updated reset handling")
Signed-off-by: Lijun Pan <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
__ibmvnic_open calls napi_disable without checking whether NAPI polling
has already been disabled or not. This could cause napi_disable
being called twice, which could generate deadlock. For example,
the first napi_disable will spin until NAPI_STATE_SCHED is cleared
by napi_complete_done, then set it again.
When napi_disable is called the second time, it will loop infinitely
because no dev->poll will be running to clear NAPI_STATE_SCHED.
To prevent above scenario from happening, call ibmvnic_napi_disable()
which checks if napi is disabled or not before calling napi_disable.
Fixes: bfc32f297337 ("ibmvnic: Move resource initialization to its own routine")
Suggested-by: Thomas Falcon <[email protected]>
Signed-off-by: Lijun Pan <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
It has been reported [0] that using pause frames in jumbo mode impacts
performance. There's no available chip documentation, but vendor
drivers r8168 and r8125 don't advertise pause in jumbo mode. So let's
do the same, according to Roman it fixes the issue.
[0] https://bugzilla.kernel.org/show_bug.cgi?id=212617
Fixes: 9cf9b84cc701 ("r8169: make use of phy_set_asym_pause")
Reported-by: Roman Mamedov <[email protected]>
Tested-by: Roman Mamedov <[email protected]>
Signed-off-by: Heiner Kallweit <[email protected]>
Cc: [email protected]
Signed-off-by: David S. Miller <[email protected]>
|
|
The intention was for pause statistics to not be reported
when driver does not have the relevant callback (only
report an empty netlink nest). What happens currently
we report all 0s instead. Make sure statistics are
initialized to "not set" (which is -1) so the dumping
code skips them.
Fixes: 9a27a33027f2 ("ethtool: add standard pause stats")
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
[ 245.463317] INFO: task iou-sqp-1374:1377 blocked for more than 122 seconds.
[ 245.463334] task:iou-sqp-1374 state:D flags:0x00004000
[ 245.463345] Call Trace:
[ 245.463352] __schedule+0x36b/0x950
[ 245.463376] schedule+0x68/0xe0
[ 245.463385] __io_uring_cancel+0xfb/0x1a0
[ 245.463407] do_exit+0xc0/0xb40
[ 245.463423] io_sq_thread+0x49b/0x710
[ 245.463445] ret_from_fork+0x22/0x30
It happens when sqpoll forgot to run park_task_work and goes to exit,
then exiting user may remove ctx from sqd_list, and so corresponding
io_sq_thread() -> io_uring_cancel_sqpoll() won't be executed. Hopefully
it just stucks in do_exit() in this case.
Fixes: dbe1bdbb39db ("io_uring: handle signals for IO threads like a normal thread")
Reported-by: Joakim Hassila <[email protected]>
Signed-off-by: Pavel Begunkov <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
|