- Linux-stable-mirror - lists.linaro.org

[Linux-stable-mirror] patch "USB: Fix off by one in type-specific length check of BOS SSP" added to usb-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: Fix off by one in type-specific length check of BOS SSP to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 07b9f12864d16c3a861aef4817eb1efccbc5d0e6 Mon Sep 17 00:00:00 2001 From: Mathias Nyman <mathias.nyman(a)linux.intel.com> Date: Tue, 19 Dec 2017 11:14:42 +0200 Subject: USB: Fix off by one in type-specific length check of BOS SSP capability USB 3.1 devices are not detected as 3.1 capable since 4.15-rc3 due to a off by one in commit 81cf4a45360f ("USB: core: Add type-specific length check of BOS descriptors") It uses USB_DT_USB_SSP_CAP_SIZE() to get SSP capability size which takes the zero based SSAC as argument, not the actual count of sublink speed attributes. USB3 spec 9.6.2.5 says "The number of Sublink Speed Attributes = SSAC + 1." The type-specific length check patch was added to stable and needs to be fixed there as well Fixes: 81cf4a45360f ("USB: core: Add type-specific length check of BOS descriptors") Cc: linux-stable <stable(a)vger.kernel.org> CC: Masakazu Mokuno <masakazu.mokuno(a)gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/core/config.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c index 78e92d29f8d9..c821b4b9647e 100644 --- a/drivers/usb/core/config.c +++ b/drivers/usb/core/config.c @@ -1007,7 +1007,7 @@ int usb_get_bos_descriptor(struct usb_device *dev) case USB_SSP_CAP_TYPE: ssp_cap = (struct usb_ssp_cap_descriptor *)buffer; ssac = (le32_to_cpu(ssp_cap->bmAttributes) & - USB_SSP_SUBLINK_SPEED_ATTRIBS) + 1; + USB_SSP_SUBLINK_SPEED_ATTRIBS); if (length >= USB_DT_USB_SSP_CAP_SIZE(ssac)) dev->bos->ssp_cap = ssp_cap; break; -- 2.15.1

7 years, 8 months

1
0
0 0

