linux-stable.git/drivers/staging, branch v5.4.97

exfat: Month timestamp metadata accidentally incremented

2021-01-17T13:05:34+00:00

The staging/exfat driver has departed, but a lot of distros are still tracking
5.4-stable, so we should fix this.

There was an 0/1 offset error in month handling for file metadata, causing
the month to get incremented on each reference to the file.

Thanks to Sebastian Gurtler for troubleshooting this, and Arpad Mueller
for bringing it to my attention.

Relevant discussions:
https://bugzilla.kernel.org/show_bug.cgi?id=210997
https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1872504

Signed-off-by: Valdis Kletnieks 
Signed-off-by: Greg Kroah-Hartman

staging: mt7621-dma: Fix a resource leak in an error handling path

2021-01-12T19:16:18+00:00

commit d887d6104adeb94d1b926936ea21f07367f0ff9f upstream.

If an error occurs after calling 'mtk_hsdma_init()', it must be undone by
a corresponding call to 'mtk_hsdma_uninit()' as already done in the
remove function.

Fixes: 0853c7a53eb3 ("staging: mt7621-dma: ralink: add rt2880 dma engine")
Signed-off-by: Christophe JAILLET 
Cc: stable 
Link: https://lore.kernel.org/r/20201213153513.138723-1-christophe.jaillet@wanadoo.fr
Signed-off-by: Greg Kroah-Hartman

staging: comedi: mf6x4: Fix AI end-of-conversion detection

2020-12-30T10:51:35+00:00

commit 56c90457ebfe9422496aac6ef3d3f0f0ea8b2ec2 upstream.

I have had reports from two different people that attempts to read the
analog input channels of the MF624 board fail with an `ETIMEDOUT` error.

After triggering the conversion, the code calls `comedi_timeout()` with
`mf6x4_ai_eoc()` as the callback function to check if the conversion is
complete.  The callback returns 0 if complete or `-EBUSY` if not yet
complete.  `comedi_timeout()` returns `-ETIMEDOUT` if it has not
completed within a timeout period which is propagated as an error to the
user application.

The existing code considers the conversion to be complete when the EOLC
bit is high.  However, according to the user manuals for the MF624 and
MF634 boards, this test is incorrect because EOLC is an active low
signal that goes high when the conversion is triggered, and goes low
when the conversion is complete.  Fix the problem by inverting the test
of the EOLC bit state.

Fixes: 04b565021a83 ("comedi: Humusoft MF634 and MF624 DAQ cards driver")
Cc:  # v4.4+
Cc: Rostislav Lisovy 
Signed-off-by: Ian Abbott 
Link: https://lore.kernel.org/r/20201207145806.4046-1-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman

speakup: fix uninitialized flush_lock

2020-12-30T10:51:22+00:00

[ Upstream commit d1b928ee1cfa965a3327bbaa59bfa005d97fa0fe ]

The flush_lock is uninitialized, use DEFINE_SPINLOCK
to define and initialize flush_lock.

Fixes: c6e3fd22cd53 ("Staging: add speakup to the staging directory")
Reported-by: Hulk Robot 
Reviewed-by: Samuel Thibault 
Signed-off-by: Yang Yingliang 
Link: https://lore.kernel.org/r/20201117012229.3395186-1-yangyingliang@huawei.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

staging: gasket: interrupt: fix the missed eventfd_ctx_put() in gasket_interrupt.c

2020-12-30T10:51:07+00:00

[ Upstream commit ab5b769a23af12a675b9f3d7dd529250c527f5ac ]

gasket_interrupt_set_eventfd() misses to call eventfd_ctx_put() in an
error path. We check interrupt is valid before calling
eventfd_ctx_fdget() to fix it.

There is the same issue in gasket_interrupt_clear_eventfd(), Add the
missed function call to fix it.

Fixes: 9a69f5087ccc ("drivers/staging: Gasket driver framework + Apex driver")
Signed-off-by: Jing Xiangfeng 
Link: https://lore.kernel.org/r/20201112064924.99680-1-jingxiangfeng@huawei.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

staging: greybus: codecs: Fix reference counter leak in error handling

2020-12-30T10:51:07+00:00

[ Upstream commit 3952659a6108f77a0d062d8e8487bdbdaf52a66c ]

gb_pm_runtime_get_sync has increased the usage counter of the device here.
Forgetting to call gb_pm_runtime_put_noidle will result in usage counter
leak in the error branch of (gbcodec_hw_params and gbcodec_prepare). We
fixed it by adding it.

