kernel/linux.git/drivers, branch v3.16.61

usb: misc: usb3503: Update error code in print message

2018-11-20T18:06:03+00:00

commit ec5734c41bee2ee7c938a8f34853d31cada7e67a upstream. 'err' is uninitialized, rather print the error code directly. This also fixes following warning. drivers/usb/misc/usb3503.c: In function ‘usb3503_probe’: drivers/usb/misc/usb3503.c:195:11: warning: ‘err’ may be used uninitialized in this function [-Wmaybe-uninitialized] dev_err(dev, "unable to request refclk (%d)\n", err); Signed-off-by: Tushar Behera Acked-by: Marek Szyprowski Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings

p54: memset(0) whole array

2018-11-20T18:06:02+00:00

commit 6f17581788206444cbbcdbc107498f85e9765e3d upstream. gcc 7 complains: drivers/net/wireless/intersil/p54/fwio.c: In function 'p54_scan': drivers/net/wireless/intersil/p54/fwio.c:491:4: warning: 'memset' used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size] Fix that by passing the correct size to memset. Signed-off-by: Jiri Slaby Cc: Christian Lamparter Cc: Kalle Valo Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org Acked-by: Christian Lamparter Signed-off-by: Kalle Valo [bwh: Backported to 3.16: adjust filename] Signed-off-by: Ben Hutchings

ir-core: fix gcc-7 warning on bool arithmetic

2018-11-20T18:06:02+00:00

commit bd7e31bbade02bc1e92aa00d5cf2cee2da66838a upstream. gcc-7 suggests that an expression using a bitwise not and a bitmask on a 'bool' variable is better written using boolean logic: drivers/media/rc/imon.c: In function 'imon_incoming_scancode': drivers/media/rc/imon.c:1725:22: error: '~' on a boolean expression [-Werror=bool-operation] ictx->pad_mouse = ~(ictx->pad_mouse) & 0x1; ^ drivers/media/rc/imon.c:1725:22: note: did you mean to use logical not? I agree. Fixes: 21677cfc562a ("V4L/DVB: ir-core: add imon driver") Signed-off-by: Arnd Bergmann Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Ben Hutchings

net/wireless/brcm80211/brcmfmac: Make return type and name reflect actual semantics

2018-11-20T18:06:01+00:00

commit e843bb199ba58ce5d1364d4c82fcf6975f08eec2 upstream. Applying ++ to a bool is equivalent to setting it true, regardless of its initial value (bools are not uint1_t). Hence the function wl_get_vif_state_all can only ever return true/false. The only in-tree caller uses its return value as a boolean. So update its return type, and since the list traversal and bit testing have no side effects, just return true immediately. Its return value tells if any vif is in the specified state, so also rename it to brcmf_get_vif_state_any. Reviewed-by: Arend van Spriel Signed-off-by: Rasmus Villemoes Signed-off-by: John W. Linville Signed-off-by: Ben Hutchings

clk: si5351: Constify clock names and struct regmap_config

2018-11-20T18:06:01+00:00

commit 8234caed27f7bce141c9fb1f7e76c91a2a66d248 upstream. The regmap_config struct may be const because it is not modified by the driver and regmap_init() accepts pointer to const. Replace doubled const in the arrays of clock names with proper const pointer to const data. This fixes the warnings: drivers/clk/clk-si5351.c:71:25: warning: duplicate const drivers/clk/clk-si5351.c:74:25: warning: duplicate const drivers/clk/clk-si5351.c:77:25: warning: duplicate const drivers/clk/clk-si5351.c:80:25: warning: duplicate const Signed-off-by: Krzysztof Kozlowski Reviewed-by: Max Filippov Signed-off-by: Stephen Boyd Signed-off-by: Ben Hutchings

iio: iio-trig-periodic-rtc: Free trigger resource correctly

2018-11-20T18:06:01+00:00

This is based on upstream commit 10e840dfb0b7, which did not touch the iio-trig-periodic-rtc driver because it has been removed upstream. The following explanation comes from that commit: These stand-alone trigger drivers were using iio_trigger_put() where they should have been using iio_trigger_free(). The iio_trigger_put() adds a module_put which is bad since they never did a module_get. In the sysfs driver, module_get/put's are used as triggers are added & removed. This extra module_put() occurs on an error path in the probe routine (probably rare). In the bfin-timer & interrupt trigger drivers, the module resources are not explicitly managed, so it's doing a put on something that was never get'd. It occurs on the probe error path and on the remove path (not so rare). Tested with the sysfs trigger driver. The bfin & interrupt drivers were build tested & inspected only. This was build tested only. Cc: Alison Schofield Cc: Jonathan Cameron Signed-off-by: Ben Hutchings Signed-off-by: Ben Hutchings

usbip: stub_rx: fix static checker warning on unnecessary checks

2018-11-20T18:06:00+00:00

commit 10c90120930628e8b959bf58d4a0aaef3ae5d945 upstream. Fix the following static checker warnings: The patch c6688ef9f297: "usbip: fix stub_rx: harden CMD_SUBMIT path to handle malicious input" from Dec 7, 2017, leads to the following static checker warning: drivers/usb/usbip/stub_rx.c:346 get_pipe() warn: impossible condition '(pdu->u.cmd_submit.transfer_buffer_length > ((~0 >> 1))) => (s32min-s32max > s32max)' drivers/usb/usbip/stub_rx.c:486 stub_recv_cmd_submit() warn: always true condition '(pdu->u.cmd_submit.transfer_buffer_length <= ((~0 >> 1))) => (s32min-s32max <= s32max)' Reported-by: Dan Carpenter Signed-off-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings

HID: clamp input to logical range if no null state

2018-11-20T18:05:59+00:00

commit c3883fe06488a483658ba5d849b70e49bee15e7c upstream. 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).asp Signed-off-by: Tomasz Kramkowski Acked-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Ben Hutchings

HID: reject input outside logical range only if null state is set

2018-11-20T18:05:59+00:00

commit 3f3752705dbd50b66b66ad7b4d54fe33d2f746ed upstream. 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@the-tk.com: shortened and fixed spelling in commit message] Signed-off-by: Valtteri Heikkilä Signed-off-by: Tomasz Kramkowski Acked-By: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Ben Hutchings

HID: usbhid: add quirk for innomedia INNEX GENESIS/ATARI adapter

2018-11-20T18:05:59+00:00

commit 9547837bdccb4af127528b36a73377150658b4ac upstream. The (1292:4745) Innomedia INNEX GENESIS/ATARI adapter needs HID_QUIRK_MULTI_INPUT to split the device up into two controllers instead of inputs from both being merged into one. Signed-off-by: Tomasz Kramkowski Acked-By: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Ben Hutchings