summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* dt-binding: peci: add NPCM PECI documentationTomer Maimon2019-04-111-0/+38
| | | | | | | | | Added device tree binding documentation for Nuvoton BMC NPCM Platform Environment Control Interface(PECI). OpenBMC-Staging-Count: 1 Signed-off-by: Tomer Maimon <tmaimon77@gmail.com> Signed-off-by: Joel Stanley <joel@jms.id.au>
* hwmon: (pmbus/isl68137): Add driver for Intersil ISL68137 PWM ControllerMaxim Sloyko2019-04-113-0/+214
| | | | | | | | | | Adds the pmbus driver for the Intersil ISL68137 PWM Controller. OpenBMC-Staging-Count: 1 Signed-off-by: Maxim Sloyko <maxims@google.com> Signed-off-by: Robert Lippert <rlippert@google.com> Signed-off-by: Patrick Venture <venture@google.com> Signed-off-by: Joel Stanley <joel@jms.id.au>
* media: platform: aspeed: change irq to threaded irqJae Hyun Yoo2019-04-111-2/+3
| | | | | | | | | | | | | | | Differently fron other Aspeed drivers, this driver calls clock control APIs in interrupt context. Since ECLK is coupled with a reset bit in clk-aspeed module, aspeed_clk_enable will make 10ms of busy waiting delay for triggering the reset and it will eventually disturb other drivers' interrupt handling. To fix this issue, this commit changes this driver's irq to threaded irq so that the delay can be happened in a thread context. OpenBMC-Staging-Count: 1 Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com> Reviewed-by: Eddie James <eajames@linux.ibm.com> Signed-off-by: Joel Stanley <joel@jms.id.au>
* media: platform: aspeed: refine clock control logicJae Hyun Yoo2019-04-111-9/+29
| | | | | | | | | | | | | Currently, this driver calls clk_prepare and clk_unprepare from interrupt context too but these should be called from sleepable context only. To fix this issue, this commit splits out clk_enable/disable and clk_prepare/unprepare, and it places clk_prepare/unprepare calls into the module probe/remove function. OpenBMC-Staging-Count: 1 Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com> Reviewed-by: Eddie James <eajames@linux.ibm.com> Signed-off-by: Joel Stanley <joel@jms.id.au>
* media: platform: aspeed: fix a kernel warning on clk controlJae Hyun Yoo2019-04-111-3/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Video engine clock control functions in the Aspeed video engine driver are being called from multiple context without any protection so video clocks can be double disabled and eventually it causes a kernel warning with stack dump printing out like below: [ 515.540498] ------------[ cut here ]------------ [ 515.545174] WARNING: CPU: 0 PID: 1310 at drivers/clk/clk.c:684 clk_core_unprepare+0x13c/0x170 [ 515.553806] vclk-gate already unprepared [ 515.557841] CPU: 0 PID: 1310 Comm: obmc-ikvm Tainted: G W 5.0.6-df66fbc97853fbba90a0bfa44de32f3d5f7602b4 #1 [ 515.568973] Hardware name: Generic DT based system [ 515.573777] Backtrace: [ 515.576272] [<80107cdc>] (dump_backtrace) from [<80107f10>] (show_stack+0x20/0x24) [ 515.583930] r7:803a5614 r6:00000009 r5:00000000 r4:9d88fe1c [ 515.589712] [<80107ef0>] (show_stack) from [<80690184>] (dump_stack+0x20/0x28) [ 515.597053] [<80690164>] (dump_stack) from [<80116044>] (__warn.part.3+0xb4/0xdc) [ 515.604557] [<80115f90>] (__warn.part.3) from [<801160d8>] (warn_slowpath_fmt+0x6c/0x90) [ 515.612734] r6:000002ac r5:8080befc r4:80a07008 [ 515.617463] [<80116070>] (warn_slowpath_fmt) from [<803a5614>] (clk_core_unprepare+0x13c/0x170) [ 515.626167] r3:8080cdf4 r2:8080bfc0 [ 515.629834] r7:98d682a8 r6:9d8a9200 r5:9e5151a0 r4:97abd620 [ 515.635530] [<803a54d8>] (clk_core_unprepare) from [<803a76a4>] (clk_unprepare+0x34/0x3c) [ 515.643812] r5:9e5151a0 r4:97abd620 [ 515.647529] [<803a7670>] (clk_unprepare) from [<804f36ec>] (aspeed_video_off+0x38/0x50) [ 515.655539] r5:9e5151a0 r4:9e504000 [ 515.659242] [<804f36b4>] (aspeed_video_off) from [<804f4358>] (aspeed_video_release+0x90/0x114) [ 515.668036] r5:9e5044b0 r4:9e504000 [ 515.671643] [<804f42c8>] (aspeed_video_release) from [<804d302c>] (v4l2_release+0xd4/0xe8) [ 515.679999] r7:98d682a8 r6:9d087810 r5:9d8a9200 r4:9e504318 [ 515.685695] [<804d2f58>] (v4l2_release) from [<80236454>] (__fput+0x98/0x1c4) [ 515.692914] r5:9e51b608 r4:9d8a9200 [ 515.696597] [<802363bc>] (__fput) from [<802365e8>] (____fput+0x18/0x1c) [ 515.703315] r9:80a0700c r8:801011e4 r7:00000000 r6:80a64b9c r5:9d8e35a0 r4:9d8e38dc [ 515.711167] [<802365d0>] (____fput) from [<80131ca4>] (task_work_run+0x7c/0xa0) [ 515.718596] [<80131c28>] (task_work_run) from [<80106884>] (do_work_pending+0x4a8/0x578) [ 515.726777] r7:801011e4 r6:80a07008 r5:9d88ffb0 r4:ffffe000 [ 515.732466] [<801063dc>] (do_work_pending) from [<8010106c>] (slow_work_pending+0xc/0x20) [ 515.740727] Exception stack(0x9d88ffb0 to 0x9d88fff8) [ 515.745840] ffa0: 00000000 76f18094 00000000 00000000 [ 515.754122] ffc0: 00000007 00176778 7eda4c20 00000006 00000000 00000000 48e20fa4 00000000 [ 515.762386] ffe0: 00000002 7eda4b08 00000000 48f91efc 80000010 00000007 [ 515.769097] r10:00000000 r9:9d88e000 r8:801011e4 r7:00000006 r6:7eda4c20 r5:00176778 [ 515.777006] r4:00000007 [ 515.779558] ---[ end trace 12c04aadef8afbbb ]--- [ 515.784176] ------------[ cut here ]------------ [ 515.788817] WARNING: CPU: 0 PID: 1310 at drivers/clk/clk.c:825 clk_core_disable+0x18c/0x204 [ 515.797161] eclk-gate already disabled [ 515.800916] CPU: 0 PID: 1310 Comm: obmc-ikvm Tainted: G W 5.0.6-df66fbc97853fbba90a0bfa44de32f3d5f7602b4 #1 [ 515.811945] Hardware name: Generic DT based system [ 515.816730] Backtrace: [ 515.819210] [<80107cdc>] (dump_backtrace) from [<80107f10>] (show_stack+0x20/0x24) [ 515.826782] r7:803a5900 r6:00000009 r5:00000000 r4:9d88fe04 [ 515.832454] [<80107ef0>] (show_stack) from [<80690184>] (dump_stack+0x20/0x28) [ 515.839687] [<80690164>] (dump_stack) from [<80116044>] (__warn.part.3+0xb4/0xdc) [ 515.847170] [<80115f90>] (__warn.part.3) from [<801160d8>] (warn_slowpath_fmt+0x6c/0x90) [ 515.855247] r6:00000339 r5:8080befc r4:80a07008 [ 515.859868] [<80116070>] (warn_slowpath_fmt) from [<803a5900>] (clk_core_disable+0x18c/0x204) [ 515.868385] r3:8080cdd0 r2:8080c00c [ 515.871957] r7:98d682a8 r6:9d8a9200 r5:97abd560 r4:97abd560 [ 515.877615] [<803a5774>] (clk_core_disable) from [<803a59a0>] (clk_core_disable_lock+0x28/0x34) [ 515.886301] r7:98d682a8 r6:9d8a9200 r5:97abd560 r4:a0000013 [ 515.891960] [<803a5978>] (clk_core_disable_lock) from [<803a7714>] (clk_disable+0x2c/0x30) [ 515.900216] r5:9e5151a0 r4:9e515f60 [ 515.903816] [<803a76e8>] (clk_disable) from [<804f36f8>] (aspeed_video_off+0x44/0x50) [ 515.911656] [<804f36b4>] (aspeed_video_off) from [<804f4358>] (aspeed_video_release+0x90/0x114) [ 515.920341] r5:9e5044b0 r4:9e504000 [ 515.923921] [<804f42c8>] (aspeed_video_release) from [<804d302c>] (v4l2_release+0xd4/0xe8) [ 515.932184] r7:98d682a8 r6:9d087810 r5:9d8a9200 r4:9e504318 [ 515.937851] [<804d2f58>] (v4l2_release) from [<80236454>] (__fput+0x98/0x1c4) [ 515.944980] r5:9e51b608 r4:9d8a9200 [ 515.948559] [<802363bc>] (__fput) from [<802365e8>] (____fput+0x18/0x1c) [ 515.955257] r9:80a0700c r8:801011e4 r7:00000000 r6:80a64b9c r5:9d8e35a0 r4:9d8e38dc [ 515.963008] [<802365d0>] (____fput) from [<80131ca4>] (task_work_run+0x7c/0xa0) [ 515.970333] [<80131c28>] (task_work_run) from [<80106884>] (do_work_pending+0x4a8/0x578) [ 515.978421] r7:801011e4 r6:80a07008 r5:9d88ffb0 r4:ffffe000 [ 515.984086] [<801063dc>] (do_work_pending) from [<8010106c>] (slow_work_pending+0xc/0x20) [ 515.992247] Exception stack(0x9d88ffb0 to 0x9d88fff8) [ 515.997296] ffa0: 00000000 76f18094 00000000 00000000 [ 516.005473] ffc0: 00000007 00176778 7eda4c20 00000006 00000000 00000000 48e20fa4 00000000 [ 516.013642] ffe0: 00000002 7eda4b08 00000000 48f91efc 80000010 00000007 [ 516.020257] r10:00000000 r9:9d88e000 r8:801011e4 r7:00000006 r6:7eda4c20 r5:00176778 [ 516.028072] r4:00000007 [ 516.030606] ---[ end trace 12c04aadef8afbbc ]--- To prevent this issue, this commit adds spinlock protection and clock status checking logic into the Aspeed video engine driver. OpenBMC-Staging-Count: 1 Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com> Reviewed-by: Eddie James <eajames@linux.ibm.com> Signed-off-by: Joel Stanley <joel@jms.id.au>
* Merge tag 'v5.0.7' into dev-5.0Joel Stanley2019-04-08300-925/+1765
|\ | | | | | | | | | | This is the 5.0.7 stable release Signed-off-by: Joel Stanley <joel@jms.id.au>
| * Linux 5.0.7Greg Kroah-Hartman2019-04-051-1/+1
| |
| * kbuild: skip sub-make for in-tree build with GNU Make 4.xMasahiro Yamada2019-04-051-12/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 688931a5ad4e55ba0c215248ba510cd67bc3afb4 upstream. Commit 2b50f7ab6368 ("kbuild: add workaround for Debian make-kpkg") annoyed people who want to wrap the top Makefile with GNUmakefile to customize it for their use. On second thought, we do not need to run the sub-make for in-tree build with Make 4.x because the 'MAKEFLAGS += -rR' issue only happens on GNU Make 3.x. With this commit, people will get back their workflow, and the Debian make-kpkg will still work. Fixes: 2b50f7ab6368 ("kbuild: add workaround for Debian make-kpkg") Reported-by: Andreas Schwab <schwab@suse.de> Reported-by: David Howells <dhowells@redhat.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Tested-by: Andreas Schwab <schwab@suse.de> Tested-by: David Howells <dhowells@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * kbuild: add workaround for Debian make-kpkgMasahiro Yamada2019-04-051-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 2b50f7ab63685cd247e32ad321f7338ed130d3d5 upstream. Since commit 3812b8c5c5d5 ("kbuild: make -r/-R effective in top Makefile for old Make versions"), make-kpkg is not working. make-kpkg directly includes the top Makefile of Linux kernel, and appends some debian_* targets. /usr/share/kernel-package/ruleset/kernel_version.mk: # Include the kernel makefile override dot-config := 1 include Makefile dot-config := 1 I did not know the kernel Makefile was used in that way, and it is hard to guarantee the behavior when the kernel Makefile is included by another Makefile from a different project. It looks like Debian Stretch stopped providing make-kpkg. Maybe it is obsolete and being replaced with 'make deb-pkg' etc. but still widely used. This commit adds a workaround; if the top Makefile is included by another Makefile, skip sub-make in order to make the main part visible. 'MAKEFLAGS += -rR' does not become effective for GNU Make < 4.0, but Debian/Ubuntu is already using newer versions. The effect of this commit: Debian 8 (Jessie) : Fixed Debian 9 (Stretch) : make-kpkg (kernel-package) is not provided Ubuntu 14.04 LTS : NOT Fixed Ubuntu 16.04 LTS : Fixed Ubuntu 18.04 LTS : Fixed This commit cannot fix Ubuntu 14.04 because it installs GNU Make 3.81, but its support will end in Apr 2019, which is before the Linux v5.1 release. I added warning so that nobody would try to include the top Makefile. Fixes: 3812b8c5c5d5 ("kbuild: make -r/-R effective in top Makefile for old Make versions") Reported-by: Liz Zhang <lizzha@microsoft.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Tested-by: Lili Deng <v-lide@microsoft.com> Cc: Manoj Srivastava <srivasta@debian.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * bcache: fix potential div-zero error of writeback_rate_p_term_inverseColy Li2019-04-051-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 5b5fd3c94eef69dcfaa8648198e54c92e5687d6d ] Current code already uses d_strtoul_nonzero() to convert input string to an unsigned integer, to make sure writeback_rate_p_term_inverse won't be zero value. But overflow may happen when converting input string to an unsigned integer value by d_strtoul_nonzero(), then dc->writeback_rate_p_term_inverse can still be set to 0 even if the sysfs file input value is not zero, e.g. 4294967296 (a.k.a UINT_MAX+1). If dc->writeback_rate_p_term_inverse is set to 0, it might cause a dev-zero error in following code from __update_writeback_rate(), int64_t proportional_scaled = div_s64(error, dc->writeback_rate_p_term_inverse); This patch replaces d_strtoul_nonzero() by sysfs_strtoul_clamp() and limit the value range in [1, UINT_MAX]. Then the unsigned integer overflow and dev-zero error can be avoided. Signed-off-by: Coly Li <colyli@suse.de> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org>
| * ACPI / video: Extend chassis-type detection with a "Lunch Box" checkHans de Goede2019-04-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit d693c008e3ca04db5916ff72e68ce661888a913b ] Commit 53fa1f6e8a59 ("ACPI / video: Only default only_lcd to true on Win8-ready _desktops_") introduced chassis type detection, limiting the lcd_only check for the backlight to devices where the chassis-type indicates their is no builtin LCD panel. The purpose of the lcd_only check is to avoid advertising a backlight interface on desktops, since skylake and newer machines seem to always have a backlight interface even if there is no LCD panel. The limiting of this check to desktops only was done to avoid breaking backlight support on some laptops which do not have the lcd flag set. The Fujitsu ESPRIMO Q910 which is a compact (NUC like) desktop machine has a chassis type of 0x10 aka "Lunch Box". Without the lcd_only check we end up falsely advertising backlight/brightness control on this device. This commit extend the dmi_is_desktop check to return true for type 0x10 to fix this. Fixes: 53fa1f6e8a59 ("ACPI / video: Only default only_lcd to true ...") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
| * gpio: of: Restrict enable-gpio quirk to regulator-gpioThierry Reding2019-04-051-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 692ef26e72fcce0c1e73c41683fd3512f3719d55 ] Commit 0e7d6f940164 ("gpio: of: Apply regulator-gpio quirk only to enable-gpios") breaks the device tree ABI specified in the device tree bindings for fixed regulators (compatible "regulator-fixed"). According to these bindings the polarity of the GPIO is exclusively controlled by the presence or absence of the enable-active-high property. As such the polarity quirk implemented in of_gpio_flags_quirks() must be applied to the GPIO specified for fixed regulators. However, commit 0e7d6f940164 ("gpio: of: Apply regulator-gpio quirk only to enable-gpios") restricted the quirk to the enable-gpios property for fixed regulators as well, whereas according to the commit message itself it should only apply to "regulator-gpio" compatible device tree nodes. Fix this by actually implementing what the offending commit intended, which is to ensure that the quirk is applied to the GPIO specified by the "enable-gpio" property for the "regulator-gpio" bindings only. This fixes a regression on Jetson TX1 where the fixed regulator for the HDMI +5V pin relies on the flags quirk for the proper polarity. Fixes: 0e7d6f940164 ("gpio: of: Apply regulator-gpio quirk only to enable-gpios") Signed-off-by: Thierry Reding <treding@nvidia.com> Tested-by: Marek Vasut <marek.vasut@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
| * appletalk: Fix compile regressionArnd Bergmann2019-04-051-4/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 27da0d2ef998e222a876c0cec72aa7829a626266 ] A bugfix just broke compilation of appletalk when CONFIG_SYSCTL is disabled: In file included from net/appletalk/ddp.c:65: net/appletalk/ddp.c: In function 'atalk_init': include/linux/atalk.h:164:34: error: expected expression before 'do' #define atalk_register_sysctl() do { } while(0) ^~ net/appletalk/ddp.c:1934:7: note: in expansion of macro 'atalk_register_sysctl' rc = atalk_register_sysctl(); This is easier to avoid by using conventional inline functions as stubs rather than macros. The header already has inline functions for other purposes, so I'm changing over all the macros for consistency. Fixes: 6377f787aeb9 ("appletalk: Fix use-after-free in atalk_proc_exit") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
| * net: stmmac: Avoid one more sometimes uninitialized Clang warningNathan Chancellor2019-04-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 1f5d861f7fefa971b2c6e766f77932c86419a319 ] When building with -Wsometimes-uninitialized, Clang warns: drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c:111:2: error: variable 'ns' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c:111:2: error: variable 'ns' is used uninitialized whenever '&&' condition is false [-Werror,-Wsometimes-uninitialized] Clang is concerned with the use of stmmac_do_void_callback (which stmmac_get_systime wraps), as it may fail to initialize these values if the if condition was ever false (meaning the callback doesn't exist). It's not wrong because the callback is what initializes ns. While it's unlikely that the callback is going to disappear at some point and make that condition false, we can easily avoid this warning by zero initializing the variable. Link: https://github.com/ClangBuiltLinux/linux/issues/384 Fixes: df103170854e ("net: stmmac: Avoid sometimes uninitialized Clang warnings") Suggested-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
| * drm/dp/mst: Configure no_stop_bit correctly for remote i2c xfersVille Syrjälä2019-04-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit c978ae9bde582e82a04c63a4071701691dd8b35c ] We aren't supposed to force a stop+start between every i2c msg when performing multi message transfers. This should eg. cause the DDC segment address to be reset back to 0 between writing the segment address and reading the actual EDID extension block. To quote the E-DDC spec: "... this standard requires that the segment pointer be reset to 00h when a NO ACK or a STOP condition is received." Since we're going to touch this might as well consult the I2C_M_STOP flag to determine whether we want to force the stop or not. Cc: Brian Vincent <brainn@gmail.com> References: https://bugs.freedesktop.org/show_bug.cgi?id=108081 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180928180403.22499-1-ville.syrjala@linux.intel.com Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
| * drm: Reorder set_property_atomic to avoid returning with an active ww_ctxChris Wilson2019-04-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 227ad6d957898a88b1746e30234ece64d305f066 ] Delay the drm_modeset_acquire_init() until after we check for an allocation failure so that we can return immediately upon error without having to unwind. WARNING: lock held when returning to user space! 4.20.0+ #174 Not tainted ------------------------------------------------ syz-executor556/8153 is leaving the kernel with locks still held! 1 lock held by syz-executor556/8153: #0: 000000005100c85c (crtc_ww_class_acquire){+.+.}, at: set_property_atomic+0xb3/0x330 drivers/gpu/drm/drm_mode_object.c:462 Reported-by: syzbot+6ea337c427f5083ebdf2@syzkaller.appspotmail.com Fixes: 144a7999d633 ("drm: Handle properties in the core for atomic drivers") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: <stable@vger.kernel.org> # v4.14+ Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181230122842.21917-1-chris@chris-wilson.co.uk Signed-off-by: Sasha Levin <sashal@kernel.org>
| * ASoC: simple-card-utils: check "reg" property on asoc_simple_card_get_dai_id()Kuninori Morimoto2019-04-051-3/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit a0c426fe143328760c9fd565cd203a37a7b4fde8 ] We will get DAI ID from "reg" property if it has on DT, otherwise get it by counting port/endpoint. But in below case, we need to get DAI ID = 0 via port reg = <0>, but current implementation returns ID = 1, because it can't judge ID = 0 was from "non reg" or "reg = <0>". Thus, it will count port/endpoint number as "non reg" case. of_graph_parse_endpoint() implementation itself is not a problem, but because asoc_simple_card_get_dai_id() need to count port/endpoint number when "non reg" case, it need to know ID = 0 was from "non reg" or "reg = <0>". This patch fix this issue. port { reg = <0>; xxxx: endpoint@0 { }; => xxxx: endpoint@1 { }; }; Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
| * Input: soc_button_array - fix mapping of the 5th GPIO in a PNP0C40 deviceHans de Goede2019-04-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit e9eb788f9442d1b5d93efdb30c3be071ce8a22b1 ] The Microsoft documenation for the PNP0C40 device aka the "Windows-compatible button array" describes the 5th GpioInt listed in the resources as: '5. Interrupt corresponding to the "Rotation Lock" button, if supported'. Notice this describes the 5th entry as a button while we sofar have been mapping it to EV_SW, SW_ROTATE_LOCK. On my Point of View TAB P1006W-232 which actually comes with a rotation-lock button, the button indeed is a button and not a slider/switch. An image search for other Windows tablets has found 2 more models with a rotation-lock button and on both of those it too is a push-button and not a slider/switch. Further evidence can be found in the HUT extension HUTRR52 from Microsoft which adds rotation lock support to the HUT, which describes 2 different usages: "0xC9 System Display Rotation Lock Button" and "0xCA System Display Rotation Lock Slider Switch" note that switch is seen as a separate thing here and the non switch wording is an exact match for the "Windows-compatible button array" spec wording. TL;DR: our current mapping of the 5th GPIO to SW_ROTATE_LOCK is wrong because the 5th GPIO is for a push-button not a switch. This commit fixes this by maping the 5th GPIO to KEY_ROTATE_LOCK_TOGGLE. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
| * staging: iio: adt7316: fix dac_bits assignmentJeremy Fertic2019-04-051-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit e9de475723de5bf207a5b7b88bdca863393e42c8 ] The value of dac_bits is used in adt7316_show_DAC() and adt7316_store_DAC(), and it should be either 8, 10, or 12 bits depending on the device in use. The driver currently only assigns a value to dac_bits in adt7316_store_da_high_resolution(). The purpose of the dac high resolution option is not to change dac resolution for normal operation. Instead, it is specific to an optional feature where one or two of the four dacs can be set to output voltage proportional to temperature. If the user chooses to set dac a and/or dac b to output voltage proportional to temperature, the da_high_resolution attribute can optionally be enabled to use 10 bit resolution rather than the default 8 bits. This is only available on the 10 and 12 bit dac devices. If the user attempts to read or write dacs a or b under these settings, the driver's current behaviour is to return an error. Dacs c and d continue to operate normally under these conditions. With the above in mind, remove the dac_bits assignments from this function since the value of dac_bits as used in the driver is not dependent on this dac high resolution option. Since the dac_bits assignments discussed above are currently the only ones in this driver, the default value of dac_bits is 0. This results in incorrect calculations when the dacs are read or written in adt7316_show_DAC() and adt7316_store_DAC(). To correct this, assign a value to dac_bits in adt7316_probe() to ensure correct operation as soon as the device is registered and available to userspace. Fixes: 35f6b6b86ede ("staging: iio: new ADT7316/7/8 and ADT7516/7/9 driver") Signed-off-by: Jeremy Fertic <jeremyfertic@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
| * dmaengine: tegra: avoid overflow of byte trackingBen Dooks2019-04-051-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit e486df39305864604b7e25f2a95d51039517ac57 ] The dma_desc->bytes_transferred counter tracks the number of bytes moved by the DMA channel. This is then used to calculate the information passed back in the in the tegra_dma_tx_status callback, which is usually fine. When the DMA channel is configured as continous, then the bytes_transferred counter will increase over time and eventually overflow to become negative so the residue count will become invalid and the ALSA sound-dma code will report invalid hardware pointer values to the application. This results in some users becoming confused about the playout position and putting audio data in the wrong place. To fix this issue, always ensure the bytes_transferred field is modulo the size of the request. We only do this for the case of the cyclic transfer done ISR as anyone attempting to move 2GiB of DMA data in one transfer is unlikely. Note, we don't fix the issue that we should /never/ transfer a negative number of bytes so we could make those fields unsigned. Reviewed-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Acked-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
| * clk: rockchip: fix frac settings of GPLL clock for rk3328Katsuhiro Suzuki2019-04-051-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit a0e447b0c50240a90ab84b7126b3c06b0bab4adc ] This patch fixes settings of GPLL frequency in fractional mode for rk3328. In this mode, FOUTVCO is calcurated by following formula: FOUTVCO = FREF * FBDIV / REFDIV + ((FREF * FRAC / REFDIV) >> 24) The problem is in FREF * FRAC >> 24 term. This result always lacks one from target value is specified by rate member. For example first itme of rk3328_pll_frac_rate originally has - rate : 1016064000 - refdiv: 3 - fbdiv : 127 - frac : 134217 - FREF * FBDIV / REFDIV = 1016000000 - (FREF * FRAC / REFDIV) >> 24 = 63999 Thus calculated rate is 1016063999. It seems wrong. If frac has 134218 (it is increased 1 from original value), second term is 64000. All other items have same situation. So this patch adds 1 to frac member in all items of rk3328_pll_frac_rate. Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> Acked-by: Elaine Zhang <zhangqing@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
| * ARM: shmobile: Fix R-Car Gen2 regulator quirkMarek Vasut2019-04-051-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 5347a0203709d5039a74d7c94e23519eee478094 ] The quirk code currently detects all compatible I2C chips with a shared IRQ line on all I2C busses, adds them into a list, and registers a bus notifier. For every chip for which the bus notifier triggers, the quirk code performs I2C transfer on that I2C bus for all addresses in the list. The problem is that this may generate transfers to non-existing chips on systems with multiple I2C busses. This patch adds a check to verify that the I2C bus to which the chip with shared IRQ is attached to matches the I2C bus of the chip which triggered the bus notifier and only starts the I2C transfer if they match. Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Tested-by: Nguyen Viet Dung <dung.nguyen.aj@renesas.com> Signed-off-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
| * clk: meson: clean-up clock registrationJerome Brunet2019-04-051-5/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 8d9981efbcab066d17af4d3c85c169200f6f78df ] Order, ids and size between the table of regmap clocks and the onecell data table could be different. Set regmap pointer in all the regmap clocks before starting the registration using the onecell data, to make sure we don't get into an incoherent situation. Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://lkml.kernel.org/r/20181221160239.26265-3-jbrunet@baylibre.com Signed-off-by: Sasha Levin <sashal@kernel.org>
| * drm/fb-helper: fix leaks in error path of drm_fb_helper_fbdev_setupPeter Wu2019-04-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 00eb5b0da8d27b3c944bfc959c3344d665caae26 ] After drm_fb_helper_fbdev_setup calls drm_fb_helper_init, "dev->fb_helper" will be initialized (and thus drm_fb_helper_fini will have some effect). After that, drm_fb_helper_initial_config is called which may call the "fb_probe" driver callback. This driver callback may call drm_fb_helper_defio_init (as is done by drm_fb_helper_generic_probe) or set a framebuffer (as is done by bochs) as documented. These are normally cleaned up on exit by drm_fb_helper_fbdev_teardown which also calls drm_fb_helper_fini. If an error occurs after "fb_probe", but before setup is complete, then calling just drm_fb_helper_fini will leak resources. This was triggered by df2052cc922 ("bochs: convert to drm_fb_helper_fbdev_setup/teardown"): [ 50.008030] bochsdrmfb: enable CONFIG_FB_LITTLE_ENDIAN to support this framebuffer [ 50.009436] bochs-drm 0000:00:02.0: [drm:drm_fb_helper_fbdev_setup] *ERROR* fbdev: Failed to set configuration (ret=-38) [ 50.011456] [drm] Initialized bochs-drm 1.0.0 20130925 for 0000:00:02.0 on minor 2 [ 50.013604] WARNING: CPU: 1 PID: 1 at drivers/gpu/drm/drm_mode_config.c:477 drm_mode_config_cleanup+0x280/0x2a0 [ 50.016175] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G T 4.20.0-rc7 #1 [ 50.017732] EIP: drm_mode_config_cleanup+0x280/0x2a0 ... [ 50.023155] Call Trace: [ 50.023155] ? bochs_kms_fini+0x1e/0x30 [ 50.023155] ? bochs_unload+0x18/0x40 This can be reproduced with QEMU and CONFIG_FB_LITTLE_ENDIAN=n. Link: https://lkml.kernel.org/r/20181221083226.GI23332@shao2-debian Link: https://lkml.kernel.org/r/20181223004315.GA11455@al Fixes: 8741216396b2 ("drm/fb-helper: Add drm_fb_helper_fbdev_setup/teardown()") Reported-by: kernel test robot <rong.a.chen@intel.com> Cc: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Peter Wu <peter@lekensteyn.nl> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20181223005507.28328-1-peter@lekensteyn.nl Signed-off-by: Sasha Levin <sashal@kernel.org>
| * x86/build: Mark per-CPU symbols as absolute explicitly for LLDRafael Ávila de Espíndola2019-04-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit d071ae09a4a1414c1433d5ae9908959a7325b0ad ] Accessing per-CPU variables is done by finding the offset of the variable in the per-CPU block and adding it to the address of the respective CPU's block. Section 3.10.8 of ld.bfd's documentation states: For expressions involving numbers, relative addresses and absolute addresses, ld follows these rules to evaluate terms: Other binary operations, that is, between two relative addresses not in the same section, or between a relative address and an absolute address, first convert any non-absolute term to an absolute address before applying the operator." Note that LLVM's linker does not adhere to the GNU ld's implementation and as such requires implicitly-absolute terms to be explicitly marked as absolute in the linker script. If not, it fails currently with: ld.lld: error: ./arch/x86/kernel/vmlinux.lds:153: at least one side of the expression must be absolute ld.lld: error: ./arch/x86/kernel/vmlinux.lds:154: at least one side of the expression must be absolute Makefile:1040: recipe for target 'vmlinux' failed This is not a functional change for ld.bfd which converts the term to an absolute symbol anyways as specified above. Based on a previous submission by Tri Vo <trong@android.com>. Reported-by: Dmitry Golovin <dima@golovin.in> Signed-off-by: Rafael Ávila de Espíndola <rafael@espindo.la> [ Update commit message per Boris' and Michael's suggestions. ] Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> [ Massage commit message more, fix typos. ] Signed-off-by: Borislav Petkov <bp@suse.de> Tested-by: Dmitry Golovin <dima@golovin.in> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Cao Jin <caoj.fnst@cn.fujitsu.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Joerg Roedel <jroedel@suse.de> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tri Vo <trong@android.com> Cc: dima@golovin.in Cc: morbo@google.com Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/20181219190145.252035-1-ndesaulniers@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>
| * wlcore: Fix memory leak in case wl12xx_fetch_firmware failureZumeng Chen2019-04-051-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit ba2ffc96321c8433606ceeb85c9e722b8113e5a7 ] Release fw_status, raw_fw_status, and tx_res_if when wl12xx_fetch_firmware failed instead of meaningless goto out to avoid the following memory leak reports(Only the last one listed): unreferenced object 0xc28a9a00 (size 512): comm "kworker/0:4", pid 31298, jiffies 2783204 (age 203.290s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<6624adab>] kmemleak_alloc+0x40/0x74 [<500ddb31>] kmem_cache_alloc_trace+0x1ac/0x270 [<db4d731d>] wl12xx_chip_wakeup+0xc4/0x1fc [wlcore] [<76c5db53>] wl1271_op_add_interface+0x4a4/0x8f4 [wlcore] [<cbf30777>] drv_add_interface+0xa4/0x1a0 [mac80211] [<65bac325>] ieee80211_reconfig+0x9c0/0x1644 [mac80211] [<2817c80e>] ieee80211_restart_work+0x90/0xc8 [mac80211] [<7e1d425a>] process_one_work+0x284/0x42c [<55f9432e>] worker_thread+0x2fc/0x48c [<abb582c6>] kthread+0x148/0x160 [<63144b13>] ret_from_fork+0x14/0x2c [< (null)>] (null) [<1f6e7715>] 0xffffffff Signed-off-by: Zumeng Chen <zumeng.chen@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
| * brcmfmac: Use firmware_request_nowarn for the clm_blobHans de Goede2019-04-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 4ad0be160544ffbdafb7cec39bb8e6dd0a97317a ] The linux-firmware brcmfmac firmware files contain an embedded table with per country allowed channels and strength info. For recent hardware these versions of the firmware are specially build for linux-firmware, the firmware files directly available from Cypress rely on a separate clm_blob file for this info. For some unknown reason Cypress refuses to provide the standard firmware files + clm_blob files it uses elsewhere for inclusion into linux-firmware, instead relying on these special builds with the clm_blob info embedded. This means that the linux-firmware firmware versions often lag behind, but I digress. The brcmfmac driver does support the separate clm_blob file and always tries to load this. Currently we use request_firmware for this. This means that on any standard install, using the standard combo of linux-kernel + linux-firmware, we will get a warning: "Direct firmware load for ... failed with error -2" On top of this, brcmfmac itself prints: "no clm_blob available (err=-2), device may have limited channels available". This commit switches to firmware_request_nowarn, fixing almost any brcmfmac device logging the warning (it leaves the brcmfmac info message in place). Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
| * selinux: do not override context on context mountsOndrej Mosnacek2019-04-051-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 53e0c2aa9a59a48e3798ef193d573ade85aa80f5 ] Ignore all selinux_inode_notifysecctx() calls on mounts with SBLABEL_MNT flag unset. This is achived by returning -EOPNOTSUPP for this case in selinux_inode_setsecurtity() (because that function should not be called in such case anyway) and translating this error to 0 in selinux_inode_notifysecctx(). This fixes behavior of kernfs-based filesystems when mounted with the 'context=' option. Before this patch, if a node's context had been explicitly set to a non-default value and later the filesystem has been remounted with the 'context=' option, then this node would show up as having the manually-set context and not the mount-specified one. Steps to reproduce: # mount -t cgroup2 cgroup2 /sys/fs/cgroup/unified # chcon unconfined_u:object_r:user_home_t:s0 /sys/fs/cgroup/unified/cgroup.stat # ls -lZ /sys/fs/cgroup/unified total 0 -r--r--r--. 1 root root system_u:object_r:cgroup_t:s0 0 Dec 13 10:41 cgroup.controllers -rw-r--r--. 1 root root system_u:object_r:cgroup_t:s0 0 Dec 13 10:41 cgroup.max.depth -rw-r--r--. 1 root root system_u:object_r:cgroup_t:s0 0 Dec 13 10:41 cgroup.max.descendants -rw-r--r--. 1 root root system_u:object_r:cgroup_t:s0 0 Dec 13 10:41 cgroup.procs -r--r--r--. 1 root root unconfined_u:object_r:user_home_t:s0 0 Dec 13 10:41 cgroup.stat -rw-r--r--. 1 root root system_u:object_r:cgroup_t:s0 0 Dec 13 10:41 cgroup.subtree_control -rw-r--r--. 1 root root system_u:object_r:cgroup_t:s0 0 Dec 13 10:41 cgroup.threads # umount /sys/fs/cgroup/unified # mount -o context=system_u:object_r:tmpfs_t:s0 -t cgroup2 cgroup2 /sys/fs/cgroup/unified Result before: # ls -lZ /sys/fs/cgroup/unified total 0 -r--r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.controllers -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.max.depth -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.max.descendants -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.procs -r--r--r--. 1 root root unconfined_u:object_r:user_home_t:s0 0 Dec 13 10:41 cgroup.stat -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.subtree_control -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.threads Result after: # ls -lZ /sys/fs/cgroup/unified total 0 -r--r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.controllers -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.max.depth -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.max.descendants -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.procs -r--r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.stat -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.subtree_control -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.threads Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com> Reviewed-by: Stephen Smalley <sds@tycho.nsa.gov> Signed-off-by: Paul Moore <paul@paul-moore.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
| * x86/build: Specify elf_i386 linker emulation explicitly for i386 objectsGeorge Rimar2019-04-052-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 927185c124d62a9a4d35878d7f6d432a166b74e3 ] The kernel uses the OUTPUT_FORMAT linker script command in it's linker scripts. Most of the time, the -m option is passed to the linker with correct architecture, but sometimes (at least for x86_64) the -m option contradicts the OUTPUT_FORMAT directive. Specifically, arch/x86/boot and arch/x86/realmode/rm produce i386 object files, but are linked with the -m elf_x86_64 linker flag when building for x86_64. The GNU linker manpage doesn't explicitly state any tie-breakers between -m and OUTPUT_FORMAT. But with BFD and Gold linkers, OUTPUT_FORMAT overrides the emulation value specified with the -m option. LLVM lld has a different behavior, however. When supplied with contradicting -m and OUTPUT_FORMAT values it fails with the following error message: ld.lld: error: arch/x86/realmode/rm/header.o is incompatible with elf_x86_64 Therefore, just add the correct -m after the incorrect one (it overrides it), so the linker invocation looks like this: ld -m elf_x86_64 -z max-page-size=0x200000 -m elf_i386 --emit-relocs -T \ realmode.lds header.o trampoline_64.o stack.o reboot.o -o realmode.elf This is not a functional change for GNU ld, because (although not explicitly documented) OUTPUT_FORMAT overrides -m EMULATION. Tested by building x86_64 kernel with GNU gcc/ld toolchain and booting it in QEMU. [ bp: massage and clarify text. ] Suggested-by: Dmitry Golovin <dima@golovin.in> Signed-off-by: George Rimar <grimar@accesssoftek.com> Signed-off-by: Tri Vo <trong@android.com> Signed-off-by: Borislav Petkov <bp@suse.de> Tested-by: Tri Vo <trong@android.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Michael Matz <matz@suse.de> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: morbo@google.com Cc: ndesaulniers@google.com Cc: ruiu@google.com Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/20190111201012.71210-1-trong@android.com Signed-off-by: Sasha Levin <sashal@kernel.org>
| * drm/nouveau: Stop using drm_crtc_force_disableDaniel Vetter2019-04-051-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 934c5b32a5e43d8de2ab4f1566f91d7c3bf8cb64 ] The correct way for legacy drivers to update properties that need to do a full modeset, is to do a full modeset. Note that we don't need to call the drm_mode_config_internal helper because we're not changing any of the refcounted paramters. v2: Fixup error handling (Ville). Since the old code didn't bother I decided to just delete it instead of adding even more code for just error handling. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> (v1) Cc: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181217194303.14397-2-daniel.vetter@ffwll.ch Signed-off-by: Sasha Levin <sashal@kernel.org>
| * drm: Auto-set allow_fb_modifiers when given modifiers at plane initPaul Kocialkowski2019-04-051-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 890880ddfdbe256083170866e49c87618b706ac7 ] When drivers pass non-empty lists of modifiers for initializing their planes, we can infer that they allow framebuffer modifiers and set the driver's allow_fb_modifiers mode config element. In case the allow_fb_modifiers element was not set (some drivers tend to set them after registering planes), the modifiers will still be registered but won't be available to userspace unless the flag is set later. However in that case, the IN_FORMATS blob won't be created. In order to avoid this case and generally reduce the trouble associated with the flag, always set allow_fb_modifiers when a non-empty list of format modifiers is passed at plane init. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190104085610.5829-1-paul.kocialkowski@bootlin.com Signed-off-by: Sasha Levin <sashal@kernel.org>
| * pinctrl: meson: meson8b: add the eth_rxd2 and eth_rxd3 pinsMartin Blumenstingl2019-04-051-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 6daae00243e622dd3feec7965bfe421ad6dd317e ] Gigabit Ethernet requires the Ethernet TXD0..3 and RXD0..3 data lines. Add the missing eth_rxd2 and eth_rxd3 definitions so we don't have to rely on the bootloader to set them up correctly. The vendor u-boot sources for Odroid-C1 use the following Ethernet pinmux configuration: SET_CBUS_REG_MASK(PERIPHS_PIN_MUX_6, 0x3f4f); SET_CBUS_REG_MASK(PERIPHS_PIN_MUX_7, 0xf00000); This translates to the following pin groups in the mainline kernel: - register 6 bit 0: eth_rxd1 (DIF_0_P) - register 6 bit 1: eth_rxd0 (DIF_0_N) - register 6 bit 2: eth_rx_dv (DIF_1_P) - register 6 bit 3: eth_rx_clk (DIF_1_N) - register 6 bit 6: eth_tx_en (DIF_3_P) - register 6 bit 8: eth_ref_clk (DIF_3_N) - register 6 bit 9: eth_mdc (DIF_4_P) - register 6 bit 10: eth_mdio_en (DIF_4_N) - register 6 bit 11: eth_tx_clk (GPIOH_9) - register 6 bit 12: eth_txd2 (GPIOH_8) - register 6 bit 13: eth_txd3 (GPIOH_7) - register 7 bit 20: eth_txd0_0 (GPIOH_6) - register 7 bit 21: eth_txd1_0 (GPIOH_5) - register 7 bit 22: eth_rxd3 (DIF_2_P) - register 7 bit 23: eth_rxd2 (DIF_2_N) All functions except eth_rxd2 and eth_rxd3 are already supported by the pinctrl-meson8b driver. Suggested-by: Jianxin Pan <jianxin.pan@amlogic.com> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by: Kevin Hilman <khilman@baylibre.com> Tested-by: Emiliano Ingrassia <ingrassia@epigenesys.com> Reviewed-by: Emiliano Ingrassia <ingrassia@epigenesys.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
| * regulator: act8865: Fix act8600_sudcdc_voltage_ranges settingAxel Lin2019-04-051-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit f01a7beb6791f1c419424c1a6958b7d0a289c974 ] The act8600_sudcdc_voltage_ranges setting does not match the datasheet. The problems in below entry: REGULATOR_LINEAR_RANGE(19000000, 191, 255, 400000), 1. The off-by-one min_sel causes wrong volatage calculation. The min_sel should be 192. 2. According to the datasheet[1] Table 7. (on page 43): The selector 248 (0b11111000) ~ 255 (0b11111111) are 41.400V. Also fix off-by-one for ACT8600_SUDCDC_VOLTAGE_NUM. [1] https://active-semi.com/wp-content/uploads/ACT8600_Datasheet.pdf Fixes: df3a950e4e73 ("regulator: act8865: Add act8600 support") Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
| * audit: hand taken context to audit_kill_trees for syscall loggingRichard Guy Briggs2019-04-053-16/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 9e36a5d49c3a6fc4a2e0ba2dc11b27c4a8ae6303 ] Since the context is derived from the task parameter handed to __audit_free(), hand the context to audit_kill_trees() so it can be used to associate with a syscall record. This requires adding the context parameter to kill_rules() rather than using the current audit_context. The callers of trim_marked() and evict_chunk() still have their context. The EOE record was being issued prior to the pruning of the killed_tree list. Move the kill_trees call before the audit_log_exit call in __audit_free() and __audit_syscall_exit() so that any pruned trees CONFIG_CHANGE records are included with the associated syscall event by the user library due to the EOE record flagging the end of the event. See: https://github.com/linux-audit/audit-kernel/issues/50 See: https://github.com/linux-audit/audit-kernel/issues/59 Signed-off-by: Richard Guy Briggs <rgb@redhat.com> [PM: fixed merge fuzz in kernel/audit_tree.c] Signed-off-by: Paul Moore <paul@paul-moore.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
| * PCI: pciehp: Assign ctrl->slot_ctrl before writing it to hardwareMika Westerberg2019-04-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 25bd879ec16ad3b83a5b1c3f16faa55e696bfccb ] Shameerali reported that running v4.20-rc1 as QEMU guest, the PCIe hotplug port times out during boot: pciehp 0000:00:01.0:pcie004: Timeout on hotplug command 0x03f1 (issued 1016 msec ago) pciehp 0000:00:01.0:pcie004: Timeout on hotplug command 0x03f1 (issued 1024 msec ago) pciehp 0000:00:01.0:pcie004: Failed to check link status pciehp 0000:00:01.0:pcie004: Timeout on hotplug command 0x02f1 (issued 2520 msec ago) The issue was bisected down to commit 720d6a671a6e ("PCI: pciehp: Do not handle events if interrupts are masked") and was further analyzed by the reporter to be caused by the fact that pciehp first updates the hardware and only then cache the ctrl->slot_ctrl in pcie_do_write_cmd(). If the interrupt happens before we cache the value, pciehp_isr() reads value 0 and decides that the interrupt was not meant for it causing the above timeout to trigger. Fix by moving ctrl->slot_ctrl assignment to happen before it is written to the hardware. Fixes: 720d6a671a6e ("PCI: pciehp: Do not handle events if interrupts are masked") Link: https://lore.kernel.org/linux-pci/5FC3163CFD30C246ABAA99954A238FA8387DD344@FRAEML521-MBX.china.huawei.com Reported-by: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
| * media: s5p-jpeg: Check for fmt_ver_flag when doing fmt enumerationPawe? Chmiel2019-04-051-8/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 49710c32cd9d6626a77c9f5f978a5f58cb536b35 ] Previously when doing format enumeration, it was returning all formats supported by driver, even if they're not supported by hw. Add missing check for fmt_ver_flag, so it'll be fixed and only those supported by hw will be returned. Similar thing is already done in s5p_jpeg_find_format. It was found by using v4l2-compliance tool and checking result of VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS test and using v4l2-ctl to get list of all supported formats. Tested on s5pv210-galaxys (Samsung i9000 phone). Fixes: bb677f3ac434 ("[media] Exynos4 JPEG codec v4l2 driver") Signed-off-by: Pawe? Chmiel <pawel.mikolaj.chmiel@gmail.com> Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> [hverkuil-cisco@xs4all.nl: fix a few alignment issues] Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
| * media: rcar-vin: Allow independent VIN link enablementSteve Longerbeam2019-04-051-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit c5ff0edb8e2270a75935c73217fb0de1abd2d910 ] There is a block of code in rvin_group_link_notify() that prevents enabling a link to a VIN node if any entity in the media graph is in use. This prevents enabling a VIN link even if there is an in-use entity somewhere in the graph that is independent of the link's pipeline. For example, the code block will prevent enabling a link from the first rcar-csi2 receiver to a VIN node even if there is an enabled link somewhere far upstream on the second independent rcar-csi2 receiver pipeline. If this code block is meant to prevent modifying a link if any entity in the graph is actively involved in streaming (because modifying the CHSEL register fields can disrupt any/all running streams), then the entities stream counts should be checked rather than the use counts. (There is already such a check in __media_entity_setup_link() that verifies the stream_count of the link's source and sink entities are both zero, but that is insufficient, since there should be no running streams in the entire graph). Modify the code block to check the entity stream_count instead of the use_count (and elaborate on the comment). VIN node links can now be enabled even if there are other independent in-use entities that are not streaming. Fixes: c0cc5aef31 ("media: rcar-vin: add link notify for Gen3") Signed-off-by: Steve Longerbeam <slongerbeam@gmail.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
| * netfilter: physdev: relax br_netfilter dependencyFlorian Westphal2019-04-053-8/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 8e2f311a68494a6677c1724bdcb10bada21af37c ] Following command: iptables -D FORWARD -m physdev ... causes connectivity loss in some setups. Reason is that iptables userspace will probe kernel for the module revision of the physdev patch, and physdev has an artificial dependency on br_netfilter (xt_physdev use makes no sense unless a br_netfilter module is loaded). This causes the "phydev" module to be loaded, which in turn enables the "call-iptables" infrastructure. bridged packets might then get dropped by the iptables ruleset. The better fix would be to change the "call-iptables" defaults to 0 and enforce explicit setting to 1, but that breaks backwards compatibility. This does the next best thing: add a request_module call to checkentry. This was a stray '-D ... -m physdev' won't activate br_netfilter anymore. Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
| * dmaengine: qcom_hidma: initialize tx flags in hidma_prep_dma_*Shunyong Yang2019-04-051-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 875aac8a46424e5b73a9ff7f40b83311b609e407 ] In async_tx_test_ack(), it uses flags in struct dma_async_tx_descriptor to check the ACK status. As hidma reuses the descriptor in a free list when hidma_prep_dma_*(memcpy/memset) is called, the flag will keep ACKed if the descriptor has been used before. This will cause a BUG_ON in async_tx_quiesce(). kernel BUG at crypto/async_tx/async_tx.c:282! Internal error: Oops - BUG: 0 1 SMP ... task: ffff8017dd3ec000 task.stack: ffff8017dd3e8000 PC is at async_tx_quiesce+0x54/0x78 [async_tx] LR is at async_trigger_callback+0x98/0x110 [async_tx] This patch initializes flags in dma_async_tx_descriptor by the flags passed from the caller when hidma_prep_dma_*(memcpy/memset) is called. Cc: Joey Zheng <yu.zheng@hxt-semitech.com> Reviewed-by: Sinan Kaya <okaya@kernel.org> Signed-off-by: Shunyong Yang <shunyong.yang@hxt-semitech.com> Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
| * dmaengine: qcom_hidma: assign channel cookie correctlyShunyong Yang2019-04-051-8/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 546c0547555efca8ba8c120716c325435e29df1b ] When dma_cookie_complete() is called in hidma_process_completed(), dma_cookie_status() will return DMA_COMPLETE in hidma_tx_status(). Then, hidma_txn_is_success() will be called to use channel cookie mchan->last_success to do additional DMA status check. Current code assigns mchan->last_success after dma_cookie_complete(). This causes a race condition of dma_cookie_status() returns DMA_COMPLETE before mchan->last_success is assigned correctly. The race will cause hidma_tx_status() return DMA_ERROR but the transaction is actually a success. Moreover, in async_tx case, it will cause a timeout panic in async_tx_quiesce(). Kernel panic - not syncing: async_tx_quiesce: DMA error waiting for transaction ... Call trace: [<ffff000008089994>] dump_backtrace+0x0/0x1f4 [<ffff000008089bac>] show_stack+0x24/0x2c [<ffff00000891e198>] dump_stack+0x84/0xa8 [<ffff0000080da544>] panic+0x12c/0x29c [<ffff0000045d0334>] async_tx_quiesce+0xa4/0xc8 [async_tx] [<ffff0000045d03c8>] async_trigger_callback+0x70/0x1c0 [async_tx] [<ffff0000048b7d74>] raid_run_ops+0x86c/0x1540 [raid456] [<ffff0000048bd084>] handle_stripe+0x5e8/0x1c7c [raid456] [<ffff0000048be9ec>] handle_active_stripes.isra.45+0x2d4/0x550 [raid456] [<ffff0000048beff4>] raid5d+0x38c/0x5d0 [raid456] [<ffff000008736538>] md_thread+0x108/0x168 [<ffff0000080fb1cc>] kthread+0x10c/0x138 [<ffff000008084d34>] ret_from_fork+0x10/0x18 Cc: Joey Zheng <yu.zheng@hxt-semitech.com> Reviewed-by: Sinan Kaya <okaya@kernel.org> Signed-off-by: Shunyong Yang <shunyong.yang@hxt-semitech.com> Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
| * dmaengine: imx-dma: fix warning comparison of distinct pointer typesAnders Roxell2019-04-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 9227ab5643cb8350449502dd9e3168a873ab0e3b ] The warning got introduced by commit 930507c18304 ("arm64: add basic Kconfig symbols for i.MX8"). Since it got enabled for arm64. The warning haven't been seen before since size_t was 'unsigned int' when built on arm32. ../drivers/dma/imx-dma.c: In function ‘imxdma_sg_next’: ../include/linux/kernel.h:846:29: warning: comparison of distinct pointer types lacks a cast (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1))) ^~ ../include/linux/kernel.h:860:4: note: in expansion of macro ‘__typecheck’ (__typecheck(x, y) && __no_side_effects(x, y)) ^~~~~~~~~~~ ../include/linux/kernel.h:870:24: note: in expansion of macro ‘__safe_cmp’ __builtin_choose_expr(__safe_cmp(x, y), \ ^~~~~~~~~~ ../include/linux/kernel.h:879:19: note: in expansion of macro ‘__careful_cmp’ #define min(x, y) __careful_cmp(x, y, <) ^~~~~~~~~~~~~ ../drivers/dma/imx-dma.c:288:8: note: in expansion of macro ‘min’ now = min(d->len, sg_dma_len(sg)); ^~~ Rework so that we use min_t and pass in the size_t that returns the minimum of two values, using the specified type. Signed-off-by: Anders Roxell <anders.roxell@linaro.org> Acked-by: Olof Johansson <olof@lixom.net> Reviewed-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
| * cpu/hotplug: Mute hotplug lockdep during initValentin Schneider2019-04-051-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit ce48c457b95316b9a01b5aa9d4456ce820df94b4 ] Since we've had: commit cb538267ea1e ("jump_label/lockdep: Assert we hold the hotplug lock for _cpuslocked() operations") we've been getting some lockdep warnings during init, such as on HiKey960: [ 0.820495] WARNING: CPU: 4 PID: 0 at kernel/cpu.c:316 lockdep_assert_cpus_held+0x3c/0x48 [ 0.820498] Modules linked in: [ 0.820509] CPU: 4 PID: 0 Comm: swapper/4 Tainted: G S 4.20.0-rc5-00051-g4cae42a #34 [ 0.820511] Hardware name: HiKey960 (DT) [ 0.820516] pstate: 600001c5 (nZCv dAIF -PAN -UAO) [ 0.820520] pc : lockdep_assert_cpus_held+0x3c/0x48 [ 0.820523] lr : lockdep_assert_cpus_held+0x38/0x48 [ 0.820526] sp : ffff00000a9cbe50 [ 0.820528] x29: ffff00000a9cbe50 x28: 0000000000000000 [ 0.820533] x27: 00008000b69e5000 x26: ffff8000bff4cfe0 [ 0.820537] x25: ffff000008ba69e0 x24: 0000000000000001 [ 0.820541] x23: ffff000008fce000 x22: ffff000008ba70c8 [ 0.820545] x21: 0000000000000001 x20: 0000000000000003 [ 0.820548] x19: ffff00000a35d628 x18: ffffffffffffffff [ 0.820552] x17: 0000000000000000 x16: 0000000000000000 [ 0.820556] x15: ffff00000958f848 x14: 455f3052464d4d34 [ 0.820559] x13: 00000000769dde98 x12: ffff8000bf3f65a8 [ 0.820564] x11: 0000000000000000 x10: ffff00000958f848 [ 0.820567] x9 : ffff000009592000 x8 : ffff00000958f848 [ 0.820571] x7 : ffff00000818ffa0 x6 : 0000000000000000 [ 0.820574] x5 : 0000000000000000 x4 : 0000000000000001 [ 0.820578] x3 : 0000000000000000 x2 : 0000000000000001 [ 0.820582] x1 : 00000000ffffffff x0 : 0000000000000000 [ 0.820587] Call trace: [ 0.820591] lockdep_assert_cpus_held+0x3c/0x48 [ 0.820598] static_key_enable_cpuslocked+0x28/0xd0 [ 0.820606] arch_timer_check_ool_workaround+0xe8/0x228 [ 0.820610] arch_timer_starting_cpu+0xe4/0x2d8 [ 0.820615] cpuhp_invoke_callback+0xe8/0xd08 [ 0.820619] notify_cpu_starting+0x80/0xb8 [ 0.820625] secondary_start_kernel+0x118/0x1d0 We've also had a similar warning in sched_init_smp() for every asymmetric system that would enable the sched_asym_cpucapacity static key, although that was singled out in: commit 40fa3780bac2 ("sched/core: Take the hotplug lock in sched_init_smp()") Those warnings are actually harmless, since we cannot have hotplug operations at the time they appear. Instead of starting to sprinkle useless hotplug lock operations in the init codepaths, mute the warnings until they start warning about real problems. Suggested-by: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Valentin Schneider <valentin.schneider@arm.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Will Deacon <will.deacon@arm.com> Cc: cai@gmx.us Cc: daniel.lezcano@linaro.org Cc: dietmar.eggemann@arm.com Cc: linux-arm-kernel@lists.infradead.org Cc: longman@redhat.com Cc: marc.zyngier@arm.com Cc: mark.rutland@arm.com Link: https://lkml.kernel.org/r/1545243796-23224-2-git-send-email-valentin.schneider@arm.com Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
| * pinctrl: sh-pfc: r8a77995: Fix MOD_SEL bit numberingTakeshi Kihara2019-04-051-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 5219aa33caec2f7b68eda2b7e4ab8e276f323254 ] MOD_SEL register bit numbering was different from R-Car D3 SoC and R-Car H3/M3-[WN] SoCs. MOD_SEL 1-bit H3/M3-[WN] D3 =============== ========== ===== Set Value = H'0 b'0 b'0 Set Value = H'1 b'1 b'1 MOD_SEL 2-bits H3/M3-[WN] D3 =============== ========== ===== Set Value = H'0 b'00 b'00 Set Value = H'1 b'01 b'10 Set Value = H'2 b'10 b'01 Set Value = H'3 b'11 b'11 MOD_SEL 3-bits H3/M3-[WN] D3 =============== ========== ===== Set Value = H'0 b'000 b'000 Set Value = H'1 b'001 b'100 Set Value = H'2 b'010 b'010 Set Value = H'3 b'011 b'110 Set Value = H'4 b'100 b'001 Set Value = H'5 b'101 b'101 Set Value = H'6 b'110 b'011 Set Value = H'7 b'111 b'111 This patch replaces the #define name and value of MOD_SEL. Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com> Fixes: 794a67117646 ("pinctrl: sh-pfc: Initial R8A77995 PFC support") [shimoda: split a patch per SoC and revise the commit log] Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> [geert: Use a macro to do the actual reordering] Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
| * pinctrl: sh-pfc: r8a77990: Fix MOD_SEL bit numberingTakeshi Kihara2019-04-051-14/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 3e3eebeacad79bda8a9664c86c04f5201e86fece ] MOD_SEL register bit numbering was different from R-Car E3 SoC and R-Car H3/M3-[WN] SoCs. MOD_SEL 1-bit H3/M3-[WN] E3 =============== ========== ===== Set Value = H'0 b'0 b'0 Set Value = H'1 b'1 b'1 MOD_SEL 2-bits H3/M3-[WN] E3 =============== ========== ===== Set Value = H'0 b'00 b'00 Set Value = H'1 b'01 b'10 Set Value = H'2 b'10 b'01 Set Value = H'3 b'11 b'11 MOD_SEL 3-bits H3/M3-[WN] E3 =============== ========== ===== Set Value = H'0 b'000 b'000 Set Value = H'1 b'001 b'100 Set Value = H'2 b'010 b'010 Set Value = H'3 b'011 b'110 Set Value = H'4 b'100 b'001 Set Value = H'5 b'101 b'101 Set Value = H'6 b'110 b'011 Set Value = H'7 b'111 b'111 This patch replaces the #define name and value of MOD_SEL. Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com> Fixes: 6d4036a1e3b3 ("pinctrl: sh-pfc: Initial R8A77990 PFC support") [shimoda: Split a patch per SoC and revise the commit log] Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> [geert: Use macros to do the actual reordering] Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
| * pinctrl: meson: fix G12A ao pull registers base addressXingyu Chen2019-04-051-10/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit e66dd48e8b0dee104d16417d30361074b08baca8 ] Since Meson G12A SoC, Introduce new ao registers AO_RTI_PULL_UP_EN_REG and AO_GPIO_O. These bits of controlling output level are remapped to the new register AO_GPIO_O, and the AO_GPIO_O_EN_N support only controlling output enable. These bits of controlling pull enable are remapped to the new register AO_RTI_PULL_UP_EN_REG, and the AO_RTI_PULL_UP_REG support only controlling pull type(up/down). The new layout of ao gpio/pull registers is as follows: - AO_GPIO_O_EN_N [offset: 0x9 << 2] - AO_GPIO_I [offset: 0xa << 2] - AO_RTI_PULL_UP_REG [offset: 0xb << 2] - AO_RTI_PULL_UP_EN_REG [offset: 0xc << 2] - AO_GPIO_O [offset: 0xd << 2] From above, we can see ao GPIO registers region has been separated by the ao pull registers. In order to ensure the continuity of the region on software, the ao GPIO and ao pull registers use the same base address, but can be identified by the offset. Fixes: 29ae0952e85f ("pinctrl: meson-g12a: add pinctrl driver support") Signed-off-by: Xingyu Chen <xingyu.chen@amlogic.com> Signed-off-by: Jianxin Pan <jianxin.pan@amlogic.com> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
| * hpet: Fix missing '=' character in the __setup() code of hpet_mmap_enableBuland Singh2019-04-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 24d48a61f2666630da130cc2ec2e526eacf229e3 ] Commit '3d035f580699 ("drivers/char/hpet.c: allow user controlled mmap for user processes")' introduced a new kernel command line parameter hpet_mmap, that is required to expose the memory map of the HPET registers to user-space. Unfortunately the kernel command line parameter 'hpet_mmap' is broken and never takes effect due to missing '=' character in the __setup() code of hpet_mmap_enable. Before this patch: dmesg output with the kernel command line parameter hpet_mmap=1 [ 0.204152] HPET mmap disabled dmesg output with the kernel command line parameter hpet_mmap=0 [ 0.204192] HPET mmap disabled After this patch: dmesg output with the kernel command line parameter hpet_mmap=1 [ 0.203945] HPET mmap enabled dmesg output with the kernel command line parameter hpet_mmap=0 [ 0.204652] HPET mmap disabled Fixes: 3d035f580699 ("drivers/char/hpet.c: allow user controlled mmap for user processes") Signed-off-by: Buland Singh <bsingh@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
| * f2fs: fix to initialize variable to avoid UBSAN/smatch warningChao Yu2019-04-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit f9aa52a8cbe09fe25244d59c29660bbe635df613 ] As Dan Carpenter as below: The patch df634f444ee9: "f2fs: use rb_*_cached friends" from Oct 4, 2018, leads to the following static checker warning: fs/f2fs/extent_cache.c:606 f2fs_update_extent_tree_range() error: uninitialized symbol 'leftmost'. And also Eric Biggers, and Kyungtae Kim reported, there is an UBSAN warning described as below: We report a bug in linux-4.20.2: "UBSAN: Undefined behaviour in fs/f2fs/extent_cache.c" kernel config: https://kt0755.github.io/etc/config_v4.20_stable repro: https://kt0755.github.io/etc/repro.4a3e7.c (f2fs is mounted on /mnt/f2fs/) This arose in f2fs_update_extent_tree_range (fs/f2fs/extent_cache.c:605). It seems that, for some reason, its last argument became "24" although that was supposed to be bool type. ========================================= UBSAN: Undefined behaviour in fs/f2fs/extent_cache.c:605:4 load of value 24 is not a valid value for type '_Bool' CPU: 0 PID: 6774 Comm: syz-executor5 Not tainted 4.20.2 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xb1/0x118 lib/dump_stack.c:113 ubsan_epilogue+0x12/0x94 lib/ubsan.c:159 __ubsan_handle_load_invalid_value+0x17a/0x1be lib/ubsan.c:457 f2fs_update_extent_tree_range+0x1d4a/0x1d50 fs/f2fs/extent_cache.c:605 f2fs_update_extent_cache+0x2b6/0x350 fs/f2fs/extent_cache.c:804 f2fs_update_data_blkaddr+0x61/0x70 fs/f2fs/data.c:656 f2fs_outplace_write_data+0x1d6/0x4b0 fs/f2fs/segment.c:3140 f2fs_convert_inline_page+0x86d/0x2060 fs/f2fs/inline.c:163 f2fs_convert_inline_inode+0x6b5/0xad0 fs/f2fs/inline.c:208 f2fs_preallocate_blocks+0x78b/0xb00 fs/f2fs/data.c:982 f2fs_file_write_iter+0x31b/0xf40 fs/f2fs/file.c:3062 call_write_iter include/linux/fs.h:1857 [inline] new_sync_write fs/read_write.c:474 [inline] __vfs_write+0x538/0x6e0 fs/read_write.c:487 vfs_write+0x1b3/0x520 fs/read_write.c:549 ksys_write+0xde/0x1c0 fs/read_write.c:598 __do_sys_write fs/read_write.c:610 [inline] __se_sys_write fs/read_write.c:607 [inline] __x64_sys_write+0x7e/0xc0 fs/read_write.c:607 do_syscall_64+0xbe/0x4f0 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x4497b9 Code: e8 8c 9f 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 9b 6b fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007f1ea15edc68 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007f1ea15ee6cc RCX: 00000000004497b9 RDX: 0000000000001000 RSI: 0000000020000140 RDI: 0000000000000013 RBP: 000000000071bea0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff R13: 000000000000bb50 R14: 00000000006f4bf0 R15: 00007f1ea15ee700 ========================================= As I checked, this uninitialized variable won't cause extent cache corruption, but in order to avoid such kind of warning of both UBSAN and smatch, fix to initialize related variable. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Reported-by: Eric Biggers <ebiggers@google.com> Reported-by: Kyungtae Kim <kt0755@gmail.com> Signed-off-by: Chao Yu <yuchao0@huawei.com> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
| * f2fs: UBSAN: set boolean value iostat_enable correctlySheng Yong2019-04-051-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit ac92985864e187a1735502f6a02f54eaa655b2aa ] When setting /sys/fs/f2fs/<DEV>/iostat_enable with non-bool value, UBSAN reports the following warning. [ 7562.295484] ================================================================================ [ 7562.296531] UBSAN: Undefined behaviour in fs/f2fs/f2fs.h:2776:10 [ 7562.297651] load of value 64 is not a valid value for type '_Bool' [ 7562.298642] CPU: 1 PID: 7487 Comm: dd Not tainted 4.20.0-rc4+ #79 [ 7562.298653] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 7562.298662] Call Trace: [ 7562.298760] dump_stack+0x46/0x5b [ 7562.298811] ubsan_epilogue+0x9/0x40 [ 7562.298830] __ubsan_handle_load_invalid_value+0x72/0x90 [ 7562.298863] f2fs_file_write_iter+0x29f/0x3f0 [ 7562.298905] __vfs_write+0x115/0x160 [ 7562.298922] vfs_write+0xa7/0x190 [ 7562.298934] ksys_write+0x50/0xc0 [ 7562.298973] do_syscall_64+0x4a/0xe0 [ 7562.298992] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 7562.299001] RIP: 0033:0x7fa45ec19c00 [ 7562.299004] Code: 73 01 c3 48 8b 0d 88 92 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d dd eb 2c 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 ce 8f 01 00 48 89 04 24 [ 7562.299044] RSP: 002b:00007ffca52b49e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 7562.299052] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fa45ec19c00 [ 7562.299059] RDX: 0000000000000400 RSI: 000000000093f000 RDI: 0000000000000001 [ 7562.299065] RBP: 000000000093f000 R08: 0000000000000004 R09: 0000000000000000 [ 7562.299071] R10: 00007ffca52b47b0 R11: 0000000000000246 R12: 0000000000000400 [ 7562.299077] R13: 000000000093f000 R14: 000000000093f400 R15: 0000000000000000 [ 7562.299091] ================================================================================ So, if iostat_enable is enabled, set its value as true. Signed-off-by: Sheng Yong <shengyong1@huawei.com> Reviewed-by: Chao Yu <yuchao0@huawei.com> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
| * HID: intel-ish: ipc: handle PIMR before ish_wakeup also clear PISR ↵Song Hongyan2019-04-051-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | busy_clear bit [ Upstream commit 2edefc056e4f0e6ec9508dd1aca2c18fa320efef ] Host driver should handle interrupt mask register earlier than wake up ish FW else there will be conditions when FW interrupt comes, host PIMR register still not set ready, so move the interrupt mask setting before ish_wakeup. Clear PISR busy_clear bit in ish_irq_handler. If not clear, there will be conditions host driver received a busy_clear interrupt (before the busy_clear mask bit is ready), it will return IRQ_NONE after check_generated_interrupt, the interrupt will never be cleared, causing the DEVICE not sending following IRQ. Since PISR clear should not be called for the CHV device we do this change. After the change, both ISH2HOST interrupt and busy_clear interrupt will be considered as interrupt from ISH, busy_clear interrupt will return IRQ_HANDLED from IPC_IS_BUSY check. Signed-off-by: Song Hongyan <hongyan.song@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <sashal@kernel.org>
| * selftests/bpf: suppress readelf stderr when probing for BTF supportStanislav Fomichev2019-04-051-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 2f0921262ba943fe9d9f59037a033927d8c4789b ] Before: $ make -s -C tools/testing/selftests/bpf readelf: Error: Missing knowledge of 32-bit reloc types used in DWARF sections of machine number 247 readelf: Warning: unable to apply unsupported reloc type 10 to section .debug_info readelf: Warning: unable to apply unsupported reloc type 1 to section .debug_info readelf: Warning: unable to apply unsupported reloc type 10 to section .debug_info After: $ make -s -C tools/testing/selftests/bpf v2: * use llvm-readelf instead of redirecting binutils' readelf stderr to /dev/null Signed-off-by: Stanislav Fomichev <sdf@google.com> Acked-by: Song Liu <songliubraving@fb.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
OpenPOWER on IntegriCloud