This is a note to let you know that I've just added the patch titled
USB: ledtrig-usbport: fix of-node 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:
usb-ledtrig-usbport-fix-of-node-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 Fri Mar 16 15:43:17 CET 2018
From: Johan Hovold <johan(a)kernel.org>
Date: Thu, 9 Nov 2017 18:07:22 +0100
Subject: USB: ledtrig-usbport: fix of-node leak
From: Johan Hovold <johan(a)kernel.org>
[ Upstream commit 03310a15484ab6a8f6d91bbf7fe486b17275c09a ]
This code looks up a USB device node from a given parent USB device but
never dropped its reference to the returned node.
As only the address of the node is used for a later matching, the
reference can be dropped immediately.
Note that this trigger implementation confuses the description of the
USB device connected to a port with the port itself (which does not have
a device-tree representation).
Fixes: 4f04c210d031 ("usb: core: read USB ports from DT in the usbport LED trigger driver")
Cc: Rafał Miłecki <rafal(a)milecki.pl>
Signed-off-by: Johan Hovold <johan(a)kernel.org>
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/usb/core/ledtrig-usbport.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
--- a/drivers/usb/core/ledtrig-usbport.c
+++ b/drivers/usb/core/ledtrig-usbport.c
@@ -140,11 +140,17 @@ static bool usbport_trig_port_observed(s
if (!led_np)
return false;
- /* Get node of port being added */
+ /*
+ * Get node of port being added
+ *
+ * FIXME: This is really the device node of the connected device
+ */
port_np = usb_of_get_child_node(usb_dev->dev.of_node, port1);
if (!port_np)
return false;
+ of_node_put(port_np);
+
/* Amount of trigger sources for this LED */
count = of_count_phandle_with_args(led_np, "trigger-sources",
"#trigger-source-cells");
Patches currently in stable-queue which might be from johan(a)kernel.org are
queue-4.14/usb-ledtrig-usbport-fix-of-node-leak.patch
queue-4.14/serial-core-mark-port-as-initialized-in-autoconfig.patch
This is a note to let you know that I've just added the patch titled
typec: tcpm: fusb302: Resolve out of order messaging events
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:
typec-tcpm-fusb302-resolve-out-of-order-messaging-events.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 Fri Mar 16 15:43:17 CET 2018
From: Adam Thomson <Adam.Thomson.Opensource(a)diasemi.com>
Date: Tue, 21 Nov 2017 14:12:12 +0000
Subject: typec: tcpm: fusb302: Resolve out of order messaging events
From: Adam Thomson <Adam.Thomson.Opensource(a)diasemi.com>
[ Upstream commit ab69f61321140ff632d560775bc226259a78dfa2 ]
The expectation in the FUSB302 driver is that a TX_SUCCESS event
should occur after a message has been sent, but before a GCRCSENT
event is raised to indicate successful receipt of a message from
the partner. However in some circumstances it is possible to see
the hardware raise a GCRCSENT event before a TX_SUCCESS event
is raised. The upshot of this is that the GCRCSENT handling portion
of code ends up reporting the GoodCRC message to TCPM because the
TX_SUCCESS event hasn't yet arrived to trigger a consumption of it.
When TX_SUCCESS is then raised by the chip it ends up consuming the
actual message that was meant for TCPM, and this incorrect sequence
results in a hard reset from TCPM.
To avoid this problem, this commit updates the message reading
code to check whether a GoodCRC message was received or not. Based
on this check it will either report that the previous transmission
has completed or it will pass the msg data to TCPM for futher
processing. This way the incorrect ordering of the events no longer
matters.
Signed-off-by: Adam Thomson <Adam.Thomson.Opensource(a)diasemi.com>
Reviewed-by: Guenter Roeck <linux(a)roeck-us.net>
Acked-by: Heikki Krogerus <heikki.krogerus(a)linux.intel.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/typec/fusb302/fusb302.c | 21 +++++++++++++++++----
1 file changed, 17 insertions(+), 4 deletions(-)
--- a/drivers/staging/typec/fusb302/fusb302.c
+++ b/drivers/staging/typec/fusb302/fusb302.c
@@ -1552,6 +1552,21 @@ static int fusb302_pd_read_message(struc
fusb302_log(chip, "PD message header: %x", msg->header);
fusb302_log(chip, "PD message len: %d", len);
+ /*
+ * Check if we've read off a GoodCRC message. If so then indicate to
+ * TCPM that the previous transmission has completed. Otherwise we pass
+ * the received message over to TCPM for processing.
+ *
+ * We make this check here instead of basing the reporting decision on
+ * the IRQ event type, as it's possible for the chip to report the
+ * TX_SUCCESS and GCRCSENT events out of order on occasion, so we need
+ * to check the message type to ensure correct reporting to TCPM.
+ */
+ if ((!len) && (pd_header_type_le(msg->header) == PD_CTRL_GOOD_CRC))
+ tcpm_pd_transmit_complete(chip->tcpm_port, TCPC_TX_SUCCESS);
+ else
+ tcpm_pd_receive(chip->tcpm_port, msg);
+
return ret;
}
@@ -1659,13 +1674,12 @@ static irqreturn_t fusb302_irq_intn(int
if (interrupta & FUSB_REG_INTERRUPTA_TX_SUCCESS) {
fusb302_log(chip, "IRQ: PD tx success");
- /* read out the received good CRC */
ret = fusb302_pd_read_message(chip, &pd_msg);
if (ret < 0) {
- fusb302_log(chip, "cannot read in GCRC, ret=%d", ret);
+ fusb302_log(chip,
+ "cannot read in PD message, ret=%d", ret);
goto done;
}
- tcpm_pd_transmit_complete(chip->tcpm_port, TCPC_TX_SUCCESS);
}
if (interrupta & FUSB_REG_INTERRUPTA_HARDRESET) {
@@ -1686,7 +1700,6 @@ static irqreturn_t fusb302_irq_intn(int
"cannot read in PD message, ret=%d", ret);
goto done;
}
- tcpm_pd_receive(chip->tcpm_port, &pd_msg);
}
done:
mutex_unlock(&chip->lock);
Patches currently in stable-queue which might be from Adam.Thomson.Opensource(a)diasemi.com are
queue-4.14/typec-tcpm-fusb302-resolve-out-of-order-messaging-events.patch
This is a note to let you know that I've just added the patch titled
tools/usbip: fixes build with musl libc toolchain
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:
tools-usbip-fixes-build-with-musl-libc-toolchain.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 Fri Mar 16 15:43:17 CET 2018
From: Julien BOIBESSOT <julien.boibessot(a)armadeus.com>
Date: Tue, 5 Dec 2017 18:48:14 +0100
Subject: tools/usbip: fixes build with musl libc toolchain
From: Julien BOIBESSOT <julien.boibessot(a)armadeus.com>
[ Upstream commit 77be4c878c72e411ad22af96b6f81dd45c26450a ]
Indeed musl doesn't define old SIGCLD signal name but only new one SIGCHLD.
SIGCHLD is the new POSIX name for that signal so it doesn't change
anything on other libcs.
This fixes this kind of build error:
usbipd.c: In function ‘set_signal’:
usbipd.c:459:12: error: 'SIGCLD' undeclared (first use in this function)
sigaction(SIGCLD, &act, NULL);
^~~~~~
usbipd.c:459:12: note: each undeclared identifier is reported only once
for each function it appears in
Makefile:407: recipe for target 'usbipd.o' failed
make[3]: *** [usbipd.o] Error 1
Signed-off-by: Julien BOIBESSOT <julien.boibessot(a)armadeus.com>
Acked-by: Shuah Khan <shuahkh(a)osg.samsung.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>
---
tools/usb/usbip/src/usbipd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/tools/usb/usbip/src/usbipd.c
+++ b/tools/usb/usbip/src/usbipd.c
@@ -456,7 +456,7 @@ static void set_signal(void)
sigaction(SIGTERM, &act, NULL);
sigaction(SIGINT, &act, NULL);
act.sa_handler = SIG_IGN;
- sigaction(SIGCLD, &act, NULL);
+ sigaction(SIGCHLD, &act, NULL);
}
static const char *pid_file;
Patches currently in stable-queue which might be from julien.boibessot(a)armadeus.com are
queue-4.14/tools-usbip-fixes-build-with-musl-libc-toolchain.patch
This is a note to let you know that I've just added the patch titled
test_firmware: fix setting old custom fw path back on exit
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:
test_firmware-fix-setting-old-custom-fw-path-back-on-exit.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 Fri Mar 16 15:43:17 CET 2018
From: "Luis R. Rodriguez" <mcgrof(a)kernel.org>
Date: Mon, 20 Nov 2017 09:45:35 -0800
Subject: test_firmware: fix setting old custom fw path back on exit
From: "Luis R. Rodriguez" <mcgrof(a)kernel.org>
[ Upstream commit 65c79230576873b312c3599479c1e42355c9f349 ]
The file /sys/module/firmware_class/parameters/path can be used
to set a custom firmware path. The fw_filesystem.sh script creates
a temporary directory to add a test firmware file to be used during
testing, in order for this to work it uses the custom path syfs file
and it was supposed to reset back the file on execution exit. The
script failed to do this due to a typo, it was using OLD_PATH instead
of OLD_FWPATH, since its inception since v3.17.
Its not as easy to just keep the old setting, it turns out that
resetting an empty setting won't actually do what we want, we need
to check if it was empty and set an empty space.
Without this we end up having the temporary path always set after
we run these tests.
Fixes: 0a8adf58475 ("test: add firmware_class loader test")
Signed-off-by: Luis R. Rodriguez <mcgrof(a)kernel.org>
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>
---
tools/testing/selftests/firmware/fw_filesystem.sh | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/tools/testing/selftests/firmware/fw_filesystem.sh
+++ b/tools/testing/selftests/firmware/fw_filesystem.sh
@@ -45,7 +45,10 @@ test_finish()
if [ "$HAS_FW_LOADER_USER_HELPER" = "yes" ]; then
echo "$OLD_TIMEOUT" >/sys/class/firmware/timeout
fi
- echo -n "$OLD_PATH" >/sys/module/firmware_class/parameters/path
+ if [ "$OLD_FWPATH" = "" ]; then
+ OLD_FWPATH=" "
+ fi
+ echo -n "$OLD_FWPATH" >/sys/module/firmware_class/parameters/path
rm -f "$FW"
rmdir "$FWPATH"
}
Patches currently in stable-queue which might be from mcgrof(a)kernel.org are
queue-4.14/test_firmware-fix-setting-old-custom-fw-path-back-on-exit.patch
This is a note to let you know that I've just added the patch titled
staging: rtl8822be: fix missing null check on dev_alloc_skb return
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:
staging-rtl8822be-fix-missing-null-check-on-dev_alloc_skb-return.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 Fri Mar 16 15:43:16 CET 2018
From: Colin Ian King <colin.king(a)canonical.com>
Date: Fri, 17 Nov 2017 14:50:55 +0000
Subject: staging: rtl8822be: fix missing null check on dev_alloc_skb return
From: Colin Ian King <colin.king(a)canonical.com>
[ Upstream commit 3eb23426e1749a0483bc4c9b18e51f657569e3ed ]
dev_alloc_skb can potentially return NULL, so add a null check to
avoid a null pointer dereference on skb
Detected by CoverityScan, CID#1454558 ("Dereference on null return")
Fixes: 7e5b796cde7e ("staging: r8822be: Add the driver code")
Signed-off-by: Colin Ian King <colin.king(a)canonical.com>
Acked-by: Larry Finger <Larry.Finger(a)lwfinger.net>
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/rtlwifi/rtl8822be/fw.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/staging/rtlwifi/rtl8822be/fw.c
+++ b/drivers/staging/rtlwifi/rtl8822be/fw.c
@@ -464,6 +464,8 @@ bool rtl8822b_halmac_cb_write_data_rsvd_
int count;
skb = dev_alloc_skb(size);
+ if (!skb)
+ return false;
memcpy((u8 *)skb_put(skb, size), buf, size);
if (!_rtl8822be_send_bcn_or_cmd_packet(rtlpriv->hw, skb, BEACON_QUEUE))
Patches currently in stable-queue which might be from colin.king(a)canonical.com are
queue-4.14/usbip-vudc-fix-null-pointer-dereference-on-udc-lock.patch
queue-4.14/crypto-cavium-fix-memory-leak-on-info.patch
queue-4.14/staging-rtl8822be-fix-missing-null-check-on-dev_alloc_skb-return.patch
This is a note to let you know that I've just added the patch titled
spi: sun6i: disable/unprepare clocks on remove
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:
spi-sun6i-disable-unprepare-clocks-on-remove.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 Fri Mar 16 15:43:17 CET 2018
From: Tobias Jordan <Tobias.Jordan(a)elektrobit.com>
Date: Thu, 7 Dec 2017 15:04:53 +0100
Subject: spi: sun6i: disable/unprepare clocks on remove
From: Tobias Jordan <Tobias.Jordan(a)elektrobit.com>
[ Upstream commit 2d9bbd02c54094ceffa555143b0d68cd06504d63 ]
sun6i_spi_probe() uses sun6i_spi_runtime_resume() to prepare/enable
clocks, so sun6i_spi_remove() should use sun6i_spi_runtime_suspend() to
disable/unprepare them if we're not suspended.
Replacing pm_runtime_disable() by pm_runtime_force_suspend() will ensure
that sun6i_spi_runtime_suspend() is called if needed.
Found by Linux Driver Verification project (linuxtesting.org).
Fixes: 3558fe900e8af (spi: sunxi: Add Allwinner A31 SPI controller driver)
Signed-off-by: Tobias Jordan <Tobias.Jordan(a)elektrobit.com>
Acked-by: Maxime Ripard <maxime.ripard(a)free-electrons.com>
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-sun6i.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/spi/spi-sun6i.c
+++ b/drivers/spi/spi-sun6i.c
@@ -541,7 +541,7 @@ err_free_master:
static int sun6i_spi_remove(struct platform_device *pdev)
{
- pm_runtime_disable(&pdev->dev);
+ pm_runtime_force_suspend(&pdev->dev);
return 0;
}
Patches currently in stable-queue which might be from Tobias.Jordan(a)elektrobit.com are
queue-4.14/spi-sun6i-disable-unprepare-clocks-on-remove.patch
This is a note to let you know that I've just added the patch titled
scsi: ses: don't ask for diagnostic pages repeatedly during probe
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:
scsi-ses-don-t-ask-for-diagnostic-pages-repeatedly-during-probe.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 Fri Mar 16 15:43:17 CET 2018
From: Li Dongyang <dongyang.li(a)anu.edu.au>
Date: Tue, 14 Nov 2017 10:48:04 +1100
Subject: scsi: ses: don't ask for diagnostic pages repeatedly during probe
From: Li Dongyang <dongyang.li(a)anu.edu.au>
[ Upstream commit 9c0a50022b8ac7e863e6ec8342fa476fe5d1d75c ]
We are testing if there is a match with the ses device in a loop by
calling ses_match_to_enclosure(), which will issue scsi receive
diagnostics commands to the ses device for every device on the same
host. On one of our boxes with 840 disks, it takes a long time to load
the driver:
[root@g1b-oss06 ~]# time modprobe ses
real 40m48.247s
user 0m0.001s
sys 0m0.196s
With the patch:
[root@g1b-oss06 ~]# time modprobe ses
real 0m17.915s
user 0m0.008s
sys 0m0.053s
Note that we still need to refresh page 10 when we see a new disk to
create the link.
Signed-off-by: Li Dongyang <dongyang.li(a)anu.edu.au>
Tested-by: Jason Ozolins <jason.ozolins(a)hpe.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/ses.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
--- a/drivers/scsi/ses.c
+++ b/drivers/scsi/ses.c
@@ -615,13 +615,16 @@ static void ses_enclosure_data_process(s
}
static void ses_match_to_enclosure(struct enclosure_device *edev,
- struct scsi_device *sdev)
+ struct scsi_device *sdev,
+ int refresh)
{
+ struct scsi_device *edev_sdev = to_scsi_device(edev->edev.parent);
struct efd efd = {
.addr = 0,
};
- ses_enclosure_data_process(edev, to_scsi_device(edev->edev.parent), 0);
+ if (refresh)
+ ses_enclosure_data_process(edev, edev_sdev, 0);
if (scsi_is_sas_rphy(sdev->sdev_target->dev.parent))
efd.addr = sas_get_address(sdev);
@@ -652,7 +655,7 @@ static int ses_intf_add(struct device *c
struct enclosure_device *prev = NULL;
while ((edev = enclosure_find(&sdev->host->shost_gendev, prev)) != NULL) {
- ses_match_to_enclosure(edev, sdev);
+ ses_match_to_enclosure(edev, sdev, 1);
prev = edev;
}
return -ENODEV;
@@ -768,7 +771,7 @@ page2_not_supported:
shost_for_each_device(tmp_sdev, sdev->host) {
if (tmp_sdev->lun != 0 || scsi_device_enclosure(tmp_sdev))
continue;
- ses_match_to_enclosure(edev, tmp_sdev);
+ ses_match_to_enclosure(edev, tmp_sdev, 0);
}
return 0;
Patches currently in stable-queue which might be from dongyang.li(a)anu.edu.au are
queue-4.14/scsi-ses-don-t-ask-for-diagnostic-pages-repeatedly-during-probe.patch
This is a note to let you know that I've just added the patch titled
scsi: dh: add new rdac devices
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:
scsi-dh-add-new-rdac-devices.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 Fri Mar 16 15:43:17 CET 2018
From: Xose Vazquez Perez <xose.vazquez(a)gmail.com>
Date: Fri, 17 Nov 2017 22:05:13 +0100
Subject: scsi: dh: add new rdac devices
From: Xose Vazquez Perez <xose.vazquez(a)gmail.com>
[ Upstream commit 4b3aec2bbbce1c35f50e7475a9fd78d24b9ea4ea ]
Add IBM 3542 and 3552, arrays: FAStT200 and FAStT500.
Add full STK OPENstorage family, arrays: 9176, D173, D178, D210, D220,
D240 and D280.
Add STK BladeCtlr family, arrays: B210, B220, B240 and B280.
These changes were done in multipath-tools time ago.
Cc: NetApp RDAC team <ng-eseries-upstream-maintainers(a)netapp.com>
Cc: Hannes Reinecke <hare(a)suse.de>
Cc: Christophe Varoqui <christophe.varoqui(a)opensvc.com>
Cc: Martin K. Petersen <martin.petersen(a)oracle.com>
Cc: James E.J. Bottomley <jejb(a)linux.vnet.ibm.com>
Cc: SCSI ML <linux-scsi(a)vger.kernel.org>
Cc: device-mapper development <dm-devel(a)redhat.com>
Signed-off-by: Xose Vazquez Perez <xose.vazquez(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/scsi_dh.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/scsi/scsi_dh.c
+++ b/drivers/scsi/scsi_dh.c
@@ -56,10 +56,13 @@ static const struct scsi_dh_blist scsi_d
{"IBM", "1815", "rdac", },
{"IBM", "1818", "rdac", },
{"IBM", "3526", "rdac", },
+ {"IBM", "3542", "rdac", },
+ {"IBM", "3552", "rdac", },
{"SGI", "TP9", "rdac", },
{"SGI", "IS", "rdac", },
- {"STK", "OPENstorage D280", "rdac", },
+ {"STK", "OPENstorage", "rdac", },
{"STK", "FLEXLINE 380", "rdac", },
+ {"STK", "BladeCtlr", "rdac", },
{"SUN", "CSM", "rdac", },
{"SUN", "LCSM100", "rdac", },
{"SUN", "STK6580_6780", "rdac", },
Patches currently in stable-queue which might be from xose.vazquez(a)gmail.com are
queue-4.14/scsi-devinfo-apply-to-hp-xp-the-same-flags-as-hitachi-vsp.patch
queue-4.14/scsi-dh-add-new-rdac-devices.patch
This is a note to let you know that I've just added the patch titled
scsi: devinfo: apply to HP XP the same flags as Hitachi VSP
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:
scsi-devinfo-apply-to-hp-xp-the-same-flags-as-hitachi-vsp.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 Fri Mar 16 15:43:17 CET 2018
From: Xose Vazquez Perez <xose.vazquez(a)gmail.com>
Date: Fri, 17 Nov 2017 21:31:36 +0100
Subject: scsi: devinfo: apply to HP XP the same flags as Hitachi VSP
From: Xose Vazquez Perez <xose.vazquez(a)gmail.com>
[ Upstream commit b369a0471503130cfc74f9f62071db97f48948c3 ]
Commit 56f3d383f37b ("scsi: scsi_devinfo: Add TRY_VPD_PAGES to HITACHI
OPEN-V blacklist entry") modified some Hitachi entries:
HITACHI is always supporting VPD pages, even though it's claiming to
support SCSI Revision 3 only.
The same should have been done also for HP-rebranded.
[mkp: checkpatch and tweaked commit message]
Cc: Hannes Reinecke <hare(a)suse.de>
Cc: Takahiro Yasui <takahiro.yasui(a)hds.com>
Cc: Matthias Rudolph <Matthias.Rudolph(a)hitachivantara.com>
Cc: Martin K. Petersen <martin.petersen(a)oracle.com>
Cc: James E.J. Bottomley <jejb(a)linux.vnet.ibm.com>
Cc: SCSI ML <linux-scsi(a)vger.kernel.org>
Signed-off-by: Xose Vazquez Perez <xose.vazquez(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/scsi_devinfo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/scsi/scsi_devinfo.c
+++ b/drivers/scsi/scsi_devinfo.c
@@ -181,7 +181,7 @@ static struct {
{"HITACHI", "6586-", "*", BLIST_SPARSELUN | BLIST_LARGELUN},
{"HITACHI", "6588-", "*", BLIST_SPARSELUN | BLIST_LARGELUN},
{"HP", "A6189A", NULL, BLIST_SPARSELUN | BLIST_LARGELUN}, /* HP VA7400 */
- {"HP", "OPEN-", "*", BLIST_REPORTLUN2}, /* HP XP Arrays */
+ {"HP", "OPEN-", "*", BLIST_REPORTLUN2 | BLIST_TRY_VPD_PAGES}, /* HP XP Arrays */
{"HP", "NetRAID-4M", NULL, BLIST_FORCELUN},
{"HP", "HSV100", NULL, BLIST_REPORTLUN2 | BLIST_NOSTARTONADD},
{"HP", "C1557A", NULL, BLIST_FORCELUN},
Patches currently in stable-queue which might be from xose.vazquez(a)gmail.com are
queue-4.14/scsi-devinfo-apply-to-hp-xp-the-same-flags-as-hitachi-vsp.patch
queue-4.14/scsi-dh-add-new-rdac-devices.patch
This is a note to let you know that I've just added the patch titled
scsi: core: scsi_get_device_flags_keyed(): Always return device flags
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:
scsi-core-scsi_get_device_flags_keyed-always-return-device-flags.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 Fri Mar 16 15:43:17 CET 2018
From: Bart Van Assche <bart.vanassche(a)wdc.com>
Date: Mon, 4 Dec 2017 10:36:31 -0800
Subject: scsi: core: scsi_get_device_flags_keyed(): Always return device flags
From: Bart Van Assche <bart.vanassche(a)wdc.com>
[ Upstream commit a44c9d36509c83cf64f33b93f6ab2e63822c01eb ]
Since scsi_get_device_flags_keyed() callers do not check whether or not
the returned value is an error code, change that function such that it
returns a flags value even if the 'key' argument is invalid. Note:
since commit 28a0bc4120d3 ("scsi: sd: Implement blacklist option for
WRITE SAME w/ UNMAP") bit 31 is a valid device information flag so
checking whether bit 31 is set in the return value is not sufficient to
tell the difference between an error code and a flags value.
Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: Hannes Reinecke <hare(a)suse.com>
Cc: Johannes Thumshirn <jthumshirn(a)suse.de>
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/scsi_devinfo.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
--- a/drivers/scsi/scsi_devinfo.c
+++ b/drivers/scsi/scsi_devinfo.c
@@ -595,17 +595,12 @@ int scsi_get_device_flags_keyed(struct s
int key)
{
struct scsi_dev_info_list *devinfo;
- int err;
devinfo = scsi_dev_info_list_find(vendor, model, key);
if (!IS_ERR(devinfo))
return devinfo->flags;
- err = PTR_ERR(devinfo);
- if (err != -ENOENT)
- return err;
-
- /* nothing found, return nothing */
+ /* key or device not found: return nothing */
if (key != SCSI_DEVINFO_GLOBAL)
return 0;
Patches currently in stable-queue which might be from bart.vanassche(a)wdc.com are
queue-4.14/scsi-core-scsi_get_device_flags_keyed-always-return-device-flags.patch