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

Patch "ima: relax requiring a file signature for new files with zero length" 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 ima: relax requiring a file signature for new files with zero length 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: ima-relax-requiring-a-file-signature-for-new-files-with-zero-length.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 09:58:12 CET 2018 From: Mimi Zohar <zohar(a)linux.vnet.ibm.com> Date: Wed, 8 Nov 2017 07:38:28 -0500 Subject: ima: relax requiring a file signature for new files with zero length From: Mimi Zohar <zohar(a)linux.vnet.ibm.com> [ Upstream commit b7e27bc1d42e8e0cc58b602b529c25cd0071b336 ] Custom policies can require file signatures based on LSM labels. These files are normally created and only afterwards labeled, requiring them to be signed. Instead of requiring file signatures based on LSM labels, entire filesystems could require file signatures. In this case, we need the ability of writing new files without requiring file signatures. The definition of a "new" file was originally defined as any file with a length of zero. Subsequent patches redefined a "new" file to be based on the FILE_CREATE open flag. By combining the open flag with a file size of zero, this patch relaxes the file signature requirement. Fixes: 1ac202e978e1 ima: accept previously set IMA_NEW_FILE Signed-off-by: Mimi Zohar <zohar(a)linux.vnet.ibm.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- security/integrity/ima/ima_appraise.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/security/integrity/ima/ima_appraise.c +++ b/security/integrity/ima/ima_appraise.c @@ -206,7 +206,8 @@ int ima_appraise_measurement(int func, s if (opened & FILE_CREATED) iint->flags |= IMA_NEW_FILE; if ((iint->flags & IMA_NEW_FILE) && - !(iint->flags & IMA_DIGSIG_REQUIRED)) + (!(iint->flags & IMA_DIGSIG_REQUIRED) || + (inode->i_size == 0))) status = INTEGRITY_PASS; goto out; } Patches currently in stable-queue which might be from zohar(a)linux.vnet.ibm.com are queue-4.4/ima-relax-requiring-a-file-signature-for-new-files-with-zero-length.patch

7 years, 6 months

1
0
0 0

