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

Patch "kernel/async.c: revert "async: simplify lowest_in_progress()"" 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 kernel/async.c: revert "async: simplify lowest_in_progress()" 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: kernel-async.c-revert-async-simplify-lowest_in_progress.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 4f7e988e63e336827f4150de48163bed05d653bd Mon Sep 17 00:00:00 2001 From: Rasmus Villemoes <linux(a)rasmusvillemoes.dk> Date: Tue, 6 Feb 2018 15:37:55 -0800 Subject: kernel/async.c: revert "async: simplify lowest_in_progress()" From: Rasmus Villemoes <linux(a)rasmusvillemoes.dk> commit 4f7e988e63e336827f4150de48163bed05d653bd upstream. This reverts commit 92266d6ef60c ("async: simplify lowest_in_progress()") which was simply wrong: In the case where domain is NULL, we now use the wrong offsetof() in the list_first_entry macro, so we don't actually fetch the ->cookie value, but rather the eight bytes located sizeof(struct list_head) further into the struct async_entry. On 64 bit, that's the data member, while on 32 bit, that's a u64 built from func and data in some order. I think the bug happens to be harmless in practice: It obviously only affects callers which pass a NULL domain, and AFAICT the only such caller is async_synchronize_full() -> async_synchronize_full_domain(NULL) -> async_synchronize_cookie_domain(ASYNC_COOKIE_MAX, NULL) and the ASYNC_COOKIE_MAX means that in practice we end up waiting for the async_global_pending list to be empty - but it would break if somebody happened to pass (void*)-1 as the data element to async_schedule, and of course also if somebody ever does a async_synchronize_cookie_domain(, NULL) with a "finite" cookie value. Maybe the "harmless in practice" means this isn't -stable material. But I'm not completely confident my quick git grep'ing is enough, and there might be affected code in one of the earlier kernels that has since been removed, so I'll leave the decision to the stable guys. Link: http://lkml.kernel.org/r/20171128104938.3921-1-linux@rasmusvillemoes.dk Fixes: 92266d6ef60c "async: simplify lowest_in_progress()" Signed-off-by: Rasmus Villemoes <linux(a)rasmusvillemoes.dk> Acked-by: Tejun Heo <tj(a)kernel.org> Cc: Arjan van de Ven <arjan(a)linux.intel.com> Cc: Adam Wallis <awallis(a)codeaurora.org> Cc: Lai Jiangshan <laijs(a)cn.fujitsu.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/async.c | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) --- a/kernel/async.c +++ b/kernel/async.c @@ -84,20 +84,24 @@ static atomic_t entry_count; static async_cookie_t lowest_in_progress(struct async_domain *domain) { - struct list_head *pending; + struct async_entry *first = NULL; async_cookie_t ret = ASYNC_COOKIE_MAX; unsigned long flags; spin_lock_irqsave(&async_lock, flags); - if (domain) - pending = &domain->pending; - else - pending = &async_global_pending; + if (domain) { + if (!list_empty(&domain->pending)) + first = list_first_entry(&domain->pending, + struct async_entry, domain_list); + } else { + if (!list_empty(&async_global_pending)) + first = list_first_entry(&async_global_pending, + struct async_entry, global_list); + } - if (!list_empty(pending)) - ret = list_first_entry(pending, struct async_entry, - domain_list)->cookie; + if (first) + ret = first->cookie; spin_unlock_irqrestore(&async_lock, flags); return ret; Patches currently in stable-queue which might be from linux(a)rasmusvillemoes.dk are queue-4.4/kernel-async.c-revert-async-simplify-lowest_in_progress.patch

7 years, 9 months

1
0
0 0

Patch "HID: quirks: Fix keyboard + touchpad on Toshiba Click Mini not working" 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 HID: quirks: Fix keyboard + touchpad on Toshiba Click Mini not working 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: hid-quirks-fix-keyboard-touchpad-on-toshiba-click-mini-not-working.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 edfc3722cfef4217c7fe92b272cbe0288ba1ff57 Mon Sep 17 00:00:00 2001 From: Hans de Goede <hdegoede(a)redhat.com> Date: Wed, 17 Jan 2018 21:05:55 +0100 Subject: HID: quirks: Fix keyboard + touchpad on Toshiba Click Mini not working From: Hans de Goede <hdegoede(a)redhat.com> commit edfc3722cfef4217c7fe92b272cbe0288ba1ff57 upstream. The Toshiba Click Mini uses an i2c attached keyboard/touchpad combo (single i2c_hid device for both) which has a vid:pid of 04F3:0401, which is also used by a bunch of Elan touchpads which are handled by the drivers/input/mouse/elan_i2c driver, but that driver deals with pure touchpads and does not work for a combo device such as the one on the Toshiba Click Mini. The combo on the Mini has an ACPI id of ELAN0800, which is not claimed by the elan_i2c driver, so check for that and if it is found do not ignore the device. This fixes the keyboard/touchpad combo on the Mini not working (although with the touchpad in mouse emulation mode). Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Signed-off-by: Jiri Kosina <jkosina(a)suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/hid/hid-core.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) --- a/drivers/hid/hid-core.c +++ b/drivers/hid/hid-core.c @@ -2308,7 +2308,6 @@ static const struct hid_device_id hid_ig { HID_USB_DEVICE(USB_VENDOR_ID_DREAM_CHEEKY, 0x0004) }, { HID_USB_DEVICE(USB_VENDOR_ID_DREAM_CHEEKY, 0x000a) }, { HID_I2C_DEVICE(USB_VENDOR_ID_ELAN, 0x0400) }, - { HID_I2C_DEVICE(USB_VENDOR_ID_ELAN, 0x0401) }, { HID_USB_DEVICE(USB_VENDOR_ID_ESSENTIAL_REALITY, USB_DEVICE_ID_ESSENTIAL_REALITY_P5) }, { HID_USB_DEVICE(USB_VENDOR_ID_ETT, USB_DEVICE_ID_TC5UH) }, { HID_USB_DEVICE(USB_VENDOR_ID_ETT, USB_DEVICE_ID_TC4UM) }, @@ -2578,6 +2577,17 @@ bool hid_ignore(struct hid_device *hdev) strncmp(hdev->name, "www.masterkit.ru MA901", 22) == 0) return true; break; + case USB_VENDOR_ID_ELAN: + /* + * Many Elan devices have a product id of 0x0401 and are handled + * by the elan_i2c input driver. But the ACPI HID ELAN0800 dev + * is not (and cannot be) handled by that driver -> + * Ignore all 0x0401 devs except for the ELAN0800 dev. + */ + if (hdev->product == 0x0401 && + strncmp(hdev->name, "ELAN0800", 8) != 0) + return true; + break; } if (hdev->type == HID_TYPE_USBMOUSE && Patches currently in stable-queue which might be from hdegoede(a)redhat.com are queue-4.4/ahci-add-pci-ids-for-intel-bay-trail-cherry-trail-and-apollo-lake-ahci.patch queue-4.4/bluetooth-btsdio-do-not-bind-to-non-removable-bcm43341.patch queue-4.4/hid-quirks-fix-keyboard-touchpad-on-toshiba-click-mini-not-working.patch queue-4.4/ahci-annotate-pci-ids-for-mobile-intel-chipsets-as-such.patch queue-4.4/bluetooth-btusb-restore-qca-rome-suspend-resume-fix-with-a-rewritten-version.patch

7 years, 9 months

1
0
0 0

Patch "EDAC, octeon: Fix an uninitialized variable warning" 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 EDAC, octeon: Fix an uninitialized variable warning 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: edac-octeon-fix-an-uninitialized-variable-warning.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 544e92581a2ac44607d7cc602c6b54d18656f56d Mon Sep 17 00:00:00 2001 From: James Hogan <jhogan(a)kernel.org> Date: Mon, 13 Nov 2017 16:12:06 +0000 Subject: EDAC, octeon: Fix an uninitialized variable warning MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: James Hogan <jhogan(a)kernel.org> commit 544e92581a2ac44607d7cc602c6b54d18656f56d upstream. Fix an uninitialized variable warning in the Octeon EDAC driver, as seen in MIPS cavium_octeon_defconfig builds since v4.14 with Codescape GNU Tools 2016.05-03: drivers/edac/octeon_edac-lmc.c In function ‘octeon_lmc_edac_poll_o2’: drivers/edac/octeon_edac-lmc.c:87:24: warning: ‘((long unsigned int*)&int_reg)[1]’ may \ be used uninitialized in this function [-Wmaybe-uninitialized] if (int_reg.s.sec_err || int_reg.s.ded_err) { ^ Iinitialise the whole int_reg variable to zero before the conditional assignments in the error injection case. Signed-off-by: James Hogan <jhogan(a)kernel.org> Acked-by: David Daney <david.daney(a)cavium.com> Cc: linux-edac <linux-edac(a)vger.kernel.org> Cc: linux-mips(a)linux-mips.org Fixes: 1bc021e81565 ("EDAC: Octeon: Add error injection support") Link: http://lkml.kernel.org/r/20171113161206.20990-1-james.hogan@mips.com Signed-off-by: Borislav Petkov <bp(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/edac/octeon_edac-lmc.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/edac/octeon_edac-lmc.c +++ b/drivers/edac/octeon_edac-lmc.c @@ -79,6 +79,7 @@ static void octeon_lmc_edac_poll_o2(stru if (!pvt->inject) int_reg.u64 = cvmx_read_csr(CVMX_LMCX_INT(mci->mc_idx)); else { + int_reg.u64 = 0; if (pvt->error_type == 1) int_reg.s.sec_err = 1; if (pvt->error_type == 2) Patches currently in stable-queue which might be from jhogan(a)kernel.org are queue-4.4/edac-octeon-fix-an-uninitialized-variable-warning.patch

7 years, 9 months

1
0
0 0

Patch "crypto: caam - fix endless loop when DECO acquire fails" 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 crypto: caam - fix endless loop when DECO acquire fails 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: crypto-caam-fix-endless-loop-when-deco-acquire-fails.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 225ece3e7dad4cfc44cca38ce7a3a80f255ea8f1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Horia=20Geant=C4=83?= <horia.geanta(a)nxp.com> Date: Mon, 5 Feb 2018 11:15:52 +0200 Subject: crypto: caam - fix endless loop when DECO acquire fails MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Horia Geantă <horia.geanta(a)nxp.com> commit 225ece3e7dad4cfc44cca38ce7a3a80f255ea8f1 upstream. In case DECO0 cannot be acquired - i.e. run_descriptor_deco0() fails with -ENODEV, caam_probe() enters an endless loop: run_descriptor_deco0 ret -ENODEV -> instantiate_rng -ENODEV, overwritten by -EAGAIN ret -EAGAIN -> caam_probe -EAGAIN results in endless loop It turns out the error path in instantiate_rng() is incorrect, the checks are done in the wrong order. Fixes: 1005bccd7a4a6 ("crypto: caam - enable instantiation of all RNG4 state handles") Reported-by: Bryan O'Donoghue <pure.logic(a)nexus-software.ie> Suggested-by: Auer Lukas <lukas.auer(a)aisec.fraunhofer.de> Signed-off-by: Horia Geantă <horia.geanta(a)nxp.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/crypto/caam/ctrl.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) --- a/drivers/crypto/caam/ctrl.c +++ b/drivers/crypto/caam/ctrl.c @@ -224,12 +224,16 @@ static int instantiate_rng(struct device * without any error (HW optimizations for later * CAAM eras), then try again. */ + if (ret) + break; + rdsta_val = rd_reg32(&ctrl->r4tst[0].rdsta) & RDSTA_IFMASK; if ((status && status != JRSTA_SSRC_JUMP_HALT_CC) || - !(rdsta_val & (1 << sh_idx))) + !(rdsta_val & (1 << sh_idx))) { ret = -EAGAIN; - if (ret) break; + } + dev_info(ctrldev, "Instantiated RNG4 SH%d\n", sh_idx); /* Clear the contents before recreating the descriptor */ memset(desc, 0x00, CAAM_CMD_SZ * 7); Patches currently in stable-queue which might be from horia.geanta(a)nxp.com are queue-4.4/crypto-tcrypt-fix-s-g-table-for-test_aead_speed.patch queue-4.4/crypto-caam-fix-endless-loop-when-deco-acquire-fails.patch

7 years, 9 months

1
0
0 0

Patch "Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version" 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 Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version 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: bluetooth-btusb-restore-qca-rome-suspend-resume-fix-with-a-rewritten-version.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 61f5acea8737d9b717fcc22bb6679924f3c82b98 Mon Sep 17 00:00:00 2001 From: Hans de Goede <hdegoede(a)redhat.com> Date: Mon, 8 Jan 2018 10:44:16 +0100 Subject: Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version From: Hans de Goede <hdegoede(a)redhat.com> commit 61f5acea8737d9b717fcc22bb6679924f3c82b98 upstream. Commit 7d06d5895c15 ("Revert "Bluetooth: btusb: fix QCA...suspend/resume"") removed the setting of the BTUSB_RESET_RESUME quirk for QCA Rome devices, instead favoring adding USB_QUIRK_RESET_RESUME quirks in usb/core/quirks.c. This was done because the DIY BTUSB_RESET_RESUME reset-resume handling has several issues (see the original commit message). An added advantage of moving over to the USB-core reset-resume handling is that it also disables autosuspend for these devices, which is similarly broken on these. But there are 2 issues with this approach: 1) It leaves the broken DIY BTUSB_RESET_RESUME code in place for Realtek devices. 2) Sofar only 2 of the 10 QCA devices known to the btusb code have been added to usb/core/quirks.c and if we fix the Realtek case the same way we need to add an additional 14 entries. So in essence we need to duplicate a large part of the usb_device_id table in btusb.c in usb/core/quirks.c and manually keep them in sync. This commit instead restores setting a reset-resume quirk for QCA devices in the btusb.c code, avoiding the duplicate usb_device_id table problem. This commit avoids the problems with the original DIY BTUSB_RESET_RESUME code by simply setting the USB_QUIRK_RESET_RESUME quirk directly on the usb_device. This commit also moves the BTUSB_REALTEK case over to directly setting the USB_QUIRK_RESET_RESUME on the usb_device and removes the now unused BTUSB_RESET_RESUME code. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1514836 Fixes: 7d06d5895c15 ("Revert "Bluetooth: btusb: fix QCA...suspend/resume"") Cc: Leif Liddy <leif.linux(a)gmail.com> Cc: Matthias Kaehlcke <mka(a)chromium.org> Cc: Brian Norris <briannorris(a)chromium.org> Cc: Daniel Drake <drake(a)endlessm.com> Cc: Kai-Heng Feng <kai.heng.feng(a)canonical.com> Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/bluetooth/btusb.c | 21 ++++++++++----------- 1 file changed, 10 insertions(+), 11 deletions(-) --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -23,6 +23,7 @@ #include <linux/module.h> #include <linux/usb.h> +#include <linux/usb/quirks.h> #include <linux/firmware.h> #include <asm/unaligned.h> @@ -360,8 +361,8 @@ static const struct usb_device_id blackl #define BTUSB_FIRMWARE_LOADED 7 #define BTUSB_FIRMWARE_FAILED 8 #define BTUSB_BOOTING 9 -#define BTUSB_RESET_RESUME 10 -#define BTUSB_DIAG_RUNNING 11 +#define BTUSB_DIAG_RUNNING 10 +#define BTUSB_OOB_WAKE_ENABLED 11 struct btusb_data { struct hci_dev *hdev; @@ -2969,6 +2970,12 @@ static int btusb_probe(struct usb_interf if (id->driver_info & BTUSB_QCA_ROME) { data->setup_on_usb = btusb_setup_qca; hdev->set_bdaddr = btusb_set_bdaddr_ath3012; + + /* QCA Rome devices lose their updated firmware over suspend, + * but the USB hub doesn't notice any status change. + * explicitly request a device reset on resume. + */ + interface_to_usbdev(intf)->quirks |= USB_QUIRK_RESET_RESUME; } #ifdef CONFIG_BT_HCIBTUSB_RTL @@ -2979,7 +2986,7 @@ static int btusb_probe(struct usb_interf * but the USB hub doesn't notice any status change. * Explicitly request a device reset on resume. */ - set_bit(BTUSB_RESET_RESUME, &data->flags); + interface_to_usbdev(intf)->quirks |= USB_QUIRK_RESET_RESUME; } #endif @@ -3136,14 +3143,6 @@ static int btusb_suspend(struct usb_inte btusb_stop_traffic(data); usb_kill_anchored_urbs(&data->tx_anchor); - /* Optionally request a device reset on resume, but only when - * wakeups are disabled. If wakeups are enabled we assume the - * device will stay powered up throughout suspend. - */ - if (test_bit(BTUSB_RESET_RESUME, &data->flags) && - !device_may_wakeup(&data->udev->dev)) - data->udev->reset_resume = 1; - return 0; } Patches currently in stable-queue which might be from hdegoede(a)redhat.com are queue-4.4/ahci-add-pci-ids-for-intel-bay-trail-cherry-trail-and-apollo-lake-ahci.patch queue-4.4/bluetooth-btsdio-do-not-bind-to-non-removable-bcm43341.patch queue-4.4/hid-quirks-fix-keyboard-touchpad-on-toshiba-click-mini-not-working.patch queue-4.4/ahci-annotate-pci-ids-for-mobile-intel-chipsets-as-such.patch queue-4.4/bluetooth-btusb-restore-qca-rome-suspend-resume-fix-with-a-rewritten-version.patch

