aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2017-09-20net: fec: remove unused interrupt FEC_ENET_TS_TIMERTroy Kisky1-2/+2
FEC_ENET_TS_TIMER is not checked in the interrupt routine so there is no need to enable it. Signed-off-by: Troy Kisky <[email protected]> Acked-by: Fugang Duan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-09-20net: fec: only check queue 0 if RXF_0/TXF_0 interrupt is setTroy Kisky1-2/+2
Before queue 0 was always checked if any queue caused an interrupt. It is better to just mark queue 0 if queue 0 has caused an interrupt. Signed-off-by: Troy Kisky <[email protected]> Acked-by: Fugang Duan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-09-20drm/amdkfd: Print event limit messages only once per processFelix Kuehling2-1/+5
To avoid spamming the log. Signed-off-by: Felix Kuehling <[email protected]> Reviewed-by: Oded Gabbay <[email protected]> Signed-off-by: Oded Gabbay <[email protected]>
2017-09-20drm/amdkfd: Fix kernel-queue wrapping bugsYong Zhao1-3/+15
Avoid intermediate negative numbers when doing calculations with a mix of signed and unsigned variables where implicit conversions can lead to unexpected results. When kernel queue buffer wraps around to 0, we need to check that rptr won't be overwritten by the new packet. Signed-off-by: Yong Zhao <[email protected]> Signed-off-by: Felix Kuehling <[email protected]> Signed-off-by: Oded Gabbay <[email protected]>
2017-09-20drm/amdkfd: Fix incorrect destroy_mqd parameterFelix Kuehling1-1/+1
When uninitializing a kernel queue. Signed-off-by: Yong Zhao <[email protected]> Signed-off-by: Felix Kuehling <[email protected]> Reviewed-by: Oded Gabbay <[email protected]> Signed-off-by: Oded Gabbay <[email protected]>
2017-09-21Merge tag 'exynos-drm-fixes-for-v4.14-rc1' of ↵Dave Airlie6-27/+55
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-fixes - fix suspend/resume issues. - fix memory corruption detected by kasan. - fix build error on x86. * tag 'exynos-drm-fixes-for-v4.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos: drm/exynos/hdmi: Fix unsafe list iteration drm: exynos: include linux/irq.h drm/exynos: Fix suspend/resume support drm/exynos: Fix locking in the suspend/resume paths
2017-09-20PCI: endpoint: Use correct "end of test" interruptJohn Keeping1-7/+6
pci_epf_test_raise_irq() reads the interrupt to use for the response from reg->command, but this has been cleared at the beginning of the command handler so the value is always zero at this point. Instead, extract the interrupt index before handling the command and then pass the requested interrupt into pci_epf_test_raise_irq(). This allows us to remove the specific code to extract the interrupt for COMMAND_RAISE_MSI_IRQ since it is now handled in common code. Fixes: 3ecf3232c54c ("PCI: endpoint: Do not reset *command* inadvertently") Signed-off-by: John Keeping <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Acked-by: Kishon Vijay Abraham I <[email protected]>
2017-09-20qtnfmac: cancel scans on wireless interface changesSergey Matyukevich3-5/+9
Cancel active scans and deactivate firmware scan watchdog timer when wireless interface configuration is changed. The usecases include wireless interface mode change, interface down, AP stop, virtual interface removal. Signed-off-by: Sergey Matyukevich <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2017-09-20qtnfmac: lock access to h/w in tx pathSergey Matyukevich2-1/+10
Fix tx path regression. Lock should be held when queuing packets to h/w fifos in order to properly handle configurations with multiple enabled interfaces. Signed-off-by: Sergey Matyukevich <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2017-09-20usb: gadget: dummy: fix nonsensical comparisonsArnd Bergmann1-5/+4
gcc-8 points out two comparisons that are clearly bogus and almost certainly not what the author intended to write: drivers/usb/gadget/udc/dummy_hcd.c: In function 'set_link_state_by_speed': drivers/usb/gadget/udc/dummy_hcd.c:379:31: error: bitwise comparison always evaluates to false [-Werror=tautological-compare] USB_PORT_STAT_ENABLE) == 1 && ^~ drivers/usb/gadget/udc/dummy_hcd.c:381:25: error: bitwise comparison always evaluates to false [-Werror=tautological-compare] USB_SS_PORT_LS_U0) == 1 && ^~ I looked at the code for a bit and came up with a change that makes it look like what the author probably meant here. This makes it look reasonable to me and to gcc, shutting up the warning. It does of course change behavior as the two conditions are actually evaluated rather than being hardcoded to false, and I have made no attempt at verifying that the changed logic makes sense in the context of a USB HCD, so that part needs to be reviewed carefully. Fixes: 1cd8fd2887e1 ("usb: gadget: dummy_hcd: add SuperSpeed support") Cc: Tatyana Brokhman <[email protected]> Cc: Felipe Balbi <[email protected]> Acked-by: Alan Stern <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2017-09-20usb: gadget: udc: fix snps_udc_plat.c build errorsRandy Dunlap1-0/+1
Fix build errors that happen when CONFIG_EXTCON=m and CONFIG_USB_SNP_UDC_PLAT=y by preventing that combination in Kconfig. CONFIG_EXTCON can still be disabled or enabled for this driver since <linux/extcon.h> has stubs for the disabled case, but if CONFIG_EXTCON=m, USB_SNP_UDC_PLAT is restricted to m or n (cannot be builtin). drivers/built-in.o: In function `udc_plat_remove': snps_udc_plat.c:(.text+0x2c4060): undefined reference to `extcon_unregister_notifier' drivers/built-in.o: In function `udc_plat_probe': snps_udc_plat.c:(.text+0x2c438c): undefined reference to `extcon_get_edev_by_phandle' snps_udc_plat.c:(.text+0x2c43f2): undefined reference to `extcon_register_notifier' snps_udc_plat.c:(.text+0x2c4416): undefined reference to `extcon_get_state' snps_udc_plat.c:(.text+0x2c44f7): undefined reference to `extcon_unregister_notifier' Reported-by: kbuild test robot <[email protected]> Signed-off-by: Randy Dunlap <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2017-09-20usb: gadget: function: printer: avoid spinlock recursionYoshihiro Shimoda1-1/+6
If usb_gadget_giveback_request() is called in usb_ep_queue(), this printer_write() is possible to cause spinlock recursion. So, this patch adds spin_unlock() before calls usb_ep_queue() to avoid it. Signed-off-by: Yoshihiro Shimoda <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2017-09-20usb: gadget: core: fix ->udc_set_speed() logicRoger Quadros1-2/+1
Consider the following case: udc controller supports SuperSpeed. If we first load a HighSpeed gadget followed by a SuperSpeed gadget, the SuperSpeed gadget will be limited to HighSpeed as UDC core driver doesn't call ->udc_set_speed() in the second case. Call ->udc_set_speed() unconditionally to fix this issue. This will also fix the case for dwc3 controller driver when SuperSpeed gadget is loaded first and works in HighSpeed only as udc_set_speed() was never being called. Fixes: 6099eca796ae ("usb: gadget: core: introduce ->udc_set_speed() method") Cc: <[email protected]> [v4.13+] Signed-off-by: Roger Quadros <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2017-09-20crypto: caam - fix LS1021A support on ARMv7 multiplatform kernelHoria Geantă3-44/+39
When built using multi_v7_defconfig, driver does not work on LS1021A: [...] caam 1700000.crypto: can't identify CAAM ipg clk: -2 caam: probe of 1700000.crypto failed with error -2 [...] It turns out we have to detect at runtime whether driver is running on an i.MX platform or not. Cc: <[email protected]> Fixes: 6c3af9559352 ("crypto: caam - add support for LS1021A") Signed-off-by: Horia Geantă <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2017-09-20crypto: inside-secure - fix gcc-4.9 warningsArnd Bergmann2-2/+2
All older compiler versions up to gcc-4.9 produce these harmless warnings: drivers/crypto/inside-secure/safexcel_cipher.c:389:9: warning: missing braces around initializer [-Wmissing-braces] drivers/crypto/inside-secure/safexcel_cipher.c:389:9: warning: (near initialization for ‘result.completion’) [-Wmissing-braces] drivers/crypto/inside-secure/safexcel_hash.c:422:9: warning: missing braces around initializer [-Wmissing-braces] drivers/crypto/inside-secure/safexcel_hash.c:422:9: warning: (near initialization for ‘result.completion’) [-Wmissing-braces] This changes the syntax to something that works on all versions without warnings. Fixes: 1b44c5a60c13 ("crypto: inside-secure - add SafeXcel EIP197 crypto engine driver") Signed-off-by: Arnd Bergmann <[email protected]> Acked-by: Antoine Tenart <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2017-09-20crypto: talitos - Don't provide setkey for non hmac hashing algs.LEROY Christophe1-1/+2
Today, md5sum fails with error -ENOKEY because a setkey function is set for non hmac hashing algs, see strace output below: mmap(NULL, 378880, PROT_READ, MAP_SHARED, 6, 0) = 0x77f50000 accept(3, 0, NULL) = 7 vmsplice(5, [{"bin/\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 378880}], 1, SPLICE_F_MORE|SPLICE_F_GIFT) = 262144 splice(4, NULL, 7, NULL, 262144, SPLICE_F_MORE) = -1 ENOKEY (Required key not available) write(2, "Generation of hash for file kcap"..., 50) = 50 munmap(0x77f50000, 378880) = 0 This patch ensures that setkey() function is set only for hmac hashing. Cc: <[email protected]> Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2017-09-20crypto: talitos - fix hashingLEROY Christophe1-1/+1
md5sum on some files gives wrong result Exemple: With the md5sum from libkcapi: c15115c05bad51113f81bdaee735dd09 test With the original md5sum: bbdf41d80ba7e8b2b7be3a0772be76cb test This patch fixes this issue Cc: <[email protected]> Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2017-09-20crypto: talitos - fix sha224LEROY Christophe1-2/+2
Kernel crypto tests report the following error at startup [ 2.752626] alg: hash: Test 4 failed for sha224-talitos [ 2.757907] 00000000: 30 e2 86 e2 e7 8a dd 0d d7 eb 9f d5 83 fe f1 b0 00000010: 2d 5a 6c a5 f9 55 ea fd 0e 72 05 22 This patch fixes it Cc: <[email protected]> Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2017-09-20brcmfmac: setup passive scan if requested by user-spaceArend Van Spriel2-15/+9
The driver was not properly configuring firmware with regard to the type of scan. It always performed an active scan even when user-space was requesting for passive scan, ie. the scan request was done without any SSIDs specified. Cc: [email protected] # v4.0.x Reported-by: Huang, Jiangyang <[email protected]> Reviewed-by: Hante Meuleman <[email protected]> Reviewed-by: Pieter-Paul Giesberts <[email protected]> Reviewed-by: Franky Lin <[email protected]> Signed-off-by: Arend van Spriel <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2017-09-20brcmfmac: add length check in brcmf_cfg80211_escan_handler()Arend Van Spriel1-3/+15
Upon handling the firmware notification for scans the length was checked properly and may result in corrupting kernel heap memory due to buffer overruns. This fix addresses CVE-2017-0786. Cc: [email protected] # v4.0.x Cc: Kevin Cernekee <[email protected]> Reviewed-by: Hante Meuleman <[email protected]> Reviewed-by: Pieter-Paul Giesberts <[email protected]> Reviewed-by: Franky Lin <[email protected]> Signed-off-by: Arend van Spriel <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2017-09-19Merge tag 'scsi-fixes' of ↵Linus Torvalds4-34/+40
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "This is a set of five small fixes: one is a null deref fix which is pretty critical for the fc transport class and one fixes a potential security issue of sg leaking kernel information" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: sg: fixup infoleak when using SG_GET_REQUEST_TABLE scsi: sg: factor out sg_fill_request_table() scsi: sd: Remove unnecessary condition in sd_read_block_limits() scsi: acornscsi: fix build error scsi: scsi_transport_fc: fix NULL pointer dereference in fc_bsg_job_timeout
2017-09-20drm/exynos/hdmi: Fix unsafe list iterationMaciej Purski1-3/+11
Function hdmi_mode_fixup() used bare list_for_each entry, which was unsafe and caused memory corruption detected by kasan. It now uses drm_for_each_connector_iter macro, which is now recommended by the documentation and safe. Signed-off-by: Maciej Purski <[email protected]> Signed-off-by: Inki Dae <[email protected]>
2017-09-19net: emac: Fix napi poll list corruptionChristian Lamparter1-2/+1
This patch is pretty much a carbon copy of commit 3079c652141f ("caif: Fix napi poll list corruption") with "caif" replaced by "emac". The commit d75b1ade567f ("net: less interrupt masking in NAPI") breaks emac. It is now required that if the entire budget is consumed when poll returns, the napi poll_list must remain empty. However, like some other drivers emac tries to do a last-ditch check and if there is more work it will call napi_reschedule and then immediately process some of this new work. Should the entire budget be consumed while processing such new work then we will violate the new caller contract. This patch fixes this by not touching any work when we reschedule in emac. Signed-off-by: Christian Lamparter <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-09-19net: hns3: Fixes the premature exit of loop when matching clientsLipeng1-34/+9
When register/unregister ae_dev, ae_dev should match all client in the client_list. Enet and roce can co-exists together so we should continue checking for enet and roce presence together. So break should not be there. Above caused problems in loading and unloading of modules. Fixes: 38eddd126772 ("net: hns3: Add support of the HNAE3 framework") Signed-off-by: Lipeng <[email protected]> Signed-off-by: Salil Mehta <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-09-19net: hns3: Fixes the default VLAN-id of PFLipeng1-1/+5
When there is no vlan id in the packets, hardware will treat the vlan id as 0 and look for the mac_vlan table. This patch set the default vlan id of PF as 0. Without this config, it will fail when look for mac_vlan table, and hardware will drop packets. Fixes: 6427264ef330 ("net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support") Signed-off-by: Mingguang Qu <[email protected]> Signed-off-by: Lipeng <[email protected]> Signed-off-by: Salil Mehta <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-09-19net: hns3: Fixes the ether address copy with appropriate APISalil Mehta1-2/+1
This patch replaces the ethernet address copy instance with more appropriate ether_addr_copy() function. Fixes: 6427264ef330 ("net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support") Signed-off-by: Salil Mehta <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-09-19net: hns3: Fixes the initialization of MAC address in hardwareLipeng1-3/+4
This patch fixes the initialization of MAC address, fetched from HNS3 firmware i.e. when it is not randomly generated, to the HNS3 hardware. Fixes: ca60906d2795 ("net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC") Signed-off-by: Lipeng <[email protected]> Signed-off-by: Salil Mehta <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-09-19net: hns3: Fixes ring-to-vector map-and-unmap commandLipeng2-2/+14
This patch fixes the vector-to-ring map and unmap command and adds INT_GL(for, Gap Limiting Interrupts) and VF id to it as required by the hardware interface. Fixes: 6427264ef330 ("net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support") Signed-off-by: Lipeng <[email protected]> Signed-off-by: Mingguang Qu <[email protected]> Signed-off-by: Salil Mehta <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-09-19net: hns3: Fixes the command used to unmap ring from vectorLipeng1-1/+1
This patch fixes the IMP command being used to unmap the vector from the corresponding ring. Fixes: 6427264ef330 ("net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support") Signed-off-by: Lipeng <[email protected]> Signed-off-by: Salil Mehta <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-09-19net: hns3: Fixes initialization of phy address from firmwareLipeng1-0/+1
Default phy address of every port is 0. Therefore, phy address for each port need to be fetched from firmware and device initialized with fetched non-default phy address. Fixes: 6427264ef330 ("net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support") Signed-off-by: Lipeng <[email protected]> Signed-off-by: Salil Mehta <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-09-20cpufreq: ti-cpufreq: Support additional am43xx platformsDave Gerlach1-1/+1
Rather than letting the ti-cpufreq driver match against 'ti,am4372' machine compatible during probe let's match against 'ti,am43' so that we can support both 'ti,am4372' and 'ti,am438x' platforms which both match to this compatible. Signed-off-by: Dave Gerlach <[email protected]> Acked-by: Viresh Kumar <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2017-09-19ACPI: properties: Return _DSD hierarchical extension (data) sub-nodes correctlySakari Ailus1-5/+6
The recently merged patch "ACPI: Prepare for constifying acpi_get_next_subnode() fwnode argument" was part of a patchset constifying the fwnode arguments across the fwnode property API. The purpose of the patch was to allow returning non-const fwnodes from a data structure the root of which is const. Unfortunately the patch introduced the functionality, in particular when starting parsed from an ACPI device node, the hierarchical data extension nodes would not be enumerated. Restore the old behaviour while still retaining constness properties of the patch. Fixes: 01c1da289791 "ACPI: Prepare for constifying acpi_get_next_subnode() fwnode argument" Signed-off-by: Sakari Ailus <[email protected]> Acked-by: Mika Westerberg <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2017-09-19ARM: cpuidle: Avoid memleak if init failStefan Wahren1-2/+4
In case there are no DT idle states defined or cpuidle_register_driver() fails, the copy of the idle driver is leaked: unreferenced object 0xede0dc00 (size 1024): comm "swapper/0", pid 1, jiffies 4294937431 (age 744.510s) hex dump (first 32 bytes): 94 9e 0b c1 00 00 00 00 00 00 00 00 00 00 00 00 ................ 57 46 49 00 00 00 00 00 00 00 00 00 00 00 00 00 WFI............. backtrace: [<c1295f04>] arm_idle_init+0x44/0x1ac [<c0301e6c>] do_one_initcall+0x3c/0x16c [<c1200d70>] kernel_init_freeable+0x110/0x1d0 [<c0cb3624>] kernel_init+0x8/0x114 [<c0307a98>] ret_from_fork+0x14/0x3c So fix this by freeing the unregistered copy in error case. Signed-off-by: Stefan Wahren <[email protected]> Fixes: d50a7d8acd78 (ARM: cpuidle: Support asymmetric idle definition) Signed-off-by: Rafael J. Wysocki <[email protected]>
2017-09-19cpufreq: dt-platdev: Add some missing platforms to the blacklistViresh Kumar1-0/+12
Commit edeec420de24 (cpufreq: dt-platdev: Automatically create cpufreq device with OPP v2) missed adding few platforms to the blacklist which create the cpufreq-dt device from their own drivers, after some dependencies are sorted out. And for those platforms, both the platform specific driver and the cpufreq-dt-platdev driver try to create the cpufreq-dt device now. Fix that by including those platforms in the blacklist. This doesn't include the TI platforms, for which there is a separate patch. Fixes: edeec420de24 (cpufreq: dt-cpufreq: platdev Automatically create device with OPP v2) Signed-off-by: Viresh Kumar <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2017-09-19PM: core: Fix device_pm_check_callbacks()Rafael J. Wysocki1-3/+6
The device_pm_check_callbacks() function doesn't check legacy ->suspend and ->resume callback pointers under the device's bus type, class and driver, so in some cases it may set the no_pm_callbacks flag for the device incorrectly and then the callbacks may be skipped during system suspend/resume, which shouldn't happen. Fixes: aa8e54b55947 (PM / sleep: Go direct_complete if driver has no callbacks) Signed-off-by: Rafael J. Wysocki <[email protected]> Cc: 4.5+ <[email protected]> # 4.5+
2017-09-19net: phy: Kconfig: Fix PHY infrastructure menu in menuconfigJerome Brunet1-9/+9
Since the integration of PHYLINK, the configuration option which used to be under the PHY infrastructure menu in menuconfig ended up one level up (the network device driver section) By placing PHYLINK option right after PHYLIB entry, it broke the way Kconfig used to build the menu. See kconfig-language.txt, section "Menu structure", 2nd method. This is fixed by placing the PHYLINK option just before PHYLIB. Fixes: 9525ae83959b ("phylink: add phylink infrastructure") Signed-off-by: Jerome Brunet <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-09-19ACPI / bus: Make ACPI_HANDLE() work for non-GPL code againJohn Hubbard1-0/+13
Due to commit db3e50f3234b (device property: Get rid of struct fwnode_handle type field), ACPI_HANDLE() inadvertently became a GPL-only call. The call path that led to that was: ACPI_HANDLE() ACPI_COMPANION() to_acpi_device_node() is_acpi_device_node() acpi_device_fwnode_ops DECLARE_ACPI_FWNODE_OPS(acpi_device_fwnode_ops); ...and the new DECLARE_ACPI_FWNODE_OPS() includes EXPORT_SYMBOL_GPL, whereas previously it was a static struct. In order to avoid changing any of that, let's instead provide ever so slightly better encapsulation of those struct fwnode_operations instances. Those do not really need to be directly used in inline function calls in header files. Simply moving two small functions (is_acpi_device_node and is_acpi_data_node) out of acpi_bus.h, and into a .c file, does that. That leaves the internals of struct fwnode_operations as GPL-only (which I think was the intent all along), but un-breaks any driver code out there that relies on the ACPI subsystem's being (historically) an EXPORT_SYMBOL-usable system. By that, I mean, ACPI_HANDLE() and other basic ACPI calls were non-GPL-protected. Also, while I'm there, remove a tiny bit of redundancy that was missed in the earlier commit, by having is_acpi_node() use the other two routines, instead of checking fwnode directly. Fixes: db3e50f3234b (device property: Get rid of struct fwnode_handle type field) Signed-off-by: John Hubbard <[email protected]> Acked-by: Sakari Ailus <[email protected]> Acked-by: Mika Westerberg <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2017-09-19irqchip.mips-gic: Fix shared interrupt mask writesPaul Burton1-3/+3
The write_gic_smask() & write_gic_rmask() functions take a shared interrupt number as a parameter, but we're incorrectly providing them a bitmask with the shared interrupt's bit set. This effectively means that we mask or unmask the shared interrupt 1<<n rather than shared interrupt n, and as a result likely drop interrupts. Signed-off-by: Paul Burton <[email protected]> Fixes: 68898c8765f4 ("irqchip: mips-gic: Drop gic_(re)set_mask() functions") Cc: Jason Cooper <[email protected]> Cc: Marc Zyngier <[email protected]> Cc: Ralf Baechle <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Signed-off-by: Marc Zyngier <[email protected]>
2017-09-19irqchip/gic-v4: Fix building with ancient gccArnd Bergmann1-3/+9
gcc-4.5 and earlier don't like named initializers for anonymous union members: drivers/irqchip/irq-gic-v4.c: In function 'its_map_vlpi': drivers/irqchip/irq-gic-v4.c:176:3: error: unknown field 'map' specified in initializer drivers/irqchip/irq-gic-v4.c:176:3: error: missing braces around initializer drivers/irqchip/irq-gic-v4.c:176:3: error: (near initialization for 'info.<anonymous>') drivers/irqchip/irq-gic-v4.c: In function 'its_get_vlpi': drivers/irqchip/irq-gic-v4.c:192:3: error: unknown field 'map' specified in initializer drivers/irqchip/irq-gic-v4.c:192:3: error: missing braces around initializer drivers/irqchip/irq-gic-v4.c:192:3: error: (near initialization for 'info.<anonymous>') drivers/irqchip/irq-gic-v4.c: In function 'its_prop_update_vlpi': drivers/irqchip/irq-gic-v4.c:208:3: error: unknown field 'config' specified in initializer drivers/irqchip/irq-gic-v4.c:208:3: error: missing braces around initializer drivers/irqchip/irq-gic-v4.c:208:3: error: (near initialization for 'info.<anonymous>') drivers/irqchip/irq-gic-v4.c:208:3: error: initialization makes pointer from integer without a cast This is fairly easy to work around, by using extra curly braces. Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Marc Zyngier <[email protected]>
2017-09-19irqchip/gic-v3: Iterate over possible CPUs by for_each_possible_cpu()zijun_hu1-4/+4
get_cpu_number() doesn't use existing helper to iterate over possible CPUs, It will cause an error in case of discontinuous @cpu_possible_mask such as 0b11110001, which can result from a core having failed to come up on a SMP machine. Fixed by using existing helper for_each_possible_cpu(). Signed-off-by: zijun_hu <[email protected]> Signed-off-by: Marc Zyngier <[email protected]>
2017-09-19Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/shli/mdLinus Torvalds1-3/+10
Pull MD fixes from Shaohua Li: "Two small patches to fix long-lived raid5 stripe batch bugs, one from Dennis and the other from me" * 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/shli/md: md/raid5: preserve STRIPE_ON_UNPLUG_LIST in break_stripe_batch_list md/raid5: fix a race condition in stripe batch
2017-09-19USB: fix out-of-bounds in usb_set_configurationGreg Kroah-Hartman1-3/+11
Andrey Konovalov reported a possible out-of-bounds problem for a USB interface association descriptor. He writes: It seems there's no proper size check of a USB_DT_INTERFACE_ASSOCIATION descriptor. It's only checked that the size is >= 2 in usb_parse_configuration(), so find_iad() might do out-of-bounds access to intf_assoc->bInterfaceCount. And he's right, we don't check for crazy descriptors of this type very well, so resolve this problem. Yet another issue found by syzkaller... Reported-by: Andrey Konovalov <[email protected]> Tested-by: Andrey Konovalov <[email protected]> Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-09-19iommu/qcom: Depend on HAS_DMA to fix compile errorGeert Uytterhoeven1-0/+1
If NO_DMA=y: warning: (IPMMU_VMSA && ARM_SMMU && ARM_SMMU_V3 && QCOM_IOMMU) selects IOMMU_IO_PGTABLE_LPAE which has unmet direct dependencies (IOMMU_SUPPORT && HAS_DMA && (ARM || ARM64 || COMPILE_TEST && !GENERIC_ATOMIC64)) and drivers/iommu/io-pgtable-arm.o: In function `__arm_lpae_sync_pte': io-pgtable-arm.c:(.text+0x206): undefined reference to `bad_dma_ops' drivers/iommu/io-pgtable-arm.o: In function `__arm_lpae_free_pages': io-pgtable-arm.c:(.text+0x6a6): undefined reference to `bad_dma_ops' drivers/iommu/io-pgtable-arm.o: In function `__arm_lpae_alloc_pages': io-pgtable-arm.c:(.text+0x812): undefined reference to `bad_dma_ops' io-pgtable-arm.c:(.text+0x81c): undefined reference to `bad_dma_ops' io-pgtable-arm.c:(.text+0x862): undefined reference to `bad_dma_ops' drivers/iommu/io-pgtable-arm.o: In function `arm_lpae_run_tests': io-pgtable-arm.c:(.init.text+0x86): undefined reference to `alloc_io_pgtable_ops' io-pgtable-arm.c:(.init.text+0x47c): undefined reference to `free_io_pgtable_ops' drivers/iommu/qcom_iommu.o: In function `qcom_iommu_init_domain': qcom_iommu.c:(.text+0x1ce): undefined reference to `alloc_io_pgtable_ops' drivers/iommu/qcom_iommu.o: In function `qcom_iommu_domain_free': qcom_iommu.c:(.text+0x754): undefined reference to `free_io_pgtable_ops' QCOM_IOMMU selects IOMMU_IO_PGTABLE_LPAE, which bypasses its dependency on HAS_DMA. Make QCOM_IOMMU depend on HAS_DMA to fix this. Fixes: 0ae349a0f33fb040 ("iommu/qcom: Add qcom_iommu") Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Joerg Roedel <[email protected]>
2017-09-19drm: exynos: include linux/irq.hArnd Bergmann1-0/+1
I ran into a build error on x86: drivers/gpu/drm/exynos/exynos5433_drm_decon.c: In function 'decon_conf_irq': drivers/gpu/drm/exynos/exynos5433_drm_decon.c:706:2: error: implicit declaration of function 'irq_set_status_flags'; did you mean 'dquot_state_flag'? [-Werror=implicit-function-declaration] irq_set_status_flags(irq, IRQ_NOAUTOEN); Adding the missing include fixes the error. Fixes: b37d53a0382c ("drm/exynos/decon5433: move TE handling to DECON") Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Inki Dae <[email protected]>
2017-09-19drm/exynos: Fix suspend/resume supportMarek Szyprowski4-28/+43
Commit 7d902c05b480 ("drm: Nuke drm_atomic_helper_connector_dpms") removed drm_atomic_helper_connector_dpms() helper saying that it was a dead code. It was however indirectly used by Exynos DRM driver for implementing suspend/resume support. To fix this regression (after that patch Exynos DRM suspend/resume functions became no-ops and hardware fails to suspend), this patch rewrites them with drm_atomic_helper_suspend/resume() helpers. Fixes: 7d902c05b480 ("drm: Nuke drm_atomic_helper_connector_dpms") Signed-off-by: Marek Szyprowski <[email protected]> Acked-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Inki Dae <[email protected]>
2017-09-19drm/exynos: Fix locking in the suspend/resume pathsMarek Szyprowski1-0/+4
Commit 48a92916729b ("drm/exynos: use drm_for_each_connector_iter()") replaced unsafe drm_for_each_connector() with drm_for_each_connector_iter() and removed surrounding drm_modeset_lock calls. However, that lock was there not only to protect unsafe drm_for_each_connector(), but it was also required to be held by the dpms code which was called from the loop body. This patch restores those drm_modeset_lock calls to fix broken suspend and resume of Exynos DRM subsystem in v4.13 kernel. Fixes: 48a92916729b ("drm/exynos: use drm_for_each_connector_iter()") CC: [email protected] # v4.13 Signed-off-by: Marek Szyprowski <[email protected]> Acked-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Inki Dae <[email protected]>
2017-09-19iommu/vt-d: Fix harmless section mismatch warningArnd Bergmann1-1/+1
Building with gcc-4.6 results in this warning due to dmar_table_print_dmar_entry being inlined as in newer compiler versions: WARNING: vmlinux.o(.text+0x5c8bee): Section mismatch in reference from the function dmar_walk_remapping_entries() to the function .init.text:dmar_table_print_dmar_entry() The function dmar_walk_remapping_entries() references the function __init dmar_table_print_dmar_entry(). This is often because dmar_walk_remapping_entries lacks a __init annotation or the annotation of dmar_table_print_dmar_entry is wrong. This removes the __init annotation to avoid the warning. On compilers that don't show the warning today, this should have no impact since the function gets inlined anyway. Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Joerg Roedel <[email protected]>
2017-09-19iommu: Add missing dependenciesGuenter Roeck1-2/+2
parisc:allmodconfig, xtensa:allmodconfig, and possibly others generate the following Kconfig warning. warning: (IPMMU_VMSA && ARM_SMMU && ARM_SMMU_V3 && QCOM_IOMMU) selects IOMMU_IO_PGTABLE_LPAE which has unmet direct dependencies (IOMMU_SUPPORT && HAS_DMA && (ARM || ARM64 || COMPILE_TEST && !GENERIC_ATOMIC64)) IOMMU_IO_PGTABLE_LPAE depends on (COMPILE_TEST && !GENERIC_ATOMIC64), so any configuration option selecting it needs to have the same dependencies. Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Joerg Roedel <[email protected]>
2017-09-19USB: serial: cp210x: add support for ELV TFD500Andreas Engel1-0/+1
Add the USB device id for the ELV TFD500 data logger. Signed-off-by: Andreas Engel <[email protected]> Cc: stable <[email protected]> Signed-off-by: Johan Hovold <[email protected]>
2017-09-19gpio: acpi: work around false-positive -Wstring-overflow warningArnd Bergmann1-1/+1
gcc-7 notices that the pin_table is an array of 16-bit numbers, but fails to take the following range check into account: drivers/gpio/gpiolib-acpi.c: In function 'acpi_gpiochip_request_interrupt': drivers/gpio/gpiolib-acpi.c:206:24: warning: '%02X' directive writing between 2 and 4 bytes into a region of size 3 [-Wformat-overflow=] sprintf(ev_name, "_%c%02X", ^~~~ drivers/gpio/gpiolib-acpi.c:206:20: note: directive argument in the range [0, 65535] sprintf(ev_name, "_%c%02X", ^~~~~~~~~ drivers/gpio/gpiolib-acpi.c:206:3: note: 'sprintf' output between 5 and 7 bytes into a destination of size 5 sprintf(ev_name, "_%c%02X", ^~~~~~~~~~~~~~~~~~~~~~~~~~~ agpio->triggering == ACPI_EDGE_SENSITIVE ? 'E' : 'L', ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ pin); ~~~~ As suggested by Andy, this changes the format string to have a fixed length. Since modifying the range check did not help, I also opened a bug against gcc, see link below. Fixes: 0d1c28a449c6 ("gpiolib-acpi: Add ACPI5 event model support to gpio.") Cc: Andy Shevchenko <[email protected]> Link: https://patchwork.kernel.org/patch/9840801/ Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82123 Signed-off-by: Arnd Bergmann <[email protected]> Acked-by: Mika Westerberg <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.