Patch "i40e: fix ethtool to get EEPROM data from X722 interface" 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 i40e: fix ethtool to get EEPROM data from X722 interface 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: i40e-fix-ethtool-to-get-eeprom-data-from-x722-interface.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 09:58:12 CET 2018 From: Lihong Yang <lihong.yang(a)intel.com> Date: Mon, 30 Jan 2017 12:29:32 -0800 Subject: i40e: fix ethtool to get EEPROM data from X722 interface From: Lihong Yang <lihong.yang(a)intel.com> [ Upstream commit c271dd6c391b535226cf1a81aaad9f33cb5899d3 ] Currently ethtool -e will error out with a X722 interface as its EEPROM has a scope limit at offset 0x5B9FFF. This patch fixes the issue by setting the EEPROM length to the scope limit to avoid NVM read failure beyond that. Change-ID: I0b7d4dd6c7f2a57cace438af5dffa0f44c229372 Signed-off-by: Lihong Yang <lihong.yang(a)intel.com> Tested-by: Andrew Bowers <andrewx.bowers(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c +++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c @@ -1073,6 +1073,11 @@ static int i40e_get_eeprom_len(struct ne struct i40e_hw *hw = &np->vsi->back->hw; u32 val; +#define X722_EEPROM_SCOPE_LIMIT 0x5B9FFF + if (hw->mac.type == I40E_MAC_X722) { + val = X722_EEPROM_SCOPE_LIMIT + 1; + return val; + } val = (rd32(hw, I40E_GLPCI_LBARCTRL) & I40E_GLPCI_LBARCTRL_FL_SIZE_MASK) >> I40E_GLPCI_LBARCTRL_FL_SIZE_SHIFT; Patches currently in stable-queue which might be from lihong.yang(a)intel.com are queue-4.4/i40e-fix-ethtool-to-get-eeprom-data-from-x722-interface.patch

7 years, 6 months

1
0
0 0

Patch "i40e: Acquire NVM lock before reads on all devices" 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 i40e: Acquire NVM lock before reads on all devices 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: i40e-acquire-nvm-lock-before-reads-on-all-devices.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 09:58:12 CET 2018 From: Aaron Salter <aaron.k.salter(a)intel.com> Date: Fri, 2 Dec 2016 12:33:02 -0800 Subject: i40e: Acquire NVM lock before reads on all devices From: Aaron Salter <aaron.k.salter(a)intel.com> [ Upstream commit 96a39aed25e6559b160786117df124084feb9080 ] Acquire NVM lock before reads on all devices. Previously, locks were only used for X722 and later. Fixes an issue where simultaneous X710 NVM accesses were interfering with each other. Change-ID: If570bb7acf958cef58725ec2a2011cead6f80638 Signed-off-by: Aaron Salter <aaron.k.salter(a)intel.com> Tested-by: Andrew Bowers <andrewx.bowers(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/i40e/i40e_nvm.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) --- a/drivers/net/ethernet/intel/i40e/i40e_nvm.c +++ b/drivers/net/ethernet/intel/i40e/i40e_nvm.c @@ -292,14 +292,14 @@ i40e_status i40e_read_nvm_word(struct i4 { enum i40e_status_code ret_code = 0; - if (hw->flags & I40E_HW_FLAG_AQ_SRCTL_ACCESS_ENABLE) { - ret_code = i40e_acquire_nvm(hw, I40E_RESOURCE_READ); - if (!ret_code) { + ret_code = i40e_acquire_nvm(hw, I40E_RESOURCE_READ); + if (!ret_code) { + if (hw->flags & I40E_HW_FLAG_AQ_SRCTL_ACCESS_ENABLE) { ret_code = i40e_read_nvm_word_aq(hw, offset, data); - i40e_release_nvm(hw); + } else { + ret_code = i40e_read_nvm_word_srctl(hw, offset, data); } - } else { - ret_code = i40e_read_nvm_word_srctl(hw, offset, data); + i40e_release_nvm(hw); } return ret_code; } Patches currently in stable-queue which might be from aaron.k.salter(a)intel.com are queue-4.4/i40e-acquire-nvm-lock-before-reads-on-all-devices.patch

7 years, 6 months

1
0
0 0

Patch "HID: reject input outside logical range only if null state is set" 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: reject input outside logical range only if null state is set 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-reject-input-outside-logical-range-only-if-null-state-is-set.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 09:58:12 CET 2018 From: "Valtteri Heikkilä" <rnd(a)nic.fi> Date: Tue, 14 Feb 2017 23:14:32 +0000 Subject: HID: reject input outside logical range only if null state is set From: "Valtteri Heikkilä" <rnd(a)nic.fi> [ Upstream commit 3f3752705dbd50b66b66ad7b4d54fe33d2f746ed ] This patch fixes an issue in drivers/hid/hid-input.c where USB HID control null state flag is not checked upon rejecting inputs outside logical minimum-maximum range. The check should be made according to USB HID specification 1.11, section 6.2.2.5, p.31. The fix will resolve issues with some game controllers, such as: https://bugzilla.kernel.org/show_bug.cgi?id=68621 [tk(a)the-tk.com: shortened and fixed spelling in commit message] Signed-off-by: Valtteri HeikkilÃ¤ <rnd(a)nic.fi> Signed-off-by: Tomasz Kramkowski <tk(a)the-tk.com> Acked-By: Benjamin Tissoires <benjamin.tissoires(a)redhat.com> Signed-off-by: Jiri Kosina <jkosina(a)suse.cz> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/hid/hid-input.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/hid/hid-input.c +++ b/drivers/hid/hid-input.c @@ -1135,6 +1135,7 @@ void hidinput_hid_event(struct hid_devic * don't specify logical min and max. */ if ((field->flags & HID_MAIN_ITEM_VARIABLE) && + (field->flags & HID_MAIN_ITEM_NULL_STATE) && (field->logical_minimum < field->logical_maximum) && (value < field->logical_minimum || value > field->logical_maximum)) { Patches currently in stable-queue which might be from rnd(a)nic.fi are queue-4.4/hid-reject-input-outside-logical-range-only-if-null-state-is-set.patch

7 years, 6 months

1
0
0 0

Patch "HID: elo: clear BTN_LEFT mapping" 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: elo: clear BTN_LEFT mapping 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-elo-clear-btn_left-mapping.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 09:58:12 CET 2018 From: Jiri Kosina <jkosina(a)suse.cz> Date: Wed, 22 Nov 2017 11:19:51 +0100 Subject: HID: elo: clear BTN_LEFT mapping From: Jiri Kosina <jkosina(a)suse.cz> [ Upstream commit 9abd04af951e5734c9d5cfee9b49790844b734cf ] ELO devices have one Button usage in GenDesk field, which makes hid-input map it to BTN_LEFT; that confuses userspace, which then considers the device to be a mouse/touchpad instead of touchscreen. Fix that by unmapping BTN_LEFT and keeping only BTN_TOUCH in place. Signed-off-by: Jiri Kosina <jkosina(a)suse.cz> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/hid/hid-elo.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/drivers/hid/hid-elo.c +++ b/drivers/hid/hid-elo.c @@ -42,6 +42,12 @@ static int elo_input_configured(struct h { struct input_dev *input = hidinput->input; + /* + * ELO devices have one Button usage in GenDesk field, which makes + * hid-input map it to BTN_LEFT; that confuses userspace, which then + * considers the device to be a mouse/touchpad instead of touchscreen. + */ + clear_bit(BTN_LEFT, input->keybit); set_bit(BTN_TOUCH, input->keybit); set_bit(ABS_PRESSURE, input->absbit); input_set_abs_params(input, ABS_PRESSURE, 0, 256, 0, 0); Patches currently in stable-queue which might be from jkosina(a)suse.cz are queue-4.4/hid-elo-clear-btn_left-mapping.patch queue-4.4/hid-clamp-input-to-logical-range-if-no-null-state.patch queue-4.4/hid-reject-input-outside-logical-range-only-if-null-state-is-set.patch

7 years, 6 months

1
0
0 0

Patch "HID: clamp input to logical range if no null state" 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: clamp input to logical range if no null state 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-clamp-input-to-logical-range-if-no-null-state.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 09:58:12 CET 2018 From: Tomasz Kramkowski <tk(a)the-tk.com> Date: Tue, 14 Mar 2017 13:29:13 +0000 Subject: HID: clamp input to logical range if no null state From: Tomasz Kramkowski <tk(a)the-tk.com> [ Upstream commit c3883fe06488a483658ba5d849b70e49bee15e7c ] This patch fixes an issue in drivers/hid/hid-input.c where values outside of the logical range are not clamped when "null state" bit of the input control is not set. This was discussed on the lists [1] and this change stems from the fact due to the ambiguity of the HID specification it might be appropriate to follow Microsoft's own interpretation of the specification. As noted in Microsoft's documentation [2] in the section titled "Required HID usages for digitizers" it is noted that values reported outside the logical range "will be considered as invalid data and the value will be changed to the nearest boundary value (logical min/max)." This patch fixes an issue where the (1292:4745) Innomedia INNEX GENESIS/ATARI reports out of range values for its X and Y axis of the DPad which, due to the null state bit being unset, are forwarded to userspace as is. Now these values will get clamped to the logical range before being forwarded to userspace. This device was also used to test this patch. This patch expands on commit 3f3752705dbd ("HID: reject input outside logical range only if null state is set"). [1]: http://lkml.kernel.org/r/20170307131036.GA853@gaia.local [2]: https://msdn.microsoft.com/en-us/library/windows/hardware/dn672278(v=vs.85)… Signed-off-by: Tomasz Kramkowski <tk(a)the-tk.com> Acked-by: Benjamin Tissoires <benjamin.tissoires(a)redhat.com> Signed-off-by: Jiri Kosina <jkosina(a)suse.cz> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/hid/hid-input.c | 21 ++++++++++++++------- 1 file changed, 14 insertions(+), 7 deletions(-) --- a/drivers/hid/hid-input.c +++ b/drivers/hid/hid-input.c @@ -1128,19 +1128,26 @@ void hidinput_hid_event(struct hid_devic /* * Ignore out-of-range values as per HID specification, - * section 5.10 and 6.2.25. + * section 5.10 and 6.2.25, when NULL state bit is present. + * When it's not, clamp the value to match Microsoft's input + * driver as mentioned in "Required HID usages for digitizers": + * https://msdn.microsoft.com/en-us/library/windows/hardware/dn672278(v=vs.85)… * * The logical_minimum < logical_maximum check is done so that we * don't unintentionally discard values sent by devices which * don't specify logical min and max. */ if ((field->flags & HID_MAIN_ITEM_VARIABLE) && - (field->flags & HID_MAIN_ITEM_NULL_STATE) && - (field->logical_minimum < field->logical_maximum) && - (value < field->logical_minimum || - value > field->logical_maximum)) { - dbg_hid("Ignoring out-of-range value %x\n", value); - return; + (field->logical_minimum < field->logical_maximum)) { + if (field->flags & HID_MAIN_ITEM_NULL_STATE && + (value < field->logical_minimum || + value > field->logical_maximum)) { + dbg_hid("Ignoring out-of-range value %x\n", value); + return; + } + value = clamp(value, + field->logical_minimum, + field->logical_maximum); } /* Patches currently in stable-queue which might be from tk(a)the-tk.com are queue-4.4/hid-clamp-input-to-logical-range-if-no-null-state.patch queue-4.4/hid-reject-input-outside-logical-range-only-if-null-state-is-set.patch

7 years, 6 months

1
0
0 0

Patch "fm10k: correctly check if interface is removed" 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 fm10k: correctly check if interface is removed 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: fm10k-correctly-check-if-interface-is-removed.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 09:58:12 CET 2018 From: Phil Turnbull <phil.turnbull(a)oracle.com> Date: Wed, 23 Nov 2016 13:33:58 -0500 Subject: fm10k: correctly check if interface is removed From: Phil Turnbull <phil.turnbull(a)oracle.com> [ Upstream commit 540fca35e38d15777b310f450f63f056e63039f5 ] FM10K_REMOVED expects a hardware address, not a 'struct fm10k_hw'. Fixes: 5cb8db4a4cbc ("fm10k: Add support for VF") Signed-off-by: Phil Turnbull <phil.turnbull(a)oracle.com> Tested-by: Krishneil Singh <krishneil.k.singh(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c +++ b/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c @@ -983,7 +983,7 @@ static void fm10k_self_test(struct net_d memset(data, 0, sizeof(*data) * FM10K_TEST_LEN); - if (FM10K_REMOVED(hw)) { + if (FM10K_REMOVED(hw->hw_addr)) { netif_err(interface, drv, dev, "Interface removed - test blocked\n"); eth_test->flags |= ETH_TEST_FL_FAILED; Patches currently in stable-queue which might be from phil.turnbull(a)oracle.com are queue-4.4/fm10k-correctly-check-if-interface-is-removed.patch

7 years, 6 months

1
0
0 0

Patch "f2fs: relax node version check for victim data in gc" 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 f2fs: relax node version check for victim data in gc 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: f2fs-relax-node-version-check-for-victim-data-in-gc.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 09:58:12 CET 2018 From: Jaegeuk Kim <jaegeuk(a)kernel.org> Date: Tue, 21 Mar 2017 10:59:50 -0400 Subject: f2fs: relax node version check for victim data in gc From: Jaegeuk Kim <jaegeuk(a)kernel.org> [ Upstream commit c13ff37e359bb3eacf4e1760dcea8d9760aa7459 ] - has_not_enough_free_secs node_secs: 0 dent_secs: 0 freed:0 free_segments:103 reserved:104 - f2fs_gc - get_victim_by_default alloc_mode 0, gc_mode 1, max_search 2672, offset 4654, ofs_unit 1 - do_garbage_collect start_segno 3976, end_segno 3977 type 0 - is_alive nid 22797, blkaddr 2131882, ofs_in_node 0, version 0x8/0x0 - gc_data_segment 766, segno 3976, block 512/426 not alive So, this patch fixes subtle corrupted case where node version does not match to summary version which results in infinite loop by gc. Reported-by: Yunlei He <heyunlei(a)huawei.com> Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/f2fs/gc.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/fs/f2fs/gc.c +++ b/fs/f2fs/gc.c @@ -522,8 +522,10 @@ static bool is_alive(struct f2fs_sb_info get_node_info(sbi, nid, dni); if (sum->version != dni->version) { - f2fs_put_page(node_page, 1); - return false; + f2fs_msg(sbi->sb, KERN_WARNING, + "%s: valid data with mismatched node version.", + __func__); + set_sbi_flag(sbi, SBI_NEED_FSCK); } *nofs = ofs_of_node(node_page); Patches currently in stable-queue which might be from jaegeuk(a)kernel.org are queue-4.4/f2fs-relax-node-version-check-for-victim-data-in-gc.patch

7 years, 6 months

1
0
0 0

Patch "drm/radeon: Fail fb creation from imported dma-bufs." 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 drm/radeon: Fail fb creation from imported dma-bufs. 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: drm-radeon-fail-fb-creation-from-imported-dma-bufs.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 09:58:12 CET 2018 From: Christopher James Halse Rogers <christopher.halse.rogers(a)canonical.com> Date: Wed, 29 Mar 2017 15:00:54 +1100 Subject: drm/radeon: Fail fb creation from imported dma-bufs. From: Christopher James Halse Rogers <christopher.halse.rogers(a)canonical.com> [ Upstream commit a294043b2fbd8de69d161457ed0c7a4026bbfa5a ] Any use of the framebuffer will migrate it to VRAM, which is not sensible for an imported dma-buf. v2: Use DRM_DEBUG_KMS to prevent userspace accidentally spamming dmesg. Reviewed-by: Michel Dänzer <michel.daenzer(a)amd.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Christopher James Halse Rogers <christopher.halse.rogers(a)canonical.com> CC: amd-gfx(a)lists.freedesktop.org Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/radeon/radeon_display.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/drivers/gpu/drm/radeon/radeon_display.c +++ b/drivers/gpu/drm/radeon/radeon_display.c @@ -1374,6 +1374,12 @@ radeon_user_framebuffer_create(struct dr return ERR_PTR(-ENOENT); } + /* Handle is imported dma-buf, so cannot be migrated to VRAM for scanout */ + if (obj->import_attach) { + DRM_DEBUG_KMS("Cannot create framebuffer from imported dma_buf\n"); + return ERR_PTR(-EINVAL); + } + radeon_fb = kzalloc(sizeof(*radeon_fb), GFP_KERNEL); if (radeon_fb == NULL) { drm_gem_object_unreference_unlocked(obj); Patches currently in stable-queue which might be from christopher.halse.rogers(a)canonical.com are queue-4.4/drm-amdgpu-fail-fb-creation-from-imported-dma-bufs.-v2.patch queue-4.4/drm-radeon-fail-fb-creation-from-imported-dma-bufs.patch

7 years, 6 months

1
0
0 0

Patch "drm/vmwgfx: Fixes to vmwgfx_fb" 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 drm/vmwgfx: Fixes to vmwgfx_fb 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: drm-vmwgfx-fixes-to-vmwgfx_fb.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 09:58:12 CET 2018 From: Sinclair Yeh <syeh(a)vmware.com> Date: Thu, 23 Mar 2017 14:28:21 -0700 Subject: drm/vmwgfx: Fixes to vmwgfx_fb From: Sinclair Yeh <syeh(a)vmware.com> [ Upstream commit aa74f0687cfe998e59b20d6454f45e8aa4403c45 ] 1. When unsetting a mode, num_connector should be set to zero 2. The pixel_format field needs to be initialized as newer DRM internal functions checks this field 3. Take the drm_modeset_lock_all() because vmw_fb_kms_detach() can change current mode Signed-off-by: Sinclair Yeh <syeh(a)vmware.com> Reviewed-by: Thomas Hellstrom <thellstrom(a)vmware.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c @@ -433,7 +433,7 @@ static int vmw_fb_kms_detach(struct vmw_ set.y = 0; set.mode = NULL; set.fb = NULL; - set.num_connectors = 1; + set.num_connectors = 0; set.connectors = &par->con; ret = drm_mode_set_config_internal(&set); if (ret) { @@ -821,7 +821,9 @@ int vmw_fb_off(struct vmw_private *vmw_p flush_delayed_work(&par->local_work); mutex_lock(&par->bo_mutex); + drm_modeset_lock_all(vmw_priv->dev); (void) vmw_fb_kms_detach(par, true, false); + drm_modeset_unlock_all(vmw_priv->dev); mutex_unlock(&par->bo_mutex); return 0; Patches currently in stable-queue which might be from syeh(a)vmware.com are queue-4.4/drm-vmwgfx-fixes-to-vmwgfx_fb.patch

7 years, 6 months

1
0
0 0

Patch "drm: qxl: Don't alloc fbdev if emulation is not supported" 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 drm: qxl: Don't alloc fbdev if emulation is not supported 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: drm-qxl-don-t-alloc-fbdev-if-emulation-is-not-supported.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 09:58:12 CET 2018 From: Gabriel Krisman Bertazi <krisman(a)collabora.co.uk> Date: Mon, 27 Feb 2017 17:33:30 -0300 Subject: drm: qxl: Don't alloc fbdev if emulation is not supported From: Gabriel Krisman Bertazi <krisman(a)collabora.co.uk> [ Upstream commit 861078381ba56b56808113736000d9e7ead349c8 ] If fbdev emulation is disabled, the QXL shutdown path will try to clean a framebuffer that wasn't initialized, hitting the Oops below. The problem is that even when FBDEV_EMULATION is disabled we allocate the qfbdev strutucture, but we don't initialize it. The fix is to stop allocating the memory, since it won't be used. This allows the existing verification in the cleanup hook to do it's job preventing the oops. Now that we don't allocate the unused fbdev structure, we need to be careful when dereferencing it in the PM suspend hook. [ 24.284684] BUG: unable to handle kernel NULL pointer dereference at 00000000000002e0 [ 24.285627] IP: mutex_lock+0x18/0x30 [ 24.286049] PGD 78cdf067 [ 24.286050] PUD 7940f067 [ 24.286344] PMD 0 [ 24.286649] [ 24.287072] Oops: 0002 [#1] SMP [ 24.287422] Modules linked in: qxl [ 24.287806] CPU: 0 PID: 2328 Comm: bash Not tainted 4.10.0-rc5+ #97 [ 24.288515] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-20161025_171302-gandalf 04/01/2014 [ 24.289681] task: ffff88007c4c0000 task.stack: ffffc90001b58000 [ 24.290354] RIP: 0010:mutex_lock+0x18/0x30 [ 24.290812] RSP: 0018:ffffc90001b5bcb0 EFLAGS: 00010246 [ 24.291401] RAX: 0000000000000000 RBX: 00000000000002e0 RCX: 0000000000000000 [ 24.292209] RDX: ffff88007c4c0000 RSI: 0000000000000001 RDI: 00000000000002e0 [ 24.292987] RBP: ffffc90001b5bcb8 R08: fffffffffffffffe R09: 0000000000000001 [ 24.293797] R10: ffff880078d80b80 R11: 0000000000011400 R12: 0000000000000000 [ 24.294601] R13: 00000000000002e0 R14: ffffffffa0009c28 R15: 0000000000000060 [ 24.295439] FS: 00007f30e3acbb40(0000) GS:ffff88007fc00000(0000) knlGS:0000000000000000 [ 24.296364] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 24.296997] CR2: 00000000000002e0 CR3: 0000000078c7b000 CR4: 00000000000006f0 [ 24.297813] Call Trace: [ 24.298097] drm_framebuffer_cleanup+0x1f/0x70 [ 24.298612] qxl_fbdev_fini+0x68/0x90 [qxl] [ 24.299074] qxl_modeset_fini+0xd/0x30 [qxl] [ 24.299562] qxl_pci_remove+0x22/0x50 [qxl] [ 24.300025] pci_device_remove+0x34/0xb0 [ 24.300507] device_release_driver_internal+0x150/0x200 [ 24.301082] device_release_driver+0xd/0x10 [ 24.301587] unbind_store+0x108/0x150 [ 24.301993] drv_attr_store+0x20/0x30 [ 24.302402] sysfs_kf_write+0x32/0x40 [ 24.302827] kernfs_fop_write+0x108/0x190 [ 24.303269] __vfs_write+0x23/0x120 [ 24.303678] ? security_file_permission+0x36/0xb0 [ 24.304193] ? rw_verify_area+0x49/0xb0 [ 24.304636] vfs_write+0xb0/0x190 [ 24.305004] SyS_write+0x41/0xa0 [ 24.305362] entry_SYSCALL_64_fastpath+0x1a/0xa9 [ 24.305887] RIP: 0033:0x7f30e31d9620 [ 24.306285] RSP: 002b:00007ffc54b47e68 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 24.307128] RAX: ffffffffffffffda RBX: 00007f30e3497600 RCX: 00007f30e31d9620 [ 24.307928] RDX: 000000000000000d RSI: 0000000000da2008 RDI: 0000000000000001 [ 24.308727] RBP: 000000000070bc60 R08: 00007f30e3498760 R09: 00007f30e3acbb40 [ 24.309504] R10: 0000000000000073 R11: 0000000000000246 R12: 0000000000000001 [ 24.310295] R13: 0000000000000000 R14: 0000000000000000 R15: 00007ffc54b47f34 [ 24.311095] Code: 0e 01 e9 7b fe ff ff 66 90 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 53 48 89 fb e8 83 e8 ff ff 65 48 8b 14 25 40 c4 00 00 31 c0 <3e> 48 0f b1 13 48 85 c0 74 08 48 89 df e8 66 fd ff ff 5b 5d c3 [ 24.313182] RIP: mutex_lock+0x18/0x30 RSP: ffffc90001b5bcb0 [ 24.313811] CR2: 00000000000002e0 [ 24.314208] ---[ end trace 29669c1593cae14b ]--- Signed-off-by: Gabriel Krisman Bertazi <krisman(a)collabora.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170227203330.18542-1-krisman… Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/qxl/qxl_fb.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) --- a/drivers/gpu/drm/qxl/qxl_fb.c +++ b/drivers/gpu/drm/qxl/qxl_fb.c @@ -494,9 +494,11 @@ static const struct drm_fb_helper_funcs int qxl_fbdev_init(struct qxl_device *qdev) { + int ret = 0; + +#ifdef CONFIG_DRM_FBDEV_EMULATION struct qxl_fbdev *qfbdev; int bpp_sel = 32; /* TODO: parameter from somewhere? */ - int ret; qfbdev = kzalloc(sizeof(struct qxl_fbdev), GFP_KERNEL); if (!qfbdev) @@ -531,6 +533,8 @@ fini: drm_fb_helper_fini(&qfbdev->helper); free: kfree(qfbdev); +#endif + return ret; } @@ -546,6 +550,9 @@ void qxl_fbdev_fini(struct qxl_device *q void qxl_fbdev_set_suspend(struct qxl_device *qdev, int state) { + if (!qdev->mode_info.qfbdev) + return; + drm_fb_helper_set_suspend(&qdev->mode_info.qfbdev->helper, state); } Patches currently in stable-queue which might be from krisman(a)collabora.co.uk are queue-4.4/drm-qxl-don-t-alloc-fbdev-if-emulation-is-not-supported.patch

7 years, 6 months

1
0
0 0

Patch "drm/edid: set ELD connector type in drm_edid_to_eld()" 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 drm/edid: set ELD connector type in drm_edid_to_eld() 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: drm-edid-set-eld-connector-type-in-drm_edid_to_eld.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 09:58:12 CET 2018 From: Jani Nikula <jani.nikula(a)intel.com> Date: Wed, 1 Nov 2017 16:20:58 +0200 Subject: drm/edid: set ELD connector type in drm_edid_to_eld() From: Jani Nikula <jani.nikula(a)intel.com> [ Upstream commit 1d1c36650752b7fb81cee515a9bba4131cac4b7c ] Since drm_edid_to_eld() knows the connector type, we can set the type in ELD while at it. Most connectors this gets called on are not DP encoders, and with the HDMI type being 0, this does not change behaviour for non-DP. For i915 having this in place earlier would have saved a considerable amount of debugging that lead to the fix 2d8f63297b9f ("drm/i915: always update ELD connector type after get modes"). I don't see other drivers, even the ones calling drm_edid_to_eld() on DP connectors, setting the connector type in ELD. Cc: Alex Deucher <alexander.deucher(a)amd.com> Cc: Christian König <christian.koenig(a)amd.com> Cc: Archit Taneja <architt(a)codeaurora.org> Cc: Andrzej Hajda <a.hajda(a)samsung.com> Cc: Russell King <linux(a)armlinux.org.uk> Cc: CK Hu <ck.hu(a)mediatek.com> Cc: Philipp Zabel <p.zabel(a)pengutronix.de> Cc: Ben Skeggs <bskeggs(a)redhat.com> Cc: Mark Yao <mark.yao(a)rock-chips.com> Cc: Benjamin Gaignard <benjamin.gaignard(a)linaro.org> Cc: Vincent Abriou <vincent.abriou(a)st.com> Cc: Thierry Reding <thierry.reding(a)gmail.com> Cc: Eric Anholt <eric(a)anholt.net> Reviewed-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Reviewed-by: Alex Deucher <alexander.deucher(a)amd.com> Acked-by: Thierry Reding <treding(a)nvidia.com> Signed-off-by: Jani Nikula <jani.nikula(a)intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/d527b31619528c477c2c136f25cdf… Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/drm_edid.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -3219,8 +3219,7 @@ monitor_name(struct detailed_timing *t, * @edid: EDID to parse * * Fill the ELD (EDID-Like Data) buffer for passing to the audio driver. The - * Conn_Type, HDCP and Port_ID ELD fields are left for the graphics driver to - * fill in. + * HDCP and Port_ID ELD fields are left for the graphics driver to fill in. */ void drm_edid_to_eld(struct drm_connector *connector, struct edid *edid) { @@ -3293,6 +3292,12 @@ void drm_edid_to_eld(struct drm_connecto } eld[5] |= sad_count << 4; + if (connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort || + connector->connector_type == DRM_MODE_CONNECTOR_eDP) + eld[DRM_ELD_SAD_COUNT_CONN_TYPE] |= DRM_ELD_CONN_TYPE_DP; + else + eld[DRM_ELD_SAD_COUNT_CONN_TYPE] |= DRM_ELD_CONN_TYPE_HDMI; + eld[DRM_ELD_BASELINE_ELD_LEN] = DIV_ROUND_UP(drm_eld_calc_baseline_block_size(eld), 4); Patches currently in stable-queue which might be from jani.nikula(a)intel.com are queue-4.4/drm-edid-set-eld-connector-type-in-drm_edid_to_eld.patch

7 years, 6 months

1
0
0 0

Patch "drm: Defer disabling the vblank IRQ until the next interrupt (for instant-off)" 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 drm: Defer disabling the vblank IRQ until the next interrupt (for instant-off) 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: drm-defer-disabling-the-vblank-irq-until-the-next-interrupt-for-instant-off.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 09:58:12 CET 2018 From: Chris Wilson <chris(a)chris-wilson.co.uk> Date: Wed, 15 Mar 2017 20:40:25 +0000 Subject: drm: Defer disabling the vblank IRQ until the next interrupt (for instant-off) From: Chris Wilson <chris(a)chris-wilson.co.uk> [ Upstream commit 608b20506941969ea30d8c08dc9ae02bb87dbf7d ] On vblank instant-off systems, we can get into a situation where the cost of enabling and disabling the vblank IRQ around a drmWaitVblank query dominates. And with the advent of even deeper hardware sleep state, touching registers becomes ever more expensive. However, we know that if the user wants the current vblank counter, they are also very likely to immediately queue a vblank wait and so we can keep the interrupt around and only turn it off if we have no further vblank requests queued within the interrupt interval. After vblank event delivery, this patch adds a shadow of one vblank where the interrupt is kept alive for the user to query and queue another vblank event. Similarly, if the user is using blocking drmWaitVblanks, the interrupt will be disabled on the IRQ following the wait completion. However, if the user is simply querying the current vblank counter and timestamp, the interrupt will be disabled after every IRQ and the user will enabled it again on the first query following the IRQ. v2: Mario Kleiner - After testing this, one more thing that would make sense is to move the disable block at the end of drm_handle_vblank() instead of at the top. Turns out that if high precision timestaming is disabled or doesn't work for some reason (as can be simulated by echo 0 > /sys/module/drm/parameters/timestamp_precision_usec), then with your delayed disable code at its current place, the vblank counter won't increment anymore at all for instant queries, ie. with your other "instant query" patches. Clients which repeatedly query the counter and wait for it to progress will simply hang, spinning in an endless query loop. There's that comment in vblank_disable_and_save: "* Skip this step if there isn't any high precision timestamp * available. In that case we can't account for this and just * hope for the best. */ With the disable happening after leading edge of vblank (== hw counter increment already happened) but before the vblank counter/timestamp handling in drm_handle_vblank, that step is needed to keep the counter progressing, so skipping it is bad. Now without high precision timestamping support, a kms driver must not set dev->vblank_disable_immediate = true, as this would cause problems for clients, so this shouldn't matter, but it would be good to still make this robust against a future kms driver which might have unreliable high precision timestamping, e.g., high precision timestamping that intermittently doesn't work. v3: Patch before coffee needs extra coffee. Testcase: igt/kms_vblank Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: Michel Dänzer <michel(a)daenzer.net> Cc: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Cc: Dave Airlie <airlied(a)redhat.com>, Cc: Mario Kleiner <mario.kleiner.de(a)gmail.com> Reviewed-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170315204027.20160-1-chris@c… Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/drm_irq.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) --- a/drivers/gpu/drm/drm_irq.c +++ b/drivers/gpu/drm/drm_irq.c @@ -1271,9 +1271,9 @@ void drm_vblank_put(struct drm_device *d if (atomic_dec_and_test(&vblank->refcount)) { if (drm_vblank_offdelay == 0) return; - else if (dev->vblank_disable_immediate || drm_vblank_offdelay < 0) + else if (drm_vblank_offdelay < 0) vblank_disable_fn((unsigned long)vblank); - else + else if (!dev->vblank_disable_immediate) mod_timer(&vblank->disable_timer, jiffies + ((drm_vblank_offdelay * HZ)/1000)); } @@ -1902,6 +1902,16 @@ bool drm_handle_vblank(struct drm_device wake_up(&vblank->queue); drm_handle_vblank_events(dev, pipe); + /* With instant-off, we defer disabling the interrupt until after + * we finish processing the following vblank. The disable has to + * be last (after drm_handle_vblank_events) so that the timestamp + * is always accurate. + */ + if (dev->vblank_disable_immediate && + drm_vblank_offdelay > 0 && + !atomic_read(&vblank->refcount)) + vblank_disable_fn((unsigned long)vblank); + spin_unlock_irqrestore(&dev->event_lock, irqflags); return true; Patches currently in stable-queue which might be from chris(a)chris-wilson.co.uk are queue-4.4/drm-defer-disabling-the-vblank-irq-until-the-next-interrupt-for-instant-off.patch queue-4.4/agp-intel-flush-all-chipset-writes-after-updating-the-ggtt.patch

7 years, 6 months

1
0
0 0

Patch "drm/amdkfd: Fix memory leaks in kfd topology" 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 drm/amdkfd: Fix memory leaks in kfd topology 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: drm-amdkfd-fix-memory-leaks-in-kfd-topology.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 09:58:12 CET 2018 From: Yong Zhao <yong.zhao(a)amd.com> Date: Fri, 8 Dec 2017 23:08:48 -0500 Subject: drm/amdkfd: Fix memory leaks in kfd topology From: Yong Zhao <yong.zhao(a)amd.com> [ Upstream commit 5108d768408abc80e4e8d99f5b406a73cb04056b ] Kobject created using kobject_create_and_add() can be freed using kobject_put() when there is no referenece any more. However, kobject memory allocated with kzalloc() has to set up a release callback in order to free it when the counter decreases to 0. Otherwise it causes memory leak. Signed-off-by: Yong Zhao <yong.zhao(a)amd.com> Signed-off-by: Felix Kuehling <Felix.Kuehling(a)amd.com> Reviewed-by: Oded Gabbay <oded.gabbay(a)gmail.com> Signed-off-by: Oded Gabbay <oded.gabbay(a)gmail.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 10 ++++++++++ 1 file changed, 10 insertions(+) --- a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c @@ -519,11 +519,17 @@ static ssize_t sysprops_show(struct kobj return ret; } +static void kfd_topology_kobj_release(struct kobject *kobj) +{ + kfree(kobj); +} + static const struct sysfs_ops sysprops_ops = { .show = sysprops_show, }; static struct kobj_type sysprops_type = { + .release = kfd_topology_kobj_release, .sysfs_ops = &sysprops_ops, }; @@ -559,6 +565,7 @@ static const struct sysfs_ops iolink_ops }; static struct kobj_type iolink_type = { + .release = kfd_topology_kobj_release, .sysfs_ops = &iolink_ops, }; @@ -586,6 +593,7 @@ static const struct sysfs_ops mem_ops = }; static struct kobj_type mem_type = { + .release = kfd_topology_kobj_release, .sysfs_ops = &mem_ops, }; @@ -625,6 +633,7 @@ static const struct sysfs_ops cache_ops }; static struct kobj_type cache_type = { + .release = kfd_topology_kobj_release, .sysfs_ops = &cache_ops, }; @@ -747,6 +756,7 @@ static const struct sysfs_ops node_ops = }; static struct kobj_type node_type = { + .release = kfd_topology_kobj_release, .sysfs_ops = &node_ops, }; Patches currently in stable-queue which might be from yong.zhao(a)amd.com are queue-4.4/drm-amdkfd-fix-memory-leaks-in-kfd-topology.patch

7 years, 6 months

1
0
0 0

Patch "drivers/perf: arm_pmu: handle no platform_device" 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 drivers/perf: arm_pmu: handle no platform_device 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: drivers-perf-arm_pmu-handle-no-platform_device.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 09:58:12 CET 2018 From: Mark Rutland <mark.rutland(a)arm.com> Date: Tue, 11 Apr 2017 09:39:49 +0100 Subject: drivers/perf: arm_pmu: handle no platform_device From: Mark Rutland <mark.rutland(a)arm.com> [ Upstream commit 7654137071fa706e5c91f4f27bc2a5cd7e435a9b ] In armpmu_dispatch_irq() we look at arm_pmu::plat_device to acquire platdata, so that we can defer to platform-specific IRQ handling, required on some 32-bit parts. With the advent of ACPI we won't always have a platform_device, and so we must avoid trying to dereference fields from it. This patch fixes up armpmu_dispatch_irq() to avoid doing so, introducing a new armpmu_get_platdata() helper. Signed-off-by: Mark Rutland <mark.rutland(a)arm.com> Tested-by: Jeremy Linton <jeremy.linton(a)arm.com> Cc: Will Deacon <will.deacon(a)arm.com> Signed-off-by: Will Deacon <will.deacon(a)arm.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/perf/arm_pmu.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) --- a/drivers/perf/arm_pmu.c +++ b/drivers/perf/arm_pmu.c @@ -321,10 +321,16 @@ validate_group(struct perf_event *event) return 0; } +static struct arm_pmu_platdata *armpmu_get_platdata(struct arm_pmu *armpmu) +{ + struct platform_device *pdev = armpmu->plat_device; + + return pdev ? dev_get_platdata(&pdev->dev) : NULL; +} + static irqreturn_t armpmu_dispatch_irq(int irq, void *dev) { struct arm_pmu *armpmu; - struct platform_device *plat_device; struct arm_pmu_platdata *plat; int ret; u64 start_clock, finish_clock; @@ -336,8 +342,8 @@ static irqreturn_t armpmu_dispatch_irq(i * dereference. */ armpmu = *(void **)dev; - plat_device = armpmu->plat_device; - plat = dev_get_platdata(&plat_device->dev); + + plat = armpmu_get_platdata(armpmu); start_clock = sched_clock(); if (plat && plat->handle_irq) Patches currently in stable-queue which might be from mark.rutland(a)arm.com are queue-4.4/drivers-perf-arm_pmu-handle-no-platform_device.patch

7 years, 6 months

1
0
0 0

Patch "drm/amdgpu: Fail fb creation from imported dma-bufs. (v2)" 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 drm/amdgpu: Fail fb creation from imported dma-bufs. (v2) 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: drm-amdgpu-fail-fb-creation-from-imported-dma-bufs.-v2.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 09:58:12 CET 2018 From: Christopher James Halse Rogers <christopher.halse.rogers(a)canonical.com> Date: Wed, 29 Mar 2017 15:02:11 +1100 Subject: drm/amdgpu: Fail fb creation from imported dma-bufs. (v2) From: Christopher James Halse Rogers <christopher.halse.rogers(a)canonical.com> [ Upstream commit 1769152ac64b0b07583f696b621624df2ca4c840 ] Any use of the framebuffer will migrate it to VRAM, which is not sensible for an imported dma-buf. v2: Use DRM_DEBUG_KMS to prevent userspace accidentally spamming dmesg. Reviewed-by: Michel Dänzer <michel.daenzer(a)amd.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Christopher James Halse Rogers <christopher.halse.rogers(a)canonical.com> CC: amd-gfx(a)lists.freedesktop.org Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c @@ -560,6 +560,12 @@ amdgpu_user_framebuffer_create(struct dr return ERR_PTR(-ENOENT); } + /* Handle is imported dma-buf, so cannot be migrated to VRAM for scanout */ + if (obj->import_attach) { + DRM_DEBUG_KMS("Cannot create framebuffer from imported dma_buf\n"); + return ERR_PTR(-EINVAL); + } + amdgpu_fb = kzalloc(sizeof(*amdgpu_fb), GFP_KERNEL); if (amdgpu_fb == NULL) { drm_gem_object_unreference_unlocked(obj); Patches currently in stable-queue which might be from christopher.halse.rogers(a)canonical.com are queue-4.4/drm-amdgpu-fail-fb-creation-from-imported-dma-bufs.-v2.patch queue-4.4/drm-radeon-fail-fb-creation-from-imported-dma-bufs.patch

7 years, 6 months

1
0
0 0

Patch "driver: (adm1275) set the m, b and R coefficients correctly for power" 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 driver: (adm1275) set the m,b and R coefficients correctly for power 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: driver-adm1275-set-the-m-b-and-r-coefficients-correctly-for-power.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 09:58:12 CET 2018 From: Shikhar Dogra <shidogra(a)cisco.com> Date: Mon, 27 Mar 2017 16:16:44 -0700 Subject: driver: (adm1275) set the m,b and R coefficients correctly for power From: Shikhar Dogra <shidogra(a)cisco.com> [ Upstream commit 6faecba0b3da7b617bf72bef422bf0d3bb6dfe7d ] Seems like coefficient values for m, b and R under power have been put in the wrong order. Rearranging them properly to get correct values of coefficients for power. For specs, please refer to table 7 (page 35) on http://www.analog.com/media/en/technical-documentation/data-sheets/ADM1075.… Fixes: 904b296f308d ("hwmon: (adm1275) Introduce configuration data structure for coeffcients") Signed-off-by: Shikhar Dogra <shidogra(a)cisco.com> Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/hwmon/pmbus/adm1275.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/hwmon/pmbus/adm1275.c +++ b/drivers/hwmon/pmbus/adm1275.c @@ -95,8 +95,8 @@ static const struct coefficients adm1075 [0] = { 27169, 0, -1 }, /* voltage */ [1] = { 806, 20475, -1 }, /* current, irange25 */ [2] = { 404, 20475, -1 }, /* current, irange50 */ - [3] = { 0, -1, 8549 }, /* power, irange25 */ - [4] = { 0, -1, 4279 }, /* power, irange50 */ + [3] = { 8549, 0, -1 }, /* power, irange25 */ + [4] = { 4279, 0, -1 }, /* power, irange50 */ }; static const struct coefficients adm1275_coefficients[] = { Patches currently in stable-queue which might be from shidogra(a)cisco.com are queue-4.4/driver-adm1275-set-the-m-b-and-r-coefficients-correctly-for-power.patch

7 years, 6 months

1
0
0 0

Patch "drivers: net: xgene: Fix hardware checksum setting" 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 drivers: net: xgene: Fix hardware checksum setting 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: drivers-net-xgene-fix-hardware-checksum-setting.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 09:58:12 CET 2018 From: Quan Nguyen <qnguyen(a)apm.com> Date: Wed, 15 Mar 2017 13:27:16 -0700 Subject: drivers: net: xgene: Fix hardware checksum setting From: Quan Nguyen <qnguyen(a)apm.com> [ Upstream commit e026e700d940a1ea3d3bc84d92ac668b1f015462 ] This patch fixes the hardware checksum settings by properly program the classifier. Otherwise, packet may be received with checksum error on X-Gene1 SoC. Signed-off-by: Quan Nguyen <qnguyen(a)apm.com> Signed-off-by: Iyappan Subramanian <isubramanian(a)apm.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 1 + drivers/net/ethernet/apm/xgene/xgene_enet_hw.h | 1 + 2 files changed, 2 insertions(+) --- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c +++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c @@ -604,6 +604,7 @@ static void xgene_enet_cle_bypass(struct xgene_enet_rd_csr(pdata, CLE_BYPASS_REG0_0_ADDR, &cb); cb |= CFG_CLE_BYPASS_EN0; CFG_CLE_IP_PROTOCOL0_SET(&cb, 3); + CFG_CLE_IP_HDR_LEN_SET(&cb, 0); xgene_enet_wr_csr(pdata, CLE_BYPASS_REG0_0_ADDR, cb); xgene_enet_rd_csr(pdata, CLE_BYPASS_REG1_0_ADDR, &cb); --- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h +++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h @@ -147,6 +147,7 @@ enum xgene_enet_rm { #define CFG_RXCLK_MUXSEL0_SET(dst, val) xgene_set_bits(dst, val, 26, 3) #define CFG_CLE_IP_PROTOCOL0_SET(dst, val) xgene_set_bits(dst, val, 16, 2) +#define CFG_CLE_IP_HDR_LEN_SET(dst, val) xgene_set_bits(dst, val, 8, 5) #define CFG_CLE_DSTQID0_SET(dst, val) xgene_set_bits(dst, val, 0, 12) #define CFG_CLE_FPSEL0_SET(dst, val) xgene_set_bits(dst, val, 16, 4) #define CFG_MACMODE_SET(dst, val) xgene_set_bits(dst, val, 18, 2) Patches currently in stable-queue which might be from qnguyen(a)apm.com are queue-4.4/drivers-net-xgene-fix-hardware-checksum-setting.patch

7 years, 6 months

1
0
0 0

Patch "dmaengine: imx-sdma: add 1ms delay to ensure SDMA channel is stopped" 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 dmaengine: imx-sdma: add 1ms delay to ensure SDMA channel is stopped 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: dmaengine-imx-sdma-add-1ms-delay-to-ensure-sdma-channel-is-stopped.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 09:58:12 CET 2018 From: Jiada Wang <jiada_wang(a)mentor.com> Date: Thu, 16 Mar 2017 23:12:09 -0700 Subject: dmaengine: imx-sdma: add 1ms delay to ensure SDMA channel is stopped From: Jiada Wang <jiada_wang(a)mentor.com> [ Upstream commit 7f3ff14b7eb1ffad132117f08a1973b48e653d43 ] sdma_disable_channel() cannot ensure dma is stopped to access module's FIFOs. There is chance SDMA core is running and accessing BD when disable of corresponding channel, this may cause sometimes even after call of .sdma_disable_channel(), SDMA core still be running and accessing module's FIFOs. According to NXP R&D team a delay of one BD SDMA cost time (maximum is 1ms) should be added after disable of the channel bit, to ensure SDMA core has really been stopped after SDMA clients call .device_terminate_all. This patch introduces adds a new function sdma_disable_channel_with_delay() which simply adds 1ms delay after call sdma_disable_channel(), and set it as .device_terminate_all. Signed-off-by: Jiada Wang <jiada_wang(a)mentor.com> Signed-off-by: Vinod Koul <vinod.koul(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/dma/imx-sdma.c | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) --- a/drivers/dma/imx-sdma.c +++ b/drivers/dma/imx-sdma.c @@ -911,6 +911,21 @@ static int sdma_disable_channel(struct d return 0; } +static int sdma_disable_channel_with_delay(struct dma_chan *chan) +{ + sdma_disable_channel(chan); + + /* + * According to NXP R&D team a delay of one BD SDMA cost time + * (maximum is 1ms) should be added after disable of the channel + * bit, to ensure SDMA core has really been stopped after SDMA + * clients call .device_terminate_all. + */ + mdelay(1); + + return 0; +} + static void sdma_set_watermarklevel_for_p2p(struct sdma_channel *sdmac) { struct sdma_engine *sdma = sdmac->sdma; @@ -1793,7 +1808,7 @@ static int sdma_probe(struct platform_de sdma->dma_device.device_prep_slave_sg = sdma_prep_slave_sg; sdma->dma_device.device_prep_dma_cyclic = sdma_prep_dma_cyclic; sdma->dma_device.device_config = sdma_config; - sdma->dma_device.device_terminate_all = sdma_disable_channel; + sdma->dma_device.device_terminate_all = sdma_disable_channel_with_delay; sdma->dma_device.src_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_4_BYTES); sdma->dma_device.dst_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_4_BYTES); sdma->dma_device.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV); Patches currently in stable-queue which might be from jiada_wang(a)mentor.com are queue-4.4/dmaengine-imx-sdma-add-1ms-delay-to-ensure-sdma-channel-is-stopped.patch

7 years, 6 months

1
0
0 0

Patch "cpufreq: Fix governor module removal race" 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 cpufreq: Fix governor module removal race 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: cpufreq-fix-governor-module-removal-race.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 09:58:12 CET 2018 From: "Rafael J. Wysocki" <rafael.j.wysocki(a)intel.com> Date: Thu, 23 Nov 2017 14:27:07 +0100 Subject: cpufreq: Fix governor module removal race From: "Rafael J. Wysocki" <rafael.j.wysocki(a)intel.com> [ Upstream commit a8b149d32b663c1a4105273295184b78f53d33cf ] It is possible to remove a cpufreq governor module after cpufreq_parse_governor() has returned success in store_scaling_governor() and before cpufreq_set_policy() acquires a reference to it, because the governor list is not protected during that period and nothing prevents the governor from being unregistered then. Prevent that from happening by acquiring an extra reference to the governor module temporarily in cpufreq_parse_governor(), under cpufreq_governor_mutex, and dropping it in store_scaling_governor(), when cpufreq_set_policy() returns. Note that the second cpufreq_parse_governor() call site is fine, because it only cares about the policy member of new_policy. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Acked-by: Viresh Kumar <viresh.kumar(a)linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/cpufreq/cpufreq.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -551,6 +551,8 @@ static int cpufreq_parse_governor(char * *governor = t; err = 0; } + if (t && !try_module_get(t->owner)) + t = NULL; mutex_unlock(&cpufreq_governor_mutex); } @@ -669,6 +671,10 @@ static ssize_t store_scaling_governor(st return -EINVAL; ret = cpufreq_set_policy(policy, &new_policy); + + if (new_policy.governor) + module_put(new_policy.governor->owner); + return ret ? ret : count; } Patches currently in stable-queue which might be from rafael.j.wysocki(a)intel.com are queue-4.4/cpufreq-fix-governor-module-removal-race.patch

7 years, 6 months

1
0
0 0

Patch "coresight: Fixes coresight DT parse to get correct output port ID." 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 coresight: Fixes coresight DT parse to get correct output port ID. 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: coresight-fixes-coresight-dt-parse-to-get-correct-output-port-id.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 09:58:12 CET 2018 From: Mike Leach <mike.leach(a)linaro.org> Date: Mon, 27 Mar 2017 11:09:33 -0600 Subject: coresight: Fixes coresight DT parse to get correct output port ID. From: Mike Leach <mike.leach(a)linaro.org> [ Upstream commit eeedc5421dd3b51de73e6106405c5c77f920f281 ] Corrected to get the port numbering to allow programmable replicator driver to operate correctly. By convention, CoreSight devices number ports, not endpoints in the .dts files:- port { reg<N> endpoint { } } Existing code read endpoint number - always 0x0, rather than the correct port number. Signed-off-by: Mike Leach <mike.leach(a)linaro.org> Signed-off-by: Mathieu Poirier <mathieu.poirier(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/hwtracing/coresight/of_coresight.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/hwtracing/coresight/of_coresight.c +++ b/drivers/hwtracing/coresight/of_coresight.c @@ -150,7 +150,7 @@ struct coresight_platform_data *of_get_c continue; /* The local out port number */ - pdata->outports[i] = endpoint.id; + pdata->outports[i] = endpoint.port; /* * Get a handle on the remote port and parent Patches currently in stable-queue which might be from mike.leach(a)linaro.org are queue-4.4/coresight-fixes-coresight-dt-parse-to-get-correct-output-port-id.patch

7 years, 6 months

1
0
0 0

Patch "braille-console: Fix value returned by _braille_console_setup" 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 braille-console: Fix value returned by _braille_console_setup 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: braille-console-fix-value-returned-by-_braille_console_setup.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 09:58:12 CET 2018 From: Samuel Thibault <samuel.thibault(a)ens-lyon.org> Date: Sun, 26 Mar 2017 22:47:36 +0200 Subject: braille-console: Fix value returned by _braille_console_setup From: Samuel Thibault <samuel.thibault(a)ens-lyon.org> [ Upstream commit 2ed2b8621be2708c0f6d61fe9841e9ad8b9753f0 ] commit bbeddf52adc1 ("printk: move braille console support into separate braille.[ch] files") introduced _braille_console_setup() to outline the braille initialization code. There was however some confusion over the value it was supposed to return. commit 2cfe6c4ac7ee ("printk: Fix return of braille_register_console()") tried to fix it but failed to. This fixes and documents the returned value according to the use in printk.c: non-zero return means a parsing error, and thus this console configuration should be ignored. Signed-off-by: Samuel Thibault <samuel.thibault(a)ens-lyon.org> Cc: Aleksey Makarov <aleksey.makarov(a)linaro.org> Cc: Joe Perches <joe(a)perches.com> Cc: Ming Lei <ming.lei(a)canonical.com> Cc: Steven Rostedt <rostedt(a)goodmis.org> Acked-by: Petr Mladek <pmladek(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/printk/braille.c | 15 ++++++++------- kernel/printk/braille.h | 13 ++++++++++--- 2 files changed, 18 insertions(+), 10 deletions(-) --- a/kernel/printk/braille.c +++ b/kernel/printk/braille.c @@ -2,12 +2,13 @@ #include <linux/kernel.h> #include <linux/console.h> +#include <linux/errno.h> #include <linux/string.h> #include "console_cmdline.h" #include "braille.h" -char *_braille_console_setup(char **str, char **brl_options) +int _braille_console_setup(char **str, char **brl_options) { if (!strncmp(*str, "brl,", 4)) { *brl_options = ""; @@ -15,14 +16,14 @@ char *_braille_console_setup(char **str, } else if (!strncmp(*str, "brl=", 4)) { *brl_options = *str + 4; *str = strchr(*brl_options, ','); - if (!*str) + if (!*str) { pr_err("need port name after brl=\n"); - else - *((*str)++) = 0; - } else - return NULL; + return -EINVAL; + } + *((*str)++) = 0; + } - return *str; + return 0; } int --- a/kernel/printk/braille.h +++ b/kernel/printk/braille.h @@ -9,7 +9,14 @@ braille_set_options(struct console_cmdli c->brl_options = brl_options; } -char * +/* + * Setup console according to braille options. + * Return -EINVAL on syntax error, 0 on success (or no braille option was + * actually given). + * Modifies str to point to the serial options + * Sets brl_options to the parsed braille options. + */ +int _braille_console_setup(char **str, char **brl_options); int @@ -25,10 +32,10 @@ braille_set_options(struct console_cmdli { } -static inline char * +static inline int _braille_console_setup(char **str, char **brl_options) { - return NULL; + return 0; } static inline int Patches currently in stable-queue which might be from samuel.thibault(a)ens-lyon.org are queue-4.4/braille-console-fix-value-returned-by-_braille_console_setup.patch queue-4.4/staging-speakup-replace-bug_on-with-warn_on.patch

7 years, 6 months

1
0
0 0

Patch "clk: qcom: msm8916: fix mnd_width for codec_digcodec" 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 clk: qcom: msm8916: fix mnd_width for codec_digcodec 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: clk-qcom-msm8916-fix-mnd_width-for-codec_digcodec.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 09:58:12 CET 2018 From: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org> Date: Wed, 6 Dec 2017 12:11:38 +0000 Subject: clk: qcom: msm8916: fix mnd_width for codec_digcodec From: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org> [ Upstream commit d8e488e8242ecf129eebc440c92d800a99ca109d ] This patch fixes missing mnd_width for codec_digital clk, this is now set to 8 inline with datasheet. Fixes: 3966fab8b6ab ("clk: qcom: Add MSM8916 Global Clock Controller support") Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org> Signed-off-by: Stephen Boyd <sboyd(a)codeaurora.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/clk/qcom/gcc-msm8916.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/clk/qcom/gcc-msm8916.c +++ b/drivers/clk/qcom/gcc-msm8916.c @@ -1437,6 +1437,7 @@ static const struct freq_tbl ftbl_codec_ static struct clk_rcg2 codec_digcodec_clk_src = { .cmd_rcgr = 0x1c09c, + .mnd_width = 8, .hid_width = 5, .parent_map = gcc_xo_gpll1_emclk_sleep_map, .freq_tbl = ftbl_codec_clk, Patches currently in stable-queue which might be from srinivas.kandagatla(a)linaro.org are queue-4.4/clk-qcom-msm8916-fix-mnd_width-for-codec_digcodec.patch

7 years, 6 months

1
0
0 0

Patch "bonding: refine bond_fold_stats() wrap detection" 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 bonding: refine bond_fold_stats() wrap detection 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: bonding-refine-bond_fold_stats-wrap-detection.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 09:58:12 CET 2018 From: Eric Dumazet <edumazet(a)google.com> Date: Wed, 29 Mar 2017 10:45:44 -0700 Subject: bonding: refine bond_fold_stats() wrap detection From: Eric Dumazet <edumazet(a)google.com> [ Upstream commit 142c6594acbcc32391af9c15f8cd65c6c177698f ] Some device drivers reset their stats at down/up events, possibly fooling bonding stats, since they operate with relative deltas. It is nearly not possible to fix drivers, since some of them compute the tx/rx counters based on per rx/tx queue stats, and the queues can be reconfigured (ethtool -L) between the down/up sequence. Lets avoid accumulating 'negative' values that render bonding stats useless. It is better to lose small deltas, assuming the bonding stats are fetched at a reasonable frequency. Fixes: 5f0c5f73e5ef ("bonding: make global bonding stats more reliable") Signed-off-by: Eric Dumazet <edumazet(a)google.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/bonding/bond_main.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) --- a/drivers/net/bonding/bond_main.c +++ b/drivers/net/bonding/bond_main.c @@ -3276,12 +3276,17 @@ static void bond_fold_stats(struct rtnl_ for (i = 0; i < sizeof(*_res) / sizeof(u64); i++) { u64 nv = new[i]; u64 ov = old[i]; + s64 delta = nv - ov; /* detects if this particular field is 32bit only */ if (((nv | ov) >> 32) == 0) - res[i] += (u32)nv - (u32)ov; - else - res[i] += nv - ov; + delta = (s64)(s32)((u32)nv - (u32)ov); + + /* filter anomalies, some drivers reset their stats + * at down/up events. + */ + if (delta > 0) + res[i] += delta; } } Patches currently in stable-queue which might be from edumazet(a)google.com are queue-4.4/selinux-check-for-address-length-in-selinux_socket_bind.patch queue-4.4/bonding-refine-bond_fold_stats-wrap-detection.patch

7 years, 6 months

1
0
0 0

Patch "blk-throttle: make sure expire time isn't too big" 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-throttle: make sure expire time isn't too big 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-throttle-make-sure-expire-time-isn-t-too-big.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 09:58:12 CET 2018 From: Shaohua Li <shli(a)fb.com> Date: Mon, 27 Mar 2017 10:51:36 -0700 Subject: blk-throttle: make sure expire time isn't too big From: Shaohua Li <shli(a)fb.com> [ Upstream commit 06cceedcca67a93ac7f7aa93bbd9980c7496d14e ] cgroup could be throttled to a limit but when all cgroups cross high limit, queue enters a higher state and so the group should be throttled to a higher limit. It's possible the cgroup is sleeping because of throttle and other cgroups don't dispatch IO any more. In this case, nobody can trigger current downgrade/upgrade logic. To fix this issue, we could either set up a timer to wakeup the cgroup if other cgroups are idle or make sure this cgroup doesn't sleep too long. Setting up a timer means we must change the timer very frequently. This patch chooses the latter. Making cgroup sleep time not too big wouldn't change cgroup bps/iops, but could make it wakeup more frequently, which isn't a big issue because throtl_slice * 8 is already quite big. Signed-off-by: Shaohua Li <shli(a)fb.com> Signed-off-by: Jens Axboe <axboe(a)fb.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- block/blk-throttle.c | 11 +++++++++++ 1 file changed, 11 insertions(+) --- a/block/blk-throttle.c +++ b/block/blk-throttle.c @@ -505,6 +505,17 @@ static void throtl_dequeue_tg(struct thr static void throtl_schedule_pending_timer(struct throtl_service_queue *sq, unsigned long expires) { + unsigned long max_expire = jiffies + 8 * throtl_slice; + + /* + * Since we are adjusting the throttle limit dynamically, the sleep + * time calculated according to previous limit might be invalid. It's + * possible the cgroup sleep time is very long and no other cgroups + * have IO running so notify the limit changes. Make sure the cgroup + * doesn't sleep too long to avoid the missed notification. + */ + if (time_after(expires, max_expire)) + expires = max_expire; mod_timer(&sq->pending_timer, expires); throtl_log(sq, "schedule timer. delay=%lu jiffies=%lu", expires - jiffies, jiffies); Patches currently in stable-queue which might be from shli(a)fb.com are queue-4.4/md-raid6-fix-anomily-when-recovering-a-single-device-in-raid6.patch queue-4.4/blk-throttle-make-sure-expire-time-isn-t-too-big.patch

7 years, 6 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror