kernel/linux.git/drivers, branch v4.9.287

scsi: virtio_scsi: Fix spelling mistake "Unsupport" -> "Unsupported"

2021-10-17T08:05:40+00:00

[ Upstream commit cced4c0ec7c06f5230a2958907a409c849762293 ] There are a couple of spelling mistakes in pr_info and pr_err messages. Fix them. Link: https://lore.kernel.org/r/20210924230330.143785-1-colin.king@canonical.com Signed-off-by: Colin Ian King Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin

scsi: ses: Fix unsigned comparison with less than zero

2021-10-17T08:05:40+00:00

[ Upstream commit dd689ed5aa905daf4ba4c99319a52aad6ea0a796 ] Fix the following coccicheck warning: ./drivers/scsi/ses.c:137:10-16: WARNING: Unsigned expression compared with zero: result > 0. Link: https://lore.kernel.org/r/1632477113-90378-1-git-send-email-jiapeng.chong@linux.alibaba.com Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin

HID: apple: Fix logical maximum and usage maximum of Magic Keyboard JIS

2021-10-17T08:05:40+00:00

[ Upstream commit 67fd71ba16a37c663d139f5ba5296f344d80d072 ] Apple Magic Keyboard(JIS)'s Logical Maximum and Usage Maximum are wrong. Below is a report descriptor. 0x05, 0x01, /* Usage Page (Desktop), */ 0x09, 0x06, /* Usage (Keyboard), */ 0xA1, 0x01, /* Collection (Application), */ 0x85, 0x01, /* Report ID (1), */ 0x05, 0x07, /* Usage Page (Keyboard), */ 0x15, 0x00, /* Logical Minimum (0), */ 0x25, 0x01, /* Logical Maximum (1), */ 0x19, 0xE0, /* Usage Minimum (KB Leftcontrol), */ 0x29, 0xE7, /* Usage Maximum (KB Right GUI), */ 0x75, 0x01, /* Report Size (1), */ 0x95, 0x08, /* Report Count (8), */ 0x81, 0x02, /* Input (Variable), */ 0x95, 0x05, /* Report Count (5), */ 0x75, 0x01, /* Report Size (1), */ 0x05, 0x08, /* Usage Page (LED), */ 0x19, 0x01, /* Usage Minimum (01h), */ 0x29, 0x05, /* Usage Maximum (05h), */ 0x91, 0x02, /* Output (Variable), */ 0x95, 0x01, /* Report Count (1), */ 0x75, 0x03, /* Report Size (3), */ 0x91, 0x03, /* Output (Constant, Variable), */ 0x95, 0x08, /* Report Count (8), */ 0x75, 0x01, /* Report Size (1), */ 0x15, 0x00, /* Logical Minimum (0), */ 0x25, 0x01, /* Logical Maximum (1), */ here is a report descriptor which is parsed one in kernel. see sys/kernel/debug/hid//rdesc 05 01 09 06 a1 01 85 01 05 07 15 00 25 01 19 e0 29 e7 75 01 95 08 81 02 95 05 75 01 05 08 19 01 29 05 91 02 95 01 75 03 91 03 95 08 75 01 15 00 25 01 06 00 ff 09 03 81 03 95 06 75 08 15 00 25 [65] 05 07 19 00 29 [65] 81 00 95 01 75 01 15 00 25 01 05 0c 09 b8 81 02 95 01 75 01 06 01 ff 09 03 81 02 95 01 75 06 81 03 06 02 ff 09 55 85 55 15 00 26 ff 00 75 08 95 40 b1 a2 c0 06 00 ff 09 14 a1 01 85 90 05 84 75 01 95 03 15 00 25 01 09 61 05 85 09 44 09 46 81 02 95 05 81 01 75 08 95 01 15 00 26 ff 00 09 65 81 02 c0 00 Position 64(Logical Maximum) and 70(Usage Maximum) are 101. Both should be 0xE7 to support JIS specific keys(ろ, Eisu, Kana, |) support. position 117 is also 101 but not related(it is Usage 65h). There are no difference of product id between JIS and ANSI. They are same 0x0267. Signed-off-by: Mizuho Mori Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin

i40e: fix endless loop under rtnl

2021-10-17T08:05:40+00:00

[ Upstream commit 857b6c6f665cca9828396d9743faf37fd09e9ac3 ] The loop in i40e_get_capabilities can never end. The problem is that although i40e_aq_discover_capabilities returns with an error if there's a firmware problem, the returned error is not checked. There is a check for pf->hw.aq.asq_last_status but that value is set to I40E_AQ_RC_OK on most firmware problems. When i40e_aq_discover_capabilities encounters a firmware problem, it will encounter the same problem on its next invocation. As the result, the loop becomes endless. We hit this with I40E_ERR_ADMIN_QUEUE_TIMEOUT but looking at the code, it can happen with a range of other firmware errors. I don't know what the correct behavior should be: whether the firmware should be retried a few times, or whether pf->hw.aq.asq_last_status should be always set to the encountered firmware error (but then it would be pointless and can be just replaced by the i40e_aq_discover_capabilities return value). However, the current behavior with an endless loop under the rtnl mutex(!) is unacceptable and Intel has not submitted a fix, although we explained the bug to them 7 months ago. This may not be the best possible fix but it's better than hanging the whole system on a firmware bug. Fixes: 56a62fc86895 ("i40e: init code and hardware support") Tested-by: Stefan Assmann Signed-off-by: Jiri Benc Reviewed-by: Jesse Brandeburg Tested-by: Dave Switzer Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin

