aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2017-07-27net/mlx5: Fix mlx5_add_flow_rules call with correct num of destsPaul Blakey1-1/+1
When adding ethtool steering rule with action DISCARD we wrongly pass a NULL dest with dest_num 1 to mlx5_add_flow_rules(). What this error seems to have caused is sending VPORT 0 (MLX5_FLOW_DESTINATION_TYPE_VPORT) as the fte dest instead of no dests. We have fte action correctly set to DROP so it might been ignored anyways. To reproduce use: # sudo ethtool --config-nfc <dev> flow-type ether \ dst aa:bb:cc:dd:ee:ff action -1 Fixes: 74491de93712 ("net/mlx5: Add multi dest support") Signed-off-by: Paul Blakey <[email protected]> Reviewed-by: Mark Bloch <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2017-07-27net/mlx5e: Schedule overflow check work to mlx5e workqueueEugenia Emantayev1-6/+5
This is done in order to ensure that work will not run after the cleanup. Fixes: ef9814deafd0 ('net/mlx5e: Add HW timestamping (TS) support') Signed-off-by: Eugenia Emantayev <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2017-07-27net/mlx5e: Fix wrong delay calculation for overflow check schedulingEugenia Emantayev1-1/+2
The overflow_period is calculated in seconds. In order to use it for delayed work scheduling translation to jiffies is needed. Fixes: ef9814deafd0 ('net/mlx5e: Add HW timestamping (TS) support') Signed-off-by: Eugenia Emantayev <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2017-07-27net/mlx5e: Add missing support for PTP_CLK_REQ_PPS requestEugenia Emantayev3-1/+21
Add the missing option to enable the PTP_CLK_PPS function. In this case pin should be configured as 1PPS IN first and then it will be connected to PPS mechanism. Events will be reported as PTP_CLOCK_PPSUSR events to relevant sysfs. Fixes: ee7f12205abc ('net/mlx5e: Implement 1PPS support') Signed-off-by: Eugenia Emantayev <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2017-07-27net/mlx5e: Change 1PPS out schemeEugenia Emantayev2-38/+87
In order to fix the drift in 1PPS out need to adjust the next pulse. On each 1PPS out falling edge driver gets the event, then the event handler adjusts the next pulse starting time. Fixes: ee7f12205abc ('net/mlx5e: Implement 1PPS support') Signed-off-by: Eugenia Emantayev <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2017-07-27net/mlx5e: Fix broken disable 1PPS flowEugenia Emantayev1-29/+46
Need to disable the MTPPS and unsubscribe from the pulse events when user disables the 1PPS functionality. Fixes: ee7f12205abc ('net/mlx5e: Implement 1PPS support') Signed-off-by: Eugenia Emantayev <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2017-07-27net/mlx5e: Add field select to MTPPS registerEugenia Emantayev4-10/+36
In order to mark relevant fields while setting the MTPPS register add field select. Otherwise it can cause a misconfiguration in firmware. Fixes: ee7f12205abc ('net/mlx5e: Implement 1PPS support') Signed-off-by: Eugenia Emantayev <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2017-07-27net/mlx5: Fix mlx5_ifc_mtpps_reg_bits structure sizeEugenia Emantayev1-1/+1
Fix miscalculation in reserved_at_1a0 field. Fixes: ee7f12205abc ('net/mlx5e: Implement 1PPS support') Signed-off-by: Eugenia Emantayev <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2017-07-27net/mlx5e: Fix outer_header_zero() check sizeIlan Tayari1-1/+1
outer_header_zero() routine checks if the outer_headers match of a flow-table entry are all zero. This function uses the size of whole fte_match_param, instead of just the outer_headers member, causing failure to detect all-zeros if any other members of the fte_match_param are non-zero. Use the correct size for zero check. Fixes: 6dc6071cfcde ("net/mlx5e: Add ethtool flow steering support") Signed-off-by: Ilan Tayari <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2017-07-27net/mlx5e: IPoIB, Modify add/remove underlay QPN flowsAlex Vesker1-5/+11
On interface remove, the clean-up was done incorrectly causing an error in the log: "SET_FLOW_TABLE_ROOT(0x92f) op_mod(0x0) failed...syndrome (0x7e9f14)" This was caused by the following flow: -ndo_uninit: Move QP state to RST (this disconnects the QP from FT), the QP cannot be attached to any FT unless it is in RTS. -mlx5_rdma_netdev_free: cleanup_rx: Destroy FT cleanup_tx: Destroy QP and remove QPN from FT This caused a problem when destroying current FT we tried to re-attach the QP to the next FT which is not needed. The correct flow is: -mlx5_rdma_netdev_free: cleanup_rx: remove QPN from FT & Destroy FT cleanup_tx: Destroy QP Fixes: 508541146af1 ("net/mlx5: Use underlay QPN from the root name space") Signed-off-by: Alex Vesker <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2017-07-27net/mlx5: Fix command bad flow on command entry allocation failureMoshe Shemesh1-2/+17
When driver fail to allocate an entry to send command to FW, it must notify the calling function and release the memory allocated for this command. Fixes: e126ba97dba9e ('mlx5: Add driver for Mellanox Connect-IB adapters') Signed-off-by: Moshe Shemesh <[email protected]> Cc: [email protected] Signed-off-by: Saeed Mahameed <[email protected]>
2017-07-27net/mlx5: Fix command completion after timeout access invalid structureMoshe Shemesh1-2/+4
Completion on timeout should not free the driver command entry structure as it will need to access it again once real completion event from FW will occur. Fixes: 73dd3a4839c1 ('net/mlx5: Avoid using pending command interface slots') Signed-off-by: Moshe Shemesh <[email protected]> Cc: [email protected] Signed-off-by: Saeed Mahameed <[email protected]>
2017-07-27net/mlx5: Consider tx_enabled in all modes on remapAviv Heller1-15/+10
The tx_enabled lag event field is used to determine whether a slave is active. Current logic uses this value only if the mode is active-backup. However, LACP mode, although considered a load balancing mode, can mark a slave as inactive in certain situations (e.g., LACP timeout). This fix takes the tx_enabled value into account when remapping, with no respect to the LAG mode (this should not affect the behavior in XOR mode, since in this mode both slaves are marked as active). Fixes: 7907f23adc18 (net/mlx5: Implement RoCE LAG feature) Signed-off-by: Aviv Heller <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2017-07-27net/mlx5: Clean SRIOV eswitch resources upon VF creation failureEran Ben Elisha2-1/+7
Upon sriov enable, eswitch is always enabled. Currently, if enable hca failed over all VFs, we would skip eswitch disable as part of sriov disable, which will lead to resources leak. Fix it by disabling eswitch if it was enabled (use indication from eswitch mode). Fixes: 6b6adee3dad2 ('net/mlx5: SRIOV core code refactoring') Signed-off-by: Eran Ben Elisha <[email protected]> Signed-off-by: Noa Osherovich <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2017-07-27genirq/cpuhotplug: Revert "Set force affinity flag on hotplug migration"Thomas Gleixner2-3/+13
That commit was part of the changes moving x86 to the generic CPU hotplug interrupt migration code. The force flag was required on x86 before the hierarchical irqdomain rework, but invoking set_affinity() with force=true stayed and had no side effects. At some point in the past, the force flag got repurposed to support the exynos timer interrupt affinity setting to a not yet online CPU, so the interrupt controller callback does not verify the supplied affinity mask against cpu_online_mask. Setting the flag in the CPU hotplug code causes the cpu online masking to be blocked on these irq controllers and results in potentially affining an interrupt to the CPU which is unplugged, i.e. instead of moving it away, it's just reassigned to it. As the force flags is not longer needed on x86, it's safe to revert that patch so the ARM irqchips which use the force flag work again. Add comments to that effect, so this won't happen again. Note: The online mask handling should be done in the generic code and the force flag and the masking in the irq chips removed all together, but that's not a change possible for 4.13. Fixes: 77f85e66aa8b ("genirq/cpuhotplug: Set force affinity flag on hotplug migration") Reported-by: Will Deacon <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Acked-by: Will Deacon <[email protected]> Cc: Marc Zyngier <[email protected]> Cc: Russell King <[email protected]> Cc: LAK <[email protected]> Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1707271217590.3109@nanos Signed-off-by: Thomas Gleixner <[email protected]>
2017-07-27ARM: dts: sun8i: a83t: Switch to CCU device tree binding macrosChen-Yu Tsai1-7/+9
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 <[email protected]> Signed-off-by: Maxime Ripard <[email protected]>
2017-07-27arm64: allwinner: sun50i-a64: Correct emac register sizeCorentin Labbe1-1/+1
The datasheet said that emac register size is 0x10000 not 0x100 Signed-off-by: Corentin Labbe <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> [[email protected]: Fixed commit subject prefix] Signed-off-by: Chen-Yu Tsai <[email protected]>
2017-07-27ARM: dts: sunxi: h3/h5: Correct emac register sizeCorentin Labbe1-1/+1
The datasheet said that emac register size is 0x10000 not 0x104 Signed-off-by: Corentin Labbe <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> [[email protected]: Fixed commit subject prefix] Signed-off-by: Chen-Yu Tsai <[email protected]>
2017-07-27drivers/perf: arm_pmu: Request PMU SPIs with IRQF_PER_CPUWill Deacon3-14/+32
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 <[email protected]> Cc: Linus Walleij <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2017-07-27ARM: sa1100: normalize clk APIArnd Bergmann1-0/+25
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 <[email protected]>
2017-07-27ARM: davinci: normalize clk APIArnd Bergmann1-0/+9
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 <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2017-07-27ARM: sa1100/pxa: fix MTD_XIP buildArnd Bergmann2-5/+9
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 <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2017-07-27ARM: davinci: don't mark vpif_input structures as 'const'Arnd Bergmann1-2/+2
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 <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2017-07-27soc: zte: Restrict SOC_ZTE to ARCH_ZX or COMPILE_TESTGeert Uytterhoeven1-0/+1
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 <[email protected]> Reviewed-by: Baoyou Xie <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2017-07-27brcmfmac: fix memleak due to calling brcmf_sdiod_sgtable_alloc() twiceArend Van Spriel1-5/+0
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: [email protected] # 4.6.x Fixes: 4d7928959832 ("brcmfmac: switch to new platform data") Reported-by: Stefan Wahren <[email protected]> Tested-by: Stefan Wahren <[email protected]> Reviewed-by: Hante Meuleman <[email protected]> Signed-off-by: Arend van Spriel <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2017-07-27brcmfmac: Don't grow SKB by negative sizeDaniel Stone1-1/+1
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 <[email protected]> Cc: Arend Van Spriel <[email protected]> Cc: James Hughes <[email protected]> Cc: Hante Meuleman <[email protected]> Cc: Pieter-Paul Giesberts <[email protected]> Cc: Franky Lin <[email protected]> Tested-by: Hans de Goede <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2017-07-27ARM: dts: da850-lcdk: drop unused VPIF endpointsKevin Hilman1-7/+0
Drop the unused endpoints. They should only be used when there is an actual remote-endpoint connected. Cc: Sekhar Nori <[email protected]> Signed-off-by: Kevin Hilman <[email protected]> Signed-off-by: Sekhar Nori <[email protected]>
2017-07-27ARM: dts: da850-evm: drop unused VPIF endpointsKevin Hilman1-21/+0
Drop the unused endpoints. They should only be used when there is an actual remote-endpoint connected. Signed-off-by: Kevin Hilman <[email protected]> Signed-off-by: Sekhar Nori <[email protected]>
2017-07-27Merge tag 'mvebu-fixes-4.13-1' of git://git.infradead.org/linux-mvebu into fixesArnd Bergmann2-3/+3
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 Kozlowski1-0/+3
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 <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2017-07-27Merge tag 'renesas-fixes2-for-v4.13' of ↵Arnd Bergmann1-1/+1
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 Bergmann6-11/+92
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 Bergmann1-1/+1
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ä1-1/+11
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 <[email protected]> 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ä <[email protected]> Tested-by: Paul Menzel <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 8753d2bc5e49daad301ce65f5dada57ed924fad6) Signed-off-by: Daniel Vetter <[email protected]>
2017-07-27drm/i915: Fix user ptr check size in eb_relocate_vma()Imre Deak1-1/+1
Fix the sizeof(ptr) vs. sizeof(*ptr) typo. Fixes: 2889caa92321 ("drm/i915: Eliminate lots of iterations over the execobjects array") Cc: Chris Wilson <[email protected]> Cc: Joonas Lahtinen <[email protected]> Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit edd9003f7f9dddd28fdd768e6e7569d996c769cb) Signed-off-by: Daniel Vetter <[email protected]>
2017-07-27sctp: fix the check for _sctp_walk_params and _sctp_walk_errorsXin Long1-2/+2
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 <[email protected]> Acked-by: Neil Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-07-27dccp: fix a memleak for dccp_feat_init err processXin Long1-2/+5
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 <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-07-27dccp: fix a memleak that dccp_ipv4 doesn't put reqsk properlyXin Long1-0/+1
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 <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-07-27dccp: fix a memleak that dccp_ipv6 doesn't put reqsk properlyXin Long1-0/+1
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 <[email protected]> Signed-off-by: Xin Long <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-07-27powerpc/mm/hash: Free the subpage_prot_table correctlyAneesh Kumar K.V1-1/+1
Fixes: dad6f37c2602e ("powerpc: subpage_protect: Increase the array size to take care of 64TB") Signed-off-by: Aneesh Kumar K.V <[email protected]> Tested-by: Ram Pai <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
2017-07-27drm: exynos: mark pm functions as __maybe_unusedArnd Bergmann1-4/+2
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 <[email protected]> Signed-off-by: Inki Dae <[email protected]>
2017-07-27drm/exynos: select CEC_CORE if CEC_NOTIFIERHans Verkuil1-0/+1
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 <[email protected]> Signed-off-by: Inki Dae <[email protected]>
2017-07-27drm/exynos/hdmi: fix disable sequenceAndrzej Hajda1-2/+0
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 <[email protected]> Reported-by: Marek Szyprowski <[email protected]> Fixes: 625e63e2 ("drm/exynos/hdmi: fix pipeline disable order") Tested-by: Marek Szyprowski <[email protected]> Signed-off-by: Inki Dae <[email protected]>
2017-07-27drm/exynos: mic: add a bridge at probeInki Dae1-9/+15
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 <[email protected]> Reviewed-by: Andrzej Hajda <[email protected]> Reviewed-by: Hoegeun Kwon <[email protected]> Signed-off-by: Inki Dae <[email protected]>
2017-07-27drm/exynos/dsi: Remove error handling for bridge_node DT parsingHoegeun Kwon1-2/+0
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 <[email protected]> Signed-off-by: Inki Dae <[email protected]>
2017-07-27drm/exynos: dsi: do not try to find bridgeInki Dae1-3/+5
It doesn't need to try to find a bridge if bridge node doesn't exist. Reviewed-by: Shuah Khan <[email protected]> Tested-by: Shuah Khan <[email protected]> Signed-off-by: Inki Dae <[email protected]>
2017-07-27drm: exynos: hdmi: make of_device_ids const.Arvind Yadav1-1/+1
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 <[email protected]> Reviewed-by: Andrzej Hajda <[email protected]> Signed-off-by: Inki Dae <[email protected]>
2017-07-27drm: exynos: constify mixer_match_types and *_mxr_drv_data.Arvind Yadav1-5/+5
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 <[email protected]> Reviewed-by: Andrzej Hajda <[email protected]> Signed-off-by: Inki Dae <[email protected]>
2017-07-27exynos_drm: Clean up duplicated assignment in exynos_drm_driverGabriel Krisman Bertazi1-1/+0
num_ioctls is already assigned when declaring the exynos_drm_driver structure. No need to duplicate it here. Signed-off-by: Gabriel Krisman Bertazi <[email protected]> Reviewed-by: Andrzej Hajda <[email protected]> Signed-off-by: Inki Dae <[email protected]>
2017-07-26bpf: don't zero out the info struct in bpf_obj_get_info_by_fd()Jakub Kicinski2-3/+6
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 <[email protected]> Acked-by: Daniel Borkmann <[email protected]> Signed-off-by: David S. Miller <[email protected]>