aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/export-to-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2018-05-06thermal: exynos: cleanup code for enabling threshold interruptsBartlomiej Zolnierkiewicz1-65/+33
Cleanup code for enabling threshold interrupts in ->tmu_control method implementations. There should be no functional changes caused by this patch. Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2018-05-06thermal: exynos: check return values of ->get_trip_[temp, hyst] methodsBartlomiej Zolnierkiewicz1-3/+7
Check return values of ->get_trip_[temp,hyst] methods in exynos_tmu_initialize(). Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2018-05-06thermal: exynos: move trips setting to exynos_tmu_initialize()Bartlomiej Zolnierkiewicz1-51/+37
* Add dummy exynos4210_tmu_set_trip_hyst() helper. * Add ->tmu_set_trip_temp and ->tmu_set_trip_hyst methods to struct exynos_tmu_data and set them in exynos_map_dt_data(). * Move trips setting to exynos_tmu_initialize(). There should be no functional changes caused by this patch. Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2018-05-06thermal: exynos: set trips in ascending order in exynos7_tmu_initialize()Bartlomiej Zolnierkiewicz1-1/+1
Set trips in ascending order in exynos7_tmu_initialize() (it should make no difference in driver operation). This prepares the driver code to moving trips setting from ->tmu_initialize method to exynos_tmu_initialize(). Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2018-05-06thermal: exynos: do not use trips structure directly in ->tmu_initializeBartlomiej Zolnierkiewicz1-10/+8
Use ->get_trip_[temp,hyst] methods instead of using trips structure directly in all ->tmu_initialize method implementations. There should be no functional changes caused by this patch. Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2018-05-06thermal: exynos: add exynos*_tmu_set_[trip,hyst]() helpersBartlomiej Zolnierkiewicz1-142/+140
Add exynos*_tmu_set_[trip,hyst]() helpers and convert all ->tmu_initialize implementations accordingly. Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2018-05-06thermal: exynos: move IRQs clearing to exynos_tmu_initialize()Bartlomiej Zolnierkiewicz1-10/+4
Move ->tmu_clear_irqs call from ->tmu_initialize method to exynos_tmu_initialize(). There should be no functional changes caused by this patch. Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2018-05-06thermal: exynos: clear IRQs later in exynos4412_tmu_initialize()Bartlomiej Zolnierkiewicz1-2/+2
Clear IRQs after enabling thermal tripping (it should make no difference in driver operation). This prepares the driver code to moving IRQs clearing call from ->tmu_initialize method to exynos_tmu_initialize(). Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2018-05-06thermal: exynos: make ->tmu_initialize method voidBartlomiej Zolnierkiewicz1-18/+10
All implementations of ->tmu_initialize always return 0 so make the method void and convert all implementations accordingly. There should be no functional changes caused by this patch. Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2018-05-06thermal: exynos: remove threshold_code checking from exynos4210_tmu_initialize()Bartlomiej Zolnierkiewicz1-5/+1
On Exynos4210 one-point trimming is always used and data->temp_error1 is equal to 75. Therefore temp_to_code() will never return negative value for the reference temperature conversion. There should be no functional changes caused by this patch. Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2018-05-06thermal: exynos: fix trips limit checking in get_th_reg()Bartlomiej Zolnierkiewicz1-2/+2
of_thermal_get_ntrips() may return value bigger than supported by a given SoC (i.e. on Exynos5422/5800) so fix the code to not iterate the loop for i values >= data->ntrip. There should be no functional changes caused by this patch. Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2018-05-06thermal: exynos: use sanitize_temp_error() in exynos7_tmu_initialize()Bartlomiej Zolnierkiewicz1-7/+6
Fix sanitize_temp_error() to handle Exynos7 SoCs and then use it in exynos7_tmu_initialize(). There should be no functional changes caused by this patch. Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2018-05-06thermal: exynos: check STATUS register in exynos_tmu_initialize()Bartlomiej Zolnierkiewicz1-32/+13
STATUS register is present on all SoCs so move its checking into exynos_tmu_initialize(). There should be no functional changes caused by this patch. Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2018-05-06thermal: exynos: always check for critical trip points existenceBartlomiej Zolnierkiewicz1-9/+10
* Check for critical trip point existence in exynos_tmu_initialize() so it is checked on all SoCs (except Exynos5433 for now). * Use dev_err() instead of pr_err(). * Fix dev_err() to reference "device tree" not "of-thermal.c". * Remove no longer needed check from exynos4412_tmu_initialize(). Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2018-05-06thermal: exynos: always check for trips points existenceBartlomiej Zolnierkiewicz1-15/+11
* Check for trip points existence in exynos_tmu_initialize() so it is checked on all SoCs. * Use dev_err() instead of pr_err(). * Fix dev_err() to reference "device tree" not "of-thermal.c". * Remove no longer needed checks from exynos4210_tmu_initialize() and get_th_reg(). Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2018-05-06thermal: exynos: fix setting rising_threshold for Exynos5433Bartlomiej Zolnierkiewicz1-0/+1
Add missing clearing of the previous value when setting rising temperature threshold. Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2018-05-06thermal: samsung: Remove support for Exynos5440Krzysztof Kozlowski2-171/+4
The Exynos5440 is not actively developed, there are no development boards available and probably there are no real products with it. Remove wide-tree support for Exynos5440. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> [b.zolnierkie: ported over driver changes] Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2018-05-06thermal: rcar_gen3_thermal: add r8a77965 supportNiklas Söderlund1-0/+1
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2018-05-06dt-bindings: thermal: rcar-gen3-thermal: add r8a77965Niklas Söderlund1-1/+2
Based on previous work by Ryo Kataoka <ryo.kataoka.wt@renesas.com>. Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2018-05-06thermal: rcar_gen3_thermal: update max temperature clampNiklas Söderlund1-2/+2
Change the upper limit to clamp the high temperature value to 120C when setting trip points. Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2018-05-06thermal: rcar_gen3_thermal: Update calculation formula due to HW evaluationHien Dang1-6/+6
Due to hardware evaluation result, Max temperature is changed from 96 to 116 degree Celsius. Also, calculation formula and pseudo FUSE values are changed accordingly. Signed-off-by: Dien Pham <dien.pham.ry@renesas.com> Signed-off-by: Hien Dang <hien.dang.eb@renesas.com> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2018-05-06thermal: tegra: Nuke clk_{readl,writel} helpersEzequiel Garcia1-27/+2
Naming driver-specific register accessors with generic names, such as clk_writel and clk_readl, is bad. Moreover, clk_writel and clk_readl are part of the common clock framework api, so readers and code grep'ers get confused by this collision. The helpers are used once, so just remove them. Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2018-05-06thermal: uniphier: add UniPhier PXs3 supportKunihiko Hayashi1-0/+4
Add support for UniPhier PXs3 SoC. It is equivalent to LD20. Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2018-05-06dt-bindings: thermal: uniphier: add a compatible string for PXs3Kunihiko Hayashi1-0/+1
Add a compatible string for thermal monitor implemented on UniPhier PXs3 SoC. Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2018-05-06thermal: exynos: remove separate exynos_tmu.h header fileBartlomiej Zolnierkiewicz2-42/+16
exynos_tmu.h is used only by exynos_tmu.c so there is no need for a separate include file. Also while at it remove no longer needed cpu_cooling.h include. There should be no functional changes caused by this patch. Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2018-05-06thermal: exynos: remove parsing of samsung, tmu_cal_type propertyBartlomiej Zolnierkiewicz2-44/+9
Since calibration type for temperature is SoC (not platform) specific just move it from platform data to struct exynos_tmu_data instance. Then remove parsing of samsung,tmu_cal_type property. Also remove no longer needed platform data structure. There should be no functional changes caused by this patch. Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2018-05-06thermal: exynos: remove parsing of samsung,tmu_gain propertyBartlomiej Zolnierkiewicz2-13/+9
Since pdata gain values are SoC (not platform) specific just move it from platform data to struct exynos_tmu_data instance. Then remove parsing of samsung,tmu_gain property. There should be no functional changes caused by this patch. Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2018-05-06thermal: exynos: remove parsing of samsung, tmu_reference_voltage propertyBartlomiej Zolnierkiewicz2-7/+15
Since pdata reference_voltage values are SoC (not platform) specific just move it from platform data to struct exynos_tmu_data instance. Then remove parsing of samsung,tmu_reference_voltage property. There should be no functional changes caused by this patch. Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2018-05-06thermal: exynos: remove parsing of samsung, tmu[_min, _max]_efuse_value propertiesBartlomiej Zolnierkiewicz2-24/+32
Since pdata efuse values are SoC (not platform) specific just move them from platform data to struct exynos_tmu_data instance. Then remove parsing of samsung,tmu[_,min_,max]_efuse_value properties. There should be no functional changes caused by this patch. Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2018-05-06thermal: exynos: remove parsing of samsung, tmu_noise_cancel_mode propertyBartlomiej Zolnierkiewicz2-9/+4
All SoCs use the same value (4) for the noise cancel mode so just make it explicit and remove parsing of samsung,tmu_noise_cancel_mode property. There should be no functional changes caused by this patch. Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2018-05-06thermal: exynos: remove parsing of samsung, tmu_[first, second]_point_trim propertiesBartlomiej Zolnierkiewicz2-13/+9
All SoCs use the same values (25, 85) for trim points (except Exynos5440 which currently specifices value 70 for the second trim point -> it seems to be a mistake because documentation uses value 85 and two points based trimming has never been used by the driver for this SoC anyway) so just make it explicit and remove parsing of samsung,tmu_[first,second]_point_trim properties. There should be no functional changes caused by this patch. Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2018-05-06thermal: exynos: remove parsing of samsung, tmu_default_temp_offset propertyBartlomiej Zolnierkiewicz2-37/+13
Trimming (one point based or two points based) is always used for the temperature calibration and the default non-trimming code is never reached. Remove it and then remove no longer needed parsing of samsung,tmu_default_temp_offset property. There should be no functional changes caused by this patch. Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2018-05-06thermal: exynos: remove unused "type" field from struct exynos_tmu_platform_dataBartlomiej Zolnierkiewicz1-2/+0
Remove unused "type" field from struct exynos_tmu_platform_data. There should be no functional changes caused by this patch. Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2018-05-06thermal: exynos: Read soc_type from match dataMaciej Purski1-40/+34
Device context's field data->soc is currently obtained by comparing of_compatible's. Provide soc_type as .data field in device's match table, as it is done in most drivers. Signed-off-by: Maciej Purski <m.purski@samsung.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2018-05-06thermal: exynos: Propagate error value from tmu_read()Marek Szyprowski1-2/+7
tmu_read() in case of Exynos4210 might return error for out of bound values. Current code ignores such value, what leads to reporting critical temperature value. Add proper error code propagation to exynos_get_temp() function. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> CC: stable@vger.kernel.org # v4.6+ Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2018-05-06thermal: exynos: Reading temperature makes sense only when TMU is turned onMarek Szyprowski1-1/+4
When thermal sensor is not yet enabled, reading temperature might return random value. This might even result in stopping system booting when such temperature is higher than the critical value. Fix this by checking if TMU has been actually enabled before reading the temperature. This change fixes booting of Exynos4210-based board with TMU enabled (for example Samsung Trats board), which was broken since v4.4 kernel release. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Fixes: 9e4249b40340 ("thermal: exynos: Fix first temperature read after registering sensor") CC: stable@vger.kernel.org # v4.6+ Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2018-05-06thermal: imx: add i.MX7 thermal sensor supportAnson Huang2-65/+239
This patch adds i.MX7 thermal sensor support, most of the i.MX7 thermal sensor functions are same with i.MX6 except the registers offset/layout, so we move those registers offset/layout definitions to soc data structure. i.MX7 uses single calibration data @25C, the calibration data is located at OCOTP offset 0x4F0, bit[17:9], the formula is as below: Tmeas = (Nmeas - n1) + 25; n1 is the fuse value for 25C. Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Signed-off-by: Bai Ping <ping.bai@nxp.com> Acked-by: Dong Aisheng <aisheng.dong@nxp.com> Acked-by: Shawn Guo <shawnguo@kernel.org> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2018-05-06thermal: mediatek: add support for MT7622 SoCSean Wang1-0/+35
MT7622 SoC has built-in thermal controller with one sensing point, the patch just is to extend the functionality of the existing logic. Changes v1 -> v2: rebase to 4.16-rc1 Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Shunli Wang <shunli.wang@mediatek.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2018-05-06dt-bindings: thermal: add binding for MT7622 SoCSean Wang1-0/+1
Add devicetree bindings for MediaTek MT7622 thermal controller Changes v1 -> v2: add tag from Rob Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Shunli Wang <shunli.wang@mediatek.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2018-05-05KVM: x86: remove APIC Timer periodic/oneshot spikesAnthoine Bourgeois1-17/+20
Since the commit "8003c9ae204e: add APIC Timer periodic/oneshot mode VMX preemption timer support", a Windows 10 guest has some erratic timer spikes. Here the results on a 150000 times 1ms timer without any load: Before 8003c9ae204e | After 8003c9ae204e Max 1834us | 86000us Mean 1100us | 1021us Deviation 59us | 149us Here the results on a 150000 times 1ms timer with a cpu-z stress test: Before 8003c9ae204e | After 8003c9ae204e Max 32000us | 140000us Mean 1006us | 1997us Deviation 140us | 11095us The root cause of the problem is starting hrtimer with an expiry time already in the past can take more than 20 milliseconds to trigger the timer function. It can be solved by forward such past timers immediately, rather than submitting them to hrtimer_start(). In case the timer is periodic, update the target expiration and call hrtimer_start with it. v2: Check if the tsc deadline is already expired. Thank you Mika. v3: Execute the past timers immediately rather than submitting them to hrtimer_start(). v4: Rearm the periodic timer with advance_periodic_target_expiration() a simpler version of set_target_expiration(). Thank you Paolo. Cc: Mika Penttilä <mika.penttila@nextfour.com> Cc: Wanpeng Li <kernellwp@gmail.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Anthoine Bourgeois <anthoine.bourgeois@blade-group.com> 8003c9ae204e ("KVM: LAPIC: add APIC Timer periodic/oneshot mode VMX preemption timer support") Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
2018-05-05genksyms: fix typo in parse.tab.{c,h} generation rulesMauro Rossi1-2/+2
'quet' is replaced by 'quiet' in scripts/genksyms/Makefile Signed-off-by: Mauro Rossi <issor.oruam@gmail.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-05-05kbuild: replace hardcoded bison in cmd_bison_h with $(YACC)Masahiro Yamada1-1/+1
Commit 73a4f6dbe70a ("kbuild: add LEX and YACC variables") missed to update cmd_bison_h somehow. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-05-05gcc-plugins: fix build condition of SANCOV pluginMasahiro Yamada1-1/+1
Since commit d677a4d60193 ("Makefile: support flag -fsanitizer-coverage=trace-cmp"), you miss to build the SANCOV plugin under some circumstances. CONFIG_KCOV=y CONFIG_KCOV_ENABLE_COMPARISONS=y Your compiler does not support -fsanitize-coverage=trace-pc Your compiler does not support -fsanitize-coverage=trace-cmp Under this condition, $(CFLAGS_KCOV) is not empty but contains a space, so the following ifeq-conditional is false. ifeq ($(CFLAGS_KCOV),) Then, scripts/Makefile.gcc-plugins misses to add sancov_plugin.so to gcc-plugin-y while the SANCOV plugin is necessary as an alternative means. Fixes: d677a4d60193 ("Makefile: support flag -fsanitizer-coverage=trace-cmp") Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Kees Cook <keescook@chromium.org>
2018-05-05MAINTAINERS: Update Kbuild entry with a few pathsRasmus Villemoes1-1/+3
I managed to send some modpost patches to old addresses of both Masahiro and Michal, and omitted linux-kbuild from cc, because my tried and trusted scripts/get_maintainer wrapper failed me. Add the modpost directory to the MAINTAINERS entry, and while at it make the Makefile glob match scripts/Makefile itself, and add one matching the Kbuild.include file as well. Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-05-04Revert "usb: host: ehci: Use dma_pool_zalloc()"Greg Kroah-Hartman2-3/+6
This reverts commit 22072e83ebd510fb6a090aef9d65ccfda9b1e7e4 as it is broken. Alan writes: What you can't see just from reading the patch is that in both cases (ehci->itd_pool and ehci->sitd_pool) there are two allocation paths -- the two branches of an "if" statement -- and only one of the paths calls dma_pool_[z]alloc. However, the memset is needed for both paths, and so it can't be eliminated. Given that it must be present, there's no advantage to calling dma_pool_zalloc rather than dma_pool_alloc. Reported-by: Erick Cafferata <erick@cafferata.me> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Souptick Joarder <jrdr.linux@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-04platform/x86: Kconfig: Fix dell-laptop dependency chain.Mario Limonciello1-1/+1
As reported by Randy Dunlap: >> WARNING: unmet direct dependencies detected for DELL_SMBIOS >> Depends on [m]: X86 [=y] && X86_PLATFORM_DEVICES [=y] >> && (DCDBAS [=m] || >> DCDBAS [=m]=n) && (ACPI_WMI [=n] || ACPI_WMI [=n]=n) >> Selected by [y]: >> - DELL_LAPTOP [=y] && X86 [=y] && X86_PLATFORM_DEVICES [=y] >> && DMI [=y] >> && BACKLIGHT_CLASS_DEVICE [=y] && (ACPI_VIDEO [=n] || >> ACPI_VIDEO [=n]=n) >> && (RFKILL [=n] || RFKILL [=n]=n) && SERIO_I8042 [=y] >> Right now it's possible to set dell laptop to compile in but this causes dell-smbios to compile in which breaks if dcdbas is a module. Dell laptop shouldn't select dell-smbios anymore, but depend on it. Fixes: 32d7b19bad96 (platform/x86: dell-smbios: Resolve dependency error on DCDBAS) Reported-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Mario Limonciello <mario.limonciello@dell.com> Cc: stable@vger.kernel.org Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
2018-05-04platform/x86: asus-wireless: Fix NULL pointer dereferenceJoão Paulo Rechi Vita1-1/+3
When the module is removed the led workqueue is destroyed in the remove callback, before the led device is unregistered from the led subsystem. This leads to a NULL pointer derefence when the led device is unregistered automatically later as part of the module removal cleanup. Bellow is the backtrace showing the problem. BUG: unable to handle kernel NULL pointer dereference at (null) IP: __queue_work+0x8c/0x410 PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI Modules linked in: ccm edac_mce_amd kvm_amd kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel aes_x86_64 joydev crypto_simd asus_nb_wmi glue_helper uvcvideo snd_hda_codec_conexant snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel asus_wmi snd_hda_codec cryptd snd_hda_core sparse_keymap videobuf2_vmalloc arc4 videobuf2_memops snd_hwdep input_leds videobuf2_v4l2 ath9k psmouse videobuf2_core videodev ath9k_common snd_pcm ath9k_hw media fam15h_power ath k10temp snd_timer mac80211 i2c_piix4 r8169 mii mac_hid cfg80211 asus_wireless(-) snd soundcore wmi shpchp 8250_dw ip_tables x_tables amdkfd amd_iommu_v2 amdgpu radeon chash i2c_algo_bit drm_kms_helper syscopyarea serio_raw sysfillrect sysimgblt fb_sys_fops ahci ttm libahci drm video CPU: 3 PID: 2177 Comm: rmmod Not tainted 4.15.0-5-generic #6+dev94.b4287e5bem1-Endless Hardware name: ASUSTeK COMPUTER INC. X555DG/X555DG, BIOS 5.011 05/05/2015 RIP: 0010:__queue_work+0x8c/0x410 RSP: 0018:ffffbe8cc249fcd8 EFLAGS: 00010086 RAX: ffff992ac6810800 RBX: 0000000000000000 RCX: 0000000000000008 RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffff992ac6400e18 RBP: ffffbe8cc249fd18 R08: ffff992ac6400db0 R09: 0000000000000000 R10: 0000000000000040 R11: ffff992ac6400dd8 R12: 0000000000002000 R13: ffff992abd762e00 R14: ffff992abd763e38 R15: 000000000001ebe0 FS: 00007f318203e700(0000) GS:ffff992aced80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001c720e000 CR4: 00000000001406e0 Call Trace: queue_work_on+0x38/0x40 led_state_set+0x2c/0x40 [asus_wireless] led_set_brightness_nopm+0x14/0x40 led_set_brightness+0x37/0x60 led_trigger_set+0xfc/0x1d0 led_classdev_unregister+0x32/0xd0 devm_led_classdev_release+0x11/0x20 release_nodes+0x109/0x1f0 devres_release_all+0x3c/0x50 device_release_driver_internal+0x16d/0x220 driver_detach+0x3f/0x80 bus_remove_driver+0x55/0xd0 driver_unregister+0x2c/0x40 acpi_bus_unregister_driver+0x15/0x20 asus_wireless_driver_exit+0x10/0xb7c [asus_wireless] SyS_delete_module+0x1da/0x2b0 entry_SYSCALL_64_fastpath+0x24/0x87 RIP: 0033:0x7f3181b65fd7 RSP: 002b:00007ffe74bcbe18 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f3181b65fd7 RDX: 000000000000000a RSI: 0000000000000800 RDI: 0000555ea2559258 RBP: 0000555ea25591f0 R08: 00007ffe74bcad91 R09: 000000000000000a R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000000003 R13: 00007ffe74bcae00 R14: 0000000000000000 R15: 0000555ea25591f0 Code: 01 00 00 02 0f 85 7d 01 00 00 48 63 45 d4 48 c7 c6 00 f4 fa 87 49 8b 9d 08 01 00 00 48 03 1c c6 4c 89 f7 e8 87 fb ff ff 48 85 c0 <48> 8b 3b 0f 84 c5 01 00 00 48 39 f8 0f 84 bc 01 00 00 48 89 c7 RIP: __queue_work+0x8c/0x410 RSP: ffffbe8cc249fcd8 CR2: 0000000000000000 ---[ end trace 7aa4f4a232e9c39c ]--- Unregistering the led device on the remove callback before destroying the workqueue avoids this problem. https://bugzilla.kernel.org/show_bug.cgi?id=196097 Reported-by: Dun Hum <bitter.taste@gmx.com> Cc: stable@vger.kernel.org Signed-off-by: João Paulo Rechi Vita <jprvita@endlessm.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
2018-05-04arm64: vgic-v2: Fix proxying of cpuif accessJames Morse1-5/+19
Proxying the cpuif accesses at EL2 makes use of vcpu_data_guest_to_host and co, which check the endianness, which call into vcpu_read_sys_reg... which isn't mapped at EL2 (it was inlined before, and got moved OoL with the VHE optimizations). The result is of course a nice panic. Let's add some specialized cruft to keep the broken platforms that require this hack alive. But, this code used vcpu_data_guest_to_host(), which expected us to write the value to host memory, instead we have trapped the guest's read or write to an mmio-device, and are about to replay it using the host's readl()/writel() which also perform swabbing based on the host endianness. This goes wrong when both host and guest are big-endian, as readl()/writel() will undo the guest's swabbing, causing the big-endian value to be written to device-memory. What needs doing? A big-endian guest will have pre-swabbed data before storing, undo this. If its necessary for the host, writel() will re-swab it. For a read a big-endian guest expects to swab the data after the load. The hosts's readl() will correct for host endianness, giving us the device-memory's value in the register. For a big-endian guest, swab it as if we'd only done the load. For a little-endian guest, nothing needs doing as readl()/writel() leave the correct device-memory value in registers. Tested on Juno with that rarest of things: a big-endian 64K host. Based on a patch from Marc Zyngier. Reported-by: Suzuki K Poulose <suzuki.poulose@arm.com> Fixes: bf8feb39642b ("arm64: KVM: vgic-v2: Add GICV access from HYP") Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-05-04KVM: arm/arm64: vgic_init: Cleanup reference to process_maintenanceValentin Schneider1-1/+1
One comment still mentioned process_maintenance operations after commit af0614991ab6 ("KVM: arm/arm64: vgic: Get rid of unnecessary process_maintenance operation") Update the comment to point to vgic_fold_lr_state instead, which is where maintenance interrupts are taken care of. Acked-by: Christoffer Dall <christoffer.dall@arm.com> Signed-off-by: Valentin Schneider <valentin.schneider@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-05-04KVM: arm64: Fix order of vcpu_write_sys_reg() argumentsJames Morse1-1/+1
A typo in kvm_vcpu_set_be()'s call: | vcpu_write_sys_reg(vcpu, SCTLR_EL1, sctlr) causes us to use the 32bit register value as an index into the sys_reg[] array, and sail off the end of the linear map when we try to bring up big-endian secondaries. | Unable to handle kernel paging request at virtual address ffff80098b982c00 | Mem abort info: | ESR = 0x96000045 | Exception class = DABT (current EL), IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW = 0 | Data abort info: | ISV = 0, ISS = 0x00000045 | CM = 0, WnR = 1 | swapper pgtable: 4k pages, 48-bit VAs, pgdp = 000000002ea0571a | [ffff80098b982c00] pgd=00000009ffff8803, pud=0000000000000000 | Internal error: Oops: 96000045 [#1] PREEMPT SMP | Modules linked in: | CPU: 2 PID: 1561 Comm: kvm-vcpu-0 Not tainted 4.17.0-rc3-00001-ga912e2261ca6-dirty #1323 | Hardware name: ARM Juno development board (r1) (DT) | pstate: 60000005 (nZCv daif -PAN -UAO) | pc : vcpu_write_sys_reg+0x50/0x134 | lr : vcpu_write_sys_reg+0x50/0x134 | Process kvm-vcpu-0 (pid: 1561, stack limit = 0x000000006df4728b) | Call trace: | vcpu_write_sys_reg+0x50/0x134 | kvm_psci_vcpu_on+0x14c/0x150 | kvm_psci_0_2_call+0x244/0x2a4 | kvm_hvc_call_handler+0x1cc/0x258 | handle_hvc+0x20/0x3c | handle_exit+0x130/0x1ec | kvm_arch_vcpu_ioctl_run+0x340/0x614 | kvm_vcpu_ioctl+0x4d0/0x840 | do_vfs_ioctl+0xc8/0x8d0 | ksys_ioctl+0x78/0xa8 | sys_ioctl+0xc/0x18 | el0_svc_naked+0x30/0x34 | Code: 73620291 604d00b0 00201891 1ab10194 (957a33f8) |---[ end trace 4b4a4f9628596602 ]--- Fix the order of the arguments. Fixes: 8d404c4c24613 ("KVM: arm64: Rewrite system register accessors to read/write functions") CC: Christoffer Dall <cdall@cs.columbia.edu> Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.