drm/nouveau/debugfs: fix file release memory leak

2021-10-17T08:05:39+00:00

[ Upstream commit f5a8703a9c418c6fc54eb772712dfe7641e3991c ] When using single_open() for opening, single_release() should be called, otherwise the 'op' allocated in single_open() will be leaked. Fixes: 6e9fc177399f ("drm/nouveau/debugfs: add copy of sysfs pstate interface ported to debugfs") Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Reviewed-by: Karol Herbst Signed-off-by: Karol Herbst Link: https://patchwork.freedesktop.org/patch/msgid/20210911075023.3969054-2-yangyingliang@huawei.com Signed-off-by: Maarten Lankhorst Signed-off-by: Sasha Levin

ptp_pch: Load module automatically if ID matches

2021-10-17T08:05:39+00:00

[ Upstream commit 7cd8b1542a7ba0720c5a0a85ed414a122015228b ] The driver can't be loaded automatically because it misses module alias to be provided. Add corresponding MODULE_DEVICE_TABLE() call to the driver. Fixes: 863d08ece9bf ("supports eg20t ptp clock") Signed-off-by: Andy Shevchenko Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

phy: mdio: fix memory leak

2021-10-17T08:05:39+00:00

[ Upstream commit ca6e11c337daf7925ff8a2aac8e84490a8691905 ] Syzbot reported memory leak in MDIO bus interface, the problem was in wrong state logic. MDIOBUS_ALLOCATED indicates 2 states: 1. Bus is only allocated 2. Bus allocated and __mdiobus_register() fails, but device_register() was called In case of device_register() has been called we should call put_device() to correctly free the memory allocated for this device, but mdiobus_free() calls just kfree(dev) in case of MDIOBUS_ALLOCATED state To avoid this behaviour we need to set bus->state to MDIOBUS_UNREGISTERED _before_ calling device_register(), because put_device() should be called even in case of device_register() failure. Link: https://lore.kernel.org/netdev/YVMRWNDZDUOvQjHL@shell.armlinux.org.uk/ Fixes: 46abc02175b3 ("phylib: give mdio buses a device tree presence") Reported-and-tested-by: syzbot+398e7dc692ddbbb4cfec@syzkaller.appspotmail.com Reviewed-by: Dan Carpenter Signed-off-by: Pavel Skripkin Link: https://lore.kernel.org/r/eceae1429fbf8fa5c73dd2a0d39d525aa905074d.1633024062.git.paskripkin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

USB: cdc-acm: fix break reporting

2021-10-17T08:05:38+00:00

commit 58fc1daa4d2e9789b9ffc880907c961ea7c062cc upstream. A recent change that started reporting break events forgot to push the event to the line discipline, which meant that a detected break would not be reported until further characters had been receive (the port could even have been closed and reopened in between). Fixes: 08dff274edda ("cdc-acm: fix BREAK rx code path adding necessary calls") Cc: stable@vger.kernel.org Acked-by: Oliver Neukum Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210929090937.7410-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman

USB: cdc-acm: fix racy tty buffer accesses

2021-10-17T08:05:38+00:00

commit 65a205e6113506e69a503b61d97efec43fc10fd7 upstream. A recent change that started reporting break events to the line discipline caused the tty-buffer insertions to no longer be serialised by inserting events also from the completion handler for the interrupt endpoint. Completion calls for distinct endpoints are not guaranteed to be serialised. For example, in case a host-controller driver uses bottom-half completion, the interrupt and bulk-in completion handlers can end up running in parallel on two CPUs (high-and low-prio tasklets, respectively) thereby breaking the tty layer's single producer assumption. Fix this by holding the read lock also when inserting characters from the bulk endpoint. Fixes: 08dff274edda ("cdc-acm: fix BREAK rx code path adding necessary calls") Cc: stable@vger.kernel.org Acked-by: Oliver Neukum Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210929090937.7410-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman

Partially revert "usb: Kconfig: using select for USB_COMMON dependency"

2021-10-17T08:05:38+00:00

commit 4d1aa9112c8e6995ef2c8a76972c9671332ccfea upstream. This reverts commit cb9c1cfc86926d0e86d19c8e34f6c23458cd3478 for USB_LED_TRIG. This config symbol has bool type and enables extra code in usb_common itself, not a separate driver. Enabling it should not force usb_common to be built-in! Fixes: cb9c1cfc8692 ("usb: Kconfig: using select for USB_COMMON dependency") Cc: stable Signed-off-by: Ben Hutchings Signed-off-by: Salvatore Bonaccorso Link: https://lore.kernel.org/r/20210921143442.340087-1-carnil@debian.org Signed-off-by: Greg Kroah-Hartman