Fixes: c388ae7696992 ("greybus: audio: Update pm runtime support in dai_ops callback")
Signed-off-by: Zhang Qilong 
Link: https://lore.kernel.org/r/20201109131347.1725288-2-zhangqilong3@huawei.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

speakup: Reject setting the speakup line discipline outside of speakup

2020-12-11T12:23:31+00:00

commit f0992098cadb4c9c6a00703b66cafe604e178fea upstream.

Speakup exposing a line discipline allows userland to try to use it,
while it is deemed to be useless, and thus uselessly exposes potential
bugs. One of them is simply that in such a case if the line sends data,
spk_ttyio_receive_buf2 is called and crashes since spk_ttyio_synth
is NULL.

This change restricts the use of the speakup line discipline to
speakup drivers, thus avoiding such kind of issues altogether.

Cc: stable@vger.kernel.org
Reported-by: Shisong Qin 
Signed-off-by: Samuel Thibault 
Tested-by: Shisong Qin 
Link: https://lore.kernel.org/r/20201129193523.hm3f6n5xrn6fiyyc@function
Signed-off-by: Greg Kroah-Hartman

staging/octeon: fix up merge error

2020-12-08T09:40:24+00:00

commit 673b41e04a035d760bc0aff83fa9ee24fd9c2779 upstream.

There's a semantic conflict in the Octeon staging network driver, which
used the skb_reset_tc() function to reset skb state when re-using an
skb.  But that inline helper function was removed in mainline by commit
2c64605b590e ("net: Fix CONFIG_NET_CLS_ACT=n and
CONFIG_NFT_FWD_NETDEV={y, m} build").

Fix it by using skb_reset_redirect() instead.  Also move it out of the

This code path only ends up triggering if REUSE_SKBUFFS_WITHOUT_FREE is
enabled, which in turn only happens if you don't have CONFIG_NETFILTER
configured.  Which was how this wasn't caught by the usual allmodconfig
builds.

Signed-off-by: Randy Dunlap 
Reported-by: Stephen Rothwell 
Signed-off-by: Linus Torvalds 
Cc: Pablo Neira Ayuso 
Signed-off-by: Greg Kroah-Hartman

staging: ralink-gdma: fix kconfig dependency bug for DMA_RALINK

2020-12-02T07:49:47+00:00

[ Upstream commit 06ea594051707c6b8834ef5b24e9b0730edd391b ]

When DMA_RALINK is enabled and DMADEVICES is disabled, it results in the
following Kbuild warnings:

WARNING: unmet direct dependencies detected for DMA_ENGINE
  Depends on [n]: DMADEVICES [=n]
  Selected by [y]:
  - DMA_RALINK [=y] && STAGING [=y] && RALINK [=y] && !SOC_RT288X [=n]

WARNING: unmet direct dependencies detected for DMA_VIRTUAL_CHANNELS
  Depends on [n]: DMADEVICES [=n]
  Selected by [y]:
  - DMA_RALINK [=y] && STAGING [=y] && RALINK [=y] && !SOC_RT288X [=n]

The reason is that DMA_RALINK selects DMA_ENGINE and DMA_VIRTUAL_CHANNELS
without depending on or selecting DMADEVICES while DMA_ENGINE and
DMA_VIRTUAL_CHANNELS are subordinate to DMADEVICES. This can also fail
building the kernel as demonstrated in a bug report.

Honor the kconfig dependency to remove unmet direct dependency warnings
and avoid any potential build failures.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=210055
Signed-off-by: Necip Fazil Yildiran 
Link: https://lore.kernel.org/r/20201104181522.43567-1-fazilyildiran@gmail.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

staging: rtl8723bs: Add 024c:0627 to the list of SDIO device-ids

2020-11-24T12:29:21+00:00

commit aee9dccc5b64e878cf1b18207436e73f66d74157 upstream.

Add 024c:0627 to the list of SDIO device-ids, based on hardware found in
the wild. This hardware exists on at least some Acer SW1-011 tablets.

Signed-off-by: Brian O'Keefe 
Reviewed-by: Hans de Goede 
Link: https://lore.kernel.org/r/b9e1523f-2ba7-fb82-646a-37f095b4440e@alum.wpi.edu
Cc: stable 
Signed-off-by: Greg Kroah-Hartman