[Linux-stable-mirror] patch "usbip: vhci: stop printing kernel pointer addresses in messages" added to usb-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usbip: vhci: stop printing kernel pointer addresses in messages to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 8272d099d05f7ab2776cf56a2ab9f9443be18907 Mon Sep 17 00:00:00 2001 From: Shuah Khan <shuahkh(a)osg.samsung.com> Date: Mon, 18 Dec 2017 17:24:22 -0700 Subject: usbip: vhci: stop printing kernel pointer addresses in messages Remove and/or change debug, info. and error messages to not print kernel pointer addresses. Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com> Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/usbip/vhci_hcd.c | 10 ---------- drivers/usb/usbip/vhci_rx.c | 23 +++++++++++------------ drivers/usb/usbip/vhci_tx.c | 3 ++- 3 files changed, 13 insertions(+), 23 deletions(-) diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c index 6b3278c4b72a..9efab3dc3734 100644 --- a/drivers/usb/usbip/vhci_hcd.c +++ b/drivers/usb/usbip/vhci_hcd.c @@ -656,9 +656,6 @@ static int vhci_urb_enqueue(struct usb_hcd *hcd, struct urb *urb, gfp_t mem_flag struct vhci_device *vdev; unsigned long flags; - usbip_dbg_vhci_hc("enter, usb_hcd %p urb %p mem_flags %d\n", - hcd, urb, mem_flags); - if (portnum > VHCI_HC_PORTS) { pr_err("invalid port number %d\n", portnum); return -ENODEV; @@ -822,8 +819,6 @@ static int vhci_urb_dequeue(struct usb_hcd *hcd, struct urb *urb, int status) struct vhci_device *vdev; unsigned long flags; - pr_info("dequeue a urb %p\n", urb); - spin_lock_irqsave(&vhci->lock, flags); priv = urb->hcpriv; @@ -851,7 +846,6 @@ static int vhci_urb_dequeue(struct usb_hcd *hcd, struct urb *urb, int status) /* tcp connection is closed */ spin_lock(&vdev->priv_lock); - pr_info("device %p seems to be disconnected\n", vdev); list_del(&priv->list); kfree(priv); urb->hcpriv = NULL; @@ -863,8 +857,6 @@ static int vhci_urb_dequeue(struct usb_hcd *hcd, struct urb *urb, int status) * vhci_rx will receive RET_UNLINK and give back the URB. * Otherwise, we give back it here. */ - pr_info("gives back urb %p\n", urb); - usb_hcd_unlink_urb_from_ep(hcd, urb); spin_unlock_irqrestore(&vhci->lock, flags); @@ -892,8 +884,6 @@ static int vhci_urb_dequeue(struct usb_hcd *hcd, struct urb *urb, int status) unlink->unlink_seqnum = priv->seqnum; - pr_info("device %p seems to be still connected\n", vdev); - /* send cmd_unlink and try to cancel the pending URB in the * peer */ list_add_tail(&unlink->list, &vdev->unlink_tx); diff --git a/drivers/usb/usbip/vhci_rx.c b/drivers/usb/usbip/vhci_rx.c index 90577e8b2282..112ebb90d8c9 100644 --- a/drivers/usb/usbip/vhci_rx.c +++ b/drivers/usb/usbip/vhci_rx.c @@ -23,24 +23,23 @@ struct urb *pickup_urb_and_free_priv(struct vhci_device *vdev, __u32 seqnum) urb = priv->urb; status = urb->status; - usbip_dbg_vhci_rx("find urb %p vurb %p seqnum %u\n", - urb, priv, seqnum); + usbip_dbg_vhci_rx("find urb seqnum %u\n", seqnum); switch (status) { case -ENOENT: /* fall through */ case -ECONNRESET: - dev_info(&urb->dev->dev, - "urb %p was unlinked %ssynchronuously.\n", urb, - status == -ENOENT ? "" : "a"); + dev_dbg(&urb->dev->dev, + "urb seq# %u was unlinked %ssynchronuously\n", + seqnum, status == -ENOENT ? "" : "a"); break; case -EINPROGRESS: /* no info output */ break; default: - dev_info(&urb->dev->dev, - "urb %p may be in a error, status %d\n", urb, - status); + dev_dbg(&urb->dev->dev, + "urb seq# %u may be in a error, status %d\n", + seqnum, status); } list_del(&priv->list); @@ -67,8 +66,8 @@ static void vhci_recv_ret_submit(struct vhci_device *vdev, spin_unlock_irqrestore(&vdev->priv_lock, flags); if (!urb) { - pr_err("cannot find a urb of seqnum %u\n", pdu->base.seqnum); - pr_info("max seqnum %d\n", + pr_err("cannot find a urb of seqnum %u max seqnum %d\n", + pdu->base.seqnum, atomic_read(&vhci_hcd->seqnum)); usbip_event_add(ud, VDEV_EVENT_ERROR_TCP); return; @@ -91,7 +90,7 @@ static void vhci_recv_ret_submit(struct vhci_device *vdev, if (usbip_dbg_flag_vhci_rx) usbip_dump_urb(urb); - usbip_dbg_vhci_rx("now giveback urb %p\n", urb); + usbip_dbg_vhci_rx("now giveback urb %u\n", pdu->base.seqnum); spin_lock_irqsave(&vhci->lock, flags); usb_hcd_unlink_urb_from_ep(vhci_hcd_to_hcd(vhci_hcd), urb); @@ -158,7 +157,7 @@ static void vhci_recv_ret_unlink(struct vhci_device *vdev, pr_info("the urb (seqnum %d) was already given back\n", pdu->base.seqnum); } else { - usbip_dbg_vhci_rx("now giveback urb %p\n", urb); + usbip_dbg_vhci_rx("now giveback urb %d\n", pdu->base.seqnum); /* If unlink is successful, status is -ECONNRESET */ urb->status = pdu->u.ret_unlink.status; diff --git a/drivers/usb/usbip/vhci_tx.c b/drivers/usb/usbip/vhci_tx.c index d625a2ff4b71..9aed15a358b7 100644 --- a/drivers/usb/usbip/vhci_tx.c +++ b/drivers/usb/usbip/vhci_tx.c @@ -69,7 +69,8 @@ static int vhci_send_cmd_submit(struct vhci_device *vdev) memset(&msg, 0, sizeof(msg)); memset(&iov, 0, sizeof(iov)); - usbip_dbg_vhci_tx("setup txdata urb %p\n", urb); + usbip_dbg_vhci_tx("setup txdata urb seqnum %lu\n", + priv->seqnum); /* 1. setup usbip_header */ setup_cmd_submit_pdu(&pdu_header, urb); -- 2.15.1

7 years, 8 months

1
0
0 0

[Linux-stable-mirror] patch "phy: tegra: fix device-tree node lookups" added to usb-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled phy: tegra: fix device-tree node lookups to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 046046737bd35bed047460f080ea47e186be731e Mon Sep 17 00:00:00 2001 From: Johan Hovold <johan(a)kernel.org> Date: Wed, 15 Nov 2017 10:43:16 +0100 Subject: phy: tegra: fix device-tree node lookups Fix child-node lookups during probe, which ended up searching the whole device tree depth-first starting at the parents rather than just matching on their children. To make things worse, some parent nodes could end up being being prematurely freed (by tegra_xusb_pad_register()) as of_find_node_by_name() drops a reference to its first argument. Fixes: 53d2a715c240 ("phy: Add Tegra XUSB pad controller support") Cc: stable <stable(a)vger.kernel.org> # 4.7 Cc: Thierry Reding <treding(a)nvidia.com> Signed-off-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Kishon Vijay Abraham I <kishon(a)ti.com> --- drivers/phy/tegra/xusb.c | 58 ++++++++++++++++++++++++------------------------ 1 file changed, 29 insertions(+), 29 deletions(-) diff --git a/drivers/phy/tegra/xusb.c b/drivers/phy/tegra/xusb.c index 4307bf0013e1..63e916d4d069 100644 --- a/drivers/phy/tegra/xusb.c +++ b/drivers/phy/tegra/xusb.c @@ -75,14 +75,14 @@ MODULE_DEVICE_TABLE(of, tegra_xusb_padctl_of_match); static struct device_node * tegra_xusb_find_pad_node(struct tegra_xusb_padctl *padctl, const char *name) { - /* - * of_find_node_by_name() drops a reference, so make sure to grab one. - */ - struct device_node *np = of_node_get(padctl->dev->of_node); + struct device_node *pads, *np; + + pads = of_get_child_by_name(padctl->dev->of_node, "pads"); + if (!pads) + return NULL; - np = of_find_node_by_name(np, "pads"); - if (np) - np = of_find_node_by_name(np, name); + np = of_get_child_by_name(pads, name); + of_node_put(pads); return np; } @@ -90,16 +90,16 @@ tegra_xusb_find_pad_node(struct tegra_xusb_padctl *padctl, const char *name) static struct device_node * tegra_xusb_pad_find_phy_node(struct tegra_xusb_pad *pad, unsigned int index) { - /* - * of_find_node_by_name() drops a reference, so make sure to grab one. - */ - struct device_node *np = of_node_get(pad->dev.of_node); + struct device_node *np, *lanes; - np = of_find_node_by_name(np, "lanes"); - if (!np) + lanes = of_get_child_by_name(pad->dev.of_node, "lanes"); + if (!lanes) return NULL; - return of_find_node_by_name(np, pad->soc->lanes[index].name); + np = of_get_child_by_name(lanes, pad->soc->lanes[index].name); + of_node_put(lanes); + + return np; } static int @@ -195,7 +195,7 @@ int tegra_xusb_pad_register(struct tegra_xusb_pad *pad, unsigned int i; int err; - children = of_find_node_by_name(pad->dev.of_node, "lanes"); + children = of_get_child_by_name(pad->dev.of_node, "lanes"); if (!children) return -ENODEV; @@ -444,21 +444,21 @@ static struct device_node * tegra_xusb_find_port_node(struct tegra_xusb_padctl *padctl, const char *type, unsigned int index) { - /* - * of_find_node_by_name() drops a reference, so make sure to grab one. - */ - struct device_node *np = of_node_get(padctl->dev->of_node); + struct device_node *ports, *np; + char *name; - np = of_find_node_by_name(np, "ports"); - if (np) { - char *name; + ports = of_get_child_by_name(padctl->dev->of_node, "ports"); + if (!ports) + return NULL; - name = kasprintf(GFP_KERNEL, "%s-%u", type, index); - if (!name) - return ERR_PTR(-ENOMEM); - np = of_find_node_by_name(np, name); - kfree(name); + name = kasprintf(GFP_KERNEL, "%s-%u", type, index); + if (!name) { + of_node_put(ports); + return ERR_PTR(-ENOMEM); } + np = of_get_child_by_name(ports, name); + kfree(name); + of_node_put(ports); return np; } @@ -847,7 +847,7 @@ static void tegra_xusb_remove_ports(struct tegra_xusb_padctl *padctl) static int tegra_xusb_padctl_probe(struct platform_device *pdev) { - struct device_node *np = of_node_get(pdev->dev.of_node); + struct device_node *np = pdev->dev.of_node; const struct tegra_xusb_padctl_soc *soc; struct tegra_xusb_padctl *padctl; const struct of_device_id *match; @@ -855,7 +855,7 @@ static int tegra_xusb_padctl_probe(struct platform_device *pdev) int err; /* for backwards compatibility with old device trees */ - np = of_find_node_by_name(np, "pads"); + np = of_get_child_by_name(np, "pads"); if (!np) { dev_warn(&pdev->dev, "deprecated DT, using legacy driver\n"); return tegra_xusb_padctl_legacy_probe(pdev); -- 2.15.1

7 years, 8 months

1
0
0 0

[Linux-stable-mirror] [PATCH] fscache: Fix the default for fscache_maybe_release_page()

by David Howells

Fix the default for fscache_maybe_release_page() for when the cookie isn't valid or the page isn't cached. It mustn't return false as that indicates the page cannot yet be freed. The problem with the default is that if, say, there's no cache, but a network filesystem's pages are using up almost all the available memory, a system can OOM because the filesystem ->releasepage() op will not allow them to be released as fscache_maybe_release_page() incorrectly prevents it. This can be tested by writing a sequence of 512MiB files to an AFS mount. It does not affect NFS or CIFS because both of those wrap the call in a check of PG_fscache and it shouldn't bother Ceph as that only has PG_private set whilst writeback is in progress. This might be an issue for 9P, however. Note that the pages aren't entirely stuck. Removing a file or unmounting will clear things because that uses ->invalidatepage() instead. Fixes: 201a15428bd5 ("FS-Cache: Handle pages pending storage that get evicted under OOM conditions") Reported-by: Marc Dionne <marc.dionne(a)auristor.com> Signed-off-by: David Howells <dhowells(a)redhat.com> Reviewed-by: Jeff Layton <jlayton(a)redhat.com> Acked-by: Al Viro <viro(a)zeniv.linux.org.uk> cc: stable(a)vger.kernel.org # 2.6.32+ --- include/linux/fscache.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/fscache.h b/include/linux/fscache.h index f4ff47d4a893..fe0c349684fa 100644 --- a/include/linux/fscache.h +++ b/include/linux/fscache.h @@ -755,7 +755,7 @@ bool fscache_maybe_release_page(struct fscache_cookie *cookie, { if (fscache_cookie_valid(cookie) && PageFsCache(page)) return __fscache_maybe_release_page(cookie, page, gfp); - return false; + return true; } /**

7 years, 8 months

1
0
0 0

[Linux-stable-mirror] [PATCH] fscache: Fix the default for fscache_maybe_release_page()

by David Howells

Fix the default for fscache_maybe_release_page() for when the cookie isn't valid or the page isn't cached. It mustn't return false as that indicates the page cannot yet be freed. The problem with the default is that if, say, there's no cache, but a network filesystem's pages are using up almost all the available memory, a system can OOM because the filesystem ->releasepage() op will not allow them to be released as fscache_maybe_release_page() incorrectly prevents it. This can be tested by writing a sequence of 512MiB files to an AFS mount. It does not affect NFS or CIFS because both of those wrap the call in a check of PG_fscache and it shouldn't bother Ceph as that only has PG_private set whilst writeback is in progress. This might be an issue for 9P, however. Note that the pages aren't entirely stuck. Removing a file or unmounting will clear things because that uses ->invalidatepage() instead. Fixes: 201a15428bd5 ("FS-Cache: Handle pages pending storage that get evicted under OOM conditions") Reported-by: Marc Dionne <marc.dionne(a)auristor.com> Signed-off-by: David Howells <dhowells(a)redhat.com> Reviewed-by: Jeff Layton <jlayton(a)redhat.com> Acked-by: Al Viro <viro(a)zeniv.linux.org.uk> cc: stable(a)vger.kernel.org # 2.6.32+ --- include/linux/fscache.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/fscache.h b/include/linux/fscache.h index f4ff47d4a893..fe0c349684fa 100644 --- a/include/linux/fscache.h +++ b/include/linux/fscache.h @@ -755,7 +755,7 @@ bool fscache_maybe_release_page(struct fscache_cookie *cookie, { if (fscache_cookie_valid(cookie) && PageFsCache(page)) return __fscache_maybe_release_page(cookie, page, gfp); - return false; + return true; } /**

7 years, 8 months

1
0
0 0

[Linux-stable-mirror] [PATCH stable-queue] drop platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch

by alexander.levin＠verizon.com

Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> --- ...ix-error-handling-in-sony_nc_setup_rfkill.patch | 56 ---------------------- queue-3.18/series | 1 - ...ix-error-handling-in-sony_nc_setup_rfkill.patch | 56 ---------------------- queue-4.14/series | 1 - ...ix-error-handling-in-sony_nc_setup_rfkill.patch | 56 ---------------------- queue-4.4/series | 1 - ...ix-error-handling-in-sony_nc_setup_rfkill.patch | 56 ---------------------- queue-4.9/series | 1 - 8 files changed, 228 deletions(-) delete mode 100644 queue-3.18/platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch delete mode 100644 queue-4.14/platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch delete mode 100644 queue-4.4/platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch delete mode 100644 queue-4.9/platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch diff --git a/queue-3.18/platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch b/queue-3.18/platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch deleted file mode 100644 index 29eccbffe..000000000 --- a/queue-3.18/platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch +++ /dev/null @@ -1,56 +0,0 @@ -From foo@baz Mon Dec 18 15:03:25 CET 2017 -From: Markus Elfring <elfring(a)users.sourceforge.net> -Date: Wed, 1 Nov 2017 18:42:45 +0100 -Subject: platform/x86: sony-laptop: Fix error handling in sony_nc_setup_rfkill() - -From: Markus Elfring <elfring(a)users.sourceforge.net> - - -[ Upstream commit f6c8a317ab208aee223776327c06f23342492d54 ] - -Source code review for a specific software refactoring showed the need -for another correction because the error code "-1" was returned so far -if a call of the function "sony_call_snc_handle" failed here. -Thus assign the return value from these two function calls also to -the variable "err" and provide it in case of a failure. - -Fixes: d6f15ed876b83a1a0eba1d0473eef58acc95444a ("sony-laptop: use soft rfkill status stored in hw") -Suggested-by: Andy Shevchenko <andy.shevchenko(a)gmail.com> -Link: https://lkml.org/lkml/2017/10/31/463 -Link: https://lkml.kernel.org/r/<CAHp75VcMkXCioCzmLE0+BTmkqc5RSOx9yPO0ectVHMrMvewgwg(a)mail.gmail.com> -Signed-off-by: Markus Elfring <elfring(a)users.sourceforge.net> -Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> -Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> -Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> ---- - drivers/platform/x86/sony-laptop.c | 14 ++++++++------ - 1 file changed, 8 insertions(+), 6 deletions(-) - ---- a/drivers/platform/x86/sony-laptop.c -+++ b/drivers/platform/x86/sony-laptop.c -@@ -1654,17 +1654,19 @@ static int sony_nc_setup_rfkill(struct a - if (!rfk) - return -ENOMEM; - -- if (sony_call_snc_handle(sony_rfkill_handle, 0x200, &result) < 0) { -+ err = sony_call_snc_handle(sony_rfkill_handle, 0x200, &result); -+ if (err < 0) { - rfkill_destroy(rfk); -- return -1; -+ return err; - } - hwblock = !(result & 0x1); - -- if (sony_call_snc_handle(sony_rfkill_handle, -- sony_rfkill_address[nc_type], -- &result) < 0) { -+ err = sony_call_snc_handle(sony_rfkill_handle, -+ sony_rfkill_address[nc_type], -+ &result); -+ if (err < 0) { - rfkill_destroy(rfk); -- return -1; -+ return err; - } - swblock = !(result & 0x2); - diff --git a/queue-3.18/series b/queue-3.18/series index ed60ddbc4..8525d16ff 100644 --- a/queue-3.18/series +++ b/queue-3.18/series @@ -43,7 +43,6 @@ pci-pme-handle-invalid-data-when-reading-root-status.patch powerpc-powernv-cpufreq-fix-the-frequency-read-by-proc-cpuinfo.patch powerpc-opal-fix-ebusy-bug-in-acquiring-tokens.patch powerpc-ipic-fix-status-get-and-status-clear.patch -platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch target-iscsi-fix-a-race-condition-in-iscsit_add_reject_from_cmd.patch iscsi-target-fix-memory-leak-in-lio_target_tiqn_addtpg.patch target-fix-condition-return-in-core_pr_dump_initiator_port.patch diff --git a/queue-4.14/platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch b/queue-4.14/platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch deleted file mode 100644 index 80673c2e3..000000000 --- a/queue-4.14/platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch +++ /dev/null @@ -1,56 +0,0 @@ -From foo@baz Mon Dec 18 13:28:59 CET 2017 -From: Markus Elfring <elfring(a)users.sourceforge.net> -Date: Wed, 1 Nov 2017 18:42:45 +0100 -Subject: platform/x86: sony-laptop: Fix error handling in sony_nc_setup_rfkill() - -From: Markus Elfring <elfring(a)users.sourceforge.net> - - -[ Upstream commit f6c8a317ab208aee223776327c06f23342492d54 ] - -Source code review for a specific software refactoring showed the need -for another correction because the error code "-1" was returned so far -if a call of the function "sony_call_snc_handle" failed here. -Thus assign the return value from these two function calls also to -the variable "err" and provide it in case of a failure. - -Fixes: d6f15ed876b83a1a0eba1d0473eef58acc95444a ("sony-laptop: use soft rfkill status stored in hw") -Suggested-by: Andy Shevchenko <andy.shevchenko(a)gmail.com> -Link: https://lkml.org/lkml/2017/10/31/463 -Link: https://lkml.kernel.org/r/<CAHp75VcMkXCioCzmLE0+BTmkqc5RSOx9yPO0ectVHMrMvewgwg(a)mail.gmail.com> -Signed-off-by: Markus Elfring <elfring(a)users.sourceforge.net> -Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> -Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> -Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> ---- - drivers/platform/x86/sony-laptop.c | 14 ++++++++------ - 1 file changed, 8 insertions(+), 6 deletions(-) - ---- a/drivers/platform/x86/sony-laptop.c -+++ b/drivers/platform/x86/sony-laptop.c -@@ -1660,17 +1660,19 @@ static int sony_nc_setup_rfkill(struct a - if (!rfk) - return -ENOMEM; - -- if (sony_call_snc_handle(sony_rfkill_handle, 0x200, &result) < 0) { -+ err = sony_call_snc_handle(sony_rfkill_handle, 0x200, &result); -+ if (err < 0) { - rfkill_destroy(rfk); -- return -1; -+ return err; - } - hwblock = !(result & 0x1); - -- if (sony_call_snc_handle(sony_rfkill_handle, -- sony_rfkill_address[nc_type], -- &result) < 0) { -+ err = sony_call_snc_handle(sony_rfkill_handle, -+ sony_rfkill_address[nc_type], -+ &result); -+ if (err < 0) { - rfkill_destroy(rfk); -- return -1; -+ return err; - } - swblock = !(result & 0x2); - diff --git a/queue-4.14/series b/queue-4.14/series index 8d3089853..7e1d0f7a3 100644 --- a/queue-4.14/series +++ b/queue-4.14/series @@ -68,7 +68,6 @@ powerpc-opal-fix-ebusy-bug-in-acquiring-tokens.patch powerpc-ipic-fix-status-get-and-status-clear.patch powerpc-pseries-vio-dispose-of-virq-mapping-on-vdevice-unregister.patch platform-x86-intel_punit_ipc-fix-resource-ioremap-warning.patch -platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch target-iscsi-detect-conn_cmd_list-corruption-early.patch target-iscsi-fix-a-race-condition-in-iscsit_add_reject_from_cmd.patch iscsi-target-fix-memory-leak-in-lio_target_tiqn_addtpg.patch diff --git a/queue-4.4/platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch b/queue-4.4/platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch deleted file mode 100644 index 7dd8d3d60..000000000 --- a/queue-4.4/platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch +++ /dev/null @@ -1,56 +0,0 @@ -From foo@baz Mon Dec 18 14:47:43 CET 2017 -From: Markus Elfring <elfring(a)users.sourceforge.net> -Date: Wed, 1 Nov 2017 18:42:45 +0100 -Subject: platform/x86: sony-laptop: Fix error handling in sony_nc_setup_rfkill() - -From: Markus Elfring <elfring(a)users.sourceforge.net> - - -[ Upstream commit f6c8a317ab208aee223776327c06f23342492d54 ] - -Source code review for a specific software refactoring showed the need -for another correction because the error code "-1" was returned so far -if a call of the function "sony_call_snc_handle" failed here. -Thus assign the return value from these two function calls also to -the variable "err" and provide it in case of a failure. - -Fixes: d6f15ed876b83a1a0eba1d0473eef58acc95444a ("sony-laptop: use soft rfkill status stored in hw") -Suggested-by: Andy Shevchenko <andy.shevchenko(a)gmail.com> -Link: https://lkml.org/lkml/2017/10/31/463 -Link: https://lkml.kernel.org/r/<CAHp75VcMkXCioCzmLE0+BTmkqc5RSOx9yPO0ectVHMrMvewgwg(a)mail.gmail.com> -Signed-off-by: Markus Elfring <elfring(a)users.sourceforge.net> -Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> -Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> -Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> ---- - drivers/platform/x86/sony-laptop.c | 14 ++++++++------ - 1 file changed, 8 insertions(+), 6 deletions(-) - ---- a/drivers/platform/x86/sony-laptop.c -+++ b/drivers/platform/x86/sony-laptop.c -@@ -1655,17 +1655,19 @@ static int sony_nc_setup_rfkill(struct a - if (!rfk) - return -ENOMEM; - -- if (sony_call_snc_handle(sony_rfkill_handle, 0x200, &result) < 0) { -+ err = sony_call_snc_handle(sony_rfkill_handle, 0x200, &result); -+ if (err < 0) { - rfkill_destroy(rfk); -- return -1; -+ return err; - } - hwblock = !(result & 0x1); - -- if (sony_call_snc_handle(sony_rfkill_handle, -- sony_rfkill_address[nc_type], -- &result) < 0) { -+ err = sony_call_snc_handle(sony_rfkill_handle, -+ sony_rfkill_address[nc_type], -+ &result); -+ if (err < 0) { - rfkill_destroy(rfk); -- return -1; -+ return err; - } - swblock = !(result & 0x2); - diff --git a/queue-4.4/series b/queue-4.4/series index d52e15576..d1ebd64a3 100644 --- a/queue-4.4/series +++ b/queue-4.4/series @@ -76,7 +76,6 @@ powerpc-powernv-cpufreq-fix-the-frequency-read-by-proc-cpuinfo.patch netfilter-ipvs-fix-inappropriate-output-of-procfs.patch powerpc-opal-fix-ebusy-bug-in-acquiring-tokens.patch powerpc-ipic-fix-status-get-and-status-clear.patch -platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch target-iscsi-fix-a-race-condition-in-iscsit_add_reject_from_cmd.patch iscsi-target-fix-memory-leak-in-lio_target_tiqn_addtpg.patch target-fix-condition-return-in-core_pr_dump_initiator_port.patch diff --git a/queue-4.9/platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch b/queue-4.9/platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch deleted file mode 100644 index be1bf544f..000000000 --- a/queue-4.9/platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch +++ /dev/null @@ -1,56 +0,0 @@ -From foo@baz Mon Dec 18 14:12:35 CET 2017 -From: Markus Elfring <elfring(a)users.sourceforge.net> -Date: Wed, 1 Nov 2017 18:42:45 +0100 -Subject: platform/x86: sony-laptop: Fix error handling in sony_nc_setup_rfkill() - -From: Markus Elfring <elfring(a)users.sourceforge.net> - - -[ Upstream commit f6c8a317ab208aee223776327c06f23342492d54 ] - -Source code review for a specific software refactoring showed the need -for another correction because the error code "-1" was returned so far -if a call of the function "sony_call_snc_handle" failed here. -Thus assign the return value from these two function calls also to -the variable "err" and provide it in case of a failure. - -Fixes: d6f15ed876b83a1a0eba1d0473eef58acc95444a ("sony-laptop: use soft rfkill status stored in hw") -Suggested-by: Andy Shevchenko <andy.shevchenko(a)gmail.com> -Link: https://lkml.org/lkml/2017/10/31/463 -Link: https://lkml.kernel.org/r/<CAHp75VcMkXCioCzmLE0+BTmkqc5RSOx9yPO0ectVHMrMvewgwg(a)mail.gmail.com> -Signed-off-by: Markus Elfring <elfring(a)users.sourceforge.net> -Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> -Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> -Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> ---- - drivers/platform/x86/sony-laptop.c | 14 ++++++++------ - 1 file changed, 8 insertions(+), 6 deletions(-) - ---- a/drivers/platform/x86/sony-laptop.c -+++ b/drivers/platform/x86/sony-laptop.c -@@ -1660,17 +1660,19 @@ static int sony_nc_setup_rfkill(struct a - if (!rfk) - return -ENOMEM; - -- if (sony_call_snc_handle(sony_rfkill_handle, 0x200, &result) < 0) { -+ err = sony_call_snc_handle(sony_rfkill_handle, 0x200, &result); -+ if (err < 0) { - rfkill_destroy(rfk); -- return -1; -+ return err; - } - hwblock = !(result & 0x1); - -- if (sony_call_snc_handle(sony_rfkill_handle, -- sony_rfkill_address[nc_type], -- &result) < 0) { -+ err = sony_call_snc_handle(sony_rfkill_handle, -+ sony_rfkill_address[nc_type], -+ &result); -+ if (err < 0) { - rfkill_destroy(rfk); -- return -1; -+ return err; - } - swblock = !(result & 0x2); - diff --git a/queue-4.9/series b/queue-4.9/series index ddb7a33cf..295f28ae2 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -121,7 +121,6 @@ netfilter-ipvs-fix-inappropriate-output-of-procfs.patch powerpc-opal-fix-ebusy-bug-in-acquiring-tokens.patch powerpc-ipic-fix-status-get-and-status-clear.patch platform-x86-intel_punit_ipc-fix-resource-ioremap-warning.patch -platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch target-iscsi-fix-a-race-condition-in-iscsit_add_reject_from_cmd.patch iscsi-target-fix-memory-leak-in-lio_target_tiqn_addtpg.patch target-fix-condition-return-in-core_pr_dump_initiator_port.patch -- 2.11.0

7 years, 8 months

2
1
0 0

[Linux-stable-mirror] [PATCH 01/14] MIPS: Fix CM region target definitions

by thirtsa.dreyfus＠intel.com

From: Paul Burton <paul.burton(a)imgtec.com> The default CM target field in the GCR_BASE register is encoded with 0 meaning memory & 1 being reserved. However the definitions we use for those bits effectively get these two values backwards - likely because they were copied from the definitions for the CM regions where the target is encoded differently. This results in use setting up GCR_BASE with the reserved target value by default, rather than targeting memory as intended. Although we currently seem to get away with this it's not a great idea to rely upon. Fix this by changing our macros to match the documentated target values. The incorrect encoding became used as of commit 9f98f3dd0c51 ("MIPS: Add generic CM probe & access code") in the Linux v3.15 cycle, and was likely carried forwards from older but unused code introduced by commit 39b8d5254246 ("[MIPS] Add support for MIPS CMP platform.") in the v2.6.26 cycle. Signed-off-by: Paul Burton <paul.burton(a)imgtec.com> Reported-by: Matt Redfearn <matt.redfearn(a)imgtec.com> Cc: Matt Redfearn <matt.redfearn(a)imgtec.com> Cc: Ralf Baechle <ralf(a)linux-mips.org> Cc: linux-mips(a)linux-mips.org Cc: <stable(a)vger.kernel.org> # v3.15+ --- arch/mips/include/asm/mips-cm.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/mips/include/asm/mips-cm.h b/arch/mips/include/asm/mips-cm.h index f6231b9..c6aaabd 100644 --- a/arch/mips/include/asm/mips-cm.h +++ b/arch/mips/include/asm/mips-cm.h @@ -142,8 +142,8 @@ static inline bool mips_cm_has_l2sync(void) GCR_ACCESSOR_RW(64, 0x008, base) #define CM_GCR_BASE_GCRBASE GENMASK_ULL(47, 15) #define CM_GCR_BASE_CMDEFTGT GENMASK(1, 0) -#define CM_GCR_BASE_CMDEFTGT_DISABLED 0 -#define CM_GCR_BASE_CMDEFTGT_MEM 1 +#define CM_GCR_BASE_CMDEFTGT_MEM 0 +#define CM_GCR_BASE_CMDEFTGT_RESERVED 1 #define CM_GCR_BASE_CMDEFTGT_IOCU0 2 #define CM_GCR_BASE_CMDEFTGT_IOCU1 3 -- 1.9.1 --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

7 years, 8 months

1
0
0 0

Re: [Linux-stable-mirror] [PATCH for-4.14.y 0/5] e1000e: Upstream fixes for linux-4.14.y

by Greg KH

On Mon, Dec 11, 2017 at 10:58:10PM +0100, Christian Hesse wrote: > Greg KH <gregkh(a)linuxfoundation.org> on Tue, 2017/12/05 08:35: > > On Tue, Dec 05, 2017 at 08:23:27AM +0100, Christian Hesse wrote: > > > Greg KH <gregkh(a)linuxfoundation.org> on Mon, 2017/12/04 19:37: > > > > On Mon, Dec 04, 2017 at 04:47:00PM +0100, Christian Hesse wrote: > > > > > Amit Pundir <amit.pundir(a)linaro.org> on Mon, 2017/11/27 18:23: > > > > > > Hi Greg, > > > > > > > > > > > > Found few e100e upstream fixes from Benjamin Poirier in lede > > > > > > source tree, https://git.lede-project.org/?p=source.git, and > > > > > > these fixes seem reasonable enough for 4.14.y too. > > > > > > > > > > > > Also submitting an e1000e buffer overrun fix by Sasha Neftin. > > > > > > > > > > > > Cherry-picked and build tested for linux v4.14.2 for ARCH=arm/arm64. > > > > > > > > > > > > Regards, > > > > > > Amit Pundir > > > > > > > > > > > > > > > > > > Benjamin Poirier (4): > > > > > > e1000e: Fix error path in link detection > > > > > > e1000e: Fix return value test > > > > > > e1000e: Separate signaling for link check/link up > > > > > > e1000e: Avoid receiver overrun interrupt bursts > > > > > > > > > > > > Sasha Neftin (1): > > > > > > e1000e: fix buffer overrun while the I219 is processing DMA > > > > > > transactions > > > > > > > > > > Hello everybody, > > > > > > > > > > looks like one of these breaks connectivity on my Thinkpad X250. > > > > > Just downgraded to linux 4.14.2 to verify. > > > > > > > > Can you try the -rc release I just did? It has a fix for this series in > > > > it. > > > > > > It connects with the notebook's built in ethernet port (did not check with > > > 4.14.3) but still fails to see a link when placed in docking station. > > > > Do you have the same issues with 4.15-rc2? > > Just a short heads-up and final result for this thread... > The issue is fixed with Benjamin's patch: > > https://patchwork.kernel.org/patch/10104349/ Any word on getting this patch into Linus's tree anytime soon? thanks, greg k-h

7 years, 8 months

2
1
0 0

[Linux-stable-mirror] [PATCH] clk: sunxi: sun9i-mmc: Implement reset callback for reset controls

by Chen-Yu Tsai

Our MMC host driver now issues a reset, instead of just deasserting the reset control, since commit c34eda69ad4c ("mmc: sunxi: Reset the device at probe time"). The sun9i-mmc clock driver does not support this, and will fail, which results in MMC not probing. This patch implements the reset callback by asserting the reset control, then deasserting it after a small delay. Fixes: 7a6fca879f59 ("clk: sunxi: Add driver for A80 MMC config clocks/resets") Cc: <stable(a)vger.kernel.org> # 4.14.x Signed-off-by: Chen-Yu Tsai <wens(a)csie.org> --- drivers/clk/sunxi/clk-sun9i-mmc.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/clk/sunxi/clk-sun9i-mmc.c b/drivers/clk/sunxi/clk-sun9i-mmc.c index a1a634253d6f..f00d8758ba24 100644 --- a/drivers/clk/sunxi/clk-sun9i-mmc.c +++ b/drivers/clk/sunxi/clk-sun9i-mmc.c @@ -16,6 +16,7 @@ #include <linux/clk.h> #include <linux/clk-provider.h> +#include <linux/delay.h> #include <linux/init.h> #include <linux/of.h> #include <linux/of_device.h> @@ -83,9 +84,20 @@ static int sun9i_mmc_reset_deassert(struct reset_controller_dev *rcdev, return 0; } +static int sun9i_mmc_reset_reset(struct reset_controller_dev *rcdev, + unsigned long id) +{ + sun9i_mmc_reset_assert(rcdev, id); + udelay(10); + sun9i_mmc_reset_deassert(rcdev, id); + + return 0; +} + static const struct reset_control_ops sun9i_mmc_reset_ops = { .assert = sun9i_mmc_reset_assert, .deassert = sun9i_mmc_reset_deassert, + .reset = sun9i_mmc_reset_reset, }; static int sun9i_a80_mmc_config_clk_probe(struct platform_device *pdev) -- 2.15.0

7 years, 8 months

3
2
0 0

Re: [Linux-stable-mirror] [PATCH] mtd: cfi: convert inline functions to macros

by Richard Weinberger

Am Mittwoch, 11. Oktober 2017, 15:54:10 CET schrieb Arnd Bergmann: > The map_word_() functions, dating back to linux-2.6.8, try to perform > bitwise operations on a 'map_word' structure. This may have worked > with compilers that were current then (gcc-3.4 or earlier), but end > up being rather inefficient on any version I could try now (gcc-4.4 or > higher). Specifically we hit a problem analyzed in gcc PR81715 where we > fail to reuse the stack space for local variables. > > This can be seen immediately in the stack consumption for > cfi_staa_erase_varsize() and other functions that (with CONFIG_KASAN) > can be up to 2200 bytes. Changing the inline functions into macros brings > this down to 1280 bytes. Without KASAN, the same problem exists, but > the stack consumption is lower to start with, my patch shrinks it from > 920 to 496 bytes on with arm-linux-gnueabi-gcc-5.4, and saves around > 1KB in .text size for cfi_cmdset_0020.c, as it avoids copying map_word > structures for each call to one of these helpers. > > With the latest gcc-8 snapshot, the problem is fixed in upstream gcc, > but nobody uses that yet, so we should still work around it in mainline > kernels and probably backport the workaround to stable kernels as well. > We had a couple of other functions that suffered from the same gcc bug, > and all of those had a simpler workaround involving dummy variables > in the inline function. Unfortunately that did not work here, the > macro hack was the best I could come up with. > > It would also be helpful to have someone to a little performance testing > on the patch, to see how much it helps in terms of CPU utilitzation. > > Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715 > Cc: stable(a)vger.kernel.org > Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Acked-by: Richard Weinberger <richard(a)nod.at> Marek, I know you are not super happy with this patch but IMHO this is the solution with the least hassle. While functions offer better type checking I think this functions are trivial enough to exist as macros too. Also forcing users to upgrade/fix their compilers is only possible in a perfect world. Thanks, //richard

7 years, 8 months

4
5
0 0

[Linux-stable-mirror] FAILED: patch "[PATCH] usb: musb: da8xx: fix babble condition handling" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From bd3486ded7a0c313a6575343e6c2b21d14476645 Mon Sep 17 00:00:00 2001 From: Bin Liu <b-liu(a)ti.com> Date: Tue, 5 Dec 2017 08:45:30 -0600 Subject: [PATCH] usb: musb: da8xx: fix babble condition handling When babble condition happens, the musb controller might automatically turns off VBUS. On DA8xx platform, the controller generates drvvbus interrupt for turning off VBUS along with the babble interrupt. In this case, we should handle the babble interrupt first and recover from the babble condition. This change ignores the drvvbus interrupt if babble interrupt is also generated at the same time, so the babble recovery routine works properly. Cc: stable(a)vger.kernel.org # v3.16+ Signed-off-by: Bin Liu <b-liu(a)ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c index 0397606a211b..6c036de63272 100644 --- a/drivers/usb/musb/da8xx.c +++ b/drivers/usb/musb/da8xx.c @@ -284,7 +284,15 @@ static irqreturn_t da8xx_musb_interrupt(int irq, void *hci) musb->xceiv->otg->state = OTG_STATE_A_WAIT_VRISE; portstate(musb->port1_status |= USB_PORT_STAT_POWER); del_timer(&musb->dev_timer); - } else { + } else if (!(musb->int_usb & MUSB_INTR_BABBLE)) { + /* + * When babble condition happens, drvvbus interrupt + * is also generated. Ignore this drvvbus interrupt + * and let babble interrupt handler recovers the + * controller; otherwise, the host-mode flag is lost + * due to the MUSB_DEV_MODE() call below and babble + * recovery logic will not be called. + */ musb->is_active = 0; MUSB_DEV_MODE(musb); otg->default_a = 0;

7 years, 8 months

3
3
0 0

[Linux-stable-mirror] Patch "usb: musb: da8xx: fix babble condition handling" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: musb: da8xx: fix babble condition handling to the 4.9-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-musb-da8xx-fix-babble-condition-handling.patch and it can be found in the queue-4.9 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 bd3486ded7a0c313a6575343e6c2b21d14476645 Mon Sep 17 00:00:00 2001 From: Bin Liu <b-liu(a)ti.com> Date: Tue, 5 Dec 2017 08:45:30 -0600 Subject: usb: musb: da8xx: fix babble condition handling From: Bin Liu <b-liu(a)ti.com> commit bd3486ded7a0c313a6575343e6c2b21d14476645 upstream. When babble condition happens, the musb controller might automatically turns off VBUS. On DA8xx platform, the controller generates drvvbus interrupt for turning off VBUS along with the babble interrupt. In this case, we should handle the babble interrupt first and recover from the babble condition. This change ignores the drvvbus interrupt if babble interrupt is also generated at the same time, so the babble recovery routine works properly. Signed-off-by: Bin Liu <b-liu(a)ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/musb/da8xx.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) --- a/drivers/usb/musb/da8xx.c +++ b/drivers/usb/musb/da8xx.c @@ -302,7 +302,15 @@ static irqreturn_t da8xx_musb_interrupt( musb->xceiv->otg->state = OTG_STATE_A_WAIT_VRISE; portstate(musb->port1_status |= USB_PORT_STAT_POWER); del_timer(&otg_workaround); - } else { + } else if (!(musb->int_usb & MUSB_INTR_BABBLE)){ + /* + * When babble condition happens, drvvbus interrupt + * is also generated. Ignore this drvvbus interrupt + * and let babble interrupt handler recovers the + * controller; otherwise, the host-mode flag is lost + * due to the MUSB_DEV_MODE() call below and babble + * recovery logic will not called. + */ musb->is_active = 0; MUSB_DEV_MODE(musb); otg->default_a = 0; Patches currently in stable-queue which might be from b-liu(a)ti.com are queue-4.9/usb-musb-da8xx-fix-babble-condition-handling.patch

7 years, 8 months

1
0
0 0

[Linux-stable-mirror] Patch "usb: musb: da8xx: fix babble condition handling" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: musb: da8xx: fix babble condition handling 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: usb-musb-da8xx-fix-babble-condition-handling.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 bd3486ded7a0c313a6575343e6c2b21d14476645 Mon Sep 17 00:00:00 2001 From: Bin Liu <b-liu(a)ti.com> Date: Tue, 5 Dec 2017 08:45:30 -0600 Subject: usb: musb: da8xx: fix babble condition handling From: Bin Liu <b-liu(a)ti.com> commit bd3486ded7a0c313a6575343e6c2b21d14476645 upstream. When babble condition happens, the musb controller might automatically turns off VBUS. On DA8xx platform, the controller generates drvvbus interrupt for turning off VBUS along with the babble interrupt. In this case, we should handle the babble interrupt first and recover from the babble condition. This change ignores the drvvbus interrupt if babble interrupt is also generated at the same time, so the babble recovery routine works properly. Signed-off-by: Bin Liu <b-liu(a)ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/musb/da8xx.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) --- a/drivers/usb/musb/da8xx.c +++ b/drivers/usb/musb/da8xx.c @@ -350,7 +350,15 @@ static irqreturn_t da8xx_musb_interrupt( musb->xceiv->otg->state = OTG_STATE_A_WAIT_VRISE; portstate(musb->port1_status |= USB_PORT_STAT_POWER); del_timer(&otg_workaround); - } else { + } else if (!(musb->int_usb & MUSB_INTR_BABBLE)){ + /* + * When babble condition happens, drvvbus interrupt + * is also generated. Ignore this drvvbus interrupt + * and let babble interrupt handler recovers the + * controller; otherwise, the host-mode flag is lost + * due to the MUSB_DEV_MODE() call below and babble + * recovery logic will not called. + */ musb->is_active = 0; MUSB_DEV_MODE(musb); otg->default_a = 0; Patches currently in stable-queue which might be from b-liu(a)ti.com are queue-4.4/usb-musb-da8xx-fix-babble-condition-handling.patch

7 years, 8 months

1
0
0 0

[Linux-stable-mirror] Patch "usb: musb: da8xx: fix babble condition handling" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: musb: da8xx: fix babble condition handling 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-musb-da8xx-fix-babble-condition-handling.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 bd3486ded7a0c313a6575343e6c2b21d14476645 Mon Sep 17 00:00:00 2001 From: Bin Liu <b-liu(a)ti.com> Date: Tue, 5 Dec 2017 08:45:30 -0600 Subject: usb: musb: da8xx: fix babble condition handling From: Bin Liu <b-liu(a)ti.com> commit bd3486ded7a0c313a6575343e6c2b21d14476645 upstream. When babble condition happens, the musb controller might automatically turns off VBUS. On DA8xx platform, the controller generates drvvbus interrupt for turning off VBUS along with the babble interrupt. In this case, we should handle the babble interrupt first and recover from the babble condition. This change ignores the drvvbus interrupt if babble interrupt is also generated at the same time, so the babble recovery routine works properly. Signed-off-by: Bin Liu <b-liu(a)ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/musb/da8xx.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) --- a/drivers/usb/musb/da8xx.c +++ b/drivers/usb/musb/da8xx.c @@ -305,7 +305,15 @@ static irqreturn_t da8xx_musb_interrupt( musb->xceiv->otg->state = OTG_STATE_A_WAIT_VRISE; portstate(musb->port1_status |= USB_PORT_STAT_POWER); del_timer(&otg_workaround); - } else { + } else if (!(musb->int_usb & MUSB_INTR_BABBLE)){ + /* + * When babble condition happens, drvvbus interrupt + * is also generated. Ignore this drvvbus interrupt + * and let babble interrupt handler recovers the + * controller; otherwise, the host-mode flag is lost + * due to the MUSB_DEV_MODE() call below and babble + * recovery logic will not called. + */ musb->is_active = 0; MUSB_DEV_MODE(musb); otg->default_a = 0; Patches currently in stable-queue which might be from b-liu(a)ti.com are queue-4.14/usb-musb-da8xx-fix-babble-condition-handling.patch

7 years, 8 months

1
0
0 0

[Linux-stable-mirror] Patch "usb: musb: da8xx: fix babble condition handling" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: musb: da8xx: fix babble condition handling to the 3.18-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-musb-da8xx-fix-babble-condition-handling.patch and it can be found in the queue-3.18 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 bd3486ded7a0c313a6575343e6c2b21d14476645 Mon Sep 17 00:00:00 2001 From: Bin Liu <b-liu(a)ti.com> Date: Tue, 5 Dec 2017 08:45:30 -0600 Subject: usb: musb: da8xx: fix babble condition handling From: Bin Liu <b-liu(a)ti.com> commit bd3486ded7a0c313a6575343e6c2b21d14476645 upstream. When babble condition happens, the musb controller might automatically turns off VBUS. On DA8xx platform, the controller generates drvvbus interrupt for turning off VBUS along with the babble interrupt. In this case, we should handle the babble interrupt first and recover from the babble condition. This change ignores the drvvbus interrupt if babble interrupt is also generated at the same time, so the babble recovery routine works properly. Signed-off-by: Bin Liu <b-liu(a)ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/musb/da8xx.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) --- a/drivers/usb/musb/da8xx.c +++ b/drivers/usb/musb/da8xx.c @@ -350,7 +350,15 @@ static irqreturn_t da8xx_musb_interrupt( musb->xceiv->state = OTG_STATE_A_WAIT_VRISE; portstate(musb->port1_status |= USB_PORT_STAT_POWER); del_timer(&otg_workaround); - } else { + } else if (!(musb->int_usb & MUSB_INTR_BABBLE)){ + /* + * When babble condition happens, drvvbus interrupt + * is also generated. Ignore this drvvbus interrupt + * and let babble interrupt handler recovers the + * controller; otherwise, the host-mode flag is lost + * due to the MUSB_DEV_MODE() call below and babble + * recovery logic will not called. + */ musb->is_active = 0; MUSB_DEV_MODE(musb); otg->default_a = 0; Patches currently in stable-queue which might be from b-liu(a)ti.com are queue-3.18/usb-musb-da8xx-fix-babble-condition-handling.patch

7 years, 8 months

1
0
0 0

[Linux-stable-mirror] patch "binder: fix proc->files use-after-free" added to char-misc-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled binder: fix proc->files use-after-free to my char-misc git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git in the char-misc-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 7f3dc0088b98533f17128058fac73cd8b2752ef1 Mon Sep 17 00:00:00 2001 From: Todd Kjos <tkjos(a)android.com> Date: Mon, 27 Nov 2017 09:32:33 -0800 Subject: binder: fix proc->files use-after-free proc->files cleanup is initiated by binder_vma_close. Therefore a reference on the binder_proc is not enough to prevent the files_struct from being released while the binder_proc still has a reference. This can lead to an attempt to dereference the stale pointer obtained from proc->files prior to proc->files cleanup. This has been seen once in task_get_unused_fd_flags() when __alloc_fd() is called with a stale "files". The fix is to protect proc->files with a mutex to prevent cleanup while in use. Signed-off-by: Todd Kjos <tkjos(a)google.com> Cc: stable <stable(a)vger.kernel.org> # 4.14 Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/android/binder.c | 44 +++++++++++++++++++++++++++++++------------- 1 file changed, 31 insertions(+), 13 deletions(-) diff --git a/drivers/android/binder.c b/drivers/android/binder.c index bccec9de0533..a7ecfde66b7b 100644 --- a/drivers/android/binder.c +++ b/drivers/android/binder.c @@ -482,7 +482,8 @@ enum binder_deferred_state { * @tsk task_struct for group_leader of process * (invariant after initialized) * @files files_struct for process - * (invariant after initialized) + * (protected by @files_lock) + * @files_lock mutex to protect @files * @deferred_work_node: element for binder_deferred_list * (protected by binder_deferred_lock) * @deferred_work: bitmap of deferred work to perform @@ -530,6 +531,7 @@ struct binder_proc { int pid; struct task_struct *tsk; struct files_struct *files; + struct mutex files_lock; struct hlist_node deferred_work_node; int deferred_work; bool is_dead; @@ -877,20 +879,26 @@ static void binder_inc_node_tmpref_ilocked(struct binder_node *node); static int task_get_unused_fd_flags(struct binder_proc *proc, int flags) { - struct files_struct *files = proc->files; unsigned long rlim_cur; unsigned long irqs; + int ret; - if (files == NULL) - return -ESRCH; - - if (!lock_task_sighand(proc->tsk, &irqs)) - return -EMFILE; - + mutex_lock(&proc->files_lock); + if (proc->files == NULL) { + ret = -ESRCH; + goto err; + } + if (!lock_task_sighand(proc->tsk, &irqs)) { + ret = -EMFILE; + goto err; + } rlim_cur = task_rlimit(proc->tsk, RLIMIT_NOFILE); unlock_task_sighand(proc->tsk, &irqs); - return __alloc_fd(files, 0, rlim_cur, flags); + ret = __alloc_fd(proc->files, 0, rlim_cur, flags); +err: + mutex_unlock(&proc->files_lock); + return ret; } /* @@ -899,8 +907,10 @@ static int task_get_unused_fd_flags(struct binder_proc *proc, int flags) static void task_fd_install( struct binder_proc *proc, unsigned int fd, struct file *file) { + mutex_lock(&proc->files_lock); if (proc->files) __fd_install(proc->files, fd, file); + mutex_unlock(&proc->files_lock); } /* @@ -910,9 +920,11 @@ static long task_close_fd(struct binder_proc *proc, unsigned int fd) { int retval; - if (proc->files == NULL) - return -ESRCH; - + mutex_lock(&proc->files_lock); + if (proc->files == NULL) { + retval = -ESRCH; + goto err; + } retval = __close_fd(proc->files, fd); /* can't restart close syscall because file table entry was cleared */ if (unlikely(retval == -ERESTARTSYS || @@ -920,7 +932,8 @@ static long task_close_fd(struct binder_proc *proc, unsigned int fd) retval == -ERESTARTNOHAND || retval == -ERESTART_RESTARTBLOCK)) retval = -EINTR; - +err: + mutex_unlock(&proc->files_lock); return retval; } @@ -4627,7 +4640,9 @@ static int binder_mmap(struct file *filp, struct vm_area_struct *vma) ret = binder_alloc_mmap_handler(&proc->alloc, vma); if (ret) return ret; + mutex_lock(&proc->files_lock); proc->files = get_files_struct(current); + mutex_unlock(&proc->files_lock); return 0; err_bad_arg: @@ -4651,6 +4666,7 @@ static int binder_open(struct inode *nodp, struct file *filp) spin_lock_init(&proc->outer_lock); get_task_struct(current->group_leader); proc->tsk = current->group_leader; + mutex_init(&proc->files_lock); INIT_LIST_HEAD(&proc->todo); proc->default_priority = task_nice(current); binder_dev = container_of(filp->private_data, struct binder_device, @@ -4903,9 +4919,11 @@ static void binder_deferred_func(struct work_struct *work) files = NULL; if (defer & BINDER_DEFERRED_PUT_FILES) { + mutex_lock(&proc->files_lock); files = proc->files; if (files) proc->files = NULL; + mutex_unlock(&proc->files_lock); } if (defer & BINDER_DEFERRED_FLUSH) -- 2.15.1

7 years, 8 months

1
0
0 0

[Linux-stable-mirror] FAILED: patch "[PATCH] usb: musb: da8xx: fix babble condition handling" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From bd3486ded7a0c313a6575343e6c2b21d14476645 Mon Sep 17 00:00:00 2001 From: Bin Liu <b-liu(a)ti.com> Date: Tue, 5 Dec 2017 08:45:30 -0600 Subject: [PATCH] usb: musb: da8xx: fix babble condition handling When babble condition happens, the musb controller might automatically turns off VBUS. On DA8xx platform, the controller generates drvvbus interrupt for turning off VBUS along with the babble interrupt. In this case, we should handle the babble interrupt first and recover from the babble condition. This change ignores the drvvbus interrupt if babble interrupt is also generated at the same time, so the babble recovery routine works properly. Cc: stable(a)vger.kernel.org # v3.16+ Signed-off-by: Bin Liu <b-liu(a)ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c index 0397606a211b..6c036de63272 100644 --- a/drivers/usb/musb/da8xx.c +++ b/drivers/usb/musb/da8xx.c @@ -284,7 +284,15 @@ static irqreturn_t da8xx_musb_interrupt(int irq, void *hci) musb->xceiv->otg->state = OTG_STATE_A_WAIT_VRISE; portstate(musb->port1_status |= USB_PORT_STAT_POWER); del_timer(&musb->dev_timer); - } else { + } else if (!(musb->int_usb & MUSB_INTR_BABBLE)) { + /* + * When babble condition happens, drvvbus interrupt + * is also generated. Ignore this drvvbus interrupt + * and let babble interrupt handler recovers the + * controller; otherwise, the host-mode flag is lost + * due to the MUSB_DEV_MODE() call below and babble + * recovery logic will not be called. + */ musb->is_active = 0; MUSB_DEV_MODE(musb); otg->default_a = 0;

7 years, 8 months

2
1
0 0

[Linux-stable-mirror] Patch "xfs: fix log block underflow during recovery cycle verification" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled xfs: fix log block underflow during recovery cycle verification to the 3.18-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: xfs-fix-log-block-underflow-during-recovery-cycle-verification.patch and it can be found in the queue-3.18 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 Mon Dec 18 15:03:25 CET 2017 From: Brian Foster <bfoster(a)redhat.com> Date: Thu, 26 Oct 2017 09:31:16 -0700 Subject: xfs: fix log block underflow during recovery cycle verification From: Brian Foster <bfoster(a)redhat.com> [ Upstream commit 9f2a4505800607e537e9dd9dea4f55c4b0c30c7a ] It is possible for mkfs to format very small filesystems with too small of an internal log with respect to the various minimum size and block count requirements. If this occurs when the log happens to be smaller than the scan window used for cycle verification and the scan wraps the end of the log, the start_blk calculation in xlog_find_head() underflows and leads to an attempt to scan an invalid range of log blocks. This results in log recovery failure and a failed mount. Since there may be filesystems out in the wild with this kind of geometry, we cannot simply refuse to mount. Instead, cap the scan window for cycle verification to the size of the physical log. This ensures that the cycle verification proceeds as expected when the scan wraps the end of the log. Reported-by: Zorro Lang <zlang(a)redhat.com> Signed-off-by: Brian Foster <bfoster(a)redhat.com> Reviewed-by: Darrick J. Wong <darrick.wong(a)oracle.com> Signed-off-by: Darrick J. Wong <darrick.wong(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/xfs/xfs_log_recover.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/xfs/xfs_log_recover.c +++ b/fs/xfs/xfs_log_recover.c @@ -740,7 +740,7 @@ xlog_find_head( * in the in-core log. The following number can be made tighter if * we actually look at the block size of the filesystem. */ - num_scan_bblks = XLOG_TOTAL_REC_SHIFT(log); + num_scan_bblks = min_t(int, log_bbnum, XLOG_TOTAL_REC_SHIFT(log)); if (head_blk >= num_scan_bblks) { /* * We are guaranteed that the entire check can be performed Patches currently in stable-queue which might be from bfoster(a)redhat.com are queue-3.18/xfs-fix-log-block-underflow-during-recovery-cycle-verification.patch

7 years, 8 months

1
0
0 0

[Linux-stable-mirror] Patch "video: udlfb: Fix read EDID timeout" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled video: udlfb: Fix read EDID timeout to the 3.18-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: video-udlfb-fix-read-edid-timeout.patch and it can be found in the queue-3.18 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 Mon Dec 18 15:03:25 CET 2017 From: Ladislav Michl <ladis(a)linux-mips.org> Date: Thu, 9 Nov 2017 18:09:30 +0100 Subject: video: udlfb: Fix read EDID timeout From: Ladislav Michl <ladis(a)linux-mips.org> [ Upstream commit c98769475575c8a585f5b3952f4b5f90266f699b ] While usb_control_msg function expects timeout in miliseconds, a value of HZ is used. Replace it with USB_CTRL_GET_TIMEOUT and also fix error message which looks like: udlfb: Read EDID byte 78 failed err ffffff92 as error is either negative errno or number of bytes transferred use %d format specifier. Returned EDID is in second byte, so return error when less than two bytes are received. Fixes: 18dffdf8913a ("staging: udlfb: enhance EDID and mode handling support") Signed-off-by: Ladislav Michl <ladis(a)linux-mips.org> Cc: Bernie Thompson <bernie(a)plugable.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie(a)samsung.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/video/fbdev/udlfb.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) --- a/drivers/video/fbdev/udlfb.c +++ b/drivers/video/fbdev/udlfb.c @@ -769,11 +769,11 @@ static int dlfb_get_edid(struct dlfb_dat for (i = 0; i < len; i++) { ret = usb_control_msg(dev->udev, - usb_rcvctrlpipe(dev->udev, 0), (0x02), - (0x80 | (0x02 << 5)), i << 8, 0xA1, rbuf, 2, - HZ); - if (ret < 1) { - pr_err("Read EDID byte %d failed err %x\n", i, ret); + usb_rcvctrlpipe(dev->udev, 0), 0x02, + (0x80 | (0x02 << 5)), i << 8, 0xA1, + rbuf, 2, USB_CTRL_GET_TIMEOUT); + if (ret < 2) { + pr_err("Read EDID byte %d failed: %d\n", i, ret); i--; break; } Patches currently in stable-queue which might be from ladis(a)linux-mips.org are queue-3.18/video-udlfb-fix-read-edid-timeout.patch

7 years, 8 months

1
0
0 0

[Linux-stable-mirror] Patch "video: fbdev: au1200fb: Return an error code if a memory allocation fails" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled video: fbdev: au1200fb: Return an error code if a memory allocation fails to the 3.18-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: video-fbdev-au1200fb-return-an-error-code-if-a-memory-allocation-fails.patch and it can be found in the queue-3.18 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 Mon Dec 18 15:03:25 CET 2017 From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Date: Thu, 9 Nov 2017 18:09:28 +0100 Subject: video: fbdev: au1200fb: Return an error code if a memory allocation fails From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> [ Upstream commit 8cae353e6b01ac3f18097f631cdbceb5ff28c7f3 ] 'ret' is known to be 0 at this point. In case of memory allocation error in 'framebuffer_alloc()', return -ENOMEM instead. Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Cc: Tejun Heo <tj(a)kernel.org> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie(a)samsung.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/video/fbdev/au1200fb.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/drivers/video/fbdev/au1200fb.c +++ b/drivers/video/fbdev/au1200fb.c @@ -1680,8 +1680,10 @@ static int au1200fb_drv_probe(struct pla fbi = framebuffer_alloc(sizeof(struct au1200fb_device), &dev->dev); - if (!fbi) + if (!fbi) { + ret = -ENOMEM; goto failed; + } _au1200fb_infos[plane] = fbi; fbdev = fbi->par; Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are queue-3.18/video-fbdev-au1200fb-release-some-resources-if-a-memory-allocation-fails.patch queue-3.18/video-fbdev-au1200fb-return-an-error-code-if-a-memory-allocation-fails.patch

7 years, 8 months

1
0
0 0

[Linux-stable-mirror] Patch "video: fbdev: au1200fb: Release some resources if a memory allocation fails" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled video: fbdev: au1200fb: Release some resources if a memory allocation fails to the 3.18-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: video-fbdev-au1200fb-release-some-resources-if-a-memory-allocation-fails.patch and it can be found in the queue-3.18 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 Mon Dec 18 15:03:25 CET 2017 From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Date: Thu, 9 Nov 2017 18:09:28 +0100 Subject: video: fbdev: au1200fb: Release some resources if a memory allocation fails From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> [ Upstream commit 451f130602619a17c8883dd0b71b11624faffd51 ] We should go through the error handling code instead of returning -ENOMEM directly. Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Cc: Tejun Heo <tj(a)kernel.org> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie(a)samsung.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/video/fbdev/au1200fb.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/video/fbdev/au1200fb.c +++ b/drivers/video/fbdev/au1200fb.c @@ -1699,7 +1699,8 @@ static int au1200fb_drv_probe(struct pla if (!fbdev->fb_mem) { print_err("fail to allocate frambuffer (size: %dK))", fbdev->fb_len / 1024); - return -ENOMEM; + ret = -ENOMEM; + goto failed; } /* Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are queue-3.18/video-fbdev-au1200fb-release-some-resources-if-a-memory-allocation-fails.patch queue-3.18/video-fbdev-au1200fb-return-an-error-code-if-a-memory-allocation-fails.patch

7 years, 8 months

1
0
0 0

[Linux-stable-mirror] Patch "tty fix oops when rmmod 8250" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled tty fix oops when rmmod 8250 to the 3.18-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: tty-fix-oops-when-rmmod-8250.patch and it can be found in the queue-3.18 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 Mon Dec 18 15:03:25 CET 2017 From: nixiaoming <nixiaoming(a)huawei.com> Date: Fri, 15 Sep 2017 17:45:56 +0800 Subject: tty fix oops when rmmod 8250 From: nixiaoming <nixiaoming(a)huawei.com> [ Upstream commit c79dde629d2027ca80329c62854a7635e623d527 ] After rmmod 8250.ko tty_kref_put starts kwork (release_one_tty) to release proc interface oops when accessing driver->driver_name in proc_tty_unregister_driver Use jprobe, found driver->driver_name point to 8250.ko static static struct uart_driver serial8250_reg .driver_name= serial, Use name in proc_dir_entry instead of driver->driver_name to fix oops test on linux 4.1.12: BUG: unable to handle kernel paging request at ffffffffa01979de IP: [<ffffffff81310f40>] strchr+0x0/0x30 PGD 1a0d067 PUD 1a0e063 PMD 851c1f067 PTE 0 Oops: 0000 [#1] PREEMPT SMP Modules linked in: ... ... [last unloaded: 8250] CPU: 7 PID: 116 Comm: kworker/7:1 Tainted: G O 4.1.12 #1 Hardware name: Insyde RiverForest/Type2 - Board Product Name1, BIOS NE5KV904 12/21/2015 Workqueue: events release_one_tty task: ffff88085b684960 ti: ffff880852884000 task.ti: ffff880852884000 RIP: 0010:[<ffffffff81310f40>] [<ffffffff81310f40>] strchr+0x0/0x30 RSP: 0018:ffff880852887c90 EFLAGS: 00010282 RAX: ffffffff81a5eca0 RBX: ffffffffa01979de RCX: 0000000000000004 RDX: ffff880852887d10 RSI: 000000000000002f RDI: ffffffffa01979de RBP: ffff880852887cd8 R08: 0000000000000000 R09: ffff88085f5d94d0 R10: 0000000000000195 R11: 0000000000000000 R12: ffffffffa01979de R13: ffff880852887d00 R14: ffffffffa01979de R15: ffff88085f02e840 FS: 0000000000000000(0000) GS:ffff88085f5c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffa01979de CR3: 0000000001a0c000 CR4: 00000000001406e0 Stack: ffffffff812349b1 ffff880852887cb8 ffff880852887d10 ffff88085f5cd6c2 ffff880852800a80 ffffffffa01979de ffff880852800a84 0000000000000010 ffff88085bb28bd8 ffff880852887d38 ffffffff812354f0 ffff880852887d08 Call Trace: [<ffffffff812349b1>] ? __xlate_proc_name+0x71/0xd0 [<ffffffff812354f0>] remove_proc_entry+0x40/0x180 [<ffffffff815f6811>] ? _raw_spin_lock_irqsave+0x41/0x60 [<ffffffff813be520>] ? destruct_tty_driver+0x60/0xe0 [<ffffffff81237c68>] proc_tty_unregister_driver+0x28/0x40 [<ffffffff813be548>] destruct_tty_driver+0x88/0xe0 [<ffffffff813be5bd>] tty_driver_kref_put+0x1d/0x20 [<ffffffff813becca>] release_one_tty+0x5a/0xd0 [<ffffffff81074159>] process_one_work+0x139/0x420 [<ffffffff810745a1>] worker_thread+0x121/0x450 [<ffffffff81074480>] ? process_scheduled_works+0x40/0x40 [<ffffffff8107a16c>] kthread+0xec/0x110 [<ffffffff81080000>] ? tg_rt_schedulable+0x210/0x220 [<ffffffff8107a080>] ? kthread_freezable_should_stop+0x80/0x80 [<ffffffff815f7292>] ret_from_fork+0x42/0x70 [<ffffffff8107a080>] ? kthread_freezable_should_stop+0x80/0x80 Signed-off-by: nixiaoming <nixiaoming(a)huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/proc/proc_tty.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/fs/proc/proc_tty.c +++ b/fs/proc/proc_tty.c @@ -14,6 +14,7 @@ #include <linux/tty.h> #include <linux/seq_file.h> #include <linux/bitops.h> +#include "internal.h" /* * The /proc/tty directory inodes... @@ -164,7 +165,7 @@ void proc_tty_unregister_driver(struct t if (!ent) return; - remove_proc_entry(driver->driver_name, proc_tty_driver); + remove_proc_entry(ent->name, proc_tty_driver); driver->proc_entry = NULL; } Patches currently in stable-queue which might be from nixiaoming(a)huawei.com are queue-3.18/tty-fix-oops-when-rmmod-8250.patch

7 years, 8 months

1
0
0 0

[Linux-stable-mirror] Patch "usb: phy: isp1301: Add OF device ID table" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: phy: isp1301: Add OF device ID table to the 3.18-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-phy-isp1301-add-of-device-id-table.patch and it can be found in the queue-3.18 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 Mon Dec 18 15:03:25 CET 2017 From: Javier Martinez Canillas <javier(a)osg.samsung.com> Date: Wed, 22 Feb 2017 15:23:22 -0300 Subject: usb: phy: isp1301: Add OF device ID table From: Javier Martinez Canillas <javier(a)osg.samsung.com> [ Upstream commit fd567653bdb908009b650f079bfd4b63169e2ac4 ] The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. But this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. Signed-off-by: Javier Martinez Canillas <javier(a)osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/phy/phy-isp1301.c | 7 +++++++ 1 file changed, 7 insertions(+) --- a/drivers/usb/phy/phy-isp1301.c +++ b/drivers/usb/phy/phy-isp1301.c @@ -32,6 +32,12 @@ static const struct i2c_device_id isp130 { } }; +static const struct of_device_id isp1301_of_match[] = { + {.compatible = "nxp,isp1301" }, + { }, +}; +MODULE_DEVICE_TABLE(of, isp1301_of_match); + static struct i2c_client *isp1301_i2c_client; static int __isp1301_write(struct isp1301 *isp, u8 reg, u8 value, u8 clear) @@ -129,6 +135,7 @@ static int isp1301_remove(struct i2c_cli static struct i2c_driver isp1301_driver = { .driver = { .name = DRV_NAME, + .of_match_table = of_match_ptr(isp1301_of_match), }, .probe = isp1301_probe, .remove = isp1301_remove, Patches currently in stable-queue which might be from javier(a)osg.samsung.com are queue-3.18/usb-phy-isp1301-add-of-device-id-table.patch

7 years, 8 months

1
0
0 0

[Linux-stable-mirror] Patch "udf: Avoid overflow when session starts at large offset" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled udf: Avoid overflow when session starts at large offset to the 3.18-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: udf-avoid-overflow-when-session-starts-at-large-offset.patch and it can be found in the queue-3.18 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 Mon Dec 18 15:03:25 CET 2017 From: Jan Kara <jack(a)suse.cz> Date: Mon, 16 Oct 2017 11:38:11 +0200 Subject: udf: Avoid overflow when session starts at large offset From: Jan Kara <jack(a)suse.cz> [ Upstream commit abdc0eb06964fe1d2fea6dd1391b734d0590365d ] When session starts beyond offset 2^31 the arithmetics in udf_check_vsd() would overflow. Make sure the computation is done in large enough type. Reported-by: Cezary Sliwa <sliwa(a)ifpan.edu.pl> Signed-off-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/udf/super.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/udf/super.c +++ b/fs/udf/super.c @@ -706,7 +706,7 @@ static loff_t udf_check_vsd(struct super else sectorsize = sb->s_blocksize; - sector += (sbi->s_session << sb->s_blocksize_bits); + sector += (((loff_t)sbi->s_session) << sb->s_blocksize_bits); udf_debug("Starting at sector %u (%ld byte sectors)\n", (unsigned int)(sector >> sb->s_blocksize_bits), Patches currently in stable-queue which might be from jack(a)suse.cz are queue-3.18/mm-handle-0-flags-in-_calc_vm_trans-macro.patch queue-3.18/udf-avoid-overflow-when-session-starts-at-large-offset.patch

7 years, 8 months

1
0
0 0

[Linux-stable-mirror] Patch "thermal/drivers/step_wise: Fix temperature regulation misbehavior" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled thermal/drivers/step_wise: Fix temperature regulation misbehavior to the 3.18-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: thermal-drivers-step_wise-fix-temperature-regulation-misbehavior.patch and it can be found in the queue-3.18 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 Mon Dec 18 15:03:25 CET 2017 From: Daniel Lezcano <daniel.lezcano(a)linaro.org> Date: Thu, 19 Oct 2017 19:05:58 +0200 Subject: thermal/drivers/step_wise: Fix temperature regulation misbehavior From: Daniel Lezcano <daniel.lezcano(a)linaro.org> [ Upstream commit 07209fcf33542c1ff1e29df2dbdf8f29cdaacb10 ] There is a particular situation when the cooling device is cpufreq and the heat dissipation is not efficient enough where the temperature increases little by little until reaching the critical threshold and leading to a SoC reset. The behavior is reproducible on a hikey6220 with bad heat dissipation (eg. stacked with other boards). Running a simple C program doing while(1); for each CPU of the SoC makes the temperature to reach the passive regulation trip point and ends up to the maximum allowed temperature followed by a reset. This issue has been also reported by running the libhugetlbfs test suite. What is observed is a ping pong between two cpu frequencies, 1.2GHz and 900MHz while the temperature continues to grow. It appears the step wise governor calls get_target_state() the first time with the throttle set to true and the trend to 'raising'. The code selects logically the next state, so the cpu frequency decreases from 1.2GHz to 900MHz, so far so good. The temperature decreases immediately but still stays greater than the trip point, then get_target_state() is called again, this time with the throttle set to true *and* the trend to 'dropping'. From there the algorithm assumes we have to step down the state and the cpu frequency jumps back to 1.2GHz. But the temperature is still higher than the trip point, so get_target_state() is called with throttle=1 and trend='raising' again, we jump to 900MHz, then get_target_state() is called with throttle=1 and trend='dropping', we jump to 1.2GHz, etc ... but the temperature does not stabilizes and continues to increase. [ 237.922654] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1 [ 237.922678] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=1 [ 237.922690] thermal cooling_device0: cur_state=0 [ 237.922701] thermal cooling_device0: old_target=0, target=1 [ 238.026656] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=2,throttle=1 [ 238.026680] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=2,throttle=1 [ 238.026694] thermal cooling_device0: cur_state=1 [ 238.026707] thermal cooling_device0: old_target=1, target=0 [ 238.134647] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1 [ 238.134667] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=1 [ 238.134679] thermal cooling_device0: cur_state=0 [ 238.134690] thermal cooling_device0: old_target=0, target=1 In this situation the temperature continues to increase while the trend is oscillating between 'dropping' and 'raising'. We need to keep the current state untouched if the throttle is set, so the temperature can decrease or a higher state could be selected, thus preventing this oscillation. Keeping the next_target untouched when 'throttle' is true at 'dropping' time fixes the issue. The following traces show the governor does not change the next state if trend==2 (dropping) and throttle==1. [ 2306.127987] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1 [ 2306.128009] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=1 [ 2306.128021] thermal cooling_device0: cur_state=0 [ 2306.128031] thermal cooling_device0: old_target=0, target=1 [ 2306.231991] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=2,throttle=1 [ 2306.232016] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=2,throttle=1 [ 2306.232030] thermal cooling_device0: cur_state=1 [ 2306.232042] thermal cooling_device0: old_target=1, target=1 [ 2306.335982] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=0,throttle=1 [ 2306.336006] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=0,throttle=1 [ 2306.336021] thermal cooling_device0: cur_state=1 [ 2306.336034] thermal cooling_device0: old_target=1, target=1 [ 2306.439984] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=2,throttle=1 [ 2306.440008] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=2,throttle=0 [ 2306.440022] thermal cooling_device0: cur_state=1 [ 2306.440034] thermal cooling_device0: old_target=1, target=0 [ ... ] After a while, if the temperature continues to increase, the next state becomes 2 which is 720MHz on the hikey. That results in the temperature stabilizing around the trip point. [ 2455.831982] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1 [ 2455.832006] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=0 [ 2455.832019] thermal cooling_device0: cur_state=1 [ 2455.832032] thermal cooling_device0: old_target=1, target=1 [ 2455.935985] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=0,throttle=1 [ 2455.936013] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=0,throttle=0 [ 2455.936027] thermal cooling_device0: cur_state=1 [ 2455.936040] thermal cooling_device0: old_target=1, target=1 [ 2456.043984] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=0,throttle=1 [ 2456.044009] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=0,throttle=0 [ 2456.044023] thermal cooling_device0: cur_state=1 [ 2456.044036] thermal cooling_device0: old_target=1, target=1 [ 2456.148001] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1 [ 2456.148028] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=1 [ 2456.148042] thermal cooling_device0: cur_state=1 [ 2456.148055] thermal cooling_device0: old_target=1, target=2 [ 2456.252009] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=2,throttle=1 [ 2456.252041] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=2,throttle=0 [ 2456.252058] thermal cooling_device0: cur_state=2 [ 2456.252075] thermal cooling_device0: old_target=2, target=1 IOW, this change is needed to keep the state for a cooling device if the temperature trend is oscillating while the temperature increases slightly. Without this change, the situation above leads to a catastrophic crash by a hardware reset on hikey. This issue has been reported to happen on an OMAP dra7xx also. Signed-off-by: Daniel Lezcano <daniel.lezcano(a)linaro.org> Cc: Keerthy <j-keerthy(a)ti.com> Cc: John Stultz <john.stultz(a)linaro.org> Cc: Leo Yan <leo.yan(a)linaro.org> Tested-by: Keerthy <j-keerthy(a)ti.com> Reviewed-by: Keerthy <j-keerthy(a)ti.com> Signed-off-by: Eduardo Valentin <edubezval(a)gmail.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/thermal/step_wise.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) --- a/drivers/thermal/step_wise.c +++ b/drivers/thermal/step_wise.c @@ -31,8 +31,7 @@ * If the temperature is higher than a trip point, * a. if the trend is THERMAL_TREND_RAISING, use higher cooling * state for this trip point - * b. if the trend is THERMAL_TREND_DROPPING, use lower cooling - * state for this trip point + * b. if the trend is THERMAL_TREND_DROPPING, do nothing * c. if the trend is THERMAL_TREND_RAISE_FULL, use upper limit * for this trip point * d. if the trend is THERMAL_TREND_DROP_FULL, use lower limit @@ -94,9 +93,11 @@ static unsigned long get_target_state(st if (!throttle) next_target = THERMAL_NO_TARGET; } else { - next_target = cur_state - 1; - if (next_target > instance->upper) - next_target = instance->upper; + if (!throttle) { + next_target = cur_state - 1; + if (next_target > instance->upper) + next_target = instance->upper; + } } break; case THERMAL_TREND_DROP_FULL: Patches currently in stable-queue which might be from daniel.lezcano(a)linaro.org are queue-3.18/thermal-drivers-step_wise-fix-temperature-regulation-misbehavior.patch

7 years, 8 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror