From: Ole Bjørn Midtbø <redacted>
[ Upstream commit cca342d98bef68151a80b024f7bf5f388d1fbdea ]
A different wait queue was used when removing ctrl_wait than when adding
it. This effectively made the remove operation without locking compared
to other operations on the wait queue ctrl_wait was part of. This caused
issues like below where dead000000000100 is LIST_POISON1 and
dead000000000200 is LIST_POISON2.
list_add corruption. next->prev should be prev (ffffffc1b0a33a08), \
but was dead000000000200. (next=ffffffc03ac77de0).
------------[ cut here ]------------
CPU: 3 PID: 2138 Comm: bluetoothd Tainted: G O 4.4.238+ #9
...
---[ end trace 0adc2158f0646eac ]---
Call trace:
[<ffffffc000443f78>] __list_add+0x38/0xb0
[<ffffffc0000f0d04>] add_wait_queue+0x4c/0x68
[<ffffffc00020eecc>] __pollwait+0xec/0x100
[<ffffffc000d1556c>] bt_sock_poll+0x74/0x200
[<ffffffc000bdb8a8>] sock_poll+0x110/0x128
[<ffffffc000210378>] do_sys_poll+0x220/0x480
[<ffffffc0002106f0>] SyS_poll+0x80/0x138
[<ffffffc00008510c>] __sys_trace_return+0x0/0x4
Unable to handle kernel paging request at virtual address dead000000000100
...
CPU: 4 PID: 5387 Comm: kworker/u15:3 Tainted: G W O 4.4.238+ #9
...
Call trace:
[<ffffffc0000f079c>] __wake_up_common+0x7c/0xa8
[<ffffffc0000f0818>] __wake_up+0x50/0x70
[<ffffffc000be11b0>] sock_def_wakeup+0x58/0x60
[<ffffffc000de5e10>] l2cap_sock_teardown_cb+0x200/0x224
[<ffffffc000d3f2ac>] l2cap_chan_del+0xa4/0x298
[<ffffffc000d45ea0>] l2cap_conn_del+0x118/0x198
[<ffffffc000d45f8c>] l2cap_disconn_cfm+0x6c/0x78
[<ffffffc000d29934>] hci_event_packet+0x564/0x2e30
[<ffffffc000d19b0c>] hci_rx_work+0x10c/0x360
[<ffffffc0000c2218>] process_one_work+0x268/0x460
[<ffffffc0000c2678>] worker_thread+0x268/0x480
[<ffffffc0000c94e0>] kthread+0x118/0x128
[<ffffffc000085070>] ret_from_fork+0x10/0x20
---[ end trace 0adc2158f0646ead ]---
Signed-off-by: Ole Bjørn Midtbø <redacted>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/bluetooth/hidp/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Dinghao Liu <redacted>
[ Upstream commit a5d704d33245b0799947a3008f9f376dba4d5c91 ]
pm_runtime_get_sync() increments the runtime PM usage counter
even when it returns an error code. However, users of its
direct wrappers in omapdrm assume that PM usage counter will
not change on error. Thus a pairing decrement is needed on
the error handling path for these wrappers to keep the counter
balanced.
Signed-off-by: Dinghao Liu <redacted>
Signed-off-by: Tomi Valkeinen <redacted>
Link: https://patchwork.freedesktop.org/patch/msgid/20200822065743.13671-1-dinghao.liu@zju.edu.cn
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 7 +++++--
drivers/gpu/drm/omapdrm/dss/dsi.c | 7 +++++--
drivers/gpu/drm/omapdrm/dss/dss.c | 7 +++++--
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 6 +++---
drivers/gpu/drm/omapdrm/dss/hdmi5.c | 6 +++---
drivers/gpu/drm/omapdrm/dss/venc.c | 7 +++++--
6 files changed, 26 insertions(+), 14 deletions(-)
From: Thierry Reding <redacted>
[ Upstream commit c9f64d1fc101c64ea2be1b2e562b4395127befc9 ]
When dumping the name and NTP servers advertised by DHCP, a blank line
is emitted if either of the lists is empty. This can lead to confusing
issues such as the blank line getting flagged as warning. This happens
because the blank line is the result of pr_cont("\n") and that may see
its level corrupted by some other driver concurrently writing to the
console.
Fix this by making sure that the terminating newline is only emitted
if at least one entry in the lists was printed before.
Reported-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <redacted>
Link: https://lore.kernel.org/r/20201110073757.1284594-1-thierry.reding@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/ipv4/ipconfig.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
@@ -1445,7 +1445,7 @@ static int __init ip_auto_config(void)intretries=CONF_OPEN_RETRIES;#endifinterr;-unsignedinti;+unsignedinti,count;/* Initialise all name servers and NTP servers to NONE (but only if the*"ip="or"nfsaddrs="kernelcommandlineparametersweren'tdecoded,
@@ -1573,7 +1573,7 @@ static int __init ip_auto_config(void)if(ic_dev_mtu)pr_cont(", mtu=%d",ic_dev_mtu);/* Name servers (if any): */-for(i=0;i<CONF_NAMESERVERS_MAX;i++){+for(i=0,count=0;i<CONF_NAMESERVERS_MAX;i++){if(ic_nameservers[i]!=NONE){if(i==0)pr_info(" nameserver%u=%pI4",
From: yuuzheng <redacted>
[ Upstream commit 1f889b58716a5f5e3e4fe0e6742c1a4472f29ac1 ]
A use-after-free or null-pointer error occurs when the 251-byte response
data is copied from IOMB buffer to response message buffer in function
pm8001_mpi_get_nvmd_resp().
After sending the command get_nvmd_data(), the caller begins to sleep by
calling wait_for_complete() and waits for the wake-up from calling
complete() in pm8001_mpi_get_nvmd_resp(). Due to unexpected events (e.g.,
interrupt), if response buffer gets freed before memcpy(), a use-after-free
error will occur. To fix this, the complete() should be called after
memcpy().
Link: https://lore.kernel.org/r/20201102165528.26510-5-Viswas.G@microchip.com.com
Acked-by: Jack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: yuuzheng <redacted>
Signed-off-by: Viswas G <redacted>
Signed-off-by: Ruksar Devadi <redacted>
Signed-off-by: Radha Ramachandran <redacted>
Signed-off-by: Martin K. Petersen <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/scsi/pm8001/pm8001_hwi.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
From: Christian Borntraeger <redacted>
[ Upstream commit d041315ef75cf52df19613f56a2da2c5911c163c ]
The s390-trng does provide 100% entropy. The quality value is supported
to be between 1 and 1024 and not 1..1000. Use 1024 to make this driver
the preferred one. If we ever have a better driver that has the same
quality but is faster we can change this again when merging the new
driver. No need to be conservative.
This makes sure that the hw variant is preferred over things like
virtio-rng, where the hypervisor has a potential to be misconfigured
and thus should have a slightly lower confidence.
Cc: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Christian Borntraeger <redacted>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/char/hw_random/s390-trng.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
From: Evgeny Novikov <redacted>
[ Upstream commit af0321a5be3e5647441eb6b79355beaa592df97a ]
zr364xx_start_readpipe() can fail but callers do not care about that.
This can result in various negative consequences. The patch adds missed
error handling.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Evgeny Novikov <redacted>
Signed-off-by: Hans Verkuil <redacted>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/media/usb/zr364xx/zr364xx.c | 31 ++++++++++++++++++++++-------
1 file changed, 24 insertions(+), 7 deletions(-)
@@ -1381,9 +1382,8 @@ static int zr364xx_board_init(struct zr364xx_camera *cam)if(i==0){printk(KERN_INFOKBUILD_MODNAME": out of memory. Aborting\n");-kfree(cam->pipe->transfer_buffer);-cam->pipe->transfer_buffer=NULL;-return-ENOMEM;+err=-ENOMEM;+gotoerr_free;}elsecam->buffer.dwFrames=i;
@@ -1398,9 +1398,17 @@ static int zr364xx_board_init(struct zr364xx_camera *cam)/*** end create system buffers ***//* start read pipe */-zr364xx_start_readpipe(cam);+err=zr364xx_start_readpipe(cam);+if(err)+gotoerr_free;+DBG(": board initialized\n");return0;++err_free:+kfree(cam->pipe->transfer_buffer);+cam->pipe->transfer_buffer=NULL;+returnerr;}staticintzr364xx_probe(structusb_interface*intf,
@@ -1597,10 +1605,19 @@ static int zr364xx_resume(struct usb_interface *intf)if(!cam->was_streaming)return0;-zr364xx_start_readpipe(cam);+res=zr364xx_start_readpipe(cam);+if(res)+returnres;+res=zr364xx_prepare(cam);-if(!res)-zr364xx_start_acquire(cam);+if(res)+gotoerr_prepare;++zr364xx_start_acquire(cam);+return0;++err_prepare:+zr364xx_stop_readpipe(cam);returnres;}#endif
From: Danielle Ratson <redacted>
[ Upstream commit 22ec19f3aee327806c37c9fa1188741574bc6445 ]
Drivers that support bridge offload need to be notified about changes to
the bridge's VLAN protocol so that they could react accordingly and
potentially veto the change.
Add a new switchdev attribute to communicate the change to drivers.
Signed-off-by: Danielle Ratson <redacted>
Reviewed-by: Petr Machata <petrm@nvidia.com>
Acked-by: Nikolay Aleksandrov <redacted>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Ivan Vecera <ivecera@redhat.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
include/net/switchdev.h | 2 ++
net/bridge/br_vlan.c | 16 ++++++++++++++--
2 files changed, 16 insertions(+), 2 deletions(-)
@@ -764,15 +764,25 @@ EXPORT_SYMBOL_GPL(br_vlan_enabled);int__br_vlan_set_proto(structnet_bridge*br,__be16proto){+structswitchdev_attrattr={+.orig_dev=br->dev,+.id=SWITCHDEV_ATTR_ID_BRIDGE_VLAN_PROTOCOL,+.flags=SWITCHDEV_F_SKIP_EOPNOTSUPP,+.u.vlan_protocol=ntohs(proto),+};interr=0;structnet_bridge_port*p;structnet_bridge_vlan*vlan;structnet_bridge_vlan_group*vg;-__be16oldproto;+__be16oldproto=br->vlan_proto;if(br->vlan_proto==proto)return0;+err=switchdev_port_attr_set(br->dev,&attr);+if(err&&err!=-EOPNOTSUPP)+returnerr;+/* Add VLANs for the new proto to the device filter. */list_for_each_entry(p,&br->port_list,list){vg=nbp_vlan_group(p);
@@ -783,7 +793,6 @@ int __br_vlan_set_proto(struct net_bridge *br, __be16 proto)}}-oldproto=br->vlan_proto;br->vlan_proto=proto;recalculate_group_addr(br);
@@ -799,6 +808,9 @@ int __br_vlan_set_proto(struct net_bridge *br, __be16 proto)return0;err_filt:+attr.u.vlan_protocol=ntohs(oldproto);+switchdev_port_attr_set(br->dev,&attr);+list_for_each_entry_continue_reverse(vlan,&vg->vlan_list,vlist)vlan_vid_del(p->dev,proto,vlan->vid);
From: Thara Gopinath <redacted>
[ Upstream commit 1148a9654b5a69611d33e14719251c6ec20f5f2c ]
Partial hash was being copied into the final result buffer without the
entire message block processed. Depending on how the end user processes
this result buffer, errors vary from result buffer corruption to result
buffer poisoing. Fix this issue by ensuring that only the final hash value
is copied into the result buffer.
Reviewed-by: Bjorn Andersson <redacted>
Signed-off-by: Thara Gopinath <redacted>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/crypto/qce/sha.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Zhang Xiaohui <redacted>
[ Upstream commit 5c455c5ab332773464d02ba17015acdca198f03d ]
mwifiex_cmd_802_11_ad_hoc_start() calls memcpy() without checking
the destination size may trigger a buffer overflower,
which a local user could use to cause denial of service
or the execution of arbitrary code.
Fix it by putting the length check before calling memcpy().
Signed-off-by: Zhang Xiaohui <redacted>
Signed-off-by: Kalle Valo <redacted>
Link: https://lore.kernel.org/r/20201206084801.26479-1-ruc_zhangxiaohui@163.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/marvell/mwifiex/join.c | 2 ++
1 file changed, 2 insertions(+)
From: Johannes Berg <redacted>
[ Upstream commit b2ed841ed070ccbe908016537f429a3a8f0221bf ]
Start tracking not just if the firmware is dead or alive,
but also if it's starting.
Signed-off-by: Johannes Berg <redacted>
Signed-off-by: Luca Coelho <redacted>
Link: https://lore.kernel.org/r/iwlwifi.20201209231352.33e50d40b688.I8bbd41af7aa5e769273a6fc1c06fbf548dd2eb26@changeid
Signed-off-by: Luca Coelho <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/intel/iwlwifi/iwl-trans.h | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
From: Daniel Lee Kruse <redacted>
[ Upstream commit dbf0b3a7b719eb3f72cb53c2ce7d34a012a9c261 ]
On AMD Family 15h (Models 30h-3fh), I/O Memory Management Unit
RiSC engine sometimes stalls, requiring a reset.
As result, MythTV and w-scan won't scan channels on the AMD Kaveri
APU with the Hauppauge QuadHD TV tuner card.
For the solution I added the Input/Output Memory Management Unit's PCI
Identity of 0x1423 to the broken_dev_id[] array, which is used by
a quirks logic meant to fix similar problems with other AMD
chipsets.
Signed-off-by: Daniel Lee Kruse <redacted>
Signed-off-by: Hans Verkuil <redacted>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/media/pci/cx23885/cx23885-core.c | 4 ++++
1 file changed, 4 insertions(+)
From: Kyle Tso <redacted>
[ Upstream commit fe79d5de77204dd946cfad76a9bec23354b1a500 ]
TCPM state machine needs 20-25ms to enter the ErrorRecovery state after
tPSSourceOn timer timeouts. Change the timer from max 480ms to 450ms to
ensure that the timer complies with the Spec. In order to keep the
flexibility for other usecases using tPSSourceOn, add another timer only
for PR_SWAP.
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: Badhri Jagan Sridharan <badhri@google.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Kyle Tso <redacted>
Signed-off-by: Will McVicker <redacted>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20201210160521.3417426-5-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/usb/typec/tcpm.c | 2 +-
include/linux/usb/pd.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
From: Takashi Iwai <redacted>
[ Upstream commit 88a06d6fd6b369d88cec46c62db3e2604a2f50d5 ]
The runtime->avail field may be accessed concurrently while some
places refer to it without taking the runtime->lock spinlock, as
detected by KCSAN. Usually this isn't a big problem, but for
consistency and safety, we should take the spinlock at each place
referencing this field.
Reported-by: syzbot+a23a6f1215c84756577c@syzkaller.appspotmail.com
Reported-by: syzbot+3d367d1df1d2b67f5c19@syzkaller.appspotmail.com
Link: https://lore.kernel.org/r/20201206083527.21163-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
sound/core/rawmidi.c | 49 +++++++++++++++++++++++++++++++-------------
1 file changed, 35 insertions(+), 14 deletions(-)
@@ -1196,7 +1208,7 @@ int __snd_rawmidi_transmit_ack(struct snd_rawmidi_substream *substream, int counruntime->avail+=count;substream->bytes+=count;if(count>0){-if(runtime->drain||snd_rawmidi_ready(substream))+if(runtime->drain||__snd_rawmidi_ready(runtime))wake_up(&runtime->sleep);}returncount;
From: Ilan Peer <redacted>
[ Upstream commit bbf31e88df2f5da20ce613c340ce508d732046b3 ]
When calculating the minimal channel width for channel context,
the current operation Rx channel width of a station was used and not
the overall channel width capability of the station, i.e., both for
Tx and Rx.
Fix ieee80211_get_sta_bw() to use the maximal channel width the
station is capable. While at it make the function static.
Signed-off-by: Ilan Peer <redacted>
Signed-off-by: Luca Coelho <redacted>
Link: https://lore.kernel.org/r/iwlwifi.20201206145305.4387040b99a0.I74bcf19238f75a5960c4098b10e355123d933281@changeid
Signed-off-by: Johannes Berg <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/mac80211/chan.c | 10 ++++++----
net/mac80211/ieee80211_i.h | 1 -
2 files changed, 6 insertions(+), 5 deletions(-)
From: Chris Chiu <redacted>
[ Upstream commit 1bea2256aa96a2d7b1b576eb74e29d79edc9bea8 ]
Tha ARCHOS Cesium 140 tablet has problem with the jack-sensing,
thus the heaset functions are not working.
Add quirk for this model to select the correct input map, jack-detect
options and channel map to enable jack sensing and headset microphone.
This device uses IN1 for its internal MIC and JD2 for jack-detect.
Signed-off-by: Chris Chiu <redacted>
Acked-by: Pierre-Louis Bossart <redacted>
Link: https://lore.kernel.org/r/20201208060414.27646-1-chiu@endlessos.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
sound/soc/intel/boards/bytcr_rt5640.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
From: Ilan Peer <redacted>
[ Upstream commit 44b72ca8163b8cf94384a11fdec716f5478411bf ]
A channel change or a channel bandwidth change can impact the
rate control logic. However, the rate control logic was not updated
before/after such a change, which might result in unexpected
behavior.
Fix this by updating the stations rate control logic when the
corresponding channel context changes.
Signed-off-by: Ilan Peer <redacted>
Signed-off-by: Luca Coelho <redacted>
Link: https://lore.kernel.org/r/iwlwifi.20201206145305.600d967fe3c9.I48305f25cfcc9c032c77c51396e9e9b882748a86@changeid
Signed-off-by: Johannes Berg <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/mac80211/chan.c | 61 +++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 61 insertions(+)
From: Johannes Berg <redacted>
[ Upstream commit 3660944a37ce73890292571f44f04891834f9044 ]
If the AP advertises a band switch during CSA, we will not have
the right information to continue working with it, since it will
likely (have to) change its capabilities and we don't track any
capability changes at all. Additionally, we store e.g. supported
rates per band, and that information would become invalid.
Since this is a fringe scenario, just disconnect explicitly.
Signed-off-by: Luca Coelho <redacted>
Link: https://lore.kernel.org/r/iwlwifi.20201129172929.0e2327107c06.I461adb07704e056b054a4a7c29b80c95a9f56637@changeid
Signed-off-by: Johannes Berg <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/mac80211/mlme.c | 18 +++++++++++++++---
1 file changed, 15 insertions(+), 3 deletions(-)
From: Avraham Stern <redacted>
[ Upstream commit c837cbad40d949feaff86734d637c7602ae0b56b ]
Accept a scan request with the duration set even if the driver
does not support setting the scan dwell. The duration can be used
as a hint to the driver, but the driver may use its internal logic
for setting the scan dwell.
Signed-off-by: Avraham Stern <redacted>
Signed-off-by: Luca Coelho <redacted>
Link: https://lore.kernel.org/r/iwlwifi.20201129172929.9491a12f9226.Ia9c5b24fcefc5ce5592537507243391633a27e5f@changeid
Signed-off-by: Johannes Berg <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/wireless/nl80211.c | 6 ------
1 file changed, 6 deletions(-)
From: Johannes Berg <redacted>
[ Upstream commit 152fdc0f698896708f9d7889a4ba4da6944b74f7 ]
If we get an error, no longer consider the firmware to be
in IWL_TRANS_FW_ALIVE state.
Signed-off-by: Johannes Berg <redacted>
Signed-off-by: Luca Coelho <redacted>
Link: https://lore.kernel.org/r/iwlwifi.20201209231352.a9d01e79c1c7.Ib2deb076b392fb516a7230bac91d7ab8a9586d86@changeid
Signed-off-by: Luca Coelho <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/intel/iwlwifi/iwl-trans.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
@@ -1189,8 +1189,10 @@ static inline void iwl_trans_fw_error(struct iwl_trans *trans)return;/* prevent double restarts due to the same erroneous FW */-if(!test_and_set_bit(STATUS_FW_ERROR,&trans->status))+if(!test_and_set_bit(STATUS_FW_ERROR,&trans->status)){iwl_op_mode_nic_error(trans->op_mode);+trans->state=IWL_TRANS_NO_FW;+}}/*****************************************************
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
[ Upstream commit b5f32555567cfe0a5d5dbe7c1e85ebe37b3f545a ]
In v2.4.0-test2pre2 mmc_ioctl_cdrom_read_data() was extended by issuing
a MODE_SELECT opcode to change the sector size and READ_10 to perform
the actual read if the READ_CD opcode is not support.
The sector size is never changed back to the previous value of 2048
bytes which is however denoted by the comment for version 3.09 of the
cdrom.c file.
Use cdrom_switch_blocksize() to change the sector size only if the
requested size deviates from 2048. Change it back to 2048 after the read
operation if a change was mode.
Link: https://lkml.kernel.org/r/20201204164803.ovwurzs3257em2rp@linutronix.de
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/cdrom/cdrom.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
From: Thierry Reding <redacted>
[ Upstream commit 5b6164d3465fcc13b5679c860c452963443172a7 ]
Device drivers usually depend on the fact that the devices that they
control are suspended in the same order that they were probed in. In
most cases this is already guaranteed via deferred probe.
However, there's one case where this can still break: if a device is
instantiated before a dependency (for example if it appears before the
dependency in device tree) but gets probed only after the dependency is
probed. Instantiation order would cause the dependency to get probed
later, in which case probe of the original device would be deferred and
the suspend/resume queue would get reordered properly. However, if the
dependency is provided by a built-in driver and the device depending on
that driver is controlled by a loadable module, which may only get
loaded after the root filesystem has become available, we can be faced
with a situation where the probe order ends up being different from the
suspend/resume order.
One example where this happens is on Tegra186, where the ACONNECT is
listed very early in device tree (sorted by unit-address) and depends on
BPMP (listed very late because it has no unit-address) for power domains
and clocks/resets. If the ACONNECT driver is built-in, there is no
problem because it will be probed before BPMP, causing a probe deferral
and that in turn reorders the suspend/resume queue. However, if built as
a module, it will end up being probed after BPMP, and therefore not
result in a probe deferral, and therefore the suspend/resume queue will
stay in the instantiation order. This in turn causes problems because
ACONNECT will be resumed before BPMP, which will result in a hang
because the ACONNECT's power domain cannot be powered on as long as the
BPMP is still suspended.
Fix this by always reordering devices on successful probe. This ensures
that the suspend/resume queue is always in probe order and hence meets
the natural expectations of drivers vs. their dependencies.
Reported-by: Jonathan Hunter <jonathanh@nvidia.com>
Acked-by: Rafael. J. Wysocki <rafael@kernel.org>
Signed-off-by: Thierry Reding <redacted>
Link: https://lore.kernel.org/r/20201203175756.1405564-1-thierry.reding@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/base/dd.c | 7 +++++++
1 file changed, 7 insertions(+)
From: Kai Vehmanen <kai.vehmanen@linux.intel.com>
[ Upstream commit 46c3bbd9827952f92e250fa6ee30a797a4c4e17e ]
The check for infoframe transmit status in hdmi_infoframe_uptodate()
makes the assumption that packet buffer index is set to zero.
Align code with specification and explicitly set the index before
AC_VERB_GET_HDMI_DIP_XMIT. The packet index setting affects both
DIP-Data and DIP-XmitCtrl verbs.
There are no known cases where the old implementation has caused driver
to work incorrectly. This change is purely based on code review against
the specification (HDA spec rev1.0a).
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20201211131613.3271407-1-kai.vehmanen@linux.intel.com
Signed-off-by: Takashi Iwai <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
sound/pci/hda/patch_hdmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Michal Simek <redacted>
[ Upstream commit 38d1985fdfcf20dc246b552580479ae602f735d1 ]
Fix the leds subnode names to match (^led-[0-9a-f]$|led).
Similar change has been also done by commit 9a19a39ee48b ("arm64: dts:
zynqmp: Fix leds subnode name for zcu100/ultra96 v1").
The patch is fixing these warnings:
.../zynq-zc702.dt.yaml: leds: 'ds23' does not match any of the regexes:
'(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+'
From schema: .../Documentation/devicetree/bindings/leds/leds-gpio.yaml
.../zynq-zybo-z7.dt.yaml: gpio-leds: 'ld4' does not match any of the
regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+'
From schema: .../Documentation/devicetree/bindings/leds/leds-gpio.yaml
From: Emmanuel Grumbach <redacted>
[ Upstream commit 189a164d0fc6c59a22c4486d641d0a0a0d33387a ]
I hit a bug in which we started a CSA with an action frame,
but the AP changed its mind and didn't change the beacon.
The CSA wasn't cancelled and we lost the connection.
The beacons were ignored because they never changed: they
never contained any CSA IE. Because they never changed, the
CRC of the beacon didn't change either which made us ignore
the beacons instead of processing them.
Now what happens is:
1) beacon has CRC X and it is valid. No CSA IE in the beacon
2) as long as beacon's CRC X, don't process their IEs
3) rx action frame with CSA
4) invalidate the beacon's CRC
5) rx beacon, CRC is still X, but now it is invalid
6) process the beacon, detect there is no CSA IE
7) abort CSA
Signed-off-by: Emmanuel Grumbach <redacted>
Signed-off-by: Luca Coelho <redacted>
Link: https://lore.kernel.org/r/iwlwifi.20201206145305.83470b8407e6.I739b907598001362744692744be15335436b8351@changeid
Signed-off-by: Johannes Berg <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/mac80211/mlme.c | 1 +
1 file changed, 1 insertion(+)
From: Jacopo Mondi <jacopo+renesas@jmondi.org>
[ Upstream commit fb25ca37317200fa97ea6b8952e07958f06da7a6 ]
The VNCSI_IFMD register controls the data expansion mode and the
channel routing between the CSI-2 receivers and VIN instances.
According to the chip manual revision 2.20 not all fields are available
for all the SoCs:
- V3M, V3H and E3 do not support the DES1 field has they do not feature
a CSI20 receiver.
- D3 only supports parallel input, and the whole register shall always
be written as 0.
Inspect the per-SoC channel routing table where the available CSI-2
instances are reported and configure VNCSI_IFMD accordingly.
This patch supports this BSP change commit:
https://github.com/renesas-rcar/linux-bsp/commit/f54697394457
("media: rcar-vin: Fix VnCSI_IFMD register access for r8a77990")
[hverkuil: replace BSP commit ID with BSP URL]
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Suggested-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Signed-off-by: Hans Verkuil <redacted>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/media/platform/rcar-vin/rcar-dma.c | 25 +++++++++++++++++++---
1 file changed, 22 insertions(+), 3 deletions(-)
@@ -1319,7 +1319,9 @@ int rvin_dma_register(struct rvin_dev *vin, int irq)*/intrvin_set_channel_routing(structrvin_dev*vin,u8chsel){-u32ifmd,vnmc;+conststructrvin_group_route*route;+u32ifmd=0;+u32vnmc;intret;ret=pm_runtime_get_sync(vin->dev);
@@ -1332,9 +1334,26 @@ int rvin_set_channel_routing(struct rvin_dev *vin, u8 chsel)vnmc=rvin_read(vin,VNMC_REG);rvin_write(vin,vnmc&~VNMC_VUP,VNMC_REG);-ifmd=VNCSI_IFMD_DES1|VNCSI_IFMD_DES0|VNCSI_IFMD_CSI_CHSEL(chsel);+/*+*Setdataexpansionmodeto"pad with 0s"byinspectingtheroutes+*tabletofindoutwhichbitfieldsareavailableintheIFMD+*register.IFMD_DES1controlsdataexpansionmodeforCSI20/21,+*IFMD_DES0controlsdataexpansionmodeforCSI40/41.+*/+for(route=vin->info->routes;route->mask;route++){+if(route->csi==RVIN_CSI20||route->csi==RVIN_CSI21)+ifmd|=VNCSI_IFMD_DES1;+else+ifmd|=VNCSI_IFMD_DES0;-rvin_write(vin,ifmd,VNCSI_IFMD_REG);+if(ifmd==(VNCSI_IFMD_DES0|VNCSI_IFMD_DES1))+break;+}++if(ifmd){+ifmd|=VNCSI_IFMD_CSI_CHSEL(chsel);+rvin_write(vin,ifmd,VNCSI_IFMD_REG);+}vin_dbg(vin,"Set IFMD 0x%x\n",ifmd);
From: Gabriele Paoloni <redacted>
[ Upstream commit 3a866b16fd2360a9c4ebf71cfbf7ebfe968c1409 ]
Right now for LMCE, if no_way_out is set, mce_panic() is called
regardless of mca_cfg.tolerant. This is not correct as, if
mca_cfg.tolerant = 3, the code should never panic.
Add that check.
[ bp: use local ptr 'cfg'. ]
Signed-off-by: Gabriele Paoloni <redacted>
Signed-off-by: Borislav Petkov <redacted>
Reviewed-by: Tony Luck <tony.luck@intel.com>
Link: https://lkml.kernel.org/r/20201127161819.3106432-4-gabriele.paoloni@intel.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/x86/kernel/cpu/mcheck/mce.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Johannes Berg <redacted>
[ Upstream commit db8ebd06ccb87b7bea8e50f3d4ba5dc0142093b8 ]
Use the appropriate bitfield helpers for encoding and decoding
the capability field in the BA session action frames instead of
open-coding the shifts/masks.
Signed-off-by: Johannes Berg <redacted>
Signed-off-by: Luca Coelho <redacted>
Link: https://lore.kernel.org/r/iwlwifi.20201206145305.0c46e5097cc0.I06e75706770c40b9ba1cabd1f8a78ab7a05c5b73@changeid
Signed-off-by: Johannes Berg <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/mac80211/agg-rx.c | 8 ++++----
net/mac80211/agg-tx.c | 12 ++++++------
2 files changed, 10 insertions(+), 10 deletions(-)
@@ -216,10 +216,10 @@ static void ieee80211_send_addba_resp(struct ieee80211_sub_if_data *sdata, u8 *dmgmt->u.action.u.addba_resp.action_code=WLAN_ACTION_ADDBA_RESP;mgmt->u.action.u.addba_resp.dialog_token=dialog_token;-capab=(u16)(amsdu<<0);/* bit 0 A-MSDU support */-capab|=(u16)(policy<<1);/* bit 1 aggregation policy */-capab|=(u16)(tid<<2);/* bit 5:2 TID number */-capab|=(u16)(buf_size<<6);/* bit 15:6 max size of aggregation */+capab=u16_encode_bits(amsdu,IEEE80211_ADDBA_PARAM_AMSDU_MASK);+capab|=u16_encode_bits(policy,IEEE80211_ADDBA_PARAM_POLICY_MASK);+capab|=u16_encode_bits(tid,IEEE80211_ADDBA_PARAM_TID_MASK);+capab|=u16_encode_bits(buf_size,IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK);mgmt->u.action.u.addba_resp.capab=cpu_to_le16(capab);mgmt->u.action.u.addba_resp.timeout=cpu_to_le16(timeout);
@@ -98,10 +98,10 @@ static void ieee80211_send_addba_request(struct ieee80211_sub_if_data *sdata,mgmt->u.action.u.addba_req.action_code=WLAN_ACTION_ADDBA_REQ;mgmt->u.action.u.addba_req.dialog_token=dialog_token;-capab=(u16)(1<<0);/* bit 0 A-MSDU support */-capab|=(u16)(1<<1);/* bit 1 aggregation policy */-capab|=(u16)(tid<<2);/* bit 5:2 TID number */-capab|=(u16)(agg_size<<6);/* bit 15:6 max size of aggergation */+capab=IEEE80211_ADDBA_PARAM_AMSDU_MASK;+capab|=IEEE80211_ADDBA_PARAM_POLICY_MASK;+capab|=u16_encode_bits(tid,IEEE80211_ADDBA_PARAM_TID_MASK);+capab|=u16_encode_bits(agg_size,IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK);mgmt->u.action.u.addba_req.capab=cpu_to_le16(capab);
From: Mingrui Ren <redacted>
[ Upstream commit aef1b6a27970607721a618a0b990716ca8dbbf97 ]
As described in Documentation, poll_init() is called by kgdb to initialize
hardware which supports both poll_put_char() and poll_get_char().
It's necessary to enable TXEN bit, otherwise, it will cause hardware fault
and kernel panic when calling imx_poll_put_char().
Generally, if use /dev/ttymxc0 as kgdb console as well as system
console, ttymxc0 is initialized early by system console which does enable
TXEN bit.But when use /dev/ttymxc1 as kgbd console, ttymxc1 is only
initialized by imx_poll_init() cannot enable the TXEN bit, which will
cause kernel panic.
Signed-off-by: Mingrui Ren <redacted>
Link: https://lore.kernel.org/r/20201202072543.151-1-972931182@qq.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/tty/serial/imx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Ilan Peer <redacted>
[ Upstream commit beee246951571cc5452176f3dbfe9aa5a10ba2b9 ]
When custom regulatory was set, only the channels setting was updated, but
the regulatory domain was not saved. Fix it by saving it.
Signed-off-by: Ilan Peer <redacted>
Signed-off-by: Luca Coelho <redacted>
Link: https://lore.kernel.org/r/iwlwifi.20201129172929.290fa5c5568a.Ic5732aa64de6ee97ae3578bd5779fc723ba489d1@changeid
Signed-off-by: Johannes Berg <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/wireless/reg.c | 8 ++++++++
1 file changed, 8 insertions(+)
From: Johannes Berg <redacted>
[ Upstream commit df72138de4bc4e85e427aabc60fc51be6cc57fc7 ]
Validate the maximum RX descriptor length against the size
of the buffers we gave the device - if it doesn't fit then
the hardware messed up.
Signed-off-by: Johannes Berg <redacted>
Signed-off-by: Luca Coelho <redacted>
Link: https://lore.kernel.org/r/iwlwifi.20201209231352.6378fb435cc0.Ib07485f3dc5999c74b03f21e7a808c50a05e353c@changeid
Signed-off-by: Luca Coelho <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
@@ -1256,6 +1256,13 @@ static void iwl_pcie_rx_handle_rb(struct iwl_trans *trans,len=iwl_rx_packet_len(pkt);len+=sizeof(u32);/* account for status word */++offset+=ALIGN(len,FH_RSCSR_FRAME_ALIGN);++/* check that what the device tells us made sense */+if(offset>max_len)+break;+trace_iwlwifi_dev_rx(trans->dev,trans,pkt,len);trace_iwlwifi_dev_rx_data(trans->dev,trans,pkt,len);
@@ -1313,7 +1320,6 @@ static void iwl_pcie_rx_handle_rb(struct iwl_trans *trans,page_stolen|=rxcb._page_stolen;if(trans->cfg->device_family>=IWL_DEVICE_FAMILY_22560)break;-offset+=ALIGN(len,FH_RSCSR_FRAME_ALIGN);}/* page was stolen from us -- free our reference */
From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
[ Upstream commit d0ac1a26ed5943127cb0156148735f5f52a07075 ]
As reported on:
https://lore.kernel.org/linux-media/20190627222020.45909-1-willemdebruijn.kernel@gmail.com/
if gp8psk_usb_in_op() returns an error, the status var is not
initialized. Yet, this var is used later on, in order to
identify:
- if the device was already started;
- if firmware has loaded;
- if the LNBf was powered on.
Using status = 0 seems to ensure that everything will be
properly powered up.
So, instead of the proposed solution, let's just set
status = 0.
Reported-by: syzbot <redacted>
Reported-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/media/usb/dvb-usb/gp8psk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Filipe Manana <redacted>
[ Upstream commit 639bd575b7c7fa326abadd2ef3e374a5a24eb40b ]
When logging an inode we may often have to fallback to a full transaction
commit, either because a new block group was allocated, there is some case
we can not deal with without a transaction commit or some error like an
ENOMEM happened. However after we fallback to a transaction commit, we
have a time window where we can make the next attempt to log any inode
commit the next transaction unnecessarily, adding additional overhead and
increasing latency.
A sequence of steps that leads to this issue is the following:
1) The current open transaction has a generation of 1000;
2) A new block group is allocated, and as a consequence we must make sure
any attempts to commit a log fallback to a transaction commit, so
btrfs_set_log_full_commit() is called from btrfs_make_block_group().
This sets fs_info->last_trans_log_full_commit to 1000;
3) Task A is holding a handle on transaction 1000 and tries to log inode X.
Once it gets to start_log_trans(), it calls btrfs_need_log_full_commit()
which returns true, since fs_info->last_trans_log_full_commit has a
value of 1000. So we end up returning EAGAIN and propagating it up to
btrfs_sync_file(), where we commit transaction 1000;
4) The transaction commit task (task A) sets the transaction state to
unblocked (TRANS_STATE_UNBLOCKED);
5) Some other task, task B, starts a new transaction with a generation of
1001;
6) Some stuff is done with transaction 1001, some btree blocks COWed, etc;
7) Transaction 1000 has not fully committed yet, we are still writing all
the extent buffers it created;
8) Some new task, task C, starts an fsync of inode Y, gets a handle for
transaction 1001, and it gets to btrfs_log_inode_parent() which does
the following check:
if (fs_info->last_trans_log_full_commit > last_committed) {
ret = 1;
goto end_no_trans;
}
At that point last_trans_log_full_commit has a value of 1000 and
last_committed (value of fs_info->last_trans_committed) has a value of
999, since transaction 1000 has not yet committed - it is either still
writing out dirty extent buffers, its super blocks or unpinning
extents.
As a consequence we return 1, which gets propagated up to
btrfs_sync_file(), which will then call btrfs_commit_transaction()
for transaction 1001.
As a consequence we have an unnecessary second transaction commit, we
previously committed transaction 1000 and now commit transaction 1001
as well, resulting in more overhead and increased latency.
So fix this double transaction commit issue simply by removing that check,
because all we need to do is wait for the previous transaction to finish
its commit, which we already do later when starting the log transaction at
start_log_trans(), because there we acquire the tree_log_mutex lock, which
is held by a transaction commit and only released after the transaction
commits its super blocks.
Another issue that check has is that it reads last_trans_log_full_commit
without using READ_ONCE(), which is incorrect since that member of
struct btrfs_fs_info is always updated with WRITE_ONCE() through the
helper btrfs_set_log_full_commit().
This double transaction commit issue can actually be triggered quite often
in long runs of dbench, since besides the creation of new block groups
that force inode logging to fallback to a transaction commit, there are
cases where dbench asks to fsync a directory which had files in it that
were previously renamed or subdirectories that were removed, resulting in
the inode logging to fallback to a full transaction commit.
This patch belongs to a patch set that is comprised of the following
patches:
btrfs: fix race causing unnecessary inode logging during link and rename
btrfs: fix race that results in logging old extents during a fast fsync
btrfs: fix race that causes unnecessary logging of ancestor inodes
btrfs: fix race that makes inode logging fallback to transaction commit
btrfs: fix race leading to unnecessary transaction commit when logging inode
btrfs: do not block inode logging for so long during transaction commit
Performance results are mentioned in the change log of the last patch.
Signed-off-by: Filipe Manana <redacted>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/btrfs/tree-log.c | 10 ----------
1 file changed, 10 deletions(-)
@@ -566,10 +564,16 @@ static int sh_cmt_start(struct sh_cmt_channel *ch, unsigned long flag)intret=0;unsignedlongflags;+if(flag&FLAG_CLOCKSOURCE)+pm_runtime_get_sync(&ch->cmt->pdev->dev);+raw_spin_lock_irqsave(&ch->lock,flags);-if(!(ch->flags&(FLAG_CLOCKEVENT|FLAG_CLOCKSOURCE)))+if(!(ch->flags&(FLAG_CLOCKEVENT|FLAG_CLOCKSOURCE))){+if(flag&FLAG_CLOCKEVENT)+pm_runtime_get_sync(&ch->cmt->pdev->dev);ret=sh_cmt_enable(ch);+}if(ret)gotoout;
@@ -594,14 +598,20 @@ static void sh_cmt_stop(struct sh_cmt_channel *ch, unsigned long flag)f=ch->flags&(FLAG_CLOCKEVENT|FLAG_CLOCKSOURCE);ch->flags&=~flag;-if(f&&!(ch->flags&(FLAG_CLOCKEVENT|FLAG_CLOCKSOURCE)))+if(f&&!(ch->flags&(FLAG_CLOCKEVENT|FLAG_CLOCKSOURCE))){sh_cmt_disable(ch);+if(flag&FLAG_CLOCKEVENT)+pm_runtime_put(&ch->cmt->pdev->dev);+}/* adjust the timeout to maximum if only clocksource left */if((flag==FLAG_CLOCKEVENT)&&(ch->flags&FLAG_CLOCKSOURCE))__sh_cmt_set_next(ch,ch->max_match_value);raw_spin_unlock_irqrestore(&ch->lock,flags);++if(flag&FLAG_CLOCKSOURCE)+pm_runtime_put(&ch->cmt->pdev->dev);}staticstructsh_cmt_channel*cs_to_sh_cmt(structclocksource*cs)
From: Jinyang He <redacted>
[ Upstream commit c0aac3a51cb6364bed367ee3e1a96ed414f386b4 ]
Most platforms do not need to do synci instruction operations when
synci_step is 0. But for example, the synci implementation on Loongson64
platform has some changes. On the one hand, it ensures that the memory
access instructions have been completed. On the other hand, it guarantees
that all prefetch instructions need to be fetched again. And its address
information is useless. Thus, only one synci operation is required when
synci_step is 0 on Loongson64 platform. I guess that some other platforms
have similar implementations on synci, so add judgment conditions in
`while` to ensure that at least all platforms perform synci operations
once. For those platforms that do not need synci, they just do one more
operation similar to nop.
Signed-off-by: Jinyang He <redacted>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/mips/kernel/relocate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Andy Lutomirski <luto@kernel.org>
[ Upstream commit 716572b0003ef67a4889bd7d85baf5099c5a0248 ]
Setting GS to 1, 2, or 3 causes a nonsensical part of the IRET microcode
to change GS back to zero on a return from kernel mode to user mode. The
result is that these tests fail randomly depending on when interrupts
happen. Detect when this happens and let the test pass.
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Borislav Petkov <redacted>
Link: https://lkml.kernel.org/r/7567fd44a1d60a9424f25b19a998f12149993b0d.1604346596.git.luto@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/testing/selftests/x86/fsgsbase.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
@@ -337,6 +337,14 @@ static void set_gs_and_switch_to(unsigned long local,if(base==local&&sel_pre_sched==sel_post_sched){printf("[OK]\tGS/BASE remained 0x%hx/0x%lx\n",sel_pre_sched,local);+}elseif(base==local&&sel_pre_sched>=1&&sel_pre_sched<=3&&+sel_post_sched==0){+/*+*IRETismisdesignedandwillsquashselectors1,2,or3+*tozero.Don'tfailthetestjustbecausethishappened.+*/+printf("[OK]\tGS/BASE changed from 0x%hx/0x%lx to 0x%hx/0x%lx because IRET is defective\n",+sel_pre_sched,local,sel_post_sched,base);}else{nerrs++;printf("[FAIL]\tGS/BASE changed from 0x%hx/0x%lx to 0x%hx/0x%lx\n",
From: Martin Schiller <ms@dev.tdt.de>
[ Upstream commit 62480b992ba3fb1d7260b11293aed9d6557831c7 ]
1. DTE interface changes immediately to LAPB_STATE_1 and start sending
SABM(E).
2. DCE interface sends N2-times DM and changes to LAPB_STATE_1
afterwards if there is no response in the meantime.
Signed-off-by: Martin Schiller <ms@dev.tdt.de>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/lapb/lapb_timer.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
From: Sami Tolvanen <samitolvanen@google.com>
[ Upstream commit 83321c335dccba262a57378361d63da96b8166d6 ]
e820__mapped_all() is passed as a callback to is_mmconf_reserved(),
which expects a function of type:
typedef bool (*check_reserved_t)(u64 start, u64 end, unsigned type);
However, e820__mapped_all() accepts enum e820_type as the last argument
and this type mismatch trips indirect call checking with Clang's
Control-Flow Integrity (CFI).
As is_mmconf_reserved() only passes enum e820_type values for the
type argument, change the typedef and the unused type argument in
is_acpi_reserved() to enum e820_type to fix the type mismatch.
Reported-by: Sedat Dilek <redacted>
Suggested-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Borislav Petkov <redacted>
Link: https://lkml.kernel.org/r/20201130193900.456726-1-samitolvanen@google.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/x86/pci/mmconfig-shared.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: Dinghao Liu <redacted>
[ Upstream commit 751341b4d7841e2b76e78eec382c2e119165497f ]
When dbBackSplit() fails, mp should be released to
prevent memleak. It's the same when dbJoin() fails.
Signed-off-by: Dinghao Liu <redacted>
Signed-off-by: Dave Kleikamp <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/jfs/jfs_dmap.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
@@ -2562,15 +2562,19 @@ dbAdjCtl(struct bmap * bmp, s64 blkno, int newval, int alloc, int level)*/if(oldval==NOFREE){rc=dbBackSplit((dmtree_t*)dcp,leafno);-if(rc)+if(rc){+release_metapage(mp);returnrc;+}oldval=dcp->stree[ti];}dbSplit((dmtree_t*)dcp,leafno,dcp->budmin,newval);}else{rc=dbJoin((dmtree_t*)dcp,leafno,newval);-if(rc)+if(rc){+release_metapage(mp);returnrc;+}}/* check if the root of the current dmap control page changed due
From: Stefan Assmann <redacted>
[ Upstream commit 6ec12e1e9404acb27a7434220bbe5f75e7bb2859 ]
When the virtual link state was set to "enable" ethtool would report
link speed as 40000Mb/s regardless of the underlying device.
Report the correct link speed.
Example from a XXV710 NIC.
Before:
$ ip link set ens3f0 vf 0 state auto
$ ethtool enp8s2 | grep Speed
Speed: 25000Mb/s
$ ip link set ens3f0 vf 0 state enable
$ ethtool enp8s2 | grep Speed
Speed: 40000Mb/s
After:
$ ip link set ens3f0 vf 0 state auto
$ ethtool enp8s2 | grep Speed
Speed: 25000Mb/s
$ ip link set ens3f0 vf 0 state enable
$ ethtool enp8s2 | grep Speed
Speed: 25000Mb/s
Signed-off-by: Stefan Assmann <redacted>
Tested-by: Aaron Brown <redacted>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
@@ -4204,6 +4204,7 @@ int i40e_ndo_set_vf_link_state(struct net_device *netdev, int vf_id, int link){structi40e_netdev_priv*np=netdev_priv(netdev);structi40e_pf*pf=np->vsi->back;+structi40e_link_status*ls=&pf->hw.phy.link_info;structvirtchnl_pf_eventpfe;structi40e_hw*hw=&pf->hw;structi40e_vf*vf;
@@ -4236,7 +4237,7 @@ int i40e_ndo_set_vf_link_state(struct net_device *netdev, int vf_id, int link)vf->link_forced=true;vf->link_up=true;pfe.event_data.link_event.link_status=true;-pfe.event_data.link_event.link_speed=VIRTCHNL_LINK_SPEED_40GB;+pfe.event_data.link_event.link_speed=i40e_virtchnl_link_speed(ls->link_speed);break;caseIFLA_VF_LINK_STATE_DISABLE:vf->link_forced=true;
From: Ethan Warth <redacted>
[ Upstream commit 1008230f2abeb624f6d71b2e1c424fa4eeebbf84 ]
Mayflash/Dragonrise seems to have yet another device ID for one of their
Gamecube controller adapters. Previous to this commit, the adapter
registered only one /dev/input/js* device, and all controller inputs (from
any controller) were mapped to this device. This patch defines the 1846
USB device ID and enables the HID_QUIRK_MULTI_INPUT quirk for it, which
fixes that (with the patch, four /dev/input/js* devices are created, one
for each of the four controller ports).
Signed-off-by: Ethan Warth <redacted>
Tested-by: Wladimir J. van der Laan <redacted>
Signed-off-by: Jiri Kosina <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/hid/hid-ids.h | 1 +
drivers/hid/hid-mf.c | 2 ++
drivers/hid/hid-quirks.c | 2 ++
3 files changed, 5 insertions(+)
From: "Andrea Parri (Microsoft)" <parri.andrea@gmail.com>
[ Upstream commit 206ad34d52a2f1205c84d08c12fc116aad0eb407 ]
Lack of validation could lead to out-of-bound reads and information
leaks (cf. usage of nvdev->chan_table[]). Check that the number of
allocated sub-channels fits into the expected range.
Suggested-by: Saruhan Karademir <redacted>
Signed-off-by: Andrea Parri (Microsoft) <parri.andrea@gmail.com>
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
Acked-by: Jakub Kicinski <kuba@kernel.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: netdev@vger.kernel.org
Link: https://lore.kernel.org/r/20201118153310.112404-1-parri.andrea@gmail.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/hyperv/rndis_filter.c | 5 +++++
1 file changed, 5 insertions(+)
@@ -1111,6 +1111,11 @@ int rndis_set_subchannel(struct net_device *ndev,return-EIO;}+/* Check that number of allocated sub channel is within the expected range */+if(init_packet->msg.v5_msg.subchn_comp.num_subchannels>nvdev->num_chn-1){+netdev_err(ndev,"invalid number of allocated sub channel\n");+return-EINVAL;+}nvdev->num_chn=1+init_packet->msg.v5_msg.subchn_comp.num_subchannels;
From: Marc Zyngier <maz@kernel.org>
[ Upstream commit 776a3c04da9fa144241476f4a0d263899d6cad26 ]
GIC400 has full support for virtualization, and yet the tegra186
DT doesn't expose the GICH/GICV regions (despite exposing the
maintenance interrupt that only makes sense for virtualization).
Add the missing regions, based on the hunch that the HW doesn't
use the CPU build-in interfaces, but instead the external ones
provided by the GIC. KVM's virtual GIC now works with this change.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Thierry Reding <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm64/boot/dts/nvidia/tegra186.dtsi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
From: Jan Höppner <hoeppner@linux.ibm.com>
[ Upstream commit 9e34c8ba91697cb7441805c36d92ab3e695df6e0 ]
During online processing and setting up a DASD device, the configuration
data for operational paths is read and validated two times
(dasd_eckd_read_conf()). The first time to provide information that are
necessary for the LCU setup. A second time after the LCU setup as a
device might report different configuration data then.
When the configuration setup for each operational path is being
validated, an initial call to dasd_eckd_clear_conf_data() is issued.
This call wipes all previously available configuration data and path
information for each path.
However, the operational path mask is not updated during this process.
As a result, the stored operational path mask might no longer correspond
to the operational paths mask reported by the CIO layer, as several
paths might be gone between the two dasd_eckd_read_conf() calls.
This inconsistency leads to more severe issues in later path handling
changes. Fix this by removing the channel paths from the operational
path mask during the dasd_eckd_clear_conf_data() call.
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/s390/block/dasd_eckd.c | 1 +
1 file changed, 1 insertion(+)
From: Evgeny Novikov <redacted>
[ Upstream commit 6651dba2bd838f34cf5a1e84229aaa579b1a94fe ]
isif_probe() invokes iounmap() on error handling paths, but it does not
reset the global state. So, later it can invoke iounmap() even when
ioremap() fails. This is the case also for isif_remove(). The patch
resets the global state after invoking iounmap() to avoid this.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Evgeny Novikov <redacted>
Signed-off-by: Hans Verkuil <redacted>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/media/platform/davinci/isif.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
@@ -953,14 +953,19 @@ brcms_c_ampdu_dotxstatus_complete(struct ampdu_info *ampdu, struct scb *scb,index=TX_SEQ_TO_INDEX(seq);ack_recd=false;if(ba_recd){+intblock_acked;+bindex=MODSUB_POW2(seq,start_seq,SEQNUM_MAX);+if(bindex<AMPDU_TX_BA_MAX_WSIZE)+block_acked=isset(bitmap,bindex);+else+block_acked=0;brcms_dbg_ht(wlc->hw->d11core,"tid %d seq %d, start_seq %d, bindex %d set %d, index %d\n",tid,seq,start_seq,bindex,-isset(bitmap,bindex),index);+block_acked,index);/* if acked then clear bit and free packet */-if((bindex<AMPDU_TX_BA_MAX_WSIZE)-&&isset(bitmap,bindex)){+if(block_acked){ini->txretry[index]=0;/*
From: David Howells <dhowells@redhat.com>
[ Upstream commit d2ae4e918218f543214fbd906db68a6c580efbbb ]
Don't let someone reading a service-side rxrpc-type key get access to the
session key that was exchanged with the client. The server application
will, at some point, need to be able to read the information in the ticket,
but this probably shouldn't include the key material.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
include/keys/rxrpc-type.h | 1 +
net/rxrpc/key.c | 8 ++++++--
2 files changed, 7 insertions(+), 2 deletions(-)
@@ -88,6 +88,7 @@ struct rxk5_key {*/structrxrpc_key_token{u16security_index;/* RxRPC header security index */+boolno_leak_key;/* Don't copy the key to userspace */structrxrpc_key_token*next;/* the next token in the list */union{structrxkad_key*kad;
From: Alexander Lobakin <redacted>
[ Upstream commit 8be33ecfc1ffd2da20cc29e957e4cb6eb99310cb ]
Similar to commit fda55eca5a33f
("net: introduce skb_transport_header_was_set()"), avoid resetting
transport offsets that were already set by GRO layer. This not only
mirrors the behavior of __netif_receive_skb_core(), but also makes
sense when it comes to UDP GSO fraglists forwarding: transport offset
of such skbs is set only once by GRO receive callback and remains
untouched and correct up to the xmitting driver in 1:1 case, but
becomes junk after untagging in ingress VLAN case and breaks UDP
GSO offload. This does not happen after this change, and all types
of forwarding of UDP GSO fraglists work as expected.
Since v1 [1]:
- keep the code 1:1 with __netif_receive_skb_core() (Jakub).
[1] https://lore.kernel.org/netdev/zYurwsZRN7BkqSoikWQLVqHyxz18h4LhHU4NFa2Vw@cp4-web-038.plabs.ch
Signed-off-by: Alexander Lobakin <redacted>
Link: https://lore.kernel.org/r/7JgIkgEztzt0W6ZtC9V9Cnk5qfkrUFYcpN871syCi8@cp4-web-040.plabs.ch
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/core/skbuff.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
From: Finn Thain <redacted>
[ Upstream commit 03fe6a640a05c5dc04b6bcdddfb981d015e84ed4 ]
It is possible that bus_reset_cleanup() or .eh_abort_handler could be
invoked during NCR5380_queuecommand(). If that takes place before the new
command is enqueued and after the ST-DMA "lock" has been acquired, the
ST-DMA "lock" will be released again. This will result in a lost DMA
interrupt and a command timeout. Fix this by excluding EH and interrupt
handlers while the new command is enqueued.
Link: https://lore.kernel.org/r/af25163257796b50bb99d4ede4025cea55787b8f.1605847196.git.fthain@telegraphics.com.au
Tested-by: Michael Schmitz <schmitzmic@gmail.com>
Reviewed-by: Michael Schmitz <schmitzmic@gmail.com>
Signed-off-by: Finn Thain <redacted>
Signed-off-by: Martin K. Petersen <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/scsi/NCR5380.c | 9 ++++++---
drivers/scsi/atari_scsi.c | 10 +++-------
2 files changed, 9 insertions(+), 10 deletions(-)
@@ -376,15 +376,11 @@ static int falcon_get_lock(struct Scsi_Host *instance)if(IS_A_TT())return1;-if(stdma_is_locked_by(scsi_falcon_intr)&&-instance->hostt->can_queue>1)+if(stdma_is_locked_by(scsi_falcon_intr))return1;-if(in_interrupt())-returnstdma_try_lock(scsi_falcon_intr,instance);--stdma_lock(scsi_falcon_intr,instance);-return1;+/* stdma_lock() may sleep which means it can't be used here */+returnstdma_try_lock(scsi_falcon_intr,instance);}#ifndef MODULE
From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
[ Upstream commit 411406a8c758d9ad6f908fab3a6cf1d3d89e1d08 ]
MIPS protection bits are setup during runtime so using defines like
PAGE_SHARED ignores this runtime changes. Using vm_get_page_prot
to get correct page protection fixes this.
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/mips/kvm/mmu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
@@ -1099,6 +1099,7 @@ int kvm_mips_handle_commpage_tlb_fault(unsigned long badvaddr,{kvm_pfn_tpfn;pte_t*ptep;+pgprot_tprot;ptep=kvm_trap_emul_pte_for_gva(vcpu,badvaddr);if(!ptep){
@@ -1108,7 +1109,8 @@ int kvm_mips_handle_commpage_tlb_fault(unsigned long badvaddr,pfn=PFN_DOWN(virt_to_phys(vcpu->arch.kseg0_commpage));/* Also set valid and dirty, so refill handler doesn't have to */-*ptep=pte_mkyoung(pte_mkdirty(pfn_pte(pfn,PAGE_SHARED)));+prot=vm_get_page_prot(VM_READ|VM_WRITE|VM_SHARED);+*ptep=pte_mkyoung(pte_mkdirty(pfn_pte(pfn,prot)));/* Invalidate this entry in the TLB, guest kernel ASID only */kvm_mips_host_tlb_inv(vcpu,badvaddr,false,true);
From: "Paul E. McKenney" <paulmck@kernel.org>
[ Upstream commit 6b74fa0a776e3715d385b23d29db469179c825b0 ]
If an locktorture torture-test run is given a bad kvm.sh argument, the
test will complain to the console, which is good. What is bad is that
from the user's perspective, it will just hang for the time specified
by the --duration argument. This commit therefore forces an immediate
kernel shutdown if a lock_torture_init()-time error occurs, thus avoiding
the appearance of a hang. It also forces a console splat in this case
to clearly indicate the presence of an error.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
kernel/locking/locktorture.c | 5 +++++
1 file changed, 5 insertions(+)
From: Marek Vasut <marex@denx.de>
[ Upstream commit 65277100caa2f2c62b6f3c4648b90d6f0435f3bc ]
In case RSI9116 SDIO WiFi operates in STA mode against Intel 9260 in AP mode,
the association fails. The former is using wpa_supplicant during association,
the later is set up using hostapd:
iwl$ cat hostapd.conf
interface=wlp1s0
ssid=test
country_code=DE
hw_mode=g
channel=1
wpa=2
wpa_passphrase=test
wpa_key_mgmt=WPA-PSK
iwl$ hostapd -d hostapd.conf
rsi$ wpa_supplicant -i wlan0 -c <(wpa_passphrase test test)
The problem is that the TX EAPOL data descriptor RSI_DESC_REQUIRE_CFM_TO_HOST
flag and extended descriptor EAPOL4_CONFIRM frame type are not set in case the
AP is iwlwifi, because in that case the TX EAPOL packet is 2 bytes shorter.
The downstream vendor driver has this change in place already [1], however
there is no explanation for it, neither is there any commit history from which
such explanation could be obtained.
[1] https://github.com/SiliconLabs/RS911X-nLink-OSD/blob/master/rsi/rsi_91x_hal.c#L238
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Angus Ainslie <redacted>
Cc: David S. Miller <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Kalle Valo <redacted>
Cc: Lee Jones <redacted>
Cc: Martin Kepplinger <martink@posteo.de>
Cc: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
Cc: Siva Rebbagondla <redacted>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Kalle Valo <redacted>
Link: https://lore.kernel.org/r/20201015111616.429220-1-marex@denx.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/rsi/rsi_91x_hal.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
From: Hans de Goede <redacted>
[ Upstream commit e524f252c42fc4f2bc4a2c3f99fe8659af5576a8 ]
Add OBDA0623 ACPI HID to the acpi_device_id table. This HID is used
for the RTL8723BS Bluetooth part on the Acer Switch 10E SW3-016.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1665610
Signed-off-by: Hans de Goede <redacted>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/bluetooth/hci_h5.c | 1 +
1 file changed, 1 insertion(+)
From: Takashi Iwai <redacted>
[ Upstream commit 4974b7950929e4a28d4eaee48e4ad07f168ac132 ]
The PCM trigger callback is atomic, hence we must not call a function
like usb_set_interface() there. Calling it from there would lead to a
kernel Oops.
Fix it by moving the usb_set_interface() call to set_sync_endpoint().
Also, apply the snd_usb_set_interface_quirk() for consistency, too.
Tested-by: Keith Milner <redacted>
Tested-by: Dylan Robinson <redacted>
Link: https://lore.kernel.org/r/20201123085347.19667-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
sound/usb/pcm.c | 28 +++++++++++++---------------
1 file changed, 13 insertions(+), 15 deletions(-)
From: "Paul E. McKenney" <paulmck@kernel.org>
[ Upstream commit 4994684ce10924a0302567c315c91b0a64eeef46 ]
If an rcutorture torture-test run is given a bad kvm.sh argument, the
test will complain to the console, which is good. What is bad is that
from the user's perspective, it will just hang for the time specified
by the --duration argument. This commit therefore forces an immediate
kernel shutdown if a rcu_torture_init()-time error occurs, thus avoiding
the appearance of a hang. It also forces a console splat in this case
to clearly indicate the presence of an error.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
kernel/rcu/rcutorture.c | 4 ++++
1 file changed, 4 insertions(+)
From: Jaegeuk Kim <redacted>
[ Upstream commit b664511297644eac34038df877b3ad7bcaa81913 ]
While running a stress test which enables/disables clkgating, we
occasionally hit device timeout. This patch avoids a subtle race condition
to address it.
Link: https://lore.kernel.org/r/20201117165839.1643377-3-jaegeuk@kernel.org
Reviewed-by: Can Guo <redacted>
Signed-off-by: Jaegeuk Kim <redacted>
Signed-off-by: Martin K. Petersen <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/scsi/ufs/ufshcd.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
@@ -228,6 +228,7 @@ int mips_cm_probe(void)if((base_reg&CM_GCR_BASE_GCRBASE)!=addr){pr_err("GCRs appear to have been moved (expected them at 0x%08lx)!\n",(unsignedlong)addr);+iounmap(mips_gcr_base);mips_gcr_base=NULL;return-ENODEV;}
From: Hans Verkuil <redacted>
[ Upstream commit e91c255733d9bbb4978a372f44fb5ed689ccdbd1 ]
If a CEC device node is unregistered, then it should be marked as
unregistered before waking up any filehandles that are waiting for
an event.
This ensures that there is no race condition where an application can
call CEC_DQEVENT and have the ioctl return 0 instead of ENODEV.
Signed-off-by: Hans Verkuil <redacted>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/media/cec/cec-core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: Dinghao Liu <redacted>
[ Upstream commit 167faadfcf9339088910e9e85a1b711fcbbef8e9 ]
When device_create() fails, dvbdev and dvbdevfops should
be freed just like when dvb_register_media_device() fails.
Signed-off-by: Dinghao Liu <redacted>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/media/dvb-core/dvbdev.c | 3 +++
1 file changed, 3 insertions(+)