7 years, 9 months

1
0
0 0

Patch "Bluetooth: btsdio: Do not bind to non-removable BCM43341" 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 Bluetooth: btsdio: Do not bind to non-removable BCM43341 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: bluetooth-btsdio-do-not-bind-to-non-removable-bcm43341.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 b4cdaba274247c9c841c6a682c08fa91fb3aa549 Mon Sep 17 00:00:00 2001 From: Hans de Goede <hdegoede(a)redhat.com> Date: Wed, 29 Nov 2017 20:29:07 +0100 Subject: Bluetooth: btsdio: Do not bind to non-removable BCM43341 From: Hans de Goede <hdegoede(a)redhat.com> commit b4cdaba274247c9c841c6a682c08fa91fb3aa549 upstream. BCM43341 devices soldered onto the PCB (non-removable) always (AFAICT) use an UART connection for bluetooth. But they also advertise btsdio support on their 3th sdio function, this causes 2 problems: 1) A non functioning BT HCI getting registered 2) Since the btsdio driver does not have suspend/resume callbacks, mmc_sdio_pre_suspend will return -ENOSYS, causing mmc_pm_notify() to react as if the SDIO-card is removed and since the slot is marked as non-removable it will never get detected as inserted again. Which results in wifi no longer working after a suspend/resume. This commit fixes both by making btsdio ignore BCM43341 devices when connected to a slot which is marked non-removable. Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/bluetooth/btsdio.c | 9 +++++++++ 1 file changed, 9 insertions(+) --- a/drivers/bluetooth/btsdio.c +++ b/drivers/bluetooth/btsdio.c @@ -31,6 +31,7 @@ #include <linux/errno.h> #include <linux/skbuff.h> +#include <linux/mmc/host.h> #include <linux/mmc/sdio_ids.h> #include <linux/mmc/sdio_func.h> @@ -291,6 +292,14 @@ static int btsdio_probe(struct sdio_func tuple = tuple->next; } + /* BCM43341 devices soldered onto the PCB (non-removable) use an + * uart connection for bluetooth, ignore the BT SDIO interface. + */ + if (func->vendor == SDIO_VENDOR_ID_BROADCOM && + func->device == SDIO_DEVICE_ID_BROADCOM_43341 && + !mmc_card_is_removable(func->card->host)) + return -ENODEV; + data = devm_kzalloc(&func->dev, sizeof(*data), GFP_KERNEL); if (!data) return -ENOMEM; Patches currently in stable-queue which might be from hdegoede(a)redhat.com are queue-4.4/ahci-add-pci-ids-for-intel-bay-trail-cherry-trail-and-apollo-lake-ahci.patch queue-4.4/bluetooth-btsdio-do-not-bind-to-non-removable-bcm43341.patch queue-4.4/hid-quirks-fix-keyboard-touchpad-on-toshiba-click-mini-not-working.patch queue-4.4/ahci-annotate-pci-ids-for-mobile-intel-chipsets-as-such.patch queue-4.4/bluetooth-btusb-restore-qca-rome-suspend-resume-fix-with-a-rewritten-version.patch

7 years, 9 months

1
0
0 0

