Add one configuration with no RT711.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Rander Wang <rander.wang@intel.com>
Reviewed-by: Libin Yang <libin.yang@intel.com>
Link: https://lore.kernel.org/r/20210415175013.192862-3-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add configurations ported over from TGL.
The topology names need to include link information given all the
hardware permutations.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Rander Wang <rander.wang@intel.com>
Reviewed-by: Libin Yang <libin.yang@intel.com>
Link: https://lore.kernel.org/r/20210415175013.192862-2-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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 <phil@philcalvin.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/80dc5663-7734-e7e5-25ef-15b5df24511a@philcalvin.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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: 66c6d1ef86 ("ALSA: control: Add memory consumption limit to user controls")
Link: https://lore.kernel.org/r/FEEBF384-44BE-42CF-8FB3-93470933F64F@purdue.edu
Link: https://lore.kernel.org/r/20210415131856.13113-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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: c22b0bcb1d ("riscv: Add kprobes supported")
Cc: stable@vger.kernel.org
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
[Palmer: add a comment]
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
Currently, the riscv's kprobes(powerred by ftrace) handler is
preemptible. Futher check indicates we miss something similar as the
commit c536aa1c5b ("kprobes/ftrace: Add recursion protection to the
ftrace callback"), so do similar modifications as the commit does.
Fixes: 829adda597 ("riscv: Add KPROBES_ON_FTRACE supported")
Cc: stable@vger.kernel.org
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
These two functions are used to implement the kprobes feature so they
can't be kprobed.
Fixes: c22b0bcb1d ("riscv: Add kprobes supported")
Cc: stable@vger.kernel.org
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
There is a spelling mistake when SPARSEMEM Kconfig copy.
Fixes: a5406a7ff5 ("riscv: Correct SPARSEMEM configuration")
Cc: stable@vger.kernel.org
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
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: 8adaf747c9 ("cxl/mem: Find device capabilities")
Reported-by: Vishal Verma <vishal.l.verma@intel.com>
Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>
Link: https://lore.kernel.org/r/20210415232610.603273-1-ben.widawsky@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
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 <davem@davemloft.net>
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: 429765a149 ("chcr: handle partial end part of a record")
Signed-off-by: Vinay Kumar Yadav <vinay.yadav@chelsio.com>
Signed-off-by: Rohit Maheshwari <rohitm@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
HW doesn't need marking TCB closed. This TCB state change
sometimes causes problem to the new connection which gets
the same tid.
Fixes: 34aba2c450 ("cxgb4/chcr : Register to tls add and del callback")
Signed-off-by: Vinay Kumar Yadav <vinay.yadav@chelsio.com>
Signed-off-by: Rohit Maheshwari <rohitm@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
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: 5a4b9fe7fe ("cxgb4/chcr: complete record tx handling")
Signed-off-by: Vinay Kumar Yadav <vinay.yadav@chelsio.com>
Signed-off-by: Rohit Maheshwari <rohitm@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
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: 5a4b9fe7fe ("cxgb4/chcr: complete record tx handling")
Signed-off-by: Vinay Kumar Yadav <vinay.yadav@chelsio.com>
Signed-off-by: Rohit Maheshwari <rohitm@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEGhZs6bAKwk/OTgTpSD+KveBX+j4FAmB3dv4ACgkQSD+KveBX
+j4VdQgAocwr2vJsDXi0Wk9I3haPQkUxw88EbggBQQVUZOqhWC3PMQLZhJp0U1LF
+smJ2irPlS/FVArnUW8sHPcbVBq3Vm04E/NWTd7tEYp+pxJcQV6ETRviFX5QMx2O
FBrfiaJJR1MR7kBUyvYbqhylz1FZy7kwNQq8RwmXOjs8C/uyxok1jEeaWZ6AoCoa
9J67xILajAaMKiFtpf/5SZPRgWPI9yPnzVeQMTLBKvH/jQUElkhOtxmCLOOR0BFL
FLyKFISxX2AebACD6wBJVa1BkRE4OWMaqJfDbZ7XqxWhjW6/fxlvvck9lMniDHd3
O2mZ0I2jFbLW3KSwPn1To3ie566Kwg==
=Pa2u
-----END PGP SIGNATURE-----
Merge tag 'mlx5-fixes-2021-04-14' of 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 <davem@davemloft.net>
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: 41c445ff0f ("i40e: main driver core")
Co-developed-by: Shujin Li <lishujin@kuaishou.com>
Signed-off-by: Shujin Li <lishujin@kuaishou.com>
Signed-off-by: Jason Xing <xingwanli@kuaishou.com>
Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
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 e5c02cf541 ("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 <kabel@kernel.org>
Acked-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Reviewed-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Restore the initrd-based ACPI table override functionality broken by
one of the recent fixes.
-----BEGIN PGP SIGNATURE-----
iQJGBAABCAAwFiEE4fcc61cGeeHD/fCwgsRv/nhiVHEFAmB4YJASHHJqd0Byand5
c29ja2kubmV0AAoJEILEb/54YlRxVxgP+gPMJ4hpNIj+x6m6Np7wgatwx/3fuWnq
Qgrpt8ydPXgSfj+B7sMvCmgkMt3f/c5tQa5k+j00tg0n6qHfQa8hISvUBofk6myu
t9J/zNiH75x/HXOBwHXHVoaNiZ6RtPu7AbmKCNfF0wSwt7CsTTtskplJEMtCtU8/
WPIbze7DlGXbLTtDZswfT+bu2ntc7sTHVPgFLtJpTuf3YpXvU5HUgA4HwATtpAV/
7cm3AFJuprSMWjFs+UXDbYB+66QYubhMcX1N6Ws2XVeVKQtkXIFIBe10eHJZGqhk
IUx/ICq0IGYdZr9RZ2r55mFgVYtthq+sV0APKKjmImcu4IxRQycHfNIYa4Uz3Nxn
qRroWiBnQDSMwQTR9ylfx/BxW0mG0FSZtmC2fY2fFLzu2NyOohfy3uiGaEepXK/U
7yFeUu94sIQ8pTuE4K5F55TsZZf2uXPcyug854qEBMHvoUBqwdBbmVWyG4f16Z71
CtVAEYtgBrV24XaNyEVy8xrjGzKXND45sWVrDgk3qiZSEMDC8XyPJaSHoWAcOrQt
laEZacqusASBUHfXNabbQseuNNzUwZWXhG9Vwmdb3remYWQs0fR6lJrd9LkvUBIM
dQ7kLm04BTAnwmPpL7vr72zaidtd/N8C1Wo7gO2WBZozc5qUsyOF20R6JtXWEkSU
oSm3wAsI0Vfc
=82xL
-----END PGP SIGNATURE-----
Merge tag 'acpi-5.12-rc8' of 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()
- do not allow exporting GPIO lines which were marked invalid by the driver
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEFp3rbAvDxGAT0sefEacuoBRx13IFAmB4RdwACgkQEacuoBRx
13ItChAAydlxfHgcH0GFnOHOy6Ezp1hgxZF9Chu+YniFM7tNGRmA+Kty4J3o1dp7
j7d0+wZ7Ju3CJ6bO2Eun2NW7BN3UlFOpl0At2UjN6xybY+IrCZBq3w4RrmhI+xrJ
Xbx0GuJKKqtCj8SRg6fAwLMopiHzO7UYd95NOEVpl3zAfHoxMi1dIxUs6vjxWL9f
Hem/QcuMHZtYI62LAPHlNGUCxDavj1jWD7UNmLPLHJ1NagVqdXxhRhCuFCwt7nq/
ss0HvIATRoKKS6e28hNTOQTdI4FJViqflCleeGnXTEKK4DcwltcC3Ka+4Qsm3/Uz
vIFAvi9FKctPCzc1JajyrQTd2oabTJ+bvv8AkxeDYYwdXZHCxIku/s4cmg7ioKn6
xLXM9OOpzc5x4nRksK6hPo/Q6iKh2Iy9lRYu2I9bgaJiL3tig3aSSOQLgin0dr4p
E7Rr6yXCvQxyVQyyakgznFFTahaA61x2UdgPKM+Z6qjSbCLhS3yxZDaEaOxk0JyL
OrFctItSkgtQoNecjS9pQ6msfJDFjS7qFuvwMZ+Tk91sOnseLCfD4HfxIjpiPJjh
DeQ6+/dxnU8OGg7VQwI4DfATBc0g+2v5MlUUKPGrDdy3jAo9SlLqo9HFZ6HImEZZ
Z0w4Vb8Q1vC6TlS7n+N2CAyrN2EaIRENG9/WBXv0lMggK58wz5A=
=GnR0
-----END PGP SIGNATURE-----
Merge tag 'gpio-fixes-for-v5.12-rc8' of 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
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 2decad92f4 ("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 966a0acce2 ("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: f7b93d4294 ("arm64/alternatives: use subsections for replacement sequences")
Cc: <stable@vger.kernel.org> # 5.8.x
Link: https://github.com/ClangBuiltLinux/linux/issues/1347
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Tested-by: Sami Tolvanen <samitolvanen@google.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Link: https://lore.kernel.org/r/20210414000803.662534-1-nathan@kernel.org
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
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: c943a586f6 ("ASoC: SOF: match SSP config with pcm hw params")
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20210415162107.130963-1-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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 <harshapriya.n@intel.com> and
Vamshi Krishna Gopal <vamshi.krishna.gopal@intel.com>
Cc: <stable@vger.kernel.org> # 5.4+
Signed-off-by: Lukasz Majczak <lma@semihalf.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20210415124347.475432-1-lma@semihalf.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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
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 <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87k0p5zs97.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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 <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87lf9lzs9c.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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 <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87mtu1zs9i.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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 <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87o8ehzs9n.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
commit d9ffff696c ("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 <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87pmyxzs9w.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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: 6d65bc64e2 ("net/mlx5e: Add mlx5e_flower_parse_meta support")
Signed-off-by: wenxu <wenxu@ucloud.cn>
Acked-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Change register setting from bit number to bit mask.
Fixes: b5ede32d33 ("net/mlx5e: Add support for FEC modes based on 50G per lane links")
Signed-off-by: Aya Levin <ayal@nvidia.com>
Reviewed-by: Eran Ben Elisha <eranbe@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
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: 241dc15939 ("net/mlx5: Notify on trap action by blocking event")
Signed-off-by: Aya Levin <ayal@nvidia.com>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Reviewed-by: Roi Dayan <roid@nvidia.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
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 <davem@davemloft.net>
This reverts commit 9c63faaa93, 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/708edb92-a5df-ecc4-3126-5ab36707e275@nvidia.com/
Reported-by: Jonathan Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
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 <wanjiabing@vivo.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit a14d273ba1 ("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 a14d273ba1 ("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: a14d273ba1 ("net: macb: restore cmp registers on resume path")
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
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) <thomas_os@shipmail.org>
Fixes: d1a73c641a ("drm/vmwgfx: Make sure we unpin no longer needed buffers")
Link: https://patchwork.freedesktop.org/patch/msgid/20210413205938.788366-1-zackr@vmware.com
Signed-off-by: Zack Rusin <zackr@vmware.com>
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 <krastevm@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Zack Rusin <zackr@vmware.com>
Fixes: 8772c0bb58 ("drm/vmwgfx: Cleanup pci resource allocation")
Link: https://patchwork.freedesktop.org/patch/msgid/20210408172245.673785-1-zackr@vmware.com
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 57fcd550eb ("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 <zackr@vmware.com>
Reviewed-by: Martin Krastev <krastevm@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Fixes: 57fcd550eb ("drm/ttm: Warn on pinning without holding a reference")
Link: https://patchwork.freedesktop.org/patch/414984/?series=86052&rev=1
Cc: Huang Rui <ray.huang@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Christian Koenig <christian.koenig@amd.com>
Cc: dri-devel@lists.freedesktop.org
aligned. This fixes a previous stable@ fix that overcorrected for a
different configuration that also resulted in misaligned roots IO.
-----BEGIN PGP SIGNATURE-----
iQFHBAABCAAxFiEEJfWUX4UqZ4x1O2wixSPxCi2dA1oFAmB3NaITHHNuaXR6ZXJA
cmVkaGF0LmNvbQAKCRDFI/EKLZ0DWi/zCACuvIs74tVsHz9o1j6M6kJ2hUYkfThv
dRIt4p5Qb5Rd5TCN0KwosRRVZopuI/doDX92ORmsyqx1XhY6x6WOrMxCv/3F+/xw
Bf3Rflhy0q+6ZlLM6tQZvYApFlpxZLMDOxc+VMxldGKHqU5D+Tid4tZ99YJMwbj/
7tKNi7oiil96CaqQfsvm+UgckIIxZVf+RTcdc6LH9W5gd4X1RmuGOoy/LKK8AeY+
PKIWjzflF/CQobUM/pVRbgSqUi2ZtzhbYBBKb5dndnjSNoHn3atZzvcAvhtuvkoB
KhjGY4PwK2PGO6QIgkJBLxg04g2AuxOqfB27AVGYVvO0ELp66sawMLxO
=B600
-----END PGP SIGNATURE-----
Merge tag 'for-5.12/dm-fixes-3' of 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: 4f04256c98 ("net: vrf: Drop local rtable and rt6_info")
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Acked-by: David Ahern <dsahern@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Let's have all seg6 sysctl at the same place.
Fixes: a6dc6670cd ("ipv6: sr: Add documentation for seg_flowlabel sysctl")
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
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 <davem@davemloft.net>
Remove the unnecessary napi_schedule() call in __ibmvnic_open() since
interrupt_rx() calls napi_schedule_prep/__napi_schedule during every
receive interrupt.
Fixes: ed651a1087 ("ibmvnic: Updated reset handling")
Signed-off-by: Lijun Pan <lijunp213@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
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: ed651a1087 ("ibmvnic: Updated reset handling")
Signed-off-by: Lijun Pan <lijunp213@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Pierre-Louis Bossart