summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2017-07-27ARM: dts: sun8i: a83t: Switch to CCU device tree binding macrosChen-Yu Tsai
Now that the CCU device tree binding headers have been merged, we can use the properly named macros in the device tree, instead of raw numbers. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
2017-07-27arm64: allwinner: sun50i-a64: Correct emac register sizeCorentin Labbe
The datasheet said that emac register size is 0x10000 not 0x100 Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [wens@csie.org: Fixed commit subject prefix] Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2017-07-27ARM: dts: sunxi: h3/h5: Correct emac register sizeCorentin Labbe
The datasheet said that emac register size is 0x10000 not 0x104 Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [wens@csie.org: Fixed commit subject prefix] Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2017-07-27scsi: sg: only check for dxfer_len greater than 256MJohannes Thumshirn
Don't make any assumptions on the sg_io_hdr_t::dxfer_direction or the sg_io_hdr_t::dxferp in order to determine if it is a valid request. The only way we can check for bad requests is by checking if the length exceeds 256M. Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de> Fixes: 28676d869bbb (scsi: sg: check for valid direction before starting the request) Reported-by: Jason L Tibbitts III <tibbs@math.uh.edu> Tested-by: Jason L Tibbitts III <tibbs@math.uh.edu> Suggested-by: Doug Gilbert <dgilbert@interlog.com> Cc: Doug Gilbert <dgilbert@interlog.com> Cc: <stable@vger.kernel.org> Reviewed-by: Hannes Reinecke <hare@suse.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2017-07-27drivers/perf: arm_pmu: Request PMU SPIs with IRQF_PER_CPUWill Deacon
Since the PMU register interface is banked per CPU, CPU PMU interrrupts cannot be handled by a CPU other than the one with the PMU asserting the interrupt. This means that migrating PMU SPIs, as we do during a CPU hotplug operation doesn't make any sense and can lead to the IRQ being disabled entirely if we route a spurious IRQ to the new affinity target. This has been observed in practice on AMD Seattle, where CPUs on the non-boot cluster appear to take a spurious PMU IRQ when coming online, which is routed to CPU0 where it cannot be handled. This patch passes IRQF_PERCPU for PMU SPIs and forcefully sets their affinity prior to requesting them, ensuring that they cannot be migrated during hotplug events. This interacts badly with the DB8500 erratum workaround that ping-pongs the interrupt affinity from the handler, so we avoid passing IRQF_PERCPU in that case by allowing the IRQ flags to be overridden in the platdata. Fixes: 3cf7ee98b848 ("drivers/perf: arm_pmu: move irq request/free into probe") Cc: Mark Rutland <mark.rutland@arm.com> Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Will Deacon <will.deacon@arm.com>
2017-07-27ARM: sa1100: normalize clk APIArnd Bergmann
sa1100 provides its own variant of the clk API rather than using the generic COMMON_CLK API. This generally works, but it causes some link errors with drivers using the clk_set_rate, clk_get_parent, clk_set_parent or clk_round_rate functions when a platform lacks those interfaces. This adds trivial stub implementations for each of them, based on the behavior of the COMMON_CLK implementation: - set_rate() and set_parent() report success without doing anything - round_rate() returns the clk rate - get_parent() returns NULL. This adds the minimal bloat and should do the right thing for the simple clock hardware in this SoC. Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2017-07-27ARM: davinci: normalize clk APIArnd Bergmann
davinci still has its own clk implementation, but lacks a clk_get_parent() helper, which can lead to link errors in randconfig builds. This adds the usual implementation. Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2017-07-27ARM: sa1100/pxa: fix MTD_XIP buildArnd Bergmann
In commit 3169663ac5902 "ARM: sa11x0/pxa: convert OS timer registers to IOMEM", the definition of the OSCR macro was changed to be an __iomem pointer, but the same register is also used by the XIP code. This patch does the corresponding change here as well. On PXA, the IRQ register definitions were removed even earlier, in commit 5d284e353eb1 ("ARM: pxa: avoid accessing interrupt registers directly"). This patch unfortunately brings some of that back. An earlier version of my patch moved the code into an external function, which could not work for CONFIG_XIP_KERNEL+CONFIG_MTD_XIP, so this restores something close to the original code. Link: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-March/241716.html Acked-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2017-07-27ARM: davinci: don't mark vpif_input structures as 'const'Arnd Bergmann
A change to the platform data definitions caused a warning in the board code: arch/arm/mach-davinci/board-da850-evm.c:1221:13: warning: initialization discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers] arch/arm/mach-davinci/board-da850-evm.c:1231:13: warning: initialization discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers] This is a bit unfortunate, since we generally like structure definitions to be const, but as this is legacy code, the easiest way out is still to remove the 'const' annotation here. Fixes: 4a5f8ae50b66 ("[media] davinci: vpif_capture: get subdevs from DT when available") Fixes: 231ce279e6e3 ("ARM: davinci: fix const warnings") Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2017-07-27soc: zte: Restrict SOC_ZTE to ARCH_ZX or COMPILE_TESTGeert Uytterhoeven
The ZTE SoC drivers are only useful when building for a ZTE ZX platform. Fixes: 4c2c2e39713b8cfb ("soc: zte: pm_domains: Prepare for supporting ARMv8 zx2967 family") Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Baoyou Xie <baoyou.xie@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2017-07-27brcmfmac: fix memleak due to calling brcmf_sdiod_sgtable_alloc() twiceArend Van Spriel
Due to a bugfix in wireless tree and the commit mentioned below a merge was needed which went haywire. So the submitted change resulted in the function brcmf_sdiod_sgtable_alloc() being called twice during the probe thus leaking the memory of the first call. Cc: stable@vger.kernel.org # 4.6.x Fixes: 4d7928959832 ("brcmfmac: switch to new platform data") Reported-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2017-07-27brcmfmac: Don't grow SKB by negative sizeDaniel Stone
The commit to rework the headroom check in start_xmit() now calls pxskb_expand_head() unconditionally if the header is CoW. Unfortunately, it does so with the delta between the extant headroom and the header length, which may be negative if there is already sufficient headroom. pskb_expand_head() does allow for size being 0, in which case it just copies, so clamp the header delta to zero. Opening Chrome (and all my tabs) on a PCIE device was enough to reliably hit this. Fixes: 270a6c1f65fe ("brcmfmac: rework headroom check in .start_xmit()") Signed-off-by: Daniel Stone <daniels@collabora.com> Cc: Arend Van Spriel <arend.vanspriel@broadcom.com> Cc: James Hughes <james.hughes@raspberrypi.org> Cc: Hante Meuleman <hante.meuleman@broadcom.com> Cc: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com> Cc: Franky Lin <franky.lin@broadcom.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2017-07-27ARM: dts: da850-lcdk: drop unused VPIF endpointsKevin Hilman
Drop the unused endpoints. They should only be used when there is an actual remote-endpoint connected. Cc: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2017-07-27ARM: dts: da850-evm: drop unused VPIF endpointsKevin Hilman
Drop the unused endpoints. They should only be used when there is an actual remote-endpoint connected. Signed-off-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2017-07-27Merge tag 'mvebu-fixes-4.13-1' of git://git.infradead.org/linux-mvebu into fixesArnd Bergmann
Pull "mvebu fixes for 4.13 (part 1)" from Gregory CLEMENT: - Fix wrong irq type for gpio expeander on Armada 388 GP - Use __pa_symbol instead of virt_to_phys in the mv98dx3236 platform SMP code * tag 'mvebu-fixes-4.13-1' of git://git.infradead.org/linux-mvebu: ARM: dts: armada-38x: Fix irq type for pca955 ARM: mvebu: use __pa_symbol in the mv98dx3236 platform SMP code
2017-07-27ARM: dts: exynos: Add clocks to audss block to fix silent hang on Exynos4412Krzysztof Kozlowski
Add necessary parent clocks for audss (Audio SubSystem, MAUDIO) clock controller block. This allows driver to keep EPLL enabled before accessing any MAUDIO registers thus fixing silent hang. This silent hang appeared with commit 6edfa11cb396 ("clk: samsung: Add enable/disable operation for PLL36XX clocks"), e.g. on Odroid U3 usually with last (but unrelated) messages: [ 2.382741] input: gpio_keys as /devices/platform/gpio_keys/input/input0 [ 2.405686] usb 1-3: new high-speed USB device number 3 using exynos-ehci [ 2.419843] max77686-rtc max77686-rtc: setting system clock to 2017-06-21 17:04:13 UTC (1498064653) Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2017-07-27Merge tag 'renesas-fixes2-for-v4.13' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas into fixes Pull "Second Round of Renesas ARM Based SoC Fixes for v4.13" from Simon Horman: Correct order of sound clock frequencies for ULCB boards used by r8a7795 and r8a7796 SoCs. These sounds clock frequencies are used as the ADG clock (output clocks for audio module) initial setting and sound codec's initial system clock which needs the maximum clock frequency. Thus, descending order is required. * tag 'renesas-fixes2-for-v4.13' of https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas: arm64: dts: renesas: ulcb: sound clock-frequency needs descending order
2017-07-27Merge tag 'omap-for-v4.13/fixes-merge-window' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes Pull "Few fixes for omaps for issues found recently" from Tony Lindgren: - Fix disable_irq related shared IRQ warnings for omap3 PRM - Fix omap4 legacy code regression that accidentally removed code that we still need for PRM interrupts - Fix dm8168-evm NAND pins and MMC write protect pin direction - Fix dra71-evm mdio impedance values * tag 'omap-for-v4.13/fixes-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: ARM: dts: dra71-evm: mdio: Fix impedance values ARM: dts: dm816x: Correct the state of the write protect pin ARM: dts: dm816x: Correct NAND support nodes ARM: OMAP4: Fix legacy code clean-up regression ARM: OMAP2+: Fix omap3 prm shared irq
2017-07-27Merge tag 'renesas-fixes-for-v4.13' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas into fixes Pull "Renesas ARM Based SoC Fixes for v4.13" from Simon Horman: Correct order of sound clock frequencies for Salvator boards used by r8a7795 and r8a7796 SoCs. These sounds clock frequencies are used as the ADG clock (output clocks for audio module) initial setting and sound codec's initial system clock which needs the maximum clock frequency. Thus, descending order is required. * tag 'renesas-fixes-for-v4.13' of https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas: arm64: renesas: salvator-common: sound clock-frequency needs descending order
2017-07-27drm/i915: Fix cursor updates on some platformsVille Syrjälä
Turns out that just writing CURPOS isn't sufficient to move the cursor on some platforms. My 830 works just fine, but eg. 945 and PNV don't. On those platforms we need to arm even the CURPOS update with a CURBASE write. Even worse, a write to any of the cursor register apart from CURBASE will cancel an already pending cursor update. So if we have armed a CURCNTR/CURBASE update, a subsequent CURPOS write prior to vblank would cancel that armed update. Thus we're left with a cursor that doesn't appear to move, or even change shape. Fix the problem by always performing the CURBASE write after a CURPOS write. Bspec is somewhat unclear which platforms actually require this CURBASE write and which don't. So to keep it simple and to make sure we really fix the problem across all supported devices, let's just perform the CURBASE write unconditionally. Cc: Paul Menzel <pmenzel@molgen.mpg.de> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101790 Fixes: 75343a44c901 ("drm/i915: Drop useless posting reads from cursor commit") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Paul Menzel <paulepanter@users.sourceforge.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170714155227.6089-1-ville.syrjala@linux.intel.com (cherry picked from commit 8753d2bc5e49daad301ce65f5dada57ed924fad6) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915: Fix user ptr check size in eb_relocate_vma()Imre Deak
Fix the sizeof(ptr) vs. sizeof(*ptr) typo. Fixes: 2889caa92321 ("drm/i915: Eliminate lots of iterations over the execobjects array") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170714151242.517-2-imre.deak@intel.com (cherry picked from commit edd9003f7f9dddd28fdd768e6e7569d996c769cb) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27x86/topology: Remove the unused parent_node() macroDou Liyang
Commit: a7be6e5a7f8d ("mm: drop useless local parameters of __register_one_node()") ... removed the last user of parent_node(), so remove the macro. Reported-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Dou Liyang <douly.fnst@cn.fujitsu.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/1501076076-1974-11-git-send-email-douly.fnst@cn.fujitsu.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-07-27sctp: fix the check for _sctp_walk_params and _sctp_walk_errorsXin Long
Commit b1f5bfc27a19 ("sctp: don't dereference ptr before leaving _sctp_walk_{params, errors}()") tried to fix the issue that it may overstep the chunk end for _sctp_walk_{params, errors} with 'chunk_end > offset(length) + sizeof(length)'. But it introduced a side effect: When processing INIT, it verifies the chunks with 'param.v == chunk_end' after iterating all params by sctp_walk_params(). With the check 'chunk_end > offset(length) + sizeof(length)', it would return when the last param is not yet accessed. Because the last param usually is fwdtsn supported param whose size is 4 and 'chunk_end == offset(length) + sizeof(length)' This is a badly issue even causing sctp couldn't process 4-shakes. Client would always get abort when connecting to server, due to the failure of INIT chunk verification on server. The patch is to use 'chunk_end <= offset(length) + sizeof(length)' instead of 'chunk_end < offset(length) + sizeof(length)' for both _sctp_walk_params and _sctp_walk_errors. Fixes: b1f5bfc27a19 ("sctp: don't dereference ptr before leaving _sctp_walk_{params, errors}()") Signed-off-by: Xin Long <lucien.xin@gmail.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-27dccp: fix a memleak for dccp_feat_init err processXin Long
In dccp_feat_init, when ccid_get_builtin_ccids failsto alloc memory for rx.val, it should free tx.val before returning an error. Signed-off-by: Xin Long <lucien.xin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-27dccp: fix a memleak that dccp_ipv4 doesn't put reqsk properlyXin Long
The patch "dccp: fix a memleak that dccp_ipv6 doesn't put reqsk properly" fixed reqsk refcnt leak for dccp_ipv6. The same issue exists on dccp_ipv4. This patch is to fix it for dccp_ipv4. Signed-off-by: Xin Long <lucien.xin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-27dccp: fix a memleak that dccp_ipv6 doesn't put reqsk properlyXin Long
In dccp_v6_conn_request, after reqsk gets alloced and hashed into ehash table, reqsk's refcnt is set 3. one is for req->rsk_timer, one is for hlist, and the other one is for current using. The problem is when dccp_v6_conn_request returns and finishes using reqsk, it doesn't put reqsk. This will cause reqsk refcnt leaks and reqsk obj never gets freed. Jianlin found this issue when running dccp_memleak.c in a loop, the system memory would run out. dccp_memleak.c: int s1 = socket(PF_INET6, 6, IPPROTO_IP); bind(s1, &sa1, 0x20); listen(s1, 0x9); int s2 = socket(PF_INET6, 6, IPPROTO_IP); connect(s2, &sa1, 0x20); close(s1); close(s2); This patch is to put the reqsk before dccp_v6_conn_request returns, just as what tcp_conn_request does. Reported-by: Jianlin Shi <jishi@redhat.com> Signed-off-by: Xin Long <lucien.xin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-27powerpc/mm/hash: Free the subpage_prot_table correctlyAneesh Kumar K.V
Fixes: dad6f37c2602e ("powerpc: subpage_protect: Increase the array size to take care of 64TB") Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Tested-by: Ram Pai <linuxram@us.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-07-26scsi: aacraid: reading out of boundsDan Carpenter
"qd.id" comes directly from the copy_from_user() on the line before so we should verify that it's within bounds. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2017-07-26scsi: qedf: Limit number of CQsThomas Bogendoerfer
FCOE offloading failed with: [qed_sp_fcoe_func_start:150(sp-0-3b:00.02)]Cannot satisfy CQ amount. CQs requested 8, CQs available 6. Aborting function start [qed_fcoe_start:821()]Failed to start fcoe [__qedf_probe:3041]:6: Cannot start FCoE function. The reason is a newly introduced check in the qed main part. This change also provides the information about how many CQs are available, so we simply limit the number of requested CQs.. Fixes: 3c5da9427802 ("qed: Share additional information with qedf") Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de> Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de> Acked-by: Chad Dupuis <chad.dupuis@cavium.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2017-07-26scsi: bnx2i: Simplify cpu hotplug codeThomas Gleixner
The CPU hotplug related code of this driver can be simplified by: 1) Consolidating the callbacks into a single state. The CPU thread can be torn down on the CPU which goes offline. There is no point in delaying that to the CPU dead state 2) Let the core code invoke the online/offline callbacks and remove the extra for_each_online_cpu() loops. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Chad Dupuis <chad.dupuis@cavium.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2017-07-26scsi: bnx2fc: Simplify CPU hotplug codeThomas Gleixner
The CPU hotplug related code of this driver can be simplified by: 1) Consolidating the callbacks into a single state. The CPU thread can be torn down on the CPU which goes offline. There is no point in delaying that to the CPU dead state 2) Let the core code invoke the online/offline callbacks and remove the extra for_each_online_cpu() loops. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2017-07-26scsi: bnx2i: Prevent recursive cpuhotplug lockingThomas Gleixner
The BNX2I module init/exit code installs/removes the hotplug callbacks with the cpu hotplug lock held. This worked with the old CPU locking implementation which allowed recursive locking, but with the new percpu rwsem based mechanism this is not longer allowed. Use the _cpuslocked() variants to fix this. Reported-by: Steven Rostedt <rostedt@goodmis.org> Acked-by: Chad Dupuis <chad.dupuis@cavium.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2017-07-26scsi: bnx2fc: Prevent recursive cpuhotplug lockingThomas Gleixner
The BNX2FC module init/exit code installs/removes the hotplug callbacks with the cpu hotplug lock held. This worked with the old CPU locking implementation which allowed recursive locking, but with the new percpu rwsem based mechanism this is not longer allowed. Use the _cpuslocked() variants to fix this. Reported-by: kernel test robot <fengguang.wu@intel.com> Acked-by: Chad Dupuis <chad.dupuis@cavium.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2017-07-26scsi: bnx2fc: Plug CPU hotplug raceThomas Gleixner
bnx2fc_process_new_cqes() has protection against CPU hotplug, which relies on the per cpu thread pointer. This protection is racy because it happens only partially with the per cpu fp_work_lock held. If the CPU is unplugged after the lock is dropped, the wakeup code can dereference a NULL pointer or access freed and potentially reused memory. Restructure the code so the thread check and wakeup happens with the fp_work_lock held. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Chad Dupuis <chad.dupuis@cavium.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2017-07-27drm: exynos: mark pm functions as __maybe_unusedArnd Bergmann
The rework of the exynos DRM clock handling introduced warnings for configurations that have CONFIG_PM disabled: drivers/gpu/drm/exynos/exynos_hdmi.c:736:13: error: 'hdmi_clk_disable_gates' defined but not used [-Werror=unused-function] static void hdmi_clk_disable_gates(struct hdmi_context *hdata) ^~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/exynos/exynos_hdmi.c:717:12: error: 'hdmi_clk_enable_gates' defined but not used [-Werror=unused-function] static int hdmi_clk_enable_gates(struct hdmi_context *hdata) The problem is that the PM functions themselves are inside of an #ifdef, but some functions they call are not. This patch removes the #ifdef and instead marks the PM functions as __maybe_unused, which is a more reliable way to get it right. Link: https://patchwork.kernel.org/patch/8436281/ Fixes: 9be7e9898444 ("drm/exynos/hdmi: clock code re-factoring") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2017-07-27drm/exynos: select CEC_CORE if CEC_NOTIFIERHans Verkuil
If the s5p-cec driver is a module and the drm exynos driver is built-in, then the CEC core will be a module also, causing the CEC notifier to fail (will be compiled as empty functions). To prevent this select CEC_CORE if CEC_NOTIFIER is set to ensure the CEC core is also built into the kernel. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2017-07-27drm/exynos/hdmi: fix disable sequenceAndrzej Hajda
The "Fixes" patch was incorrectly merged, as a result PHY is prematurely powered off and for example Odroid-U3 cannot disable TV power domain when HDMI cable is unplugged. Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Fixes: 625e63e2 ("drm/exynos/hdmi: fix pipeline disable order") Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2017-07-27drm/exynos: mic: add a bridge at probeInki Dae
This patch moves drm_bridge_add call into probe. It doesn't need to call drm_bridge_add call every time bind callback is called. Changelog v2 - moved drm_bridge_remove call into remove callback. - corrected description. Suggested-by: Andrzej Hajda <a.hajda@samsung.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Reviewed-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2017-07-27drm/exynos/dsi: Remove error handling for bridge_node DT parsingHoegeun Kwon
Remove the error handling of bridge_node because the bridge_node is optional. For example, In case of Exynos SoC, a bridge device such as mDNIe and MIC could be placed between Display Controller and MIPI DSI device but the bridge device is optional. Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2017-07-27drm/exynos: dsi: do not try to find bridgeInki Dae
It doesn't need to try to find a bridge if bridge node doesn't exist. Reviewed-by: Shuah Khan <shuahkh@osg.samsung.com> Tested-by: Shuah Khan <shuahkh@osg.samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2017-07-27drm: exynos: hdmi: make of_device_ids const.Arvind Yadav
of_device_ids are not supposed to change at runtime. All functions working with of_device_ids provided by <linux/of.h> work with const of_device_ids. So mark the non-const structs as const. File size before: text data bss dec hex filename 12294 1192 0 13486 34ae drivers/gpu/drm/exynos/exynos_hdmi.o File size after constify hdmi_match_types. text data bss dec hex filename 13318 176 0 13494 34b6 drivers/gpu/drm/exynos/exynos_hdmi.o Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2017-07-27drm: exynos: constify mixer_match_types and *_mxr_drv_data.Arvind Yadav
File size before: text data bss dec hex filename 9983 1424 0 11407 2c8f drivers/gpu/drm/exynos/exynos_mixer.o File size after constify: text data bss dec hex filename 11231 176 0 11407 2c8f drivers/gpu/drm/exynos/exynos_mixer.o Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2017-07-27exynos_drm: Clean up duplicated assignment in exynos_drm_driverGabriel Krisman Bertazi
num_ioctls is already assigned when declaring the exynos_drm_driver structure. No need to duplicate it here. Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2017-07-26bpf: don't zero out the info struct in bpf_obj_get_info_by_fd()Jakub Kicinski
The buffer passed to bpf_obj_get_info_by_fd() should be initialized to zeros. Kernel will enforce that to guarantee we can safely extend info structures in the future. Making the bpf_obj_get_info_by_fd() call in libbpf perform the zeroing is problematic, however, since some members of the info structures may need to be initialized by the callers (for instance pointers to buffers to which kernel is to dump translated and jited images). Remove the zeroing and fix up the in-tree callers before any kernel has been released with this code. As Daniel points out this seems to be the intended operation anyway, since commit 95b9afd3987f ("bpf: Test for bpf ID") is itself setting the buffer pointers before calling bpf_obj_get_info_by_fd(). Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-26netpoll: Fix device name check in netpoll_setup()Matthias Kaehlcke
Apparently netpoll_setup() assumes that netpoll.dev_name is a pointer when checking if the device name is set: if (np->dev_name) { ... However the field is a character array, therefore the condition always yields true. Check instead whether the first byte of the array has a non-zero value. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-27Merge branch 'drm-fixes-4.13' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie
into drm-fixes Three misc amd fixes. * 'drm-fixes-4.13' of git://people.freedesktop.org/~agd5f/linux: drm/amd/powerplay: fix AVFS voltage offset for Vega10 drm/amdgpu/gfx9: simplify and fix GRBM index selection drm/amdgpu: Fix blocking in RCU critical section(v2)
2017-07-26NFS: Use raw NFS access mask in nfs4_opendata_access()Anna Schumaker
Commit bd8b2441742b ("NFS: Store the raw NFS access mask in the inode's access cache") changed how the access results are stored after an access() call. An NFS v4 OPEN might have access bits returned with the opendata, so we should use the NFS4_ACCESS values when determining the return value in nfs4_opendata_access(). Fixes: bd8b2441742b ("NFS: Store the raw NFS access mask in the inode's access cache") Reported-by: Eryu Guan <eguan@redhat.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com> Tested-by: Takashi Iwai <tiwai@suse.de>
2017-07-26bonding: commit link status change after proposeWANG Cong
Commit de77ecd4ef02 ("bonding: improve link-status update in mii-monitoring") moves link status commitment into bond_mii_monitor(), but it still relies on the return value of bond_miimon_inspect() as the hint. We need to return non-zero as long as we propose a link status change. Fixes: de77ecd4ef02 ("bonding: improve link-status update in mii-monitoring") Reported-by: Benjamin Gilbert <benjamin.gilbert@coreos.com> Tested-by: Benjamin Gilbert <benjamin.gilbert@coreos.com> Cc: Mahesh Bandewar <maheshb@google.com> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> Acked-by: Mahesh Bandewar <maheshb@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-26vfio/pci: Use pci_try_reset_function() on initial openAlex Williamson
Device lock bites again; if a device .remove() callback races a user calling ioctl(VFIO_GROUP_GET_DEVICE_FD), the unbind request will hold the device lock, but the user ioctl may have already taken a vfio_device reference. In the case of a PCI device, the initial open will attempt to reset the device, which again attempts to get the device lock, resulting in deadlock. Use the trylock PCI reset interface and return error on the open path if reset fails due to lock contention. Link: https://lkml.org/lkml/2017/7/25/381 Reported-by: Wen Congyang <wencongyang2@huawei.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2017-07-26dm, dax: Make sure dm_dax_flush() is called if device supports itVivek Goyal
Currently dm_dax_flush() is not being called, even if underlying dax device supports write cache, because DAXDEV_WRITE_CACHE is not being propagated up to the DM dax device. If the underlying dax device supports write cache, set DAXDEV_WRITE_CACHE on the DM dax device. This will cause dm_dax_flush() to be called. Fixes: abebfbe2f7 ("dm: add ->flush() dax operation support") Signed-off-by: Vivek Goyal <vgoyal@redhat.com> Acked-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com>