May 2018 - Linux-stable-mirror

[PATCH 1/3] orangefs: set i_size on new symlink

by Martin Brandenburg

As long as a symlink inode remains in-core, the destination (and therefore size) will not be re-fetched from the server, as it cannot change. The original implementation of the attribute cache assumed that setting the expiry time in the past was sufficient to cause a re-fetch of all attributes on the next getattr. That does not work in this case. The bug manifested itself as follows. When the command sequence touch foo; ln -s foo bar; ls -l bar is run, the output was lrwxrwxrwx. 1 fedora fedora 4906 Apr 24 19:10 bar -> foo However, after a re-mount, ls -l bar produces lrwxrwxrwx. 1 fedora fedora 3 Apr 24 19:10 bar -> foo After this commit, even before a re-mount, the output is lrwxrwxrwx. 1 fedora fedora 3 Apr 24 19:10 bar -> foo Reported-by: Becky Ligon <ligon(a)clemson.edu> Signed-off-by: Martin Brandenburg <martin(a)omnibond.com> Fixes: 71680c18c8f2 ("orangefs: Cache getattr results.") Cc: stable(a)vger.kernel.org Cc: hubcap(a)omnibond.com --- fs/orangefs/namei.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/fs/orangefs/namei.c b/fs/orangefs/namei.c index 6e3134e6d98a..bfc4b1028701 100644 --- a/fs/orangefs/namei.c +++ b/fs/orangefs/namei.c @@ -327,6 +327,13 @@ static int orangefs_symlink(struct inode *dir, ret = PTR_ERR(inode); goto out; } + /* + * This is necessary because orangefs_inode_getattr will not + * re-read symlink size as it is impossible for it to change. + * Invalidating the cache does not help. orangefs_new_inode + * does not set the correct size (it does not know symname). + */ + inode->i_size = strlen(symname); gossip_debug(GOSSIP_NAME_DEBUG, "Assigned symlink inode new number of %pU\n", -- 2.14.3

5 years, 11 months

1
1
0 0

[PATCH v2] libata: Drop SanDisk SD7UB3Q*G1001 NOLPM quirk

by Hans de Goede

Commit 184add2ca23c ("libata: Apply NOLPM quirk for SanDisk SD7UB3Q*G1001 SSDs") disabled LPM for SanDisk SD7UB3Q*G1001 SSDs. This has lead to several reports of users of that SSD where LPM was working fine and who know have a significantly increased idle power consumption on their laptops. Likely there is another problem on the T450s from the original reporter which gets exposed by the uncore reaching deeper sleep states (higher PC-states) due to LPM being enabled. The problem as reported, a hardfreeze about once a day, already did not sound like it would be caused by LPM and the reports of the SSD working fine confirm this. The original reporter is ok with dropping the quirk. A X250 user has reported the same hard freeze problem and for him the problem went away after unrelated updates, I suspect some GPU driver stack changes fixed things. TL;DR: The original reporters problem were triggered by LPM but not an LPM issue, so drop the quirk for the SSD in question. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1583207 Cc: stable(a)vger.kernel.org Cc: Richard W.M. Jones <rjones(a)redhat.com> Cc: Lorenzo Dalrio <lorenzo.dalrio(a)gmail.com> Reported-by: Lorenzo Dalrio <lorenzo.dalrio(a)gmail.com> Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- Changes in v2: -Rebase on 4.17-rc7 --- drivers/ata/libata-core.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c index 346b163f6e89..9bfd2f7e4542 100644 --- a/drivers/ata/libata-core.c +++ b/drivers/ata/libata-core.c @@ -4557,9 +4557,6 @@ static const struct ata_blacklist_entry ata_device_blacklist [] = { { "SAMSUNG MZMPC128HBFU-000MV", "CXM14M1Q", ATA_HORKAGE_NOLPM, }, { "SAMSUNG SSD PM830 mSATA *", "CXM13D1Q", ATA_HORKAGE_NOLPM, }, - /* Sandisk devices which are known to not handle LPM well */ - { "SanDisk SD7UB3Q*G1001", NULL, ATA_HORKAGE_NOLPM, }, - /* devices that don't properly handle queued TRIM commands */ { "Micron_M500IT_*", "MU01", ATA_HORKAGE_NO_NCQ_TRIM | ATA_HORKAGE_ZERO_AFTER_TRIM, }, -- 2.17.0

5 years, 11 months

3
3
0 0

[PATCH v8 0/5] mtd: cfi_cmdset_0002: Change write and erase functions

by Tokunori Ikegami

The changes are to make sure to check the operation status. Actually the flash write and erase error behavior is caused on our products. The flash is Macronix flash device MX29GL512FHT2I-11G used by our products. The patch series was separated for changes of flash write and erase. Since those were not depended each other at the time. But by additional changes the changes are related more as same way currently. So combine patch series for the flash write and erase changes as v6. Signed-off-by: Tokunori Ikegami <ikegami(a)allied-telesis.co.jp> Reviewed-by: Joakim Tjernlund <Joakim.Tjernlund(a)infinera.com> Cc: Chris Packham <chris.packham(a)alliedtelesis.co.nz> Cc: Brian Norris <computersforpeace(a)gmail.com> Cc: David Woodhouse <dwmw2(a)infradead.org> Cc: Boris Brezillon <boris.brezillon(a)free-electrons.com> Cc: Marek Vasut <marek.vasut(a)gmail.com> Cc: Richard Weinberger <richard(a)nod.at> Cc: Cyrille Pitchen <cyrille.pitchen(a)wedev4u.fr> Cc: linux-mtd(a)lists.infradead.org Cc: stable(a)vger.kernel.org Tokunori Ikegami (5): mtd: cfi_cmdset_0002: Change write buffer to check correct value mtd: cfi_cmdset_0002: Change definition naming to retry write operation mtd: cfi_cmdset_0002: Change erase functions to retry for error mtd: cfi_cmdset_0002: Change erase functions to check chip good only mtd: cfi_cmdset_0002: Change erase one block to enable XIP once drivers/mtd/chips/cfi_cmdset_0002.c | 36 +++++++++++++++++++++++------------- 1 file changed, 23 insertions(+), 13 deletions(-) -- 2.16.1

5 years, 11 months

2
5
0 0

[PATCH 08/18] drm/amd/display: Update color props when modeset is required

by Harry Wentland

From: "Leo (Sunpeng) Li" <sunpeng.li(a)amd.com> This fixes issues where color management properties don't persist over DPMS on/off, or when the CRTC is moved across connectors. Signed-off-by: Leo (Sunpeng) Li <sunpeng.li(a)amd.com> Reviewed-by: Harry Wentland <Harry.Wentland(a)amd.com> Cc: stable(a)vger.kernel.org --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index b6020a83cdb0..29176d2c5d6e 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -4848,8 +4848,12 @@ static int dm_update_crtcs_state(struct amdgpu_display_manager *dm, update_stream_scaling_settings( &new_crtc_state->mode, dm_new_conn_state, dm_new_crtc_state->stream); - /* Color managment settings */ - if (dm_new_crtc_state->base.color_mgmt_changed) { + /* + * Color management settings. We also update color properties + * when a modeset is needed, to ensure it gets reprogrammed. + */ + if (dm_new_crtc_state->base.color_mgmt_changed || + drm_atomic_crtc_needs_modeset(new_crtc_state)) { ret = amdgpu_dm_set_regamma_lut(dm_new_crtc_state); if (ret) goto fail; -- 2.17.0

5 years, 11 months

1
0
0 0

[PATCH 05/18] drm/amd/display: Fix BUG_ON during CRTC atomic check update

by Harry Wentland

From: "Leo (Sunpeng) Li" <sunpeng.li(a)amd.com> For cases where the CRTC is inactive (DPMS off), where a modeset is not required, yet the CRTC is still in the atomic state, we should not attempt to update anything on it. Previously, we were relying on the modereset_required() helper to check the above condition. However, the function returns false immediatly if a modeset is not required, ignoring the CRTC's enable/active state flags. The correct way to filter is by looking at these flags instead. Signed-off-by: Leo (Sunpeng) Li <sunpeng.li(a)amd.com> Reviewed-by: Harry Wentland <Harry.Wentland(a)amd.com> Cc: stable(a)vger.kernel.org --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index e7ecddf359da..b6020a83cdb0 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -4830,15 +4830,16 @@ static int dm_update_crtcs_state(struct amdgpu_display_manager *dm, * We want to do dc stream updates that do not require a * full modeset below. */ - if (!enable || !aconnector || modereset_required(new_crtc_state)) + if (!(enable && aconnector && new_crtc_state->enable && + new_crtc_state->active)) continue; /* * Given above conditions, the dc state cannot be NULL because: - * 1. We're attempting to enable a CRTC. Which has a... - * 2. Valid connector attached, and - * 3. User does not want to reset it (disable or mark inactive, - * which can happen on a CRTC that's already disabled). - * => It currently exists. + * 1. We're in the process of enabling CRTCs (just been added + * to the dc context, or already is on the context) + * 2. Has a valid connector attached, and + * 3. Is currently active and enabled. + * => The dc stream state currently exists. */ BUG_ON(dm_new_crtc_state->stream == NULL); -- 2.17.0

5 years, 11 months

1
0
0 0

[PATCH v4] xpad: Add GPD Win 2 Controller USB IDs

by flibitijibibo＠gmail.com

From: Ethan Lee <flibitijibibo(a)gmail.com> GPD Win 2 Website: http://www.gpd.hk/gpdwin2.asp Tested on a unit from the first production run sent to Indiegogo backers Signed-off-by: Ethan Lee <flibitijibibo(a)gmail.com> Cc: stable(a)vger.kernel.org --- drivers/input/joystick/xpad.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c index 06e9650b3b30..a89b81b35932 100644 --- a/drivers/input/joystick/xpad.c +++ b/drivers/input/joystick/xpad.c @@ -123,6 +123,7 @@ static const struct xpad_device { u8 mapping; u8 xtype; } xpad_device[] = { + { 0x0079, 0x18d4, "GPD Win 2 Controller", 0, XTYPE_XBOX360 }, { 0x044f, 0x0f00, "Thrustmaster Wheel", 0, XTYPE_XBOX }, { 0x044f, 0x0f03, "Thrustmaster Wheel", 0, XTYPE_XBOX }, { 0x044f, 0x0f07, "Thrustmaster, Inc. Controller", 0, XTYPE_XBOX }, @@ -409,6 +410,7 @@ static const signed short xpad_abs_triggers[] = { static const struct usb_device_id xpad_table[] = { { USB_INTERFACE_INFO('X', 'B', 0) }, /* X-Box USB-IF not approved class */ + XPAD_XBOX360_VENDOR(0x0079), /* GPD Win 2 Controller */ XPAD_XBOX360_VENDOR(0x044f), /* Thrustmaster X-Box 360 controllers */ XPAD_XBOX360_VENDOR(0x045e), /* Microsoft X-Box 360 controllers */ XPAD_XBOXONE_VENDOR(0x045e), /* Microsoft X-Box One controllers */ -- 2.13.6

5 years, 11 months

2
1
0 0

[PATCH v3] goodix: Add new I2C/ACPI ids for GPD Win 2 touch screen

by flibitijibibo＠gmail.com

From: Ethan Lee <flibitijibibo(a)gmail.com> GPD Win 2 Website: http://www.gpd.hk/gpdwin2.asp Tested on a unit from the first production run sent to Indiegogo backers Signed-off-by: Ethan Lee <flibitijibibo(a)gmail.com> Cc: stable(a)vger.kernel.org --- drivers/input/touchscreen/goodix.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/input/touchscreen/goodix.c b/drivers/input/touchscreen/goodix.c index 9736c83dd418..6a4ffe800194 100644 --- a/drivers/input/touchscreen/goodix.c +++ b/drivers/input/touchscreen/goodix.c @@ -926,6 +926,7 @@ static SIMPLE_DEV_PM_OPS(goodix_pm_ops, goodix_suspend, goodix_resume); static const struct i2c_device_id goodix_ts_id[] = { { "GDIX1001:00", 0 }, + { "GDIX1002:00", 0 }, { } }; MODULE_DEVICE_TABLE(i2c, goodix_ts_id); @@ -933,6 +934,7 @@ MODULE_DEVICE_TABLE(i2c, goodix_ts_id); #ifdef CONFIG_ACPI static const struct acpi_device_id goodix_acpi_match[] = { { "GDIX1001", 0 }, + { "GDIX1002", 0 }, { } }; MODULE_DEVICE_TABLE(acpi, goodix_acpi_match); -- 2.13.6

5 years, 11 months

1
0
0 0

[PATCH v2 1/5] crypto: ccree: correct host regs offset

by Gilad Ben-Yossef

The product signature and HW revision register have different offset on the older HW revisions. This fixes the problem of the driver failing sanity check on silicon despite working on the FPGA emulation systems. Fixes: 27b3b22dd98c ("crypto: ccree - add support for older HW revs") Cc: stable(a)vger.kernel.org Signed-off-by: Gilad Ben-Yossef <gilad(a)benyossef.com> --- drivers/crypto/ccree/cc_debugfs.c | 7 +++++-- drivers/crypto/ccree/cc_driver.c | 8 ++++++-- drivers/crypto/ccree/cc_driver.h | 2 ++ drivers/crypto/ccree/cc_host_regs.h | 6 ++++-- 4 files changed, 17 insertions(+), 6 deletions(-) diff --git a/drivers/crypto/ccree/cc_debugfs.c b/drivers/crypto/ccree/cc_debugfs.c index 08f8db4..5ca184e 100644 --- a/drivers/crypto/ccree/cc_debugfs.c +++ b/drivers/crypto/ccree/cc_debugfs.c @@ -26,7 +26,8 @@ struct cc_debugfs_ctx { static struct dentry *cc_debugfs_dir; static struct debugfs_reg32 debug_regs[] = { - CC_DEBUG_REG(HOST_SIGNATURE), + { .name = "SIGNATURE" }, /* Must be 0th */ + { .name = "VERSION" }, /* Must be 1st */ CC_DEBUG_REG(HOST_IRR), CC_DEBUG_REG(HOST_POWER_DOWN_EN), CC_DEBUG_REG(AXIM_MON_ERR), @@ -34,7 +35,6 @@ static struct debugfs_reg32 debug_regs[] = { CC_DEBUG_REG(HOST_IMR), CC_DEBUG_REG(AXIM_CFG), CC_DEBUG_REG(AXIM_CACHE_PARAMS), - CC_DEBUG_REG(HOST_VERSION), CC_DEBUG_REG(GPR_HOST), CC_DEBUG_REG(AXIM_MON_COMP), }; @@ -58,6 +58,9 @@ int cc_debugfs_init(struct cc_drvdata *drvdata) struct debugfs_regset32 *regset; struct dentry *file; + debug_regs[0].offset = drvdata->sig_offset; + debug_regs[1].offset = drvdata->ver_offset; + ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL); if (!ctx) return -ENOMEM; diff --git a/drivers/crypto/ccree/cc_driver.c b/drivers/crypto/ccree/cc_driver.c index 89ce013..6f93ce7 100644 --- a/drivers/crypto/ccree/cc_driver.c +++ b/drivers/crypto/ccree/cc_driver.c @@ -207,9 +207,13 @@ static int init_cc_resources(struct platform_device *plat_dev) if (hw_rev->rev >= CC_HW_REV_712) { new_drvdata->hash_len_sz = HASH_LEN_SIZE_712; new_drvdata->axim_mon_offset = CC_REG(AXIM_MON_COMP); + new_drvdata->sig_offset = CC_REG(HOST_SIGNATURE_712); + new_drvdata->ver_offset = CC_REG(HOST_VERSION_712); } else { new_drvdata->hash_len_sz = HASH_LEN_SIZE_630; new_drvdata->axim_mon_offset = CC_REG(AXIM_MON_COMP8); + new_drvdata->sig_offset = CC_REG(HOST_SIGNATURE_630); + new_drvdata->ver_offset = CC_REG(HOST_VERSION_630); } platform_set_drvdata(plat_dev, new_drvdata); @@ -276,7 +280,7 @@ static int init_cc_resources(struct platform_device *plat_dev) } /* Verify correct mapping */ - signature_val = cc_ioread(new_drvdata, CC_REG(HOST_SIGNATURE)); + signature_val = cc_ioread(new_drvdata, new_drvdata->sig_offset); if (signature_val != hw_rev->sig) { dev_err(dev, "Invalid CC signature: SIGNATURE=0x%08X != expected=0x%08X\n", signature_val, hw_rev->sig); @@ -287,7 +291,7 @@ static int init_cc_resources(struct platform_device *plat_dev) /* Display HW versions */ dev_info(dev, "ARM CryptoCell %s Driver: HW version 0x%08X, Driver version %s\n", - hw_rev->name, cc_ioread(new_drvdata, CC_REG(HOST_VERSION)), + hw_rev->name, cc_ioread(new_drvdata, new_drvdata->ver_offset), DRV_MODULE_VERSION); rc = init_cc_regs(new_drvdata, true); diff --git a/drivers/crypto/ccree/cc_driver.h b/drivers/crypto/ccree/cc_driver.h index 2048fde..95f82b2 100644 --- a/drivers/crypto/ccree/cc_driver.h +++ b/drivers/crypto/ccree/cc_driver.h @@ -129,6 +129,8 @@ struct cc_drvdata { enum cc_hw_rev hw_rev; u32 hash_len_sz; u32 axim_mon_offset; + u32 sig_offset; + u32 ver_offset; }; struct cc_crypto_alg { diff --git a/drivers/crypto/ccree/cc_host_regs.h b/drivers/crypto/ccree/cc_host_regs.h index f510018..616b2e1 100644 --- a/drivers/crypto/ccree/cc_host_regs.h +++ b/drivers/crypto/ccree/cc_host_regs.h @@ -45,7 +45,8 @@ #define CC_HOST_ICR_DSCRPTR_WATERMARK_QUEUE0_CLEAR_BIT_SIZE 0x1UL #define CC_HOST_ICR_AXIM_COMP_INT_CLEAR_BIT_SHIFT 0x17UL #define CC_HOST_ICR_AXIM_COMP_INT_CLEAR_BIT_SIZE 0x1UL -#define CC_HOST_SIGNATURE_REG_OFFSET 0xA24UL +#define CC_HOST_SIGNATURE_712_REG_OFFSET 0xA24UL +#define CC_HOST_SIGNATURE_630_REG_OFFSET 0xAC8UL #define CC_HOST_SIGNATURE_VALUE_BIT_SHIFT 0x0UL #define CC_HOST_SIGNATURE_VALUE_BIT_SIZE 0x20UL #define CC_HOST_BOOT_REG_OFFSET 0xA28UL @@ -105,7 +106,8 @@ #define CC_HOST_BOOT_ONLY_ENCRYPT_LOCAL_BIT_SIZE 0x1UL #define CC_HOST_BOOT_AES_EXISTS_LOCAL_BIT_SHIFT 0x1EUL #define CC_HOST_BOOT_AES_EXISTS_LOCAL_BIT_SIZE 0x1UL -#define CC_HOST_VERSION_REG_OFFSET 0xA40UL +#define CC_HOST_VERSION_712_REG_OFFSET 0xA40UL +#define CC_HOST_VERSION_630_REG_OFFSET 0xAD8UL #define CC_HOST_VERSION_VALUE_BIT_SHIFT 0x0UL #define CC_HOST_VERSION_VALUE_BIT_SIZE 0x20UL #define CC_HOST_KFDE0_VALID_REG_OFFSET 0xA60UL -- 2.7.4

5 years, 11 months

2
2
0 0

[PATCH] libata: Drop SanDisk SD7UB3Q*G1001 NOLPM quirk

by Hans de Goede

Commit 184add2ca23c ("libata: Apply NOLPM quirk for SanDisk SD7UB3Q*G1001 SSDs") disabled LPM for SanDisk SD7UB3Q*G1001 SSDs. This has lead to several reports of users of that SSD where LPM was working fine and who know have a significantly increased idle power consumption on their laptops. Likely there is another problem on the T450s from the original reporter which gets exposed by the uncore reaching deeper sleep states (higher PC-states) due to LPM being enabled. The problem as reported, a hardfreeze about once a day, already did not sound like it would be caused by LPM and the reports of the SSD working fine confirm this. The original reporter is ok with dropping the quirk. A X250 user has reported the same hard freeze problem and for him the problem went away after unrelated updates, I suspect some GPU driver stack changes fixed things. TL;DR: The original reporters problem were triggered by LPM but not an LPM issue, so drop the quirk for the SSD in question. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1583207 Cc: stable(a)vger.kernel.org Cc: Richard W.M. Jones <rjones(a)redhat.com> Cc: Lorenzo Dalrio <lorenzo.dalrio(a)gmail.com> Reported-by: Lorenzo Dalrio <lorenzo.dalrio(a)gmail.com> Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- drivers/ata/libata-core.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c index 68596bd4cf06..6e400ff2b5db 100644 --- a/drivers/ata/libata-core.c +++ b/drivers/ata/libata-core.c @@ -4552,9 +4552,6 @@ static const struct ata_blacklist_entry ata_device_blacklist [] = { /* This specific Samsung model/firmware-rev does not handle LPM well */ { "SAMSUNG MZMPC128HBFU-000MV", "CXM14M1Q", ATA_HORKAGE_NOLPM, }, - /* Sandisk devices which are known to not handle LPM well */ - { "SanDisk SD7UB3Q*G1001", NULL, ATA_HORKAGE_NOLPM, }, - /* devices that don't properly handle queued TRIM commands */ { "Micron_M500_*", NULL, ATA_HORKAGE_NO_NCQ_TRIM | ATA_HORKAGE_ZERO_AFTER_TRIM, }, -- 2.17.0

5 years, 11 months

1
1
0 0

patch "usb: core: message: remove extra endianness conversion in" added to usb-testing

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: core: message: remove extra endianness conversion in to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-testing branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will be merged to the usb-next branch sometime soon, after it passes testing, and the merge window is open. If you have any questions about this process, please let me know. >From 48b73d0fa11aa8613d51f7be61d2fa7f0ab05fd3 Mon Sep 17 00:00:00 2001 From: Ruslan Bilovol <ruslan.bilovol(a)gmail.com> Date: Fri, 25 May 2018 19:11:40 +0300 Subject: usb: core: message: remove extra endianness conversion in usb_set_isoch_delay No need to do extra endianness conversion in usb_set_isoch_delay because it is already done in usb_control_msg() Fixes: 886ee36e7205 ("usb: core: add support for USB_REQ_SET_ISOCH_DELAY") Cc: Dmytro Panchenko <dmytro.panchenko(a)globallogic.com> Cc: Felipe Balbi <felipe.balbi(a)linux.intel.com> Cc: stable <stable(a)vger.kernel.org> # v4.16+ Signed-off-by: Ruslan Bilovol <ruslan.bilovol(a)gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/core/message.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c index 0c11d40a12bc..7b137003c2be 100644 --- a/drivers/usb/core/message.c +++ b/drivers/usb/core/message.c @@ -940,7 +940,7 @@ int usb_set_isoch_delay(struct usb_device *dev) return usb_control_msg(dev, usb_sndctrlpipe(dev, 0), USB_REQ_SET_ISOCH_DELAY, USB_DIR_OUT | USB_TYPE_STANDARD | USB_RECIP_DEVICE, - cpu_to_le16(dev->hub_delay), 0, NULL, 0, + dev->hub_delay, 0, NULL, 0, USB_CTRL_SET_TIMEOUT); } -- 2.17.1

5 years, 11 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2018