This is a note to let you know that I've just added the patch titled
tcm_fileio: Prevent information leak for short reads
to the 4.4-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:
tcm_fileio-prevent-information-leak-for-short-reads.patch
and it can be found in the queue-4.4 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:57:32 CET 2018
From: Dmitry Monakhov <dmonakhov(a)openvz.org>
Date: Fri, 31 Mar 2017 19:53:35 +0400
Subject: tcm_fileio: Prevent information leak for short reads
From: Dmitry Monakhov <dmonakhov(a)openvz.org>
[ Upstream commit f11b55d13563e9428c88c873f4f03a6bef11ec0a ]
If we failed to read data from backing file (probably because some one
truncate file under us), we must zerofill cmd's data, otherwise it will
be returned as is. Most likely cmd's data are unitialized pages from
page cache. This result in information leak.
(Change BUG_ON into -EINVAL se_cmd failure - nab)
testcase: https://github.com/dmonakhov/xfstests/commit/e11a1b7b907ca67b1be51a15940256…
Signed-off-by: Dmitry Monakhov <dmonakhov(a)openvz.org>
Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/target/target_core_file.c | 23 +++++++++++++++++------
1 file changed, 17 insertions(+), 6 deletions(-)
--- a/drivers/target/target_core_file.c
+++ b/drivers/target/target_core_file.c
@@ -276,12 +276,11 @@ static int fd_do_rw(struct se_cmd *cmd,
else
ret = vfs_iter_read(fd, &iter, &pos);
- kfree(bvec);
-
if (is_write) {
if (ret < 0 || ret != data_length) {
pr_err("%s() write returned %d\n", __func__, ret);
- return (ret < 0 ? ret : -EINVAL);
+ if (ret >= 0)
+ ret = -EINVAL;
}
} else {
/*
@@ -294,17 +293,29 @@ static int fd_do_rw(struct se_cmd *cmd,
pr_err("%s() returned %d, expecting %u for "
"S_ISBLK\n", __func__, ret,
data_length);
- return (ret < 0 ? ret : -EINVAL);
+ if (ret >= 0)
+ ret = -EINVAL;
}
} else {
if (ret < 0) {
pr_err("%s() returned %d for non S_ISBLK\n",
__func__, ret);
- return ret;
+ } else if (ret != data_length) {
+ /*
+ * Short read case:
+ * Probably some one truncate file under us.
+ * We must explicitly zero sg-pages to prevent
+ * expose uninizialized pages to userspace.
+ */
+ if (ret < data_length)
+ ret += iov_iter_zero(data_length - ret, &iter);
+ else
+ ret = -EINVAL;
}
}
}
- return 1;
+ kfree(bvec);
+ return ret;
}
static sense_reason_t
Patches currently in stable-queue which might be from dmonakhov(a)openvz.org are
queue-4.4/tcm_fileio-prevent-information-leak-for-short-reads.patch
This is a note to let you know that I've just added the patch titled
staging: unisys: visorhba: fix s-Par to boot with option CONFIG_VMAP_STACK set to y
to the 4.4-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:
staging-unisys-visorhba-fix-s-par-to-boot-with-option-config_vmap_stack-set-to-y.patch
and it can be found in the queue-4.4 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:57:32 CET 2018
From: Sameer Wadgaonkar <sameer.wadgaonkar(a)unisys.com>
Date: Tue, 18 Apr 2017 16:55:25 -0400
Subject: staging: unisys: visorhba: fix s-Par to boot with option CONFIG_VMAP_STACK set to y
From: Sameer Wadgaonkar <sameer.wadgaonkar(a)unisys.com>
[ Upstream commit 3c2bf0bd08123f3497bd3e84bd9088c937b0cb40 ]
The root issue is that we are not allowed to have items on the
stack being passed to "DMA" like operations. In this case we have
a vmcall and an inline completion of scsi command.
This patch fixes the issue by moving the variables on stack in
do_scsi_nolinuxstat() to heap memory.
Signed-off-by: Sameer Wadgaonkar <sameer.wadgaonkar(a)unisys.com>
Signed-off-by: David Kershner <david.kershner(a)unisys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/unisys/visorhba/visorhba_main.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
--- a/drivers/staging/unisys/visorhba/visorhba_main.c
+++ b/drivers/staging/unisys/visorhba/visorhba_main.c
@@ -792,7 +792,7 @@ static void
do_scsi_nolinuxstat(struct uiscmdrsp *cmdrsp, struct scsi_cmnd *scsicmd)
{
struct scsi_device *scsidev;
- unsigned char buf[36];
+ unsigned char *buf;
struct scatterlist *sg;
unsigned int i;
char *this_page;
@@ -807,6 +807,10 @@ do_scsi_nolinuxstat(struct uiscmdrsp *cm
if (cmdrsp->scsi.no_disk_result == 0)
return;
+ buf = kzalloc(sizeof(char) * 36, GFP_KERNEL);
+ if (!buf)
+ return;
+
/* Linux scsi code wants a device at Lun 0
* to issue report luns, but we don't want
* a disk there so we'll present a processor
@@ -820,6 +824,7 @@ do_scsi_nolinuxstat(struct uiscmdrsp *cm
if (scsi_sg_count(scsicmd) == 0) {
memcpy(scsi_sglist(scsicmd), buf,
cmdrsp->scsi.bufflen);
+ kfree(buf);
return;
}
@@ -831,6 +836,7 @@ do_scsi_nolinuxstat(struct uiscmdrsp *cm
memcpy(this_page, buf + bufind, sg[i].length);
kunmap_atomic(this_page_orig);
}
+ kfree(buf);
} else {
devdata = (struct visorhba_devdata *)scsidev->host->hostdata;
for_each_vdisk_match(vdisk, devdata, scsidev) {
Patches currently in stable-queue which might be from sameer.wadgaonkar(a)unisys.com are
queue-4.4/staging-unisys-visorhba-fix-s-par-to-boot-with-option-config_vmap_stack-set-to-y.patch
This is a note to let you know that I've just added the patch titled
spi: dw: Disable clock after unregistering the host
to the 4.4-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:
spi-dw-disable-clock-after-unregistering-the-host.patch
and it can be found in the queue-4.4 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:57:32 CET 2018
From: Marek Vasut <marex(a)denx.de>
Date: Tue, 18 Apr 2017 20:09:06 +0200
Subject: spi: dw: Disable clock after unregistering the host
From: Marek Vasut <marex(a)denx.de>
[ Upstream commit 400c18e3dc86e04ef5afec9b86a8586ca629b9e9 ]
The dw_mmio driver disables the block clock before unregistering
the host. The code unregistering the host may access the SPI block
registers. If register access happens with block clock disabled,
this may lead to a bus hang. Disable the clock after unregistering
the host to prevent such situation.
This bug was observed on Altera Cyclone V SoC.
Signed-off-by: Marek Vasut <marex(a)denx.de>
Cc: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com>
Cc: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/spi/spi-dw-mmio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/spi/spi-dw-mmio.c
+++ b/drivers/spi/spi-dw-mmio.c
@@ -120,8 +120,8 @@ static int dw_spi_mmio_remove(struct pla
{
struct dw_spi_mmio *dwsmmio = platform_get_drvdata(pdev);
- clk_disable_unprepare(dwsmmio->clk);
dw_spi_remove_host(&dwsmmio->dws);
+ clk_disable_unprepare(dwsmmio->clk);
return 0;
}
Patches currently in stable-queue which might be from marex(a)denx.de are
queue-4.4/spi-dw-disable-clock-after-unregistering-the-host.patch
This is a note to let you know that I've just added the patch titled
scsi: virtio_scsi: Always try to read VPD pages
to the 4.4-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:
scsi-virtio_scsi-always-try-to-read-vpd-pages.patch
and it can be found in the queue-4.4 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:57:32 CET 2018
From: David Gibson <david(a)gibson.dropbear.id.au>
Date: Thu, 13 Apr 2017 12:13:00 +1000
Subject: scsi: virtio_scsi: Always try to read VPD pages
From: David Gibson <david(a)gibson.dropbear.id.au>
[ Upstream commit 25d1d50e23275e141e3a3fe06c25a99f4c4bf4e0 ]
Passed through SCSI targets may have transfer limits which come from the
host SCSI controller or something on the host side other than the target
itself.
To make this work properly, the hypervisor can adjust the target's VPD
information to advertise these limits. But for that to work, the guest
has to look at the VPD pages, which we won't do by default if it is an
SPC-2 device, even if it does actually support it.
This adds a workaround to address this, forcing devices attached to a
virtio-scsi controller to always check the VPD pages. This is modelled
on a similar workaround for the storvsc (Hyper-V) SCSI controller,
although that exists for slightly different reasons.
A specific case which causes this is a volume from IBM's IPR RAID
controller (which presents as an SPC-2 device, although it does support
VPD) passed through with qemu's 'scsi-block' device.
[mkp: fixed typo]
Signed-off-by: David Gibson <david(a)gibson.dropbear.id.au>
Acked-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/virtio_scsi.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -28,6 +28,7 @@
#include <scsi/scsi_device.h>
#include <scsi/scsi_cmnd.h>
#include <scsi/scsi_tcq.h>
+#include <scsi/scsi_devinfo.h>
#include <linux/seqlock.h>
#define VIRTIO_SCSI_MEMPOOL_SZ 64
@@ -704,6 +705,28 @@ static int virtscsi_device_reset(struct
return virtscsi_tmf(vscsi, cmd);
}
+static int virtscsi_device_alloc(struct scsi_device *sdevice)
+{
+ /*
+ * Passed through SCSI targets (e.g. with qemu's 'scsi-block')
+ * may have transfer limits which come from the host SCSI
+ * controller or something on the host side other than the
+ * target itself.
+ *
+ * To make this work properly, the hypervisor can adjust the
+ * target's VPD information to advertise these limits. But
+ * for that to work, the guest has to look at the VPD pages,
+ * which we won't do by default if it is an SPC-2 device, even
+ * if it does actually support it.
+ *
+ * So, set the blist to always try to read the VPD pages.
+ */
+ sdevice->sdev_bflags = BLIST_TRY_VPD_PAGES;
+
+ return 0;
+}
+
+
/**
* virtscsi_change_queue_depth() - Change a virtscsi target's queue depth
* @sdev: Virtscsi target whose queue depth to change
@@ -775,6 +798,7 @@ static struct scsi_host_template virtscs
.change_queue_depth = virtscsi_change_queue_depth,
.eh_abort_handler = virtscsi_abort,
.eh_device_reset_handler = virtscsi_device_reset,
+ .slave_alloc = virtscsi_device_alloc,
.can_queue = 1024,
.dma_boundary = UINT_MAX,
Patches currently in stable-queue which might be from david(a)gibson.dropbear.id.au are
queue-4.4/kvm-ppc-book3s-pr-exit-kvm-on-failed-mapping.patch
queue-4.4/scsi-virtio_scsi-always-try-to-read-vpd-pages.patch
This is a note to let you know that I've just added the patch titled
sm501fb: don't return zero on failure path in sm501fb_start()
to the 4.4-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:
sm501fb-don-t-return-zero-on-failure-path-in-sm501fb_start.patch
and it can be found in the queue-4.4 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:57:32 CET 2018
From: Alexey Khoroshilov <khoroshilov(a)ispras.ru>
Date: Tue, 2 May 2017 13:47:53 +0200
Subject: sm501fb: don't return zero on failure path in sm501fb_start()
From: Alexey Khoroshilov <khoroshilov(a)ispras.ru>
[ Upstream commit dc85e9a87420613b3129d5cc5ecd79c58351c546 ]
If fbmem iomemory mapping failed, sm501fb_start() breaks off
initialization, deallocates resources, but returns zero.
As a result, double deallocation can happen in sm501fb_stop().
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov(a)ispras.ru>
Cc: Tomi Valkeinen <tomi.valkeinen(a)ti.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie(a)samsung.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/video/fbdev/sm501fb.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/video/fbdev/sm501fb.c
+++ b/drivers/video/fbdev/sm501fb.c
@@ -1600,6 +1600,7 @@ static int sm501fb_start(struct sm501fb_
info->fbmem = ioremap(res->start, resource_size(res));
if (info->fbmem == NULL) {
dev_err(dev, "cannot remap framebuffer\n");
+ ret = -ENXIO;
goto err_mem_res;
}
Patches currently in stable-queue which might be from khoroshilov(a)ispras.ru are
queue-4.4/sm501fb-don-t-return-zero-on-failure-path-in-sm501fb_start.patch
This is a note to let you know that I've just added the patch titled
scsi: mac_esp: Replace bogus memory barrier with spinlock
to the 4.4-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:
scsi-mac_esp-replace-bogus-memory-barrier-with-spinlock.patch
and it can be found in the queue-4.4 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:57:32 CET 2018
From: Finn Thain <fthain(a)telegraphics.com.au>
Date: Sun, 2 Apr 2017 17:08:05 +1000
Subject: scsi: mac_esp: Replace bogus memory barrier with spinlock
From: Finn Thain <fthain(a)telegraphics.com.au>
[ Upstream commit 4da2b1eb230ba4ad19b58984dc52e05b1073df5f ]
Commit da244654c66e ("[SCSI] mac_esp: fix for quadras with two esp
chips") added mac_scsi_esp_intr() to handle the IRQ lines from a pair of
on-board ESP chips (a normal shared IRQ did not work).
Proper mutual exclusion was missing from that patch. This patch fixes
race conditions between comparison and assignment of esp_chips[]
pointers.
Signed-off-by: Finn Thain <fthain(a)telegraphics.com.au>
Reviewed-by: Michael Schmitz <schmitzmic(a)gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/mac_esp.c | 33 +++++++++++++++++++++++----------
1 file changed, 23 insertions(+), 10 deletions(-)
--- a/drivers/scsi/mac_esp.c
+++ b/drivers/scsi/mac_esp.c
@@ -55,6 +55,7 @@ struct mac_esp_priv {
int error;
};
static struct esp *esp_chips[2];
+static DEFINE_SPINLOCK(esp_chips_lock);
#define MAC_ESP_GET_PRIV(esp) ((struct mac_esp_priv *) \
platform_get_drvdata((struct platform_device *) \
@@ -562,15 +563,18 @@ static int esp_mac_probe(struct platform
}
host->irq = IRQ_MAC_SCSI;
- esp_chips[dev->id] = esp;
- mb();
- if (esp_chips[!dev->id] == NULL) {
- err = request_irq(host->irq, mac_scsi_esp_intr, 0, "ESP", NULL);
- if (err < 0) {
- esp_chips[dev->id] = NULL;
- goto fail_free_priv;
- }
+
+ /* The request_irq() call is intended to succeed for the first device
+ * and fail for the second device.
+ */
+ err = request_irq(host->irq, mac_scsi_esp_intr, 0, "ESP", NULL);
+ spin_lock(&esp_chips_lock);
+ if (err < 0 && esp_chips[!dev->id] == NULL) {
+ spin_unlock(&esp_chips_lock);
+ goto fail_free_priv;
}
+ esp_chips[dev->id] = esp;
+ spin_unlock(&esp_chips_lock);
err = scsi_esp_register(esp, &dev->dev);
if (err)
@@ -579,8 +583,13 @@ static int esp_mac_probe(struct platform
return 0;
fail_free_irq:
- if (esp_chips[!dev->id] == NULL)
+ spin_lock(&esp_chips_lock);
+ esp_chips[dev->id] = NULL;
+ if (esp_chips[!dev->id] == NULL) {
+ spin_unlock(&esp_chips_lock);
free_irq(host->irq, esp);
+ } else
+ spin_unlock(&esp_chips_lock);
fail_free_priv:
kfree(mep);
fail_free_command_block:
@@ -599,9 +608,13 @@ static int esp_mac_remove(struct platfor
scsi_esp_unregister(esp);
+ spin_lock(&esp_chips_lock);
esp_chips[dev->id] = NULL;
- if (!(esp_chips[0] || esp_chips[1]))
+ if (esp_chips[!dev->id] == NULL) {
+ spin_unlock(&esp_chips_lock);
free_irq(irq, NULL);
+ } else
+ spin_unlock(&esp_chips_lock);
kfree(mep);
Patches currently in stable-queue which might be from fthain(a)telegraphics.com.au are
queue-4.4/scsi-mac_esp-replace-bogus-memory-barrier-with-spinlock.patch
This is a note to let you know that I've just added the patch titled
rtlwifi: rtl_pci: Fix the bug when inactiveps is enabled.
to the 4.4-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:
rtlwifi-rtl_pci-fix-the-bug-when-inactiveps-is-enabled.patch
and it can be found in the queue-4.4 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:57:32 CET 2018
From: Tsang-Shian Lin <thlin(a)realtek.com>
Date: Sat, 9 Dec 2017 11:37:10 -0600
Subject: rtlwifi: rtl_pci: Fix the bug when inactiveps is enabled.
From: Tsang-Shian Lin <thlin(a)realtek.com>
[ Upstream commit b7573a0a27bfa8270dea9b145448f6884b7cacc1 ]
Reset the driver current tx read/write index to zero when inactiveps
nic out of sync with HW state. Wrong driver tx read/write index will
cause Tx fail.
Signed-off-by: Tsang-Shian Lin <thlin(a)realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih(a)realtek.com>
Signed-off-by: Larry Finger <Larry.Finger(a)lwfinger.net>
Cc: Yan-Hsuan Chuang <yhchuang(a)realtek.com>
Cc: Birming Chiu <birming(a)realtek.com>
Cc: Shaofu <shaofu(a)realtek.com>
Cc: Steven Ting <steventing(a)realtek.com>
Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/realtek/rtlwifi/pci.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/drivers/net/wireless/realtek/rtlwifi/pci.c
+++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
@@ -1572,7 +1572,14 @@ int rtl_pci_reset_trx_ring(struct ieee80
dev_kfree_skb_irq(skb);
ring->idx = (ring->idx + 1) % ring->entries;
}
+
+ if (rtlpriv->use_new_trx_flow) {
+ rtlpci->tx_ring[i].cur_tx_rp = 0;
+ rtlpci->tx_ring[i].cur_tx_wp = 0;
+ }
+
ring->idx = 0;
+ ring->entries = rtlpci->txringcount[i];
}
}
spin_unlock_irqrestore(&rtlpriv->locks.irq_th_lock, flags);
Patches currently in stable-queue which might be from thlin(a)realtek.com are
queue-4.4/rtlwifi-rtl_pci-fix-the-bug-when-inactiveps-is-enabled.patch
This is a note to let you know that I've just added the patch titled
rtc: ds1374: wdt: Fix stop/start ioctl always returning -EINVAL
to the 4.4-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:
rtc-ds1374-wdt-fix-stop-start-ioctl-always-returning-einval.patch
and it can be found in the queue-4.4 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:57:32 CET 2018
From: Moritz Fischer <mdf(a)kernel.org>
Date: Mon, 24 Apr 2017 15:05:12 -0700
Subject: rtc: ds1374: wdt: Fix stop/start ioctl always returning -EINVAL
From: Moritz Fischer <mdf(a)kernel.org>
[ Upstream commit 538c08f4c89580fc644e2bc64e0a4b86c925da4e ]
The WDIOC_SETOPTIONS case in the watchdog ioctl would alwayss falls
through to the -EINVAL case. This is wrong since thew watchdog does
actually get stopped or started correctly.
Fixes: 920f91e50c5b ("drivers/rtc/rtc-ds1374.c: add watchdog support")
Signed-off-by: Moritz Fischer <mdf(a)kernel.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni(a)free-electrons.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/rtc/rtc-ds1374.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/rtc/rtc-ds1374.c
+++ b/drivers/rtc/rtc-ds1374.c
@@ -548,14 +548,15 @@ static long ds1374_wdt_ioctl(struct file
if (options & WDIOS_DISABLECARD) {
pr_info("disable watchdog\n");
ds1374_wdt_disable();
+ return 0;
}
if (options & WDIOS_ENABLECARD) {
pr_info("enable watchdog\n");
ds1374_wdt_settimeout(wdt_margin);
ds1374_wdt_ping();
+ return 0;
}
-
return -EINVAL;
}
return -ENOTTY;
Patches currently in stable-queue which might be from mdf(a)kernel.org are
queue-4.4/rtc-ds1374-wdt-fix-stop-start-ioctl-always-returning-einval.patch
queue-4.4/rtc-ds1374-wdt-fix-issue-with-timeout-scaling-from-secs-to-wdt-ticks.patch
This is a note to let you know that I've just added the patch titled
rtc: ds1374: wdt: Fix issue with timeout scaling from secs to wdt ticks
to the 4.4-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:
rtc-ds1374-wdt-fix-issue-with-timeout-scaling-from-secs-to-wdt-ticks.patch
and it can be found in the queue-4.4 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:57:32 CET 2018
From: Moritz Fischer <mdf(a)kernel.org>
Date: Mon, 24 Apr 2017 15:05:11 -0700
Subject: rtc: ds1374: wdt: Fix issue with timeout scaling from secs to wdt ticks
From: Moritz Fischer <mdf(a)kernel.org>
[ Upstream commit 453d0744f6c6ca3f9749b8c57c2e85b5b9f52514 ]
The issue is that the internal counter that triggers the watchdog reset
is actually running at 4096 Hz instead of 1Hz, therefore the value
given by userland (in sec) needs to be multiplied by 4096 to get the
correct behavior.
Fixes: 920f91e50c5b ("drivers/rtc/rtc-ds1374.c: add watchdog support")
Signed-off-by: Moritz Fischer <mdf(a)kernel.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni(a)free-electrons.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/rtc/rtc-ds1374.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/drivers/rtc/rtc-ds1374.c
+++ b/drivers/rtc/rtc-ds1374.c
@@ -527,6 +527,10 @@ static long ds1374_wdt_ioctl(struct file
if (get_user(new_margin, (int __user *)arg))
return -EFAULT;
+ /* the hardware's tick rate is 4096 Hz, so
+ * the counter value needs to be scaled accordingly
+ */
+ new_margin <<= 12;
if (new_margin < 1 || new_margin > 16777216)
return -EINVAL;
@@ -535,7 +539,8 @@ static long ds1374_wdt_ioctl(struct file
ds1374_wdt_ping();
/* fallthrough */
case WDIOC_GETTIMEOUT:
- return put_user(wdt_margin, (int __user *)arg);
+ /* when returning ... inverse is true */
+ return put_user((wdt_margin >> 12), (int __user *)arg);
case WDIOC_SETOPTIONS:
if (copy_from_user(&options, (int __user *)arg, sizeof(int)))
return -EFAULT;
Patches currently in stable-queue which might be from mdf(a)kernel.org are
queue-4.4/rtc-ds1374-wdt-fix-stop-start-ioctl-always-returning-einval.patch
queue-4.4/rtc-ds1374-wdt-fix-issue-with-timeout-scaling-from-secs-to-wdt-ticks.patch
This is a note to let you know that I've just added the patch titled
rtc: cmos: Do not assume irq 8 for rtc when there are no legacy irqs
to the 4.4-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:
rtc-cmos-do-not-assume-irq-8-for-rtc-when-there-are-no-legacy-irqs.patch
and it can be found in the queue-4.4 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:57:32 CET 2018
From: Hans de Goede <hdegoede(a)redhat.com>
Date: Sat, 18 Mar 2017 14:45:49 +0100
Subject: rtc: cmos: Do not assume irq 8 for rtc when there are no legacy irqs
From: Hans de Goede <hdegoede(a)redhat.com>
[ Upstream commit a1e23a42f1bdc00e32fc4869caef12e4e6272f26 ]
On some systems (e.g. Intel Bay Trail systems) the legacy PIC is not
used, in this case virq 8 will be a random irq, rather then hw_irq 8
from the PIC.
Requesting virq 8 in this case will not help us to get alarm irqs and
may cause problems for other drivers which actually do need virq 8,
for example on an Asus Transformer T100TA this leads to:
[ 28.745155] genirq: Flags mismatch irq 8. 00000088 (mmc0) vs. 00000080 (rtc0)
<snip oops>
[ 28.753700] mmc0: Failed to request IRQ 8: -16
[ 28.975934] sdhci-acpi: probe of 80860F14:01 failed with error -16
This commit fixes this by making the rtc-cmos driver continue
without using an irq rather then claiming irq 8 when no irq is
specified in the pnp-info and there are no legacy-irqs.
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni(a)free-electrons.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/rtc/rtc-cmos.c | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)
--- a/drivers/rtc/rtc-cmos.c
+++ b/drivers/rtc/rtc-cmos.c
@@ -41,6 +41,9 @@
#include <linux/pm.h>
#include <linux/of.h>
#include <linux/of_platform.h>
+#ifdef CONFIG_X86
+#include <asm/i8259.h>
+#endif
/* this is for "generic access to PC-style RTC" using CMOS_READ/CMOS_WRITE */
#include <asm-generic/rtc.h>
@@ -1058,17 +1061,23 @@ static int cmos_pnp_probe(struct pnp_dev
{
cmos_wake_setup(&pnp->dev);
- if (pnp_port_start(pnp, 0) == 0x70 && !pnp_irq_valid(pnp, 0))
+ if (pnp_port_start(pnp, 0) == 0x70 && !pnp_irq_valid(pnp, 0)) {
+ unsigned int irq = 0;
+#ifdef CONFIG_X86
/* Some machines contain a PNP entry for the RTC, but
* don't define the IRQ. It should always be safe to
- * hardcode it in these cases
+ * hardcode it on systems with a legacy PIC.
*/
+ if (nr_legacy_irqs())
+ irq = 8;
+#endif
return cmos_do_probe(&pnp->dev,
- pnp_get_resource(pnp, IORESOURCE_IO, 0), 8);
- else
+ pnp_get_resource(pnp, IORESOURCE_IO, 0), irq);
+ } else {
return cmos_do_probe(&pnp->dev,
pnp_get_resource(pnp, IORESOURCE_IO, 0),
pnp_irq(pnp, 0));
+ }
}
static void __exit cmos_pnp_remove(struct pnp_dev *pnp)
Patches currently in stable-queue which might be from hdegoede(a)redhat.com are
queue-4.4/acpi-pmic-xpower-fix-power_table-addresses.patch
queue-4.4/rtc-cmos-do-not-assume-irq-8-for-rtc-when-there-are-no-legacy-irqs.patch
queue-4.4/genirq-use-irqd_get_trigger_type-to-compare-the-trigger-type-for-shared-irqs.patch
queue-4.4/x86-i8259-export-legacy_pic-symbol.patch