Patch "blk-mq: quiesce queue before freeing queue" 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 blk-mq: quiesce queue before freeing queue 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: blk-mq-quiesce-queue-before-freeing-queue.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 c2856ae2f315d754a0b6a268e4c6745b332b42e7 Mon Sep 17 00:00:00 2001 From: Ming Lei <ming.lei(a)redhat.com> Date: Sat, 6 Jan 2018 16:27:37 +0800 Subject: blk-mq: quiesce queue before freeing queue From: Ming Lei <ming.lei(a)redhat.com> commit c2856ae2f315d754a0b6a268e4c6745b332b42e7 upstream. After queue is frozen, dispatch still may happen, for example: 1) requests are submitted from several contexts 2) requests from all these contexts are inserted to queue, but may dispatch to LLD in one of these paths, but other paths sill need to move on even all these requests are completed(that means blk_mq_freeze_queue_wait() returns at that time) 3) dispatch after queue freezing still moves on and causes use-after-free, because request queue is freed This patch quiesces queue after it is frozen, and makes sure all in-progress dispatch are completed. This patch fixes the following kernel crash when running heavy IOs vs. deleting device: [ 36.719251] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 [ 36.720318] IP: kyber_has_work+0x14/0x40 [ 36.720847] PGD 254bf5067 P4D 254bf5067 PUD 255e6a067 PMD 0 [ 36.721584] Oops: 0000 [#1] PREEMPT SMP [ 36.722105] Dumping ftrace buffer: [ 36.722570] (ftrace buffer empty) [ 36.723057] Modules linked in: scsi_debug ebtable_filter ebtables ip6table_filter ip6_tables tcm_loop iscsi_target_mod target_core_file target_core_iblock target_core_pscsi target_core_mod xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack libcrc32c bridge stp llc fuse iptable_filter ip_tables sd_mod sg btrfs xor zstd_decompress zstd_compress xxhash raid6_pq mptsas mptscsih bcache crc32c_intel ahci mptbase libahci serio_raw scsi_transport_sas nvme libata shpchp lpc_ich virtio_scsi nvme_core binfmt_misc dm_mod iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi null_blk configs [ 36.733438] CPU: 2 PID: 2374 Comm: fio Not tainted 4.15.0-rc2.blk_mq_quiesce+ #714 [ 36.735143] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.9.3-1.fc25 04/01/2014 [ 36.736688] RIP: 0010:kyber_has_work+0x14/0x40 [ 36.737515] RSP: 0018:ffffc9000209bca0 EFLAGS: 00010202 [ 36.738431] RAX: 0000000000000008 RBX: ffff88025578bfc8 RCX: ffff880257bf4ed0 [ 36.739581] RDX: 0000000000000038 RSI: ffffffff81a98c6d RDI: ffff88025578bfc8 [ 36.740730] RBP: ffff880253cebfc8 R08: ffffc9000209bda0 R09: ffff8802554f3480 [ 36.741885] R10: ffffc9000209be60 R11: ffff880263f72538 R12: ffff88025573e9e8 [ 36.743036] R13: ffff88025578bfd0 R14: 0000000000000001 R15: 0000000000000000 [ 36.744189] FS: 00007f9b9bee67c0(0000) GS:ffff88027fc80000(0000) knlGS:0000000000000000 [ 36.746617] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 36.748483] CR2: 0000000000000008 CR3: 0000000254bf4001 CR4: 00000000003606e0 [ 36.750164] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 36.751455] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 36.752796] Call Trace: [ 36.753992] blk_mq_do_dispatch_sched+0x7f/0xe0 [ 36.755110] blk_mq_sched_dispatch_requests+0x119/0x190 [ 36.756179] __blk_mq_run_hw_queue+0x83/0x90 [ 36.757144] __blk_mq_delay_run_hw_queue+0xaf/0x110 [ 36.758046] blk_mq_run_hw_queue+0x24/0x70 [ 36.758845] blk_mq_flush_plug_list+0x1e7/0x270 [ 36.759676] blk_flush_plug_list+0xd6/0x240 [ 36.760463] blk_finish_plug+0x27/0x40 [ 36.761195] do_io_submit+0x19b/0x780 [ 36.761921] ? entry_SYSCALL_64_fastpath+0x1a/0x7d [ 36.762788] entry_SYSCALL_64_fastpath+0x1a/0x7d [ 36.763639] RIP: 0033:0x7f9b9699f697 [ 36.764352] RSP: 002b:00007ffc10f991b8 EFLAGS: 00000206 ORIG_RAX: 00000000000000d1 [ 36.765773] RAX: ffffffffffffffda RBX: 00000000008f6f00 RCX: 00007f9b9699f697 [ 36.766965] RDX: 0000000000a5e6c0 RSI: 0000000000000001 RDI: 00007f9b8462a000 [ 36.768377] RBP: 0000000000000000 R08: 0000000000000001 R09: 00000000008f6420 [ 36.769649] R10: 00007f9b846e5000 R11: 0000000000000206 R12: 00007f9b795d6a70 [ 36.770807] R13: 00007f9b795e4140 R14: 00007f9b795e3fe0 R15: 0000000100000000 [ 36.771955] Code: 83 c7 10 e9 3f 68 d1 ff 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 8b 97 b0 00 00 00 48 8d 42 08 48 83 c2 38 <48> 3b 00 74 06 b8 01 00 00 00 c3 48 3b 40 08 75 f4 48 83 c0 10 [ 36.775004] RIP: kyber_has_work+0x14/0x40 RSP: ffffc9000209bca0 [ 36.776012] CR2: 0000000000000008 [ 36.776690] ---[ end trace 4045cbce364ff2a4 ]--- [ 36.777527] Kernel panic - not syncing: Fatal exception [ 36.778526] Dumping ftrace buffer: [ 36.779313] (ftrace buffer empty) [ 36.780081] Kernel Offset: disabled [ 36.780877] ---[ end Kernel panic - not syncing: Fatal exception Reviewed-by: Christoph Hellwig <hch(a)lst.de> Tested-by: Yi Zhang <yi.zhang(a)redhat.com> Signed-off-by: Ming Lei <ming.lei(a)redhat.com> Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- block/blk-core.c | 9 +++++++++ 1 file changed, 9 insertions(+) --- a/block/blk-core.c +++ b/block/blk-core.c @@ -579,6 +579,15 @@ void blk_cleanup_queue(struct request_qu queue_flag_set(QUEUE_FLAG_DEAD, q); spin_unlock_irq(lock); + /* + * make sure all in-progress dispatch are completed because + * blk_freeze_queue() can only complete all requests, and + * dispatch may still be in-progress since we dispatch requests + * from more than one contexts + */ + if (q->mq_ops) + blk_mq_quiesce_queue(q); + /* for synchronous bio-based driver finish in-flight integrity i/o */ blk_flush_integrity(); Patches currently in stable-queue which might be from ming.lei(a)redhat.com are queue-4.4/blk-mq-quiesce-queue-before-freeing-queue.patch

7 years, 9 months

1
0
0 0

Patch "arm: KVM: Fix SMCCC handling of unimplemented SMC/HVC calls" 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 arm: KVM: Fix SMCCC handling of unimplemented SMC/HVC calls 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: arm-kvm-fix-smccc-handling-of-unimplemented-smc-hvc-calls.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 20e8175d246e9f9deb377f2784b3e7dfb2ad3e86 Mon Sep 17 00:00:00 2001 From: Marc Zyngier <marc.zyngier(a)arm.com> Date: Tue, 6 Feb 2018 17:56:06 +0000 Subject: arm: KVM: Fix SMCCC handling of unimplemented SMC/HVC calls From: Marc Zyngier <marc.zyngier(a)arm.com> commit 20e8175d246e9f9deb377f2784b3e7dfb2ad3e86 upstream. KVM doesn't follow the SMCCC when it comes to unimplemented calls, and inject an UNDEF instead of returning an error. Since firmware calls are now used for security mitigation, they are becoming more common, and the undef is counter productive. Instead, let's follow the SMCCC which states that -1 must be returned to the caller when getting an unknown function number. Tested-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com> Signed-off-by: Catalin Marinas <catalin.marinas(a)arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/kvm/handle_exit.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) --- a/arch/arm/kvm/handle_exit.c +++ b/arch/arm/kvm/handle_exit.c @@ -45,7 +45,7 @@ static int handle_hvc(struct kvm_vcpu *v ret = kvm_psci_call(vcpu); if (ret < 0) { - kvm_inject_undefined(vcpu); + vcpu_set_reg(vcpu, 0, ~0UL); return 1; } @@ -54,7 +54,16 @@ static int handle_hvc(struct kvm_vcpu *v static int handle_smc(struct kvm_vcpu *vcpu, struct kvm_run *run) { - kvm_inject_undefined(vcpu); + /* + * "If an SMC instruction executed at Non-secure EL1 is + * trapped to EL2 because HCR_EL2.TSC is 1, the exception is a + * Trap exception, not a Secure Monitor Call exception [...]" + * + * We need to advance the PC after the trap, as it would + * otherwise return to the same address... + */ + vcpu_set_reg(vcpu, 0, ~0UL); + kvm_skip_instr(vcpu, kvm_vcpu_trap_il_is32bit(vcpu)); return 1; } Patches currently in stable-queue which might be from marc.zyngier(a)arm.com are queue-4.4/arm-kvm-fix-smccc-handling-of-unimplemented-smc-hvc-calls.patch

7 years, 9 months

1
0
0 0

Patch "alpha: fix reboot on Avanti platform" 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 alpha: fix reboot on Avanti platform 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: alpha-fix-reboot-on-avanti-platform.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 55fc633c41a08ce9244ff5f528f420b16b1e04d6 Mon Sep 17 00:00:00 2001 From: Mikulas Patocka <mpatocka(a)redhat.com> Date: Tue, 2 Jan 2018 13:59:54 -0500 Subject: alpha: fix reboot on Avanti platform From: Mikulas Patocka <mpatocka(a)redhat.com> commit 55fc633c41a08ce9244ff5f528f420b16b1e04d6 upstream. We need to define NEED_SRM_SAVE_RESTORE on the Avanti, otherwise we get machine check exception when attempting to reboot the machine. Signed-off-by: Mikulas Patocka <mpatocka(a)redhat.com> Signed-off-by: Matt Turner <mattst88(a)gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/alpha/kernel/pci_impl.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/arch/alpha/kernel/pci_impl.h +++ b/arch/alpha/kernel/pci_impl.h @@ -143,7 +143,8 @@ struct pci_iommu_arena }; #if defined(CONFIG_ALPHA_SRM) && \ - (defined(CONFIG_ALPHA_CIA) || defined(CONFIG_ALPHA_LCA)) + (defined(CONFIG_ALPHA_CIA) || defined(CONFIG_ALPHA_LCA) || \ + defined(CONFIG_ALPHA_AVANTI)) # define NEED_SRM_SAVE_RESTORE #else # undef NEED_SRM_SAVE_RESTORE Patches currently in stable-queue which might be from mpatocka(a)redhat.com are queue-4.4/alpha-fix-crash-if-pthread_create-races-with-signal-delivery.patch queue-4.4/alpha-fix-reboot-on-avanti-platform.patch

7 years, 9 months

1
0
0 0

Patch "alpha: fix crash if pthread_create races with signal delivery" 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 alpha: fix crash if pthread_create races with signal delivery 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: alpha-fix-crash-if-pthread_create-races-with-signal-delivery.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 21ffceda1c8b3807615c40d440d7815e0c85d366 Mon Sep 17 00:00:00 2001 From: Mikulas Patocka <mpatocka(a)redhat.com> Date: Tue, 2 Jan 2018 14:01:34 -0500 Subject: alpha: fix crash if pthread_create races with signal delivery From: Mikulas Patocka <mpatocka(a)redhat.com> commit 21ffceda1c8b3807615c40d440d7815e0c85d366 upstream. On alpha, a process will crash if it attempts to start a thread and a signal is delivered at the same time. The crash can be reproduced with this program: https://cygwin.com/ml/cygwin/2014-11/msg00473.html The reason for the crash is this: * we call the clone syscall * we go to the function copy_process * copy process calls copy_thread_tls, it is a wrapper around copy_thread * copy_thread sets the tls pointer: childti->pcb.unique = regs->r20 * copy_thread sets regs->r20 to zero * we go back to copy_process * copy process checks "if (signal_pending(current))" and returns -ERESTARTNOINTR * the clone syscall is restarted, but this time, regs->r20 is zero, so the new thread is created with zero tls pointer * the new thread crashes in start_thread when attempting to access tls The comment in the code says that setting the register r20 is some compatibility with OSF/1. But OSF/1 doesn't use the CLONE_SETTLS flag, so we don't have to zero r20 if CLONE_SETTLS is set. This patch fixes the bug by zeroing regs->r20 only if CLONE_SETTLS is not set. Signed-off-by: Mikulas Patocka <mpatocka(a)redhat.com> Signed-off-by: Matt Turner <mattst88(a)gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/alpha/kernel/process.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/arch/alpha/kernel/process.c +++ b/arch/alpha/kernel/process.c @@ -273,12 +273,13 @@ copy_thread(unsigned long clone_flags, u application calling fork. */ if (clone_flags & CLONE_SETTLS) childti->pcb.unique = regs->r20; + else + regs->r20 = 0; /* OSF/1 has some strange fork() semantics. */ childti->pcb.usp = usp ?: rdusp(); *childregs = *regs; childregs->r0 = 0; childregs->r19 = 0; childregs->r20 = 1; /* OSF/1 has some strange fork() semantics. */ - regs->r20 = 0; stack = ((struct switch_stack *) regs) - 1; *childstack = *stack; childstack->r26 = (unsigned long) ret_from_fork; Patches currently in stable-queue which might be from mpatocka(a)redhat.com are queue-4.4/alpha-fix-crash-if-pthread_create-races-with-signal-delivery.patch queue-4.4/alpha-fix-reboot-on-avanti-platform.patch

7 years, 9 months

1
0
0 0

Patch "xtensa: fix futex_atomic_cmpxchg_inatomic" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled xtensa: fix futex_atomic_cmpxchg_inatomic to the 4.15-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: xtensa-fix-futex_atomic_cmpxchg_inatomic.patch and it can be found in the queue-4.15 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 ca47480921587ae30417dd234a9f79af188e3666 Mon Sep 17 00:00:00 2001 From: Max Filippov <jcmvbkbc(a)gmail.com> Date: Fri, 5 Jan 2018 14:27:58 -0800 Subject: xtensa: fix futex_atomic_cmpxchg_inatomic From: Max Filippov <jcmvbkbc(a)gmail.com> commit ca47480921587ae30417dd234a9f79af188e3666 upstream. Return 0 if the operation was successful, not the userspace memory value. Check that userspace value equals passed oldval, not itself. Don't update *uval if the value wasn't read from userspace memory. This fixes process hang due to infinite loop in futex_lock_pi. It also fixes a bunch of glibc tests nptl/tst-mutexpi*. Signed-off-by: Max Filippov <jcmvbkbc(a)gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/xtensa/include/asm/futex.h | 23 ++++++++++------------- 1 file changed, 10 insertions(+), 13 deletions(-) --- a/arch/xtensa/include/asm/futex.h +++ b/arch/xtensa/include/asm/futex.h @@ -92,7 +92,6 @@ futex_atomic_cmpxchg_inatomic(u32 *uval, u32 oldval, u32 newval) { int ret = 0; - u32 prev; if (!access_ok(VERIFY_WRITE, uaddr, sizeof(u32))) return -EFAULT; @@ -103,26 +102,24 @@ futex_atomic_cmpxchg_inatomic(u32 *uval, __asm__ __volatile__ ( " # futex_atomic_cmpxchg_inatomic\n" - "1: l32i %1, %3, 0\n" - " mov %0, %5\n" - " wsr %1, scompare1\n" - "2: s32c1i %0, %3, 0\n" - "3:\n" + " wsr %5, scompare1\n" + "1: s32c1i %1, %4, 0\n" + " s32i %1, %6, 0\n" + "2:\n" " .section .fixup,\"ax\"\n" " .align 4\n" - "4: .long 3b\n" - "5: l32r %1, 4b\n" - " movi %0, %6\n" + "3: .long 2b\n" + "4: l32r %1, 3b\n" + " movi %0, %7\n" " jx %1\n" " .previous\n" " .section __ex_table,\"a\"\n" - " .long 1b,5b,2b,5b\n" + " .long 1b,4b\n" " .previous\n" - : "+r" (ret), "=&r" (prev), "+m" (*uaddr) - : "r" (uaddr), "r" (oldval), "r" (newval), "I" (-EFAULT) + : "+r" (ret), "+r" (newval), "+m" (*uaddr), "+m" (*uval) + : "r" (uaddr), "r" (oldval), "r" (uval), "I" (-EFAULT) : "memory"); - *uval = prev; return ret; } Patches currently in stable-queue which might be from jcmvbkbc(a)gmail.com are queue-4.15/xtensa-fix-futex_atomic_cmpxchg_inatomic.patch

7 years, 9 months

1
0
0 0

Patch "watchdog: imx2_wdt: restore previous timeout after suspend+resume" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled watchdog: imx2_wdt: restore previous timeout after suspend+resume to the 4.15-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: watchdog-imx2_wdt-restore-previous-timeout-after-suspend-resume.patch and it can be found in the queue-4.15 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 0be267255cef64e1c58475baa7b25568355a3816 Mon Sep 17 00:00:00 2001 From: Martin Kaiser <martin(a)kaiser.cx> Date: Mon, 1 Jan 2018 18:26:47 +0100 Subject: watchdog: imx2_wdt: restore previous timeout after suspend+resume From: Martin Kaiser <martin(a)kaiser.cx> commit 0be267255cef64e1c58475baa7b25568355a3816 upstream. When the watchdog device is suspended, its timeout is set to the maximum value. During resume, the previously set timeout should be restored. This does not work at the moment. The suspend function calls imx2_wdt_set_timeout(wdog, IMX2_WDT_MAX_TIME); and resume reverts this by calling imx2_wdt_set_timeout(wdog, wdog->timeout); However, imx2_wdt_set_timeout() updates wdog->timeout. Therefore, wdog->timeout is set to IMX2_WDT_MAX_TIME when we enter the resume function. Fix this by adding a new function __imx2_wdt_set_timeout() which only updates the hardware settings. imx2_wdt_set_timeout() now calls __imx2_wdt_set_timeout() and then saves the new timeout to wdog->timeout. During suspend, we call __imx2_wdt_set_timeout() directly so that wdog->timeout won't be updated and we can restore the previous value during resume. This approach makes wdog->timeout different from the actual setting in the hardware which is usually not a good thing. However, the two differ only while we're suspended and no kernel code is running, so it should be ok in this case. Signed-off-by: Martin Kaiser <martin(a)kaiser.cx> Reviewed-by: Guenter Roeck <linux(a)roeck-us.net> Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim(a)iguana.be> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/watchdog/imx2_wdt.c | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-) --- a/drivers/watchdog/imx2_wdt.c +++ b/drivers/watchdog/imx2_wdt.c @@ -169,15 +169,21 @@ static int imx2_wdt_ping(struct watchdog return 0; } -static int imx2_wdt_set_timeout(struct watchdog_device *wdog, - unsigned int new_timeout) +static void __imx2_wdt_set_timeout(struct watchdog_device *wdog, + unsigned int new_timeout) { struct imx2_wdt_device *wdev = watchdog_get_drvdata(wdog); - wdog->timeout = new_timeout; - regmap_update_bits(wdev->regmap, IMX2_WDT_WCR, IMX2_WDT_WCR_WT, WDOG_SEC_TO_COUNT(new_timeout)); +} + +static int imx2_wdt_set_timeout(struct watchdog_device *wdog, + unsigned int new_timeout) +{ + __imx2_wdt_set_timeout(wdog, new_timeout); + + wdog->timeout = new_timeout; return 0; } @@ -371,7 +377,11 @@ static int imx2_wdt_suspend(struct devic /* The watchdog IP block is running */ if (imx2_wdt_is_running(wdev)) { - imx2_wdt_set_timeout(wdog, IMX2_WDT_MAX_TIME); + /* + * Don't update wdog->timeout, we'll restore the current value + * during resume. + */ + __imx2_wdt_set_timeout(wdog, IMX2_WDT_MAX_TIME); imx2_wdt_ping(wdog); } Patches currently in stable-queue which might be from martin(a)kaiser.cx are queue-4.15/watchdog-imx2_wdt-restore-previous-timeout-after-suspend-resume.patch

7 years, 9 months

1
0
0 0

Patch "signal/sh: Ensure si_signo is initialized in do_divide_error" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled signal/sh: Ensure si_signo is initialized in do_divide_error to the 4.15-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: signal-sh-ensure-si_signo-is-initialized-in-do_divide_error.patch and it can be found in the queue-4.15 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 0e88bb002a9b2ee8cc3cc9478ce2dc126f849696 Mon Sep 17 00:00:00 2001 From: "Eric W. Biederman" <ebiederm(a)xmission.com> Date: Mon, 24 Jul 2017 17:30:30 -0500 Subject: signal/sh: Ensure si_signo is initialized in do_divide_error From: Eric W. Biederman <ebiederm(a)xmission.com> commit 0e88bb002a9b2ee8cc3cc9478ce2dc126f849696 upstream. Set si_signo. Cc: Yoshinori Sato <ysato(a)users.sourceforge.jp> Cc: Rich Felker <dalias(a)libc.org> Cc: Paul Mundt <lethal(a)linux-sh.org> Cc: linux-sh(a)vger.kernel.org Fixes: 0983b31849bb ("sh: Wire up division and address error exceptions on SH-2A.") Signed-off-by: "Eric W. Biederman" <ebiederm(a)xmission.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/sh/kernel/traps_32.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/arch/sh/kernel/traps_32.c +++ b/arch/sh/kernel/traps_32.c @@ -609,7 +609,8 @@ asmlinkage void do_divide_error(unsigned break; } - force_sig_info(SIGFPE, &info, current); + info.si_signo = SIGFPE; + force_sig_info(info.si_signo, &info, current); } #endif Patches currently in stable-queue which might be from ebiederm(a)xmission.com are queue-4.15/signal-openrisc-fix-do_unaligned_access-to-send-the-proper-signal.patch queue-4.15/signal-sh-ensure-si_signo-is-initialized-in-do_divide_error.patch

7 years, 9 months

1
0
0 0

Patch "signal/openrisc: Fix do_unaligned_access to send the proper signal" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled signal/openrisc: Fix do_unaligned_access to send the proper signal to the 4.15-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: signal-openrisc-fix-do_unaligned_access-to-send-the-proper-signal.patch and it can be found in the queue-4.15 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 500d58300571b6602341b041f97c082a461ef994 Mon Sep 17 00:00:00 2001 From: "Eric W. Biederman" <ebiederm(a)xmission.com> Date: Tue, 1 Aug 2017 04:16:47 -0500 Subject: signal/openrisc: Fix do_unaligned_access to send the proper signal From: Eric W. Biederman <ebiederm(a)xmission.com> commit 500d58300571b6602341b041f97c082a461ef994 upstream. While reviewing the signal sending on openrisc the do_unaligned_access function stood out because it is obviously wrong. A comment about an si_code set above when actually si_code is never set. Leading to a random si_code being sent to userspace in the event of an unaligned access. Looking further SIGBUS BUS_ADRALN is the proper pair of signal and si_code to send for an unaligned access. That is what other architectures do and what is required by posix. Given that do_unaligned_access is broken in a way that no one can be relying on it on openrisc fix the code to just do the right thing. Fixes: 769a8a96229e ("OpenRISC: Traps") Cc: Jonas Bonn <jonas(a)southpole.se> Cc: Stefan Kristiansson <stefan.kristiansson(a)saunalahti.fi> Cc: Stafford Horne <shorne(a)gmail.com> Cc: Arnd Bergmann <arnd(a)arndb.de> Cc: openrisc(a)lists.librecores.org Acked-by: Stafford Horne <shorne(a)gmail.com> Signed-off-by: "Eric W. Biederman" <ebiederm(a)xmission.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/openrisc/kernel/traps.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) --- a/arch/openrisc/kernel/traps.c +++ b/arch/openrisc/kernel/traps.c @@ -266,12 +266,12 @@ asmlinkage void do_unaligned_access(stru siginfo_t info; if (user_mode(regs)) { - /* Send a SIGSEGV */ - info.si_signo = SIGSEGV; + /* Send a SIGBUS */ + info.si_signo = SIGBUS; info.si_errno = 0; - /* info.si_code has been set above */ - info.si_addr = (void *)address; - force_sig_info(SIGSEGV, &info, current); + info.si_code = BUS_ADRALN; + info.si_addr = (void __user *)address; + force_sig_info(SIGBUS, &info, current); } else { printk("KERNEL: Unaligned Access 0x%.8lx\n", address); show_registers(regs); Patches currently in stable-queue which might be from ebiederm(a)xmission.com are queue-4.15/signal-openrisc-fix-do_unaligned_access-to-send-the-proper-signal.patch queue-4.15/signal-sh-ensure-si_signo-is-initialized-in-do_divide_error.patch

7 years, 9 months

1
0
0 0

Patch "Revert "Bluetooth: btusb: fix QCA Rome suspend/resume"" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Revert "Bluetooth: btusb: fix QCA Rome suspend/resume" to the 4.15-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: revert-bluetooth-btusb-fix-qca-rome-suspend-resume.patch and it can be found in the queue-4.15 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 7d06d5895c159f64c46560dc258e553ad8670fe0 Mon Sep 17 00:00:00 2001 From: Kai-Heng Feng <kai.heng.feng(a)canonical.com> Date: Wed, 20 Dec 2017 19:00:07 +0800 Subject: Revert "Bluetooth: btusb: fix QCA Rome suspend/resume" From: Kai-Heng Feng <kai.heng.feng(a)canonical.com> commit 7d06d5895c159f64c46560dc258e553ad8670fe0 upstream. This reverts commit fd865802c66bc451dc515ed89360f84376ce1a56. This commit causes a regression on some QCA ROME chips. The USB device reset happens in btusb_open(), hence firmware loading gets interrupted. Furthermore, this commit stops working after commit ("a0085f2510e8976614ad8f766b209448b385492f Bluetooth: btusb: driver to enable the usb-wakeup feature"). Reset-resume quirk only gets enabled in btusb_suspend() when it's not a wakeup source. If we really want to reset the USB device, we need to do it before btusb_open(). Let's handle it in drivers/usb/core/quirks.c. Cc: Leif Liddy <leif.linux(a)gmail.com> Cc: Matthias Kaehlcke <mka(a)chromium.org> Cc: Brian Norris <briannorris(a)chromium.org> Cc: Daniel Drake <drake(a)endlessm.com> Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> Reviewed-by: Brian Norris <briannorris(a)chromium.org> Tested-by: Brian Norris <briannorris(a)chromium.org> Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/bluetooth/btusb.c | 6 ------ 1 file changed, 6 deletions(-) --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -3117,12 +3117,6 @@ static int btusb_probe(struct usb_interf if (id->driver_info & BTUSB_QCA_ROME) { data->setup_on_usb = btusb_setup_qca; hdev->set_bdaddr = btusb_set_bdaddr_ath3012; - - /* QCA Rome devices lose their updated firmware over suspend, - * but the USB hub doesn't notice any status change. - * Explicitly request a device reset on resume. - */ - set_bit(BTUSB_RESET_RESUME, &data->flags); } #ifdef CONFIG_BT_HCIBTUSB_RTL Patches currently in stable-queue which might be from kai.heng.feng(a)canonical.com are queue-4.15/revert-bluetooth-btusb-fix-qca-rome-suspend-resume.patch queue-4.15/bluetooth-btusb-restore-qca-rome-suspend-resume-fix-with-a-rewritten-version.patch

7 years, 9 months

1
0
0 0

Patch "pktcdvd: Fix pkt_setup_dev() error path" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled pktcdvd: Fix pkt_setup_dev() error path to the 4.15-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: pktcdvd-fix-pkt_setup_dev-error-path.patch and it can be found in the queue-4.15 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 5a0ec388ef0f6e33841aeb810d7fa23f049ec4cd Mon Sep 17 00:00:00 2001 From: Bart Van Assche <bart.vanassche(a)wdc.com> Date: Tue, 2 Jan 2018 11:39:47 -0800 Subject: pktcdvd: Fix pkt_setup_dev() error path From: Bart Van Assche <bart.vanassche(a)wdc.com> commit 5a0ec388ef0f6e33841aeb810d7fa23f049ec4cd upstream. Commit 523e1d399ce0 ("block: make gendisk hold a reference to its queue") modified add_disk() and disk_release() but did not update any of the error paths that trigger a put_disk() call after disk->queue has been assigned. That introduced the following behavior in the pktcdvd driver if pkt_new_dev() fails: Kernel BUG at 00000000e98fd882 [verbose debug info unavailable] Since disk_release() calls blk_put_queue() anyway if disk->queue != NULL, fix this by removing the blk_cleanup_queue() call from the pkt_setup_dev() error path. Fixes: commit 523e1d399ce0 ("block: make gendisk hold a reference to its queue") Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com> Cc: Tejun Heo <tj(a)kernel.org> Cc: Maciej S. Szmigiero <mail(a)maciej.szmigiero.name> Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/block/pktcdvd.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) --- a/drivers/block/pktcdvd.c +++ b/drivers/block/pktcdvd.c @@ -2745,7 +2745,7 @@ static int pkt_setup_dev(dev_t dev, dev_ pd->pkt_dev = MKDEV(pktdev_major, idx); ret = pkt_new_dev(pd, dev); if (ret) - goto out_new_dev; + goto out_mem2; /* inherit events of the host device */ disk->events = pd->bdev->bd_disk->events; @@ -2763,8 +2763,6 @@ static int pkt_setup_dev(dev_t dev, dev_ mutex_unlock(&ctl_mutex); return 0; -out_new_dev: - blk_cleanup_queue(disk->queue); out_mem2: put_disk(disk); out_mem: Patches currently in stable-queue which might be from bart.vanassche(a)wdc.com are queue-4.15/pktcdvd-fix-pkt_setup_dev-error-path.patch queue-4.15/pktcdvd-fix-a-recently-introduced-null-pointer-dereference.patch

7 years, 9 months

1
0
0 0

Patch "pktcdvd: Fix a recently introduced NULL pointer dereference" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled pktcdvd: Fix a recently introduced NULL pointer dereference to the 4.15-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: pktcdvd-fix-a-recently-introduced-null-pointer-dereference.patch and it can be found in the queue-4.15 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 882d4171a8950646413b1a3cbe0e4a6a612fe82e Mon Sep 17 00:00:00 2001 From: Bart Van Assche <bart.vanassche(a)wdc.com> Date: Tue, 2 Jan 2018 11:39:48 -0800 Subject: pktcdvd: Fix a recently introduced NULL pointer dereference From: Bart Van Assche <bart.vanassche(a)wdc.com> commit 882d4171a8950646413b1a3cbe0e4a6a612fe82e upstream. Call bdev_get_queue(bdev) after bdev->bd_disk has been initialized instead of just before that pointer has been initialized. This patch avoids that the following command pktsetup 1 /dev/sr0 triggers the following kernel crash: BUG: unable to handle kernel NULL pointer dereference at 0000000000000548 IP: pkt_setup_dev+0x2db/0x670 [pktcdvd] CPU: 2 PID: 724 Comm: pktsetup Not tainted 4.15.0-rc4-dbg+ #1 Call Trace: pkt_ctl_ioctl+0xce/0x1c0 [pktcdvd] do_vfs_ioctl+0x8e/0x670 SyS_ioctl+0x3c/0x70 entry_SYSCALL_64_fastpath+0x23/0x9a Reported-by: Maciej S. Szmigiero <mail(a)maciej.szmigiero.name> Fixes: commit ca18d6f769d2 ("block: Make most scsi_req_init() calls implicit") Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com> Tested-by: Maciej S. Szmigiero <mail(a)maciej.szmigiero.name> Cc: Maciej S. Szmigiero <mail(a)maciej.szmigiero.name> Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/block/pktcdvd.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- a/drivers/block/pktcdvd.c +++ b/drivers/block/pktcdvd.c @@ -2579,14 +2579,14 @@ static int pkt_new_dev(struct pktcdvd_de bdev = bdget(dev); if (!bdev) return -ENOMEM; + ret = blkdev_get(bdev, FMODE_READ | FMODE_NDELAY, NULL); + if (ret) + return ret; if (!blk_queue_scsi_passthrough(bdev_get_queue(bdev))) { WARN_ONCE(true, "Attempt to register a non-SCSI queue\n"); - bdput(bdev); + blkdev_put(bdev, FMODE_READ | FMODE_NDELAY); return -EINVAL; } - ret = blkdev_get(bdev, FMODE_READ | FMODE_NDELAY, NULL); - if (ret) - return ret; /* This is safe, since we have a reference from open(). */ __module_get(THIS_MODULE); Patches currently in stable-queue which might be from bart.vanassche(a)wdc.com are queue-4.15/pktcdvd-fix-pkt_setup_dev-error-path.patch queue-4.15/pktcdvd-fix-a-recently-introduced-null-pointer-dereference.patch

7 years, 9 months

1
0
0 0

Patch "pipe: fix off-by-one error when checking buffer limits" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled pipe: fix off-by-one error when checking buffer limits to the 4.15-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: pipe-fix-off-by-one-error-when-checking-buffer-limits.patch and it can be found in the queue-4.15 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 9903a91c763ecdae333a04a9d89d79d2b8966503 Mon Sep 17 00:00:00 2001 From: Eric Biggers <ebiggers(a)google.com> Date: Tue, 6 Feb 2018 15:41:56 -0800 Subject: pipe: fix off-by-one error when checking buffer limits From: Eric Biggers <ebiggers(a)google.com> commit 9903a91c763ecdae333a04a9d89d79d2b8966503 upstream. With pipe-user-pages-hard set to 'N', users were actually only allowed up to 'N - 1' buffers; and likewise for pipe-user-pages-soft. Fix this to allow up to 'N' buffers, as would be expected. Link: http://lkml.kernel.org/r/20180111052902.14409-5-ebiggers3@gmail.com Fixes: b0b91d18e2e9 ("pipe: fix limit checking in pipe_set_size()") Signed-off-by: Eric Biggers <ebiggers(a)google.com> Acked-by: Willy Tarreau <w(a)1wt.eu> Acked-by: Kees Cook <keescook(a)chromium.org> Acked-by: Joe Lawrence <joe.lawrence(a)redhat.com> Cc: Alexander Viro <viro(a)zeniv.linux.org.uk> Cc: "Luis R . Rodriguez" <mcgrof(a)kernel.org> Cc: Michael Kerrisk <mtk.manpages(a)gmail.com> Cc: Mikulas Patocka <mpatocka(a)redhat.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/pipe.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/fs/pipe.c +++ b/fs/pipe.c @@ -610,12 +610,12 @@ static unsigned long account_pipe_buffer static bool too_many_pipe_buffers_soft(unsigned long user_bufs) { - return pipe_user_pages_soft && user_bufs >= pipe_user_pages_soft; + return pipe_user_pages_soft && user_bufs > pipe_user_pages_soft; } static bool too_many_pipe_buffers_hard(unsigned long user_bufs) { - return pipe_user_pages_hard && user_bufs >= pipe_user_pages_hard; + return pipe_user_pages_hard && user_bufs > pipe_user_pages_hard; } static bool is_unprivileged_user(void) Patches currently in stable-queue which might be from ebiggers(a)google.com are queue-4.15/pipe-fix-off-by-one-error-when-checking-buffer-limits.patch queue-4.15/crypto-hash-annotate-algorithms-taking-optional-key.patch queue-4.15/crypto-cryptd-pass-through-absence-of-setkey.patch queue-4.15/crypto-hash-prevent-using-keyed-hashes-without-setting-key.patch queue-4.15/ubifs-free-the-encrypted-symlink-target.patch queue-4.15/pipe-actually-allow-root-to-exceed-the-pipe-buffer-limits.patch queue-4.15/kernel-relay.c-revert-kernel-relay.c-fix-potential-memory-leak.patch queue-4.15/nfs-reject-request-for-id_legacy-key-without-auxdata.patch queue-4.15/crypto-poly1305-remove-setkey-method.patch queue-4.15/crypto-sha512-mb-initialize-pending-lengths-correctly.patch queue-4.15/crypto-hash-introduce-crypto_hash_alg_has_setkey.patch queue-4.15/crypto-mcryptd-pass-through-absence-of-setkey.patch

7 years, 9 months

1
0
0 0

Patch "pipe: actually allow root to exceed the pipe buffer limits" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled pipe: actually allow root to exceed the pipe buffer limits to the 4.15-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: pipe-actually-allow-root-to-exceed-the-pipe-buffer-limits.patch and it can be found in the queue-4.15 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 85c2dd5473b2718b4b63e74bfeb1ca876868e11f Mon Sep 17 00:00:00 2001 From: Eric Biggers <ebiggers(a)google.com> Date: Tue, 6 Feb 2018 15:41:53 -0800 Subject: pipe: actually allow root to exceed the pipe buffer limits From: Eric Biggers <ebiggers(a)google.com> commit 85c2dd5473b2718b4b63e74bfeb1ca876868e11f upstream. pipe-user-pages-hard and pipe-user-pages-soft are only supposed to apply to unprivileged users, as documented in both Documentation/sysctl/fs.txt and the pipe(7) man page. However, the capabilities are actually only checked when increasing a pipe's size using F_SETPIPE_SZ, not when creating a new pipe. Therefore, if pipe-user-pages-hard has been set, the root user can run into it and be unable to create pipes. Similarly, if pipe-user-pages-soft has been set, the root user can run into it and have their pipes limited to 1 page each. Fix this by allowing the privileged override in both cases. Link: http://lkml.kernel.org/r/20180111052902.14409-4-ebiggers3@gmail.com Fixes: 759c01142a5d ("pipe: limit the per-user amount of pages allocated in pipes") Signed-off-by: Eric Biggers <ebiggers(a)google.com> Acked-by: Kees Cook <keescook(a)chromium.org> Acked-by: Joe Lawrence <joe.lawrence(a)redhat.com> Cc: Alexander Viro <viro(a)zeniv.linux.org.uk> Cc: "Luis R . Rodriguez" <mcgrof(a)kernel.org> Cc: Michael Kerrisk <mtk.manpages(a)gmail.com> Cc: Mikulas Patocka <mpatocka(a)redhat.com> Cc: Willy Tarreau <w(a)1wt.eu> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/pipe.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) --- a/fs/pipe.c +++ b/fs/pipe.c @@ -618,6 +618,11 @@ static bool too_many_pipe_buffers_hard(u return pipe_user_pages_hard && user_bufs >= pipe_user_pages_hard; } +static bool is_unprivileged_user(void) +{ + return !capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN); +} + struct pipe_inode_info *alloc_pipe_info(void) { struct pipe_inode_info *pipe; @@ -634,12 +639,12 @@ struct pipe_inode_info *alloc_pipe_info( user_bufs = account_pipe_buffers(user, 0, pipe_bufs); - if (too_many_pipe_buffers_soft(user_bufs)) { + if (too_many_pipe_buffers_soft(user_bufs) && is_unprivileged_user()) { user_bufs = account_pipe_buffers(user, pipe_bufs, 1); pipe_bufs = 1; } - if (too_many_pipe_buffers_hard(user_bufs)) + if (too_many_pipe_buffers_hard(user_bufs) && is_unprivileged_user()) goto out_revert_acct; pipe->bufs = kcalloc(pipe_bufs, sizeof(struct pipe_buffer), @@ -1069,7 +1074,7 @@ static long pipe_set_size(struct pipe_in if (nr_pages > pipe->buffers && (too_many_pipe_buffers_hard(user_bufs) || too_many_pipe_buffers_soft(user_bufs)) && - !capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN)) { + is_unprivileged_user()) { ret = -EPERM; goto out_revert_acct; } Patches currently in stable-queue which might be from ebiggers(a)google.com are queue-4.15/pipe-fix-off-by-one-error-when-checking-buffer-limits.patch queue-4.15/crypto-hash-annotate-algorithms-taking-optional-key.patch queue-4.15/crypto-cryptd-pass-through-absence-of-setkey.patch queue-4.15/crypto-hash-prevent-using-keyed-hashes-without-setting-key.patch queue-4.15/ubifs-free-the-encrypted-symlink-target.patch queue-4.15/pipe-actually-allow-root-to-exceed-the-pipe-buffer-limits.patch queue-4.15/kernel-relay.c-revert-kernel-relay.c-fix-potential-memory-leak.patch queue-4.15/nfs-reject-request-for-id_legacy-key-without-auxdata.patch queue-4.15/crypto-poly1305-remove-setkey-method.patch queue-4.15/crypto-sha512-mb-initialize-pending-lengths-correctly.patch queue-4.15/crypto-hash-introduce-crypto_hash_alg_has_setkey.patch queue-4.15/crypto-mcryptd-pass-through-absence-of-setkey.patch

7 years, 9 months

1
0
0 0

Patch "pinctrl: sx150x: Unregister the pinctrl on release" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled pinctrl: sx150x: Unregister the pinctrl on release to the 4.15-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: pinctrl-sx150x-unregister-the-pinctrl-on-release.patch and it can be found in the queue-4.15 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 0657cb50b5a75abd92956028727dc255d690a4a6 Mon Sep 17 00:00:00 2001 From: Peter Rosin <peda(a)axentia.se> Date: Wed, 17 Jan 2018 14:34:21 +0100 Subject: pinctrl: sx150x: Unregister the pinctrl on release From: Peter Rosin <peda(a)axentia.se> commit 0657cb50b5a75abd92956028727dc255d690a4a6 upstream. There is no matching call to pinctrl_unregister, so switch to the managed devm_pinctrl_register to clean up properly when done. Fixes: 9e80f9064e73 ("pinctrl: Add SX150X GPIO Extender Pinctrl Driver") Signed-off-by: Peter Rosin <peda(a)axentia.se> Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/pinctrl/pinctrl-sx150x.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/pinctrl/pinctrl-sx150x.c +++ b/drivers/pinctrl/pinctrl-sx150x.c @@ -1225,7 +1225,7 @@ static int sx150x_probe(struct i2c_clien pctl->pinctrl_desc.npins = pctl->data->npins; pctl->pinctrl_desc.owner = THIS_MODULE; - pctl->pctldev = pinctrl_register(&pctl->pinctrl_desc, dev, pctl); + pctl->pctldev = devm_pinctrl_register(dev, &pctl->pinctrl_desc, pctl); if (IS_ERR(pctl->pctldev)) { dev_err(dev, "Failed to register pinctrl device\n"); return PTR_ERR(pctl->pctldev); Patches currently in stable-queue which might be from peda(a)axentia.se are queue-4.15/pinctrl-sx150x-register-pinctrl-before-adding-the-gpiochip.patch queue-4.15/pinctrl-sx150x-unregister-the-pinctrl-on-release.patch queue-4.15/pinctrl-sx150x-add-a-static-gpio-pinctrl-pin-range-mapping.patch

7 years, 9 months

1
0
0 0

Patch "pinctrl: sx150x: Register pinctrl before adding the gpiochip" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled pinctrl: sx150x: Register pinctrl before adding the gpiochip to the 4.15-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: pinctrl-sx150x-register-pinctrl-before-adding-the-gpiochip.patch and it can be found in the queue-4.15 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 1a1d39e1b8dd1d0f92a79da4fcc1ab0be3ae9bfc Mon Sep 17 00:00:00 2001 From: Peter Rosin <peda(a)axentia.se> Date: Wed, 17 Jan 2018 14:34:22 +0100 Subject: pinctrl: sx150x: Register pinctrl before adding the gpiochip From: Peter Rosin <peda(a)axentia.se> commit 1a1d39e1b8dd1d0f92a79da4fcc1ab0be3ae9bfc upstream. Various gpiolib activity depend on the pinctrl to be up and kicking. Therefore, register the pinctrl before adding a gpiochip. Suggested-by: Linus Walleij <linus.walleij(a)linaro.org> Signed-off-by: Peter Rosin <peda(a)axentia.se> Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/pinctrl/pinctrl-sx150x.c | 35 +++++++++++++++++++++-------------- 1 file changed, 21 insertions(+), 14 deletions(-) --- a/drivers/pinctrl/pinctrl-sx150x.c +++ b/drivers/pinctrl/pinctrl-sx150x.c @@ -1144,6 +1144,27 @@ static int sx150x_probe(struct i2c_clien if (ret) return ret; + /* Pinctrl_desc */ + pctl->pinctrl_desc.name = "sx150x-pinctrl"; + pctl->pinctrl_desc.pctlops = &sx150x_pinctrl_ops; + pctl->pinctrl_desc.confops = &sx150x_pinconf_ops; + pctl->pinctrl_desc.pins = pctl->data->pins; + pctl->pinctrl_desc.npins = pctl->data->npins; + pctl->pinctrl_desc.owner = THIS_MODULE; + + ret = devm_pinctrl_register_and_init(dev, &pctl->pinctrl_desc, + pctl, &pctl->pctldev); + if (ret) { + dev_err(dev, "Failed to register pinctrl device\n"); + return ret; + } + + ret = pinctrl_enable(pctl->pctldev); + if (ret) { + dev_err(dev, "Failed to enable pinctrl device\n"); + return ret; + } + /* Register GPIO controller */ pctl->gpio.label = devm_kstrdup(dev, client->name, GFP_KERNEL); pctl->gpio.base = -1; @@ -1217,20 +1238,6 @@ static int sx150x_probe(struct i2c_clien client->irq); } - /* Pinctrl_desc */ - pctl->pinctrl_desc.name = "sx150x-pinctrl"; - pctl->pinctrl_desc.pctlops = &sx150x_pinctrl_ops; - pctl->pinctrl_desc.confops = &sx150x_pinconf_ops; - pctl->pinctrl_desc.pins = pctl->data->pins; - pctl->pinctrl_desc.npins = pctl->data->npins; - pctl->pinctrl_desc.owner = THIS_MODULE; - - pctl->pctldev = devm_pinctrl_register(dev, &pctl->pinctrl_desc, pctl); - if (IS_ERR(pctl->pctldev)) { - dev_err(dev, "Failed to register pinctrl device\n"); - return PTR_ERR(pctl->pctldev); - } - return 0; } Patches currently in stable-queue which might be from peda(a)axentia.se are queue-4.15/pinctrl-sx150x-register-pinctrl-before-adding-the-gpiochip.patch queue-4.15/pinctrl-sx150x-unregister-the-pinctrl-on-release.patch queue-4.15/pinctrl-sx150x-add-a-static-gpio-pinctrl-pin-range-mapping.patch

7 years, 9 months

1
0
0 0

Patch "pinctrl: sx150x: Add a static gpio/pinctrl pin range mapping" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled pinctrl: sx150x: Add a static gpio/pinctrl pin range mapping to the 4.15-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: pinctrl-sx150x-add-a-static-gpio-pinctrl-pin-range-mapping.patch and it can be found in the queue-4.15 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 b930151e5b55a0e62a3aad06876de891ac980471 Mon Sep 17 00:00:00 2001 From: Peter Rosin <peda(a)axentia.se> Date: Wed, 17 Jan 2018 14:34:23 +0100 Subject: pinctrl: sx150x: Add a static gpio/pinctrl pin range mapping From: Peter Rosin <peda(a)axentia.se> commit b930151e5b55a0e62a3aad06876de891ac980471 upstream. Without such a range, gpiolib fails with -EPROBE_DEFER, pending the addition of the range. So, without a range, gpiolib will keep deferring indefinitely. Fixes: 9e80f9064e73 ("pinctrl: Add SX150X GPIO Extender Pinctrl Driver") Fixes: e10f72bf4b3e ("gpio: gpiolib: Generalise state persistence beyond sleep") Suggested-by: Linus Walleij <linus.walleij(a)linaro.org> Signed-off-by: Peter Rosin <peda(a)axentia.se> Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/pinctrl/pinctrl-sx150x.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/drivers/pinctrl/pinctrl-sx150x.c +++ b/drivers/pinctrl/pinctrl-sx150x.c @@ -1193,6 +1193,11 @@ static int sx150x_probe(struct i2c_clien if (ret) return ret; + ret = gpiochip_add_pin_range(&pctl->gpio, dev_name(dev), + 0, 0, pctl->data->npins); + if (ret) + return ret; + /* Add Interrupt support if an irq is specified */ if (client->irq > 0) { pctl->irq_chip.name = devm_kstrdup(dev, client->name, Patches currently in stable-queue which might be from peda(a)axentia.se are queue-4.15/pinctrl-sx150x-register-pinctrl-before-adding-the-gpiochip.patch queue-4.15/pinctrl-sx150x-unregister-the-pinctrl-on-release.patch queue-4.15/pinctrl-sx150x-add-a-static-gpio-pinctrl-pin-range-mapping.patch

7 years, 9 months

1
0
0 0

Patch "pinctrl: mcp23s08: fix irq setup order" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled pinctrl: mcp23s08: fix irq setup order to the 4.15-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: pinctrl-mcp23s08-fix-irq-setup-order.patch and it can be found in the queue-4.15 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 02e389e63e3523828fc3832f27e0341885f60f6f Mon Sep 17 00:00:00 2001 From: Dmitry Mastykin <mastichi(a)gmail.com> Date: Thu, 28 Dec 2017 18:19:24 +0300 Subject: pinctrl: mcp23s08: fix irq setup order From: Dmitry Mastykin <mastichi(a)gmail.com> commit 02e389e63e3523828fc3832f27e0341885f60f6f upstream. When using mcp23s08 module with gpio-keys, often (50% of boots) it fails to get irq numbers with message: "gpio-keys keys: Unable to get irq number for GPIO 0, error -6". Seems that irqs must be setup before devm_gpiochip_add_data(). Signed-off-by: Dmitry Mastykin <mastichi(a)gmail.com> Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/pinctrl/pinctrl-mcp23s08.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- a/drivers/pinctrl/pinctrl-mcp23s08.c +++ b/drivers/pinctrl/pinctrl-mcp23s08.c @@ -896,16 +896,16 @@ static int mcp23s08_probe_one(struct mcp goto fail; } - ret = devm_gpiochip_add_data(dev, &mcp->chip, mcp); - if (ret < 0) - goto fail; - if (mcp->irq && mcp->irq_controller) { ret = mcp23s08_irq_setup(mcp); if (ret) goto fail; } + ret = devm_gpiochip_add_data(dev, &mcp->chip, mcp); + if (ret < 0) + goto fail; + mcp->pinctrl_desc.name = "mcp23xxx-pinctrl"; mcp->pinctrl_desc.pctlops = &mcp_pinctrl_ops; mcp->pinctrl_desc.confops = &mcp_pinconf_ops; Patches currently in stable-queue which might be from mastichi(a)gmail.com are queue-4.15/pinctrl-mcp23s08-fix-irq-setup-order.patch

7 years, 9 months

1
0
0 0

Patch "pinctrl: intel: Initialize GPIO properly when used through irqchip" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled pinctrl: intel: Initialize GPIO properly when used through irqchip to the 4.15-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: pinctrl-intel-initialize-gpio-properly-when-used-through-irqchip.patch and it can be found in the queue-4.15 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 f5a26acf0162477af6ee4c11b4fb9cffe5d3e257 Mon Sep 17 00:00:00 2001 From: Mika Westerberg <mika.westerberg(a)linux.intel.com> Date: Wed, 29 Nov 2017 16:25:44 +0300 Subject: pinctrl: intel: Initialize GPIO properly when used through irqchip From: Mika Westerberg <mika.westerberg(a)linux.intel.com> commit f5a26acf0162477af6ee4c11b4fb9cffe5d3e257 upstream. When a GPIO is requested using gpiod_get_* APIs the intel pinctrl driver switches the pin to GPIO mode and makes sure interrupts are routed to the GPIO hardware instead of IOAPIC. However, if the GPIO is used directly through irqchip, as is the case with many I2C-HID devices where I2C core automatically configures interrupt for the device, the pin is not initialized as GPIO. Instead we rely that the BIOS configures the pin accordingly which seems not to be the case at least in Asus X540NA SKU3 with Focaltech touchpad. When the pin is not properly configured it might result weird behaviour like interrupts suddenly stop firing completely and the touchpad stops responding to user input. Fix this by properly initializing the pin to GPIO mode also when it is used directly through irqchip. Fixes: 7981c0015af2 ("pinctrl: intel: Add Intel Sunrisepoint pin controller and GPIO support") Reported-by: Daniel Drake <drake(a)endlessm.com> Reported-and-tested-by: Chris Chiu <chiu(a)endlessm.com> Signed-off-by: Mika Westerberg <mika.westerberg(a)linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/pinctrl/intel/pinctrl-intel.c | 23 +++++++++++++++-------- 1 file changed, 15 insertions(+), 8 deletions(-) --- a/drivers/pinctrl/intel/pinctrl-intel.c +++ b/drivers/pinctrl/intel/pinctrl-intel.c @@ -425,6 +425,18 @@ static void __intel_gpio_set_direction(v writel(value, padcfg0); } +static void intel_gpio_set_gpio_mode(void __iomem *padcfg0) +{ + u32 value; + + /* Put the pad into GPIO mode */ + value = readl(padcfg0) & ~PADCFG0_PMODE_MASK; + /* Disable SCI/SMI/NMI generation */ + value &= ~(PADCFG0_GPIROUTIOXAPIC | PADCFG0_GPIROUTSCI); + value &= ~(PADCFG0_GPIROUTSMI | PADCFG0_GPIROUTNMI); + writel(value, padcfg0); +} + static int intel_gpio_request_enable(struct pinctrl_dev *pctldev, struct pinctrl_gpio_range *range, unsigned pin) @@ -432,7 +444,6 @@ static int intel_gpio_request_enable(str struct intel_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev); void __iomem *padcfg0; unsigned long flags; - u32 value; raw_spin_lock_irqsave(&pctrl->lock, flags); @@ -442,13 +453,7 @@ static int intel_gpio_request_enable(str } padcfg0 = intel_get_padcfg(pctrl, pin, PADCFG0); - /* Put the pad into GPIO mode */ - value = readl(padcfg0) & ~PADCFG0_PMODE_MASK; - /* Disable SCI/SMI/NMI generation */ - value &= ~(PADCFG0_GPIROUTIOXAPIC | PADCFG0_GPIROUTSCI); - value &= ~(PADCFG0_GPIROUTSMI | PADCFG0_GPIROUTNMI); - writel(value, padcfg0); - + intel_gpio_set_gpio_mode(padcfg0); /* Disable TX buffer and enable RX (this will be input) */ __intel_gpio_set_direction(padcfg0, true); @@ -935,6 +940,8 @@ static int intel_gpio_irq_type(struct ir raw_spin_lock_irqsave(&pctrl->lock, flags); + intel_gpio_set_gpio_mode(reg); + value = readl(reg); value &= ~(PADCFG0_RXEVCFG_MASK | PADCFG0_RXINV); Patches currently in stable-queue which might be from mika.westerberg(a)linux.intel.com are queue-4.15/pinctrl-intel-initialize-gpio-properly-when-used-through-irqchip.patch queue-4.15/ahci-add-intel-cannon-lake-pch-h-pci-id.patch

7 years, 9 months

1
0
0 0

Patch "media: vivid: fix module load error when enabling fb and no_error_inj=1" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled media: vivid: fix module load error when enabling fb and no_error_inj=1 to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: media-vivid-fix-module-load-error-when-enabling-fb-and-no_error_inj-1.patch and it can be found in the queue-4.15 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 0fa2c5f954c41e870fe327907c01cb8f7ea8d5a2 Mon Sep 17 00:00:00 2001 From: Hans Verkuil <hans.verkuil(a)cisco.com> Date: Thu, 25 Jan 2018 06:57:45 -0500 Subject: media: vivid: fix module load error when enabling fb and no_error_inj=1 From: Hans Verkuil <hans.verkuil(a)cisco.com> commit 0fa2c5f954c41e870fe327907c01cb8f7ea8d5a2 upstream. If the framebuffer is enabled and error injection is disabled, then creating the controls for the video output device would fail with an error. This is because the Clear Framebuffer control uses the 'vivid control class' and that control class isn't added if error injection is disabled. In addition, this control was added to e.g. vbi devices as well, which makes no sense. Move this control to its own control handler and handle it correctly. Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com> Acked-by: Sakari Ailus <sakari.ailus(a)linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/platform/vivid/vivid-core.h | 1 drivers/media/platform/vivid/vivid-ctrls.c | 35 ++++++++++++++++++++++++----- 2 files changed, 30 insertions(+), 6 deletions(-) --- a/drivers/media/platform/vivid/vivid-core.h +++ b/drivers/media/platform/vivid/vivid-core.h @@ -154,6 +154,7 @@ struct vivid_dev { struct v4l2_ctrl_handler ctrl_hdl_streaming; struct v4l2_ctrl_handler ctrl_hdl_sdtv_cap; struct v4l2_ctrl_handler ctrl_hdl_loop_cap; + struct v4l2_ctrl_handler ctrl_hdl_fb; struct video_device vid_cap_dev; struct v4l2_ctrl_handler ctrl_hdl_vid_cap; struct video_device vid_out_dev; --- a/drivers/media/platform/vivid/vivid-ctrls.c +++ b/drivers/media/platform/vivid/vivid-ctrls.c @@ -120,9 +120,6 @@ static int vivid_user_gen_s_ctrl(struct clear_bit(V4L2_FL_REGISTERED, &dev->radio_rx_dev.flags); clear_bit(V4L2_FL_REGISTERED, &dev->radio_tx_dev.flags); break; - case VIVID_CID_CLEAR_FB: - vivid_clear_fb(dev); - break; case VIVID_CID_BUTTON: dev->button_pressed = 30; break; @@ -274,8 +271,28 @@ static const struct v4l2_ctrl_config viv .type = V4L2_CTRL_TYPE_BUTTON, }; + +/* Framebuffer Controls */ + +static int vivid_fb_s_ctrl(struct v4l2_ctrl *ctrl) +{ + struct vivid_dev *dev = container_of(ctrl->handler, + struct vivid_dev, ctrl_hdl_fb); + + switch (ctrl->id) { + case VIVID_CID_CLEAR_FB: + vivid_clear_fb(dev); + break; + } + return 0; +} + +static const struct v4l2_ctrl_ops vivid_fb_ctrl_ops = { + .s_ctrl = vivid_fb_s_ctrl, +}; + static const struct v4l2_ctrl_config vivid_ctrl_clear_fb = { - .ops = &vivid_user_gen_ctrl_ops, + .ops = &vivid_fb_ctrl_ops, .id = VIVID_CID_CLEAR_FB, .name = "Clear Framebuffer", .type = V4L2_CTRL_TYPE_BUTTON, @@ -1357,6 +1374,7 @@ int vivid_create_controls(struct vivid_d struct v4l2_ctrl_handler *hdl_streaming = &dev->ctrl_hdl_streaming; struct v4l2_ctrl_handler *hdl_sdtv_cap = &dev->ctrl_hdl_sdtv_cap; struct v4l2_ctrl_handler *hdl_loop_cap = &dev->ctrl_hdl_loop_cap; + struct v4l2_ctrl_handler *hdl_fb = &dev->ctrl_hdl_fb; struct v4l2_ctrl_handler *hdl_vid_cap = &dev->ctrl_hdl_vid_cap; struct v4l2_ctrl_handler *hdl_vid_out = &dev->ctrl_hdl_vid_out; struct v4l2_ctrl_handler *hdl_vbi_cap = &dev->ctrl_hdl_vbi_cap; @@ -1384,10 +1402,12 @@ int vivid_create_controls(struct vivid_d v4l2_ctrl_new_custom(hdl_sdtv_cap, &vivid_ctrl_class, NULL); v4l2_ctrl_handler_init(hdl_loop_cap, 1); v4l2_ctrl_new_custom(hdl_loop_cap, &vivid_ctrl_class, NULL); + v4l2_ctrl_handler_init(hdl_fb, 1); + v4l2_ctrl_new_custom(hdl_fb, &vivid_ctrl_class, NULL); v4l2_ctrl_handler_init(hdl_vid_cap, 55); v4l2_ctrl_new_custom(hdl_vid_cap, &vivid_ctrl_class, NULL); v4l2_ctrl_handler_init(hdl_vid_out, 26); - if (!no_error_inj) + if (!no_error_inj || dev->has_fb) v4l2_ctrl_new_custom(hdl_vid_out, &vivid_ctrl_class, NULL); v4l2_ctrl_handler_init(hdl_vbi_cap, 21); v4l2_ctrl_new_custom(hdl_vbi_cap, &vivid_ctrl_class, NULL); @@ -1561,7 +1581,7 @@ int vivid_create_controls(struct vivid_d v4l2_ctrl_new_custom(hdl_loop_cap, &vivid_ctrl_loop_video, NULL); if (dev->has_fb) - v4l2_ctrl_new_custom(hdl_user_gen, &vivid_ctrl_clear_fb, NULL); + v4l2_ctrl_new_custom(hdl_fb, &vivid_ctrl_clear_fb, NULL); if (dev->has_radio_rx) { v4l2_ctrl_new_custom(hdl_radio_rx, &vivid_ctrl_radio_hw_seek_mode, NULL); @@ -1658,6 +1678,7 @@ int vivid_create_controls(struct vivid_d v4l2_ctrl_add_handler(hdl_vid_cap, hdl_streaming, NULL); v4l2_ctrl_add_handler(hdl_vid_cap, hdl_sdtv_cap, NULL); v4l2_ctrl_add_handler(hdl_vid_cap, hdl_loop_cap, NULL); + v4l2_ctrl_add_handler(hdl_vid_cap, hdl_fb, NULL); if (hdl_vid_cap->error) return hdl_vid_cap->error; dev->vid_cap_dev.ctrl_handler = hdl_vid_cap; @@ -1666,6 +1687,7 @@ int vivid_create_controls(struct vivid_d v4l2_ctrl_add_handler(hdl_vid_out, hdl_user_gen, NULL); v4l2_ctrl_add_handler(hdl_vid_out, hdl_user_aud, NULL); v4l2_ctrl_add_handler(hdl_vid_out, hdl_streaming, NULL); + v4l2_ctrl_add_handler(hdl_vid_out, hdl_fb, NULL); if (hdl_vid_out->error) return hdl_vid_out->error; dev->vid_out_dev.ctrl_handler = hdl_vid_out; @@ -1725,4 +1747,5 @@ void vivid_free_controls(struct vivid_de v4l2_ctrl_handler_free(&dev->ctrl_hdl_streaming); v4l2_ctrl_handler_free(&dev->ctrl_hdl_sdtv_cap); v4l2_ctrl_handler_free(&dev->ctrl_hdl_loop_cap); + v4l2_ctrl_handler_free(&dev->ctrl_hdl_fb); } Patches currently in stable-queue which might be from hans.verkuil(a)cisco.com are queue-4.15/media-hdpvr-fix-an-error-handling-path-in-hdpvr_probe.patch queue-4.15/media-v4l2-compat-ioctl32.c-copy-m.userptr-in-put_v4l2_plane32.patch queue-4.15/media-v4l2-compat-ioctl32.c-avoid-sizeof-type.patch queue-4.15/media-v4l2-compat-ioctl32.c-drop-pr_info-for-unknown-buffer-type.patch queue-4.15/media-v4l2-compat-ioctl32.c-add-missing-vidioc_prepare_buf.patch queue-4.15/media-v4l2-compat-ioctl32.c-refactor-compat-ioctl32-logic.patch queue-4.15/media-v4l2-compat-ioctl32.c-fix-ctrl_is_pointer.patch queue-4.15/media-vivid-fix-module-load-error-when-enabling-fb-and-no_error_inj-1.patch queue-4.15/media-v4l2-compat-ioctl32.c-move-helper-functions-to-__get-put_v4l2_format32.patch queue-4.15/media-v4l2-compat-ioctl32.c-don-t-copy-back-the-result-for-certain-errors.patch queue-4.15/media-dt-bindings-media-cec-gpio.txt-mention-the-cec-hpd-max-voltages.patch queue-4.15/media-v4l2-compat-ioctl32.c-make-ctrl_is_pointer-work-for-subdevs.patch queue-4.15/media-v4l2-compat-ioctl32.c-fix-the-indentation.patch queue-4.15/media-v4l2-ioctl.c-don-t-copy-back-the-result-for-enotty.patch queue-4.15/media-v4l2-ioctl.c-use-check_fmt-for-enum-g-s-try_fmt.patch queue-4.15/media-v4l2-compat-ioctl32.c-copy-clip-list-in-put_v4l2_window32.patch

7 years, 9 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror