This is a note to let you know that I've just added the patch titled
nfsd4: permit layoutget of executable-only files
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
nfsd4-permit-layoutget-of-executable-only-files.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Mar 22 14:26:48 CET 2018
From: Benjamin Coddington <bcodding(a)redhat.com>
Date: Tue, 19 Dec 2017 09:35:25 -0500
Subject: nfsd4: permit layoutget of executable-only files
From: Benjamin Coddington <bcodding(a)redhat.com>
[ Upstream commit 66282ec1cf004c09083c29cb5e49019037937bbd ]
Clients must be able to read a file in order to execute it, and for pNFS
that means the client needs to be able to perform a LAYOUTGET on the file.
This behavior for executable-only files was added for OPEN in commit
a043226bc140 "nfsd4: permit read opens of executable-only files".
This fixes up xfstests generic/126 on block/scsi layouts.
Signed-off-by: Benjamin Coddington <bcodding(a)redhat.com>
Signed-off-by: J. Bruce Fields <bfields(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfsd/nfs4proc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/fs/nfsd/nfs4proc.c
+++ b/fs/nfsd/nfs4proc.c
@@ -1372,14 +1372,14 @@ nfsd4_layoutget(struct svc_rqst *rqstp,
const struct nfsd4_layout_ops *ops;
struct nfs4_layout_stateid *ls;
__be32 nfserr;
- int accmode;
+ int accmode = NFSD_MAY_READ_IF_EXEC;
switch (lgp->lg_seg.iomode) {
case IOMODE_READ:
- accmode = NFSD_MAY_READ;
+ accmode |= NFSD_MAY_READ;
break;
case IOMODE_RW:
- accmode = NFSD_MAY_READ | NFSD_MAY_WRITE;
+ accmode |= NFSD_MAY_READ | NFSD_MAY_WRITE;
break;
default:
dprintk("%s: invalid iomode %d\n",
Patches currently in stable-queue which might be from bcodding(a)redhat.com are
queue-4.14/nfsd4-permit-layoutget-of-executable-only-files.patch
This is a note to let you know that I've just added the patch titled
net: phy: meson-gxl: check phy_write return value
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-phy-meson-gxl-check-phy_write-return-value.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Mar 22 14:26:48 CET 2018
From: Jerome Brunet <jbrunet(a)baylibre.com>
Date: Mon, 18 Dec 2017 10:44:40 +0100
Subject: net: phy: meson-gxl: check phy_write return value
From: Jerome Brunet <jbrunet(a)baylibre.com>
[ Upstream commit 9042b46eda33ef5db3cdfc9e12b3c8cabb196141 ]
Always check phy_write return values. Better to be safe than sorry
Reviewed-by: Andrew Lunn <andrew(a)lunn.ch>
Signed-off-by: Jerome Brunet <jbrunet(a)baylibre.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/phy/meson-gxl.c | 50 +++++++++++++++++++++++++++++++++-----------
1 file changed, 38 insertions(+), 12 deletions(-)
--- a/drivers/net/phy/meson-gxl.c
+++ b/drivers/net/phy/meson-gxl.c
@@ -25,27 +25,53 @@
static int meson_gxl_config_init(struct phy_device *phydev)
{
+ int ret;
+
/* Enable Analog and DSP register Bank access by */
- phy_write(phydev, 0x14, 0x0000);
- phy_write(phydev, 0x14, 0x0400);
- phy_write(phydev, 0x14, 0x0000);
- phy_write(phydev, 0x14, 0x0400);
+ ret = phy_write(phydev, 0x14, 0x0000);
+ if (ret)
+ return ret;
+ ret = phy_write(phydev, 0x14, 0x0400);
+ if (ret)
+ return ret;
+ ret = phy_write(phydev, 0x14, 0x0000);
+ if (ret)
+ return ret;
+ ret = phy_write(phydev, 0x14, 0x0400);
+ if (ret)
+ return ret;
/* Write Analog register 23 */
- phy_write(phydev, 0x17, 0x8E0D);
- phy_write(phydev, 0x14, 0x4417);
+ ret = phy_write(phydev, 0x17, 0x8E0D);
+ if (ret)
+ return ret;
+ ret = phy_write(phydev, 0x14, 0x4417);
+ if (ret)
+ return ret;
/* Enable fractional PLL */
- phy_write(phydev, 0x17, 0x0005);
- phy_write(phydev, 0x14, 0x5C1B);
+ ret = phy_write(phydev, 0x17, 0x0005);
+ if (ret)
+ return ret;
+ ret = phy_write(phydev, 0x14, 0x5C1B);
+ if (ret)
+ return ret;
/* Program fraction FR_PLL_DIV1 */
- phy_write(phydev, 0x17, 0x029A);
- phy_write(phydev, 0x14, 0x5C1D);
+ ret = phy_write(phydev, 0x17, 0x029A);
+ if (ret)
+ return ret;
+ ret = phy_write(phydev, 0x14, 0x5C1D);
+ if (ret)
+ return ret;
/* Program fraction FR_PLL_DIV1 */
- phy_write(phydev, 0x17, 0xAAAA);
- phy_write(phydev, 0x14, 0x5C1C);
+ ret = phy_write(phydev, 0x17, 0xAAAA);
+ if (ret)
+ return ret;
+ ret = phy_write(phydev, 0x14, 0x5C1C);
+ if (ret)
+ return ret;
return 0;
}
Patches currently in stable-queue which might be from jbrunet(a)baylibre.com are
queue-4.14/net-phy-meson-gxl-check-phy_write-return-value.patch
This is a note to let you know that I've just added the patch titled
net: fec: add phy_reset_after_clk_enable() support
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-fec-add-phy_reset_after_clk_enable-support.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Mar 22 14:26:48 CET 2018
From: Richard Leitner <richard.leitner(a)skidata.com>
Date: Mon, 11 Dec 2017 13:17:00 +0100
Subject: net: fec: add phy_reset_after_clk_enable() support
From: Richard Leitner <richard.leitner(a)skidata.com>
[ Upstream commit 1b0a83ac04e383e3bed21332962b90710fcf2828 ]
Some PHYs (for example the SMSC LAN8710/LAN8720) doesn't allow turning
the refclk on and off again during operation (according to their
datasheet). Nonetheless exactly this behaviour was introduced for power
saving reasons by commit e8fcfcd5684a ("net: fec: optimize the clock management to save power").
Therefore add support for the phy_reset_after_clk_enable function from
phylib to mitigate this issue.
Generally speaking this issue is only relevant if the ref clk for the
PHY is generated by the SoC and therefore the PHY is configured to
"REF_CLK In Mode". In our specific case (PCB) this problem does occur at
about every 10th to 50th POR of an LAN8710 connected to an i.MX6SOLO
SoC. The typical symptom of this problem is a "swinging" ethernet link.
Similar issues were reported by users of the NXP forum:
https://community.nxp.com/thread/389902https://community.nxp.com/message/309354
With this patch applied the issue didn't occur for at least a few
hundret PORs of our board.
Fixes: e8fcfcd5684a ("net: fec: optimize the clock management to save power")
Signed-off-by: Richard Leitner <richard.leitner(a)skidata.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/freescale/fec_main.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -1872,6 +1872,8 @@ static int fec_enet_clk_enable(struct ne
ret = clk_prepare_enable(fep->clk_ref);
if (ret)
goto failed_clk_ref;
+
+ phy_reset_after_clk_enable(ndev->phydev);
} else {
clk_disable_unprepare(fep->clk_ahb);
clk_disable_unprepare(fep->clk_enet_out);
@@ -2844,6 +2846,7 @@ fec_enet_open(struct net_device *ndev)
{
struct fec_enet_private *fep = netdev_priv(ndev);
int ret;
+ bool reset_again;
ret = pm_runtime_get_sync(&fep->pdev->dev);
if (ret < 0)
@@ -2854,6 +2857,17 @@ fec_enet_open(struct net_device *ndev)
if (ret)
goto clk_enable;
+ /* During the first fec_enet_open call the PHY isn't probed at this
+ * point. Therefore the phy_reset_after_clk_enable() call within
+ * fec_enet_clk_enable() fails. As we need this reset in order to be
+ * sure the PHY is working correctly we check if we need to reset again
+ * later when the PHY is probed
+ */
+ if (ndev->phydev && ndev->phydev->drv)
+ reset_again = false;
+ else
+ reset_again = true;
+
/* I should reset the ring buffers here, but I don't yet know
* a simple way to do that.
*/
@@ -2870,6 +2884,12 @@ fec_enet_open(struct net_device *ndev)
if (ret)
goto err_enet_mii_probe;
+ /* Call phy_reset_after_clk_enable() again if it failed during
+ * phy_reset_after_clk_enable() before because the PHY wasn't probed.
+ */
+ if (reset_again)
+ phy_reset_after_clk_enable(ndev->phydev);
+
if (fep->quirks & FEC_QUIRK_ERR006687)
imx6q_cpuidle_fec_irqs_used();
Patches currently in stable-queue which might be from richard.leitner(a)skidata.com are
queue-4.14/net-fec-add-phy_reset_after_clk_enable-support.patch
This is a note to let you know that I've just added the patch titled
mmc: sdhci-xenon: wait 5ms after set 1.8V signal enable
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mmc-sdhci-xenon-wait-5ms-after-set-1.8v-signal-enable.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Mar 22 14:26:48 CET 2018
From: Zhoujie Wu <zjwu(a)marvell.com>
Date: Mon, 18 Dec 2017 14:38:47 -0800
Subject: mmc: sdhci-xenon: wait 5ms after set 1.8V signal enable
From: Zhoujie Wu <zjwu(a)marvell.com>
[ Upstream commit 8d876bf472dba73c015cea9feea80dcb80626a7c ]
According to SD spec 3.00 3.6.1 signal voltage switch
procedure step 6~8,
(6) Set 1.8V Signal Enable in the Host Control 2 register.
(7) Wait 5ms. 1.8V voltage regulator shall be stable within this period.
(8) If 1.8V Signal Enable is cleared by Host Controller, go to step (12).
Host should wait 5ms after set 1.8V signal enable bit in
Host Control 2 register and check if 1.8V is stable or not.
But current code checks this bit right after set it.
On some platforms with xenon controller found the bit is
cleared right away and host reports "1.8V regulator output
did not became stable" and 5ms delay can help.
Implement voltage_switch callback for xenon controller to add 5ms
delay to make sure the 1.8V signal enable bit is set by controller.
Signed-off-by: Zhoujie Wu <zjwu(a)marvell.com>
Acked-by: Adrian Hunter <adrian.hunter(a)intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mmc/host/sdhci-xenon.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/drivers/mmc/host/sdhci-xenon.c
+++ b/drivers/mmc/host/sdhci-xenon.c
@@ -230,7 +230,14 @@ static void xenon_set_power(struct sdhci
mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
}
+static void xenon_voltage_switch(struct sdhci_host *host)
+{
+ /* Wait for 5ms after set 1.8V signal enable bit */
+ usleep_range(5000, 5500);
+}
+
static const struct sdhci_ops sdhci_xenon_ops = {
+ .voltage_switch = xenon_voltage_switch,
.set_clock = sdhci_set_clock,
.set_power = xenon_set_power,
.set_bus_width = sdhci_set_bus_width,
Patches currently in stable-queue which might be from zjwu(a)marvell.com are
queue-4.14/mmc-sdhci-xenon-wait-5ms-after-set-1.8v-signal-enable.patch
This is a note to let you know that I've just added the patch titled
mmc: block: fix logical error to avoid memory leak
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mmc-block-fix-logical-error-to-avoid-memory-leak.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Mar 22 14:26:48 CET 2018
From: "Liu, Changcheng" <changcheng.liu(a)intel.com>
Date: Sat, 16 Dec 2017 23:15:45 +0800
Subject: mmc: block: fix logical error to avoid memory leak
From: "Liu, Changcheng" <changcheng.liu(a)intel.com>
[ Upstream commit 0be55579a127916ebe39db2a74d906a2dfceed42 ]
If the MMC_DRV_OP_GET_EXT_CSD request completes successfully, then
ext_csd must be freed, but in one case it was not. Fix that.
Signed-off-by: Liu Changcheng <changcheng.liu(a)intel.com>
Acked-by: Adrian Hunter <adrian.hunter(a)intel.com>
Acked-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mmc/core/block.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/mmc/core/block.c
+++ b/drivers/mmc/core/block.c
@@ -2387,6 +2387,7 @@ static int mmc_ext_csd_open(struct inode
if (n != EXT_CSD_STR_LEN) {
err = -EINVAL;
+ kfree(ext_csd);
goto out_free;
}
Patches currently in stable-queue which might be from changcheng.liu(a)intel.com are
queue-4.14/mmc-block-fix-logical-error-to-avoid-memory-leak.patch
This is a note to let you know that I've just added the patch titled
mmc: avoid removing non-removable hosts during suspend
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mmc-avoid-removing-non-removable-hosts-during-suspend.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Mar 22 14:26:48 CET 2018
From: Daniel Drake <drake(a)endlessm.com>
Date: Tue, 12 Dec 2017 10:49:02 +0000
Subject: mmc: avoid removing non-removable hosts during suspend
From: Daniel Drake <drake(a)endlessm.com>
[ Upstream commit de8dcc3d2c0e08e5068ee1e26fc46415c15e3637 ]
The Weibu F3C MiniPC has an onboard AP6255 module, presenting
two SDIO functions on a single MMC host (Bluetooth/btsdio and
WiFi/brcmfmac), and the mmc layer correctly detects this as
non-removable.
After suspend/resume, the wifi and bluetooth interfaces disappear
and do not get probed again.
The conditions here are:
1. During suspend, we reach mmc_pm_notify()
2. mmc_pm_notify() calls mmc_sdio_pre_suspend() to see if we can
suspend the SDIO host. However, mmc_sdio_pre_suspend() returns
-ENOSYS because btsdio_driver does not have a suspend method.
3. mmc_pm_notify() proceeds to remove the card
4. Upon resume, mmc_rescan() does nothing with this host, because of
the rescan_entered check which aims to only scan a non-removable
device a single time (i.e. during boot).
Fix the loss of functionality by detecting that we are unable to
suspend a non-removable host, so avoid the forced removal in that
case. The comment above this function already indicates that this
code was only intended for removable devices.
Signed-off-by: Daniel Drake <drake(a)endlessm.com>
Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mmc/core/core.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -2751,6 +2751,14 @@ static int mmc_pm_notify(struct notifier
if (!err)
break;
+ if (!mmc_card_is_removable(host)) {
+ dev_warn(mmc_dev(host),
+ "pre_suspend failed for non-removable host: "
+ "%d\n", err);
+ /* Avoid removing non-removable hosts */
+ break;
+ }
+
/* Calling bus_ops->remove() with a claimed host can deadlock */
host->bus_ops->remove(host);
mmc_claim_host(host);
Patches currently in stable-queue which might be from drake(a)endlessm.com are
queue-4.14/mmc-avoid-removing-non-removable-hosts-during-suspend.patch
This is a note to let you know that I've just added the patch titled
media: s5p-mfc: Fix lock contention - request_firmware() once
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
media-s5p-mfc-fix-lock-contention-request_firmware-once.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Mar 22 14:26:48 CET 2018
From: Shuah Khan <shuahkh(a)osg.samsung.com>
Date: Fri, 3 Nov 2017 22:01:58 -0400
Subject: media: s5p-mfc: Fix lock contention - request_firmware() once
From: Shuah Khan <shuahkh(a)osg.samsung.com>
[ Upstream commit f45ce9877561044090010e0eb0fad644232ded04 ]
Driver calls request_firmware() whenever the device is opened for the
first time. As the device gets opened and closed, dev->num_inst == 1
is true several times. This is not necessary since the firmware is saved
in the fw_buf. s5p_mfc_load_firmware() copies the buffer returned by
the request_firmware() to dev->fw_buf.
fw_buf sticks around until it gets released from s5p_mfc_remove(), hence
there is no need to keep requesting firmware and copying it to fw_buf.
This might have been overlooked when changes are made to free fw_buf from
the device release interface s5p_mfc_release().
Fix s5p_mfc_load_firmware() to call request_firmware() once and keep state.
Change _probe() to load firmware once fw_buf has been allocated.
s5p_mfc_open() and it continues to call s5p_mfc_load_firmware() and init
hardware which is the step where firmware is written to the device.
This addresses the mfc_mutex contention due to repeated request_firmware()
calls from open() in the following circular locking warning:
[ 552.194115] qtdemux0:sink/2710 is trying to acquire lock:
[ 552.199488] (&dev->mfc_mutex){+.+.}, at: [<bf145544>] s5p_mfc_mmap+0x28/0xd4 [s5p_mfc]
[ 552.207459]
but task is already holding lock:
[ 552.213264] (&mm->mmap_sem){++++}, at: [<c01df2e4>] vm_mmap_pgoff+0x44/0xb8
[ 552.220284]
which lock already depends on the new lock.
[ 552.228429]
the existing dependency chain (in reverse order) is:
[ 552.235881]
-> #2 (&mm->mmap_sem){++++}:
[ 552.241259] __might_fault+0x80/0xb0
[ 552.245331] filldir64+0xc0/0x2f8
[ 552.249144] call_filldir+0xb0/0x14c
[ 552.253214] ext4_readdir+0x768/0x90c
[ 552.257374] iterate_dir+0x74/0x168
[ 552.261360] SyS_getdents64+0x7c/0x1a0
[ 552.265608] ret_fast_syscall+0x0/0x28
[ 552.269850]
-> #1 (&type->i_mutex_dir_key#2){++++}:
[ 552.276180] down_read+0x48/0x90
[ 552.279904] lookup_slow+0x74/0x178
[ 552.283889] walk_component+0x1a4/0x2e4
[ 552.288222] link_path_walk+0x174/0x4a0
[ 552.292555] path_openat+0x68/0x944
[ 552.296541] do_filp_open+0x60/0xc4
[ 552.300528] file_open_name+0xe4/0x114
[ 552.304772] filp_open+0x28/0x48
[ 552.308499] kernel_read_file_from_path+0x30/0x78
[ 552.313700] _request_firmware+0x3ec/0x78c
[ 552.318291] request_firmware+0x3c/0x54
[ 552.322642] s5p_mfc_load_firmware+0x54/0x150 [s5p_mfc]
[ 552.328358] s5p_mfc_open+0x4e4/0x550 [s5p_mfc]
[ 552.333394] v4l2_open+0xa0/0x104 [videodev]
[ 552.338137] chrdev_open+0xa4/0x18c
[ 552.342121] do_dentry_open+0x208/0x310
[ 552.346454] path_openat+0x28c/0x944
[ 552.350526] do_filp_open+0x60/0xc4
[ 552.354512] do_sys_open+0x118/0x1c8
[ 552.358586] ret_fast_syscall+0x0/0x28
[ 552.362830]
-> #0 (&dev->mfc_mutex){+.+.}:
-> #0 (&dev->mfc_mutex){+.+.}:
[ 552.368379] lock_acquire+0x6c/0x88
[ 552.372364] __mutex_lock+0x68/0xa34
[ 552.376437] mutex_lock_interruptible_nested+0x1c/0x24
[ 552.382086] s5p_mfc_mmap+0x28/0xd4 [s5p_mfc]
[ 552.386939] v4l2_mmap+0x54/0x88 [videodev]
[ 552.391601] mmap_region+0x3a8/0x638
[ 552.395673] do_mmap+0x330/0x3a4
[ 552.399400] vm_mmap_pgoff+0x90/0xb8
[ 552.403472] SyS_mmap_pgoff+0x90/0xc0
[ 552.407632] ret_fast_syscall+0x0/0x28
[ 552.411876]
other info that might help us debug this:
[ 552.419848] Chain exists of:
&dev->mfc_mutex --> &type->i_mutex_dir_key#2 --> &mm->mmap_sem
[ 552.431200] Possible unsafe locking scenario:
[ 552.437092] CPU0 CPU1
[ 552.441598] ---- ----
[ 552.446104] lock(&mm->mmap_sem);
[ 552.449484] lock(&type->i_mutex_dir_key#2);
[ 552.456329] lock(&mm->mmap_sem);
[ 552.462222] lock(&dev->mfc_mutex);
[ 552.465775]
*** DEADLOCK ***
Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki(a)samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/platform/s5p-mfc/s5p_mfc.c | 6 ++++++
drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 3 +++
drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c | 5 +++++
3 files changed, 14 insertions(+)
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1315,6 +1315,12 @@ static int s5p_mfc_probe(struct platform
goto err_dma;
}
+ /*
+ * Load fails if fs isn't mounted. Try loading anyway.
+ * _open() will load it, it it fails now. Ignore failure.
+ */
+ s5p_mfc_load_firmware(dev);
+
mutex_init(&dev->mfc_mutex);
init_waitqueue_head(&dev->queue);
dev->hw_lock = 0;
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -290,6 +290,8 @@ struct s5p_mfc_priv_buf {
* @mfc_cmds: cmd structure holding HW commands function pointers
* @mfc_regs: structure holding MFC registers
* @fw_ver: loaded firmware sub-version
+ * @fw_get_done flag set when request_firmware() is complete and
+ * copied into fw_buf
* risc_on: flag indicates RISC is on or off
*
*/
@@ -336,6 +338,7 @@ struct s5p_mfc_dev {
struct s5p_mfc_hw_cmds *mfc_cmds;
const struct s5p_mfc_regs *mfc_regs;
enum s5p_mfc_fw_ver fw_ver;
+ bool fw_get_done;
bool risc_on; /* indicates if RISC is on or off */
};
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
@@ -55,6 +55,9 @@ int s5p_mfc_load_firmware(struct s5p_mfc
* into kernel. */
mfc_debug_enter();
+ if (dev->fw_get_done)
+ return 0;
+
for (i = MFC_FW_MAX_VERSIONS - 1; i >= 0; i--) {
if (!dev->variant->fw_name[i])
continue;
@@ -82,6 +85,7 @@ int s5p_mfc_load_firmware(struct s5p_mfc
}
memcpy(dev->fw_buf.virt, fw_blob->data, fw_blob->size);
wmb();
+ dev->fw_get_done = true;
release_firmware(fw_blob);
mfc_debug_leave();
return 0;
@@ -93,6 +97,7 @@ int s5p_mfc_release_firmware(struct s5p_
/* Before calling this function one has to make sure
* that MFC is no longer processing */
s5p_mfc_release_priv_buf(dev, &dev->fw_buf);
+ dev->fw_get_done = false;
return 0;
}
Patches currently in stable-queue which might be from shuahkh(a)osg.samsung.com are
queue-4.14/media-s5p-mfc-fix-lock-contention-request_firmware-once.patch
This is a note to let you know that I've just added the patch titled
media: [RESEND] media: dvb-frontends: Add delay to Si2168 restart
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
media-media-dvb-frontends-add-delay-to-si2168-restart.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Mar 22 14:26:48 CET 2018
From: Ron Economos <w6rz(a)comcast.net>
Date: Mon, 11 Dec 2017 19:51:53 -0500
Subject: media: [RESEND] media: dvb-frontends: Add delay to Si2168 restart
From: Ron Economos <w6rz(a)comcast.net>
[ Upstream commit 380a6c86457573aa42d27ae11e025eb25941a0b7 ]
On faster CPUs a delay is required after the resume command and the restart command. Without the delay, the restart command often returns -EREMOTEIO and the Si2168 does not restart.
Note that this patch fixes the same issue as https://patchwork.linuxtv.org/patch/44304/, but I believe my udelay() fix addresses the actual problem.
Signed-off-by: Ron Economos <w6rz(a)comcast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/dvb-frontends/si2168.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/media/dvb-frontends/si2168.c
+++ b/drivers/media/dvb-frontends/si2168.c
@@ -14,6 +14,8 @@
* GNU General Public License for more details.
*/
+#include <linux/delay.h>
+
#include "si2168_priv.h"
static const struct dvb_frontend_ops si2168_ops;
@@ -435,6 +437,7 @@ static int si2168_init(struct dvb_fronte
if (ret)
goto err;
+ udelay(100);
memcpy(cmd.args, "\x85", 1);
cmd.wlen = 1;
cmd.rlen = 1;
Patches currently in stable-queue which might be from w6rz(a)comcast.net are
queue-4.14/media-media-dvb-frontends-add-delay-to-si2168-restart.patch
This is a note to let you know that I've just added the patch titled
media: davinci: fix a debug printk
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
media-davinci-fix-a-debug-printk.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Mar 22 14:26:48 CET 2018
From: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Date: Wed, 1 Nov 2017 17:05:49 -0400
Subject: media: davinci: fix a debug printk
From: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
[ Upstream commit 4f6c11044f512356cb63d3df0f3b38db79dc6736 ]
Two orthogonal changesets caused a breakage at a printk
inside davinci. Commit a2d17962c9ca
("[media] davinci: Switch from V4L2 OF to V4L2 fwnode")
made davinci to use struct fwnode_handle instead of
struct device_node. Commit 68d9c47b1679
("media: Convert to using %pOF instead of full_name")
changed the printk to not use ->full_name, but, instead,
to rely on %pOF.
With both patches applied, the Kernel will do the wrong
thing, as warned by smatch:
drivers/media/platform/davinci/vpif_capture.c:1399 vpif_async_bound() error: '%pOF' expects argument of type 'struct device_node*', argument 5 has type 'void*'
So, change the logic to actually print the device name
that was obtained before the print logic.
Fixes: 68d9c47b1679 ("media: Convert to using %pOF instead of full_name")
Fixes: a2d17962c9ca ("[media] davinci: Switch from V4L2 OF to V4L2 fwnode")
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Acked-by: Lad, Prabhakar <prabhakar.csengg(a)gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/platform/davinci/vpif_capture.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -1397,9 +1397,9 @@ static int vpif_async_bound(struct v4l2_
vpif_obj.config->chan_config->inputs[i].subdev_name =
(char *)to_of_node(subdev->fwnode)->full_name;
vpif_dbg(2, debug,
- "%s: setting input %d subdev_name = %pOF\n",
+ "%s: setting input %d subdev_name = %s\n",
__func__, i,
- to_of_node(subdev->fwnode));
+ vpif_obj.config->chan_config->inputs[i].subdev_name);
return 0;
}
}
Patches currently in stable-queue which might be from mchehab(a)s-opensource.com are
queue-4.14/media-s5p-mfc-fix-lock-contention-request_firmware-once.patch
queue-4.14/media-media-dvb-frontends-add-delay-to-si2168-restart.patch
queue-4.14/media-c8sectpfe-fix-potential-null-pointer-dereference-in-c8sectpfe_timer_interrupt.patch
queue-4.14/media-davinci-fix-a-debug-printk.patch
queue-4.14/media-bt8xx-fix-err-bt878_probe.patch
This is a note to let you know that I've just added the patch titled
media: c8sectpfe: fix potential NULL pointer dereference in c8sectpfe_timer_interrupt
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
media-c8sectpfe-fix-potential-null-pointer-dereference-in-c8sectpfe_timer_interrupt.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Mar 22 14:26:48 CET 2018
From: "Gustavo A. R. Silva" <garsilva(a)embeddedor.com>
Date: Mon, 20 Nov 2017 09:00:55 -0500
Subject: media: c8sectpfe: fix potential NULL pointer dereference in c8sectpfe_timer_interrupt
From: "Gustavo A. R. Silva" <garsilva(a)embeddedor.com>
[ Upstream commit baed3c4bc4c13de93e0dba0a26d601411ebcb389 ]
_channel_ is being dereferenced before it is null checked, hence there is a
potential null pointer dereference. Fix this by moving the pointer dereference
after _channel_ has been null checked.
This issue was detected with the help of Coccinelle.
Fixes: c5f5d0f99794 ("[media] c8sectpfe: STiH407/10 Linux DVB demux support")
Signed-off-by: Gustavo A. R. Silva <garsilva(a)embeddedor.com>
Acked-by: Patrice Chotard <patrice.chotard(a)st.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
+++ b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
@@ -83,7 +83,7 @@ static void c8sectpfe_timer_interrupt(un
static void channel_swdemux_tsklet(unsigned long data)
{
struct channel_info *channel = (struct channel_info *)data;
- struct c8sectpfei *fei = channel->fei;
+ struct c8sectpfei *fei;
unsigned long wp, rp;
int pos, num_packets, n, size;
u8 *buf;
@@ -91,6 +91,8 @@ static void channel_swdemux_tsklet(unsig
if (unlikely(!channel || !channel->irec))
return;
+ fei = channel->fei;
+
wp = readl(channel->irec + DMA_PRDS_BUSWP_TP(0));
rp = readl(channel->irec + DMA_PRDS_BUSRP_TP(0));
Patches currently in stable-queue which might be from garsilva(a)embeddedor.com are
queue-4.14/media-c8sectpfe-fix-potential-null-pointer-dereference-in-c8sectpfe_timer_interrupt.patch