Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

-Wsometimes-uninitialized in drivers/net/ethernet/stmicro/stmmac/stmmac_main.c #384

Closed
nickdesaulniers opened this issue Feb 26, 2019 · 5 comments
Closed

-Wsometimes-uninitialized in drivers/net/ethernet/stmicro/stmmac/stmmac_main.c #384

nickdesaulniers opened this issue Feb 26, 2019 · 5 comments
Assignees
@nathanchance
Labels
-Wsometimes-uninitialized [ARCH] arm32 This bug impacts ARCH=arm [BUG] linux A bug that should be fixed in the mainline kernel. [FIXED][LINUX] 5.1 This bug was fixed in Linux 5.1

Comments

@nickdesaulniers
Copy link
Member

from #381

drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:495:3: error: variable 'ns' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:495:3: error: variable 'ns' is used uninitialized whenever '&&' condition is false [-Werror,-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:532:3: error: variable 'ns' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:532:3: error: variable 'ns' is used uninitialized whenever '&&' condition is false [-Werror,-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:741:3: error: variable 'sec_inc' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:741:3: error: variable 'sec_inc' is used uninitialized whenever '&&' condition is false [-Werror,-Wsometimes-uninitialized]
@nickdesaulniers nickdesaulniers added good first issue Good for newcomers [BUG] linux A bug that should be fixed in the mainline kernel. low priority This bug is not critical and not a priority [ARCH] arm32 This bug impacts ARCH=arm -Wsometimes-uninitialized labels Feb 26, 2019
@nickdesaulniers
Copy link
Member Author

Seems like the use of stmmac_get_timestamp is problematic in the first 4 cases, and stmmac_config_sub_second_increment in the second. Also, line numbers of the above are off due to them coming from linux-next, but I still see the issue in mainline.

stmmac_get_timestamp expands to stmmac_do_void_callback, which invokes a function it's passed (get_timestamp) and forwards the rest of the args to that function.

The issue is that the check in stmmac_do_void_callback if ever false would not call the callback, and potentially not initialize the variable.

Doesn't hurt to just initialize the variable ns.

sec_inc has the same problem in stmmac_config_sub_second_increment which expands to stmmac_do_void_callback again but invokes the passed callback config_sub_second_increment which may or may not get called. Almost every other local variable in stmmac_config_sub_second_increment is zero initialized, except sec_inc.

@nathanchance
Copy link
Member

Patch sent: https://lore.kernel.org/lkml/20190307162101.29204-1-natechancellor@gmail.com/

@nathanchance nathanchance added [PATCH] Submitted A patch has been submitted for review and removed good first issue Good for newcomers low priority This bug is not critical and not a priority labels Mar 7, 2019
@nathanchance nathanchance self-assigned this Mar 7, 2019
@nathanchance
Copy link
Member

Patch accepted: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=df103170854e87124ee7bdd2bca64b178e653f97

@nathanchance nathanchance added [PATCH] Accepted A submitted patch has been accepted upstream and removed [PATCH] Submitted A patch has been submitted for review labels Mar 7, 2019
avagin pushed a commit to avagin/linux that referenced this issue Mar 8, 2019
@nathanchance @davem330
net: stmmac: Avoid sometimes uninitialized Clang warnings
df10317 
When building with -Wsometimes-uninitialized, Clang warns:

drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:495:3: warning: variable 'ns' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:495:3: warning: variable 'ns' is used uninitialized whenever '&&' condition is false [-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:532:3: warning: variable 'ns' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:532:3: warning: variable 'ns' is used uninitialized whenever '&&' condition is false [-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:741:3: warning: variable 'sec_inc' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:741:3: warning: variable 'sec_inc' is used uninitialized whenever '&&' condition is false [-Wsometimes-uninitialized]

Clang is concerned with the use of stmmac_do_void_callback (which
stmmac_get_timestamp and stmmac_config_sub_second_increment wrap),
as it may fail to initialize these values if the if condition was ever
false (meaning the callbacks don't exist). It's not wrong because the
callbacks (get_timestamp and config_sub_second_increment respectively)
are the ones that initialize the variables. While it's unlikely that the
callbacks are ever going to disappear and make that condition false, we
can easily avoid this warning by zero initialize the variables.

Link: ClangBuiltLinux/linux#384
Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
@nathanchance
Copy link
Member

Another fix accepted: https://git.kernel.org/davem/net/c/1f5d861f7fefa971b2c6e766f77932c86419a319

fengguang pushed a commit to 0day-ci/linux that referenced this issue Mar 10, 2019
@nathanchance @davem330
net: stmmac: Avoid one more sometimes uninitialized Clang warning
1f5d861 
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: ClangBuiltLinux#384
Fixes: df10317 ("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>
@nathanchance
Copy link
Member

Merged into mainline:

https://git.kernel.org/torvalds/c/df103170854e87124ee7bdd2bca64b178e653f97

https://git.kernel.org/torvalds/c/1f5d861f7fefa971b2c6e766f77932c86419a319

@nathanchance nathanchance added [FIXED][LINUX] 5.1 This bug was fixed in Linux 5.1 and removed [PATCH] Accepted A submitted patch has been accepted upstream labels Mar 11, 2019
Whissi pushed a commit to Whissi/linux-stable that referenced this issue Apr 5, 2019
@nathanchance @gregkh
net: stmmac: Avoid sometimes uninitialized Clang warnings
aaad698 
[ Upstream commit df10317 ]

When building with -Wsometimes-uninitialized, Clang warns:

drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:495:3: warning: variable 'ns' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:495:3: warning: variable 'ns' is used uninitialized whenever '&&' condition is false [-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:532:3: warning: variable 'ns' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:532:3: warning: variable 'ns' is used uninitialized whenever '&&' condition is false [-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:741:3: warning: variable 'sec_inc' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:741:3: warning: variable 'sec_inc' is used uninitialized whenever '&&' condition is false [-Wsometimes-uninitialized]

Clang is concerned with the use of stmmac_do_void_callback (which
stmmac_get_timestamp and stmmac_config_sub_second_increment wrap),
as it may fail to initialize these values if the if condition was ever
false (meaning the callbacks don't exist). It's not wrong because the
callbacks (get_timestamp and config_sub_second_increment respectively)
are the ones that initialize the variables. While it's unlikely that the
callbacks are ever going to disappear and make that condition false, we
can easily avoid this warning by zero initialize the variables.

Link: ClangBuiltLinux/linux#384
Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Whissi pushed a commit to Whissi/linux-stable that referenced this issue Apr 5, 2019
@nathanchance @gregkh
net: stmmac: Avoid one more sometimes uninitialized Clang warning
a84b7c6 
[ Upstream commit 1f5d861 ]

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: ClangBuiltLinux/linux#384
Fixes: df10317 ("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>
Whissi pushed a commit to Whissi/linux-stable that referenced this issue Apr 5, 2019
@nathanchance @gregkh
net: stmmac: Avoid sometimes uninitialized Clang warnings
9ec4860 
[ Upstream commit df10317 ]

When building with -Wsometimes-uninitialized, Clang warns:

drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:495:3: warning: variable 'ns' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:495:3: warning: variable 'ns' is used uninitialized whenever '&&' condition is false [-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:532:3: warning: variable 'ns' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:532:3: warning: variable 'ns' is used uninitialized whenever '&&' condition is false [-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:741:3: warning: variable 'sec_inc' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:741:3: warning: variable 'sec_inc' is used uninitialized whenever '&&' condition is false [-Wsometimes-uninitialized]

Clang is concerned with the use of stmmac_do_void_callback (which
stmmac_get_timestamp and stmmac_config_sub_second_increment wrap),
as it may fail to initialize these values if the if condition was ever
false (meaning the callbacks don't exist). It's not wrong because the
callbacks (get_timestamp and config_sub_second_increment respectively)
are the ones that initialize the variables. While it's unlikely that the
callbacks are ever going to disappear and make that condition false, we
can easily avoid this warning by zero initialize the variables.

Link: ClangBuiltLinux/linux#384
Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Whissi pushed a commit to Whissi/linux-stable that referenced this issue Apr 5, 2019
@nathanchance @gregkh
net: stmmac: Avoid one more sometimes uninitialized Clang warning
d1d2ca9 
[ Upstream commit 1f5d861 ]

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: ClangBuiltLinux/linux#384
Fixes: df10317 ("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>
LLJY added a commit to LLJY/x86-kernel that referenced this issue Apr 9, 2019
@LLJY
Linux 5.07
b4d20d8 
commit 8b298d3a0bd5feeb47129c4889356b38b78ab231
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Apr 5 22:34:54 2019 +0200

    Linux 5.0.7

commit e73f145543fa6e1ce0b7a9d99c65caa1b422aac9
Author: Masahiro Yamada <yamada.masahiro@socionext.com>
Date:   Tue Mar 19 13:02:36 2019 +0900

    kbuild: skip sub-make for in-tree build with GNU Make 4.x

    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>

commit d972d1c0d76da4a04ea9c0a35a3fb853fb141248
Author: Masahiro Yamada <yamada.masahiro@socionext.com>
Date:   Fri Mar 8 18:13:39 2019 +0900

    kbuild: add workaround for Debian make-kpkg

    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>

commit 38d2286e52ea5f06fa5a1692fad36db043456291
Author: Coly Li <colyli@suse.de>
Date:   Sat Feb 9 12:53:06 2019 +0800

    bcache: fix potential div-zero error of writeback_rate_p_term_inverse

    [ 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>

commit ae050638bc97083f43e13186087626754d658cb9
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Jan 7 17:08:21 2019 +0100

    ACPI / video: Extend chassis-type detection with a "Lunch Box" check

    [ 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>

commit 3e033b1b435a47b16d63ff6bd5159f699b8bf173
Author: Thierry Reding <treding@nvidia.com>
Date:   Wed Feb 20 11:52:14 2019 +0100

    gpio: of: Restrict enable-gpio quirk to regulator-gpio

    [ 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>

commit ae42fc868cd5fca29f6f31487dc7d016c923f8fa
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Mar 6 11:52:36 2019 +0100

    appletalk: Fix compile regression

    [ 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>

commit a84b7c68966a91f937d609786fd8968dc2b5f085
Author: Nathan Chancellor <natechancellor@gmail.com>
Date:   Thu Mar 7 21:02:39 2019 -0700

    net: stmmac: Avoid one more sometimes uninitialized Clang warning

    [ 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>

commit 36b39631cc851b6b90b22a3aa4a09ee79b0718de
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Fri Sep 28 21:03:59 2018 +0300

    drm/dp/mst: Configure no_stop_bit correctly for remote i2c xfers

    [ 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>

commit 8826838f43fe879eba8df230e93e2f43ab0b3081
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sun Dec 30 12:28:42 2018 +0000

    drm: Reorder set_property_atomic to avoid returning with an active ww_ctx

    [ 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>

commit 0a2e1a5b583b8564834cdbc161cd1614cc834e59
Author: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Date:   Thu Dec 20 10:45:42 2018 +0900

    ASoC: simple-card-utils: check "reg" property on asoc_simple_card_get_dai_id()

    [ 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>

commit 45040e92500cb70bcb906dc6aa0427166097871c
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Thu Jan 3 18:10:45 2019 -0800

    Input: soc_button_array - fix mapping of the 5th GPIO in a PNP0C40 device

    [ 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>

commit 1ad62489b25aa992113813447657ef5192a93b96
Author: Jeremy Fertic <jeremyfertic@gmail.com>
Date:   Sat Dec 22 21:57:40 2018 -0700

    staging: iio: adt7316: fix dac_bits assignment

    [ 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>

commit 2bece1d313aa1c05e10f827b2c797589fdc985ec
Author: Ben Dooks <ben.dooks@codethink.co.uk>
Date:   Wed Nov 21 16:13:19 2018 +0000

    dmaengine: tegra: avoid overflow of byte tracking

    [ 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>

commit e84e0a8c3f22dba823b33cfd38c65c3fe6e35dd5
Author: Katsuhiro Suzuki <katsuhiro@katsuster.net>
Date:   Sun Dec 23 01:42:49 2018 +0900

    clk: rockchip: fix frac settings of GPLL clock for rk3328

    [ 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>

commit 25fb6c323b55dbb7ec9227a174c36a13697bcb5d
Author: Marek Vasut <marek.vasut@gmail.com>
Date:   Fri Dec 7 21:28:58 2018 +0100

    ARM: shmobile: Fix R-Car Gen2 regulator quirk

    [ 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>

commit 9b0f430450cf230e736bc40f95bf34fbdb99cead
Author: Jerome Brunet <jbrunet@baylibre.com>
Date:   Fri Dec 21 17:02:36 2018 +0100

    clk: meson: clean-up clock registration

    [ 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>

commit a644d2d28baf8472368903b28823cf85c9a13a1d
Author: Peter Wu <peter@lekensteyn.nl>
Date:   Sun Dec 23 01:55:07 2018 +0100

    drm/fb-helper: fix leaks in error path of drm_fb_helper_fbdev_setup

    [ 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>

commit c8a8dd1d85ca715ec65169feac54a7a06b8d2a29
Author: Rafael Ávila de Espíndola <rafael@espindo.la>
Date:   Wed Dec 19 11:01:43 2018 -0800

    x86/build: Mark per-CPU symbols as absolute explicitly for LLD

    [ 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>

commit 38af5462fa5179ede1f63b88d3c2e8201392cca1
Author: Zumeng Chen <zumeng.chen@gmail.com>
Date:   Wed Dec 19 15:50:29 2018 +0800

    wlcore: Fix memory leak in case wl12xx_fetch_firmware failure

    [ 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>

commit ab79dc3ef0244c9b3d712d0cef17b74c363d6069
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Jan 7 14:33:27 2019 +0100

    brcmfmac: Use firmware_request_nowarn for the clm_blob

    [ 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>

commit f836093a2eeb48e565d2484523b5aceda072da72
Author: Ondrej Mosnacek <omosnace@redhat.com>
Date:   Fri Dec 21 21:18:53 2018 +0100

    selinux: do not override context on context mounts

    [ 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>

commit 993f96415a72731d8f3b7211dee44cefc47d44ff
Author: George Rimar <grimar@accesssoftek.com>
Date:   Fri Jan 11 12:10:12 2019 -0800

    x86/build: Specify elf_i386 linker emulation explicitly for i386 objects

    [ 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>

commit 16d4d75d8b6e5262ca65710620f421975f889555
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon Dec 17 20:42:58 2018 +0100

    drm/nouveau: Stop using drm_crtc_force_disable

    [ 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>

commit bfb59eabe2c940c6869f128200f2047d46215845
Author: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Date:   Fri Jan 4 09:56:10 2019 +0100

    drm: Auto-set allow_fb_modifiers when given modifiers at plane init

    [ 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>

commit 778c82db727adb780bbfcbc303149bd7b764194c
Author: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Date:   Sat Jan 12 13:59:13 2019 +0100

    pinctrl: meson: meson8b: add the eth_rxd2 and eth_rxd3 pins

    [ 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>

commit 1048bfd8bf67f889efd67090fdf08489a835a06b
Author: Axel Lin <axel.lin@ingics.com>
Date:   Thu Jan 10 17:26:16 2019 +0800

    regulator: act8865: Fix act8600_sudcdc_voltage_ranges setting

    [ 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>

commit e78d5e16f1d6ea80c67c0eb1631f86add4896c26
Author: Richard Guy Briggs <rgb@redhat.com>
Date:   Mon Dec 10 17:17:50 2018 -0500

    audit: hand taken context to audit_kill_trees for syscall logging

    [ 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>

commit a43ea8ca186574f871c79f05fa7d04fad173d731
Author: Mika Westerberg <mika.westerberg@linux.intel.com>
Date:   Mon Jan 7 16:09:40 2019 +0300

    PCI: pciehp: Assign ctrl->slot_ctrl before writing it to hardware

    [ 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>

commit e5d1f1c0148de0d484941a661cb2f99534be4b1f
Author: Pawe? Chmiel <pawel.mikolaj.chmiel@gmail.com>
Date:   Sat Dec 29 10:46:01 2018 -0500

    media: s5p-jpeg: Check for fmt_ver_flag when doing fmt enumeration

    [ 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>

commit 68ec6a13ef0d745d7e6f962df4f09f2b215a676e
Author: Steve Longerbeam <slongerbeam@gmail.com>
Date:   Mon Jan 14 20:10:19 2019 -0500

    media: rcar-vin: Allow independent VIN link enablement

    [ 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>

commit ebd0f3066c35bd27d3a4b224135e638eeaf70b8d
Author: Florian Westphal <fw@strlen.de>
Date:   Fri Jan 11 14:46:15 2019 +0100

    netfilter: physdev: relax br_netfilter dependency

    [ 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>

commit d7e6e93b95f2ba9f328f1976c4ada11548eb15fa
Author: Shunyong Yang <shunyong.yang@hxt-semitech.com>
Date:   Mon Jan 7 09:32:14 2019 +0800

    dmaengine: qcom_hidma: initialize tx flags in hidma_prep_dma_*

    [ 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>

commit 1bac8b82d95cfe1d43fc30236f99da224ceccc2a
Author: Shunyong Yang <shunyong.yang@hxt-semitech.com>
Date:   Mon Jan 7 09:34:02 2019 +0800

    dmaengine: qcom_hidma: assign channel cookie correctly

    [ 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>

commit 56d276b536141152bb4c6d2e58248d28296553c4
Author: Anders Roxell <anders.roxell@linaro.org>
Date:   Thu Jan 10 12:15:35 2019 +0100

    dmaengine: imx-dma: fix warning comparison of distinct pointer types

    [ 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>

commit 964065d234c7f52f8e6ab26ee96bf928bf064999
Author: Valentin Schneider <valentin.schneider@arm.com>
Date:   Wed Dec 19 18:23:15 2018 +0000

    cpu/hotplug: Mute hotplug lockdep during init

    [ 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>

commit 8376acca6f18200f68945548c59a9518c80e25e0
Author: Takeshi Kihara <takeshi.kihara.df@renesas.com>
Date:   Wed Dec 12 19:19:35 2018 +0900

    pinctrl: sh-pfc: r8a77995: Fix MOD_SEL bit numbering

    [ 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>

commit e848354f28b7bfc4419af2fcee45503282a8edbd
Author: Takeshi Kihara <takeshi.kihara.df@renesas.com>
Date:   Wed Dec 12 19:19:34 2018 +0900

    pinctrl: sh-pfc: r8a77990: Fix MOD_SEL bit numbering

    [ 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>

commit 9d7ff2ae8fd6a95b1d04a7cf67b5644df03664c7
Author: Xingyu Chen <xingyu.chen@amlogic.com>
Date:   Thu Jan 17 11:23:14 2019 +0100

    pinctrl: meson: fix G12A ao pull registers base address

    [ 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>

commit e17a340f9598595eaaaff9ed5327dc912585ed68
Author: Buland Singh <bsingh@redhat.com>
Date:   Thu Dec 20 17:35:24 2018 +0530

    hpet: Fix missing '=' character in the __setup() code of hpet_mmap_enable

    [ 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 out…
isjerryxiao pushed a commit to isjerryxiao/Amlogic_s905-kernel that referenced this issue Apr 12, 2019
@nathanchance @isjerryxiao
net: stmmac: Avoid sometimes uninitialized Clang warnings
c0a7046 
[ Upstream commit df103170854e87124ee7bdd2bca64b178e653f97 ]

When building with -Wsometimes-uninitialized, Clang warns:

drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:495:3: warning: variable 'ns' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:495:3: warning: variable 'ns' is used uninitialized whenever '&&' condition is false [-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:532:3: warning: variable 'ns' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:532:3: warning: variable 'ns' is used uninitialized whenever '&&' condition is false [-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:741:3: warning: variable 'sec_inc' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:741:3: warning: variable 'sec_inc' is used uninitialized whenever '&&' condition is false [-Wsometimes-uninitialized]

Clang is concerned with the use of stmmac_do_void_callback (which
stmmac_get_timestamp and stmmac_config_sub_second_increment wrap),
as it may fail to initialize these values if the if condition was ever
false (meaning the callbacks don't exist). It's not wrong because the
callbacks (get_timestamp and config_sub_second_increment respectively)
are the ones that initialize the variables. While it's unlikely that the
callbacks are ever going to disappear and make that condition false, we
can easily avoid this warning by zero initialize the variables.

Link: ClangBuiltLinux/linux#384
Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
isjerryxiao pushed a commit to isjerryxiao/Amlogic_s905-kernel that referenced this issue Apr 12, 2019
@nathanchance @isjerryxiao
net: stmmac: Avoid one more sometimes uninitialized Clang warning
b9e24d4 
[ 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: ClangBuiltLinux/linux#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>
Staars pushed a commit to Staars/linux-stable that referenced this issue May 11, 2019
@nathanchance @Staars
net: stmmac: Avoid sometimes uninitialized Clang warnings
fa07f36 
[ Upstream commit df10317 ]

When building with -Wsometimes-uninitialized, Clang warns:

drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:495:3: warning: variable 'ns' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:495:3: warning: variable 'ns' is used uninitialized whenever '&&' condition is false [-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:532:3: warning: variable 'ns' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:532:3: warning: variable 'ns' is used uninitialized whenever '&&' condition is false [-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:741:3: warning: variable 'sec_inc' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:741:3: warning: variable 'sec_inc' is used uninitialized whenever '&&' condition is false [-Wsometimes-uninitialized]

Clang is concerned with the use of stmmac_do_void_callback (which
stmmac_get_timestamp and stmmac_config_sub_second_increment wrap),
as it may fail to initialize these values if the if condition was ever
false (meaning the callbacks don't exist). It's not wrong because the
callbacks (get_timestamp and config_sub_second_increment respectively)
are the ones that initialize the variables. While it's unlikely that the
callbacks are ever going to disappear and make that condition false, we
can easily avoid this warning by zero initialize the variables.

Link: ClangBuiltLinux/linux#384
Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Staars pushed a commit to Staars/linux-stable that referenced this issue May 11, 2019
@nathanchance @Staars
net: stmmac: Avoid one more sometimes uninitialized Clang warning
b6576a5 
[ Upstream commit 1f5d861 ]

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: ClangBuiltLinux/linux#384
Fixes: df10317 ("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>
jason77-wang pushed a commit to jason77-wang/oem that referenced this issue Jun 1, 2019
@nathanchance @smb49
net: stmmac: Avoid sometimes uninitialized Clang warnings
b66c949 
BugLink: https://bugs.launchpad.net/bugs/1828410

[ Upstream commit df103170854e87124ee7bdd2bca64b178e653f97 ]

When building with -Wsometimes-uninitialized, Clang warns:

drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:495:3: warning: variable 'ns' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:495:3: warning: variable 'ns' is used uninitialized whenever '&&' condition is false [-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:532:3: warning: variable 'ns' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:532:3: warning: variable 'ns' is used uninitialized whenever '&&' condition is false [-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:741:3: warning: variable 'sec_inc' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:741:3: warning: variable 'sec_inc' is used uninitialized whenever '&&' condition is false [-Wsometimes-uninitialized]

Clang is concerned with the use of stmmac_do_void_callback (which
stmmac_get_timestamp and stmmac_config_sub_second_increment wrap),
as it may fail to initialize these values if the if condition was ever
false (meaning the callbacks don't exist). It's not wrong because the
callbacks (get_timestamp and config_sub_second_increment respectively)
are the ones that initialize the variables. While it's unlikely that the
callbacks are ever going to disappear and make that condition false, we
can easily avoid this warning by zero initialize the variables.

Link: ClangBuiltLinux/linux#384
Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
jason77-wang pushed a commit to jason77-wang/oem that referenced this issue Jun 1, 2019
@nathanchance @smb49
net: stmmac: Avoid one more sometimes uninitialized Clang warning
ae36935 
BugLink: https://bugs.launchpad.net/bugs/1828410

[ 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: ClangBuiltLinux/linux#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>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
mseaster-wr pushed a commit to WindRiver-Labs/linux-yocto-4.18 that referenced this issue Jun 5, 2019
@nathanchance @paulgortmaker
net: stmmac: Avoid sometimes uninitialized Clang warnings
f5f0dda 
commit df103170854e87124ee7bdd2bca64b178e653f97 upstream.

When building with -Wsometimes-uninitialized, Clang warns:

drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:495:3: warning: variable 'ns' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:495:3: warning: variable 'ns' is used uninitialized whenever '&&' condition is false [-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:532:3: warning: variable 'ns' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:532:3: warning: variable 'ns' is used uninitialized whenever '&&' condition is false [-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:741:3: warning: variable 'sec_inc' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:741:3: warning: variable 'sec_inc' is used uninitialized whenever '&&' condition is false [-Wsometimes-uninitialized]

Clang is concerned with the use of stmmac_do_void_callback (which
stmmac_get_timestamp and stmmac_config_sub_second_increment wrap),
as it may fail to initialize these values if the if condition was ever
false (meaning the callbacks don't exist). It's not wrong because the
callbacks (get_timestamp and config_sub_second_increment respectively)
are the ones that initialize the variables. While it's unlikely that the
callbacks are ever going to disappear and make that condition false, we
can easily avoid this warning by zero initialize the variables.

Link: ClangBuiltLinux/linux#384
Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
mseaster-wr pushed a commit to WindRiver-Labs/linux-yocto-4.18 that referenced this issue Jun 5, 2019
@nathanchance @paulgortmaker
net: stmmac: Avoid one more sometimes uninitialized Clang warning
1dca461 
commit 1f5d861f7fefa971b2c6e766f77932c86419a319 upstream.

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: ClangBuiltLinux/linux#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: Paul Gortmaker <paul.gortmaker@windriver.com>
nathanchance pushed a commit that referenced this issue Jan 25, 2020
@asverdlin
ARM: 8950/1: ftrace/recordmcount: filter relocation types
927d780 
Scenario 1, ARMv7
=================

If code in arch/arm/kernel/ftrace.c would operate on mcount() pointer
the following may be generated:

00000230 <prealloc_fixed_plts>:
 230:   b5f8            push    {r3, r4, r5, r6, r7, lr}
 232:   b500            push    {lr}
 234:   f7ff fffe       bl      0 <__gnu_mcount_nc>
                        234: R_ARM_THM_CALL     __gnu_mcount_nc
 238:   f240 0600       movw    r6, #0
                        238: R_ARM_THM_MOVW_ABS_NC      __gnu_mcount_nc
 23c:   f8d0 1180       ldr.w   r1, [r0, #384]  ; 0x180

FTRACE currently is not able to deal with it:

WARNING: CPU: 0 PID: 0 at .../kernel/trace/ftrace.c:1979 ftrace_bug+0x1ad/0x230()
...
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.116-... #1
...
[<c0314e3d>] (unwind_backtrace) from [<c03115e9>] (show_stack+0x11/0x14)
[<c03115e9>] (show_stack) from [<c051a7f1>] (dump_stack+0x81/0xa8)
[<c051a7f1>] (dump_stack) from [<c0321c5d>] (warn_slowpath_common+0x69/0x90)
[<c0321c5d>] (warn_slowpath_common) from [<c0321cf3>] (warn_slowpath_null+0x17/0x1c)
[<c0321cf3>] (warn_slowpath_null) from [<c038ee9d>] (ftrace_bug+0x1ad/0x230)
[<c038ee9d>] (ftrace_bug) from [<c038f1f9>] (ftrace_process_locs+0x27d/0x444)
[<c038f1f9>] (ftrace_process_locs) from [<c08915bd>] (ftrace_init+0x91/0xe8)
[<c08915bd>] (ftrace_init) from [<c0885a67>] (start_kernel+0x34b/0x358)
[<c0885a67>] (start_kernel) from [<00308095>] (0x308095)
---[ end trace cb88537fdc8fa200 ]---
ftrace failed to modify [<c031266c>] prealloc_fixed_plts+0x8/0x60
 actual: 44:f2:e1:36
ftrace record flags: 0
 (0)   expected tramp: c03143e9

Scenario 2, ARMv4T
==================

ftrace: allocating 14435 entries in 43 pages
------------[ cut here ]------------
WARNING: CPU: 0 PID: 0 at kernel/trace/ftrace.c:2029 ftrace_bug+0x204/0x310
CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.5 #1
Hardware name: Cirrus Logic EDB9302 Evaluation Board
[<c0010a24>] (unwind_backtrace) from [<c000ecb0>] (show_stack+0x20/0x2c)
[<c000ecb0>] (show_stack) from [<c03c72e8>] (dump_stack+0x20/0x30)
[<c03c72e8>] (dump_stack) from [<c0021c18>] (__warn+0xdc/0x104)
[<c0021c18>] (__warn) from [<c0021d7c>] (warn_slowpath_null+0x4c/0x5c)
[<c0021d7c>] (warn_slowpath_null) from [<c0095360>] (ftrace_bug+0x204/0x310)
[<c0095360>] (ftrace_bug) from [<c04dabac>] (ftrace_init+0x3b4/0x4d4)
[<c04dabac>] (ftrace_init) from [<c04cef4c>] (start_kernel+0x20c/0x410)
[<c04cef4c>] (start_kernel) from [<00000000>] (  (null))
---[ end trace 0506a2f5dae6b341 ]---
ftrace failed to modify
[<c000c350>] perf_trace_sys_exit+0x5c/0xe8
 actual:   1e:ff:2f:e1
Initializing ftrace call sites
ftrace record flags: 0
 (0)
 expected tramp: c000fb24

The analysis for this problem has been already performed previously,
refer to the link below.

Fix the above problems by allowing only selected reloc types in
__mcount_loc. The list itself comes from the legacy recordmcount.pl
script.

Link: https://lore.kernel.org/lkml/56961010.6000806@pengutronix.de/
Cc: stable@vger.kernel.org
Fixes: ed60453 ("ARM: 6511/1: ftrace: add ARM support for C version of recordmcount")
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
itisFarzin pushed a commit to itisFarzin-Phone/kernel_daria_mt6877 that referenced this issue Apr 29, 2024
@nathanchance @FloraFu-mediatek
UPSTREAM: net: stmmac: Avoid sometimes uninitialized Clang warnings
a4f302b 
When building with -Wsometimes-uninitialized, Clang warns:

drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:495:3: warning: variable 'ns' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:495:3: warning: variable 'ns' is used uninitialized whenever '&&' condition is false [-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:532:3: warning: variable 'ns' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:532:3: warning: variable 'ns' is used uninitialized whenever '&&' condition is false [-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:741:3: warning: variable 'sec_inc' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:741:3: warning: variable 'sec_inc' is used uninitialized whenever '&&' condition is false [-Wsometimes-uninitialized]

Clang is concerned with the use of stmmac_do_void_callback (which
stmmac_get_timestamp and stmmac_config_sub_second_increment wrap),
as it may fail to initialize these values if the if condition was ever
false (meaning the callbacks don't exist). It's not wrong because the
callbacks (get_timestamp and config_sub_second_increment respectively)
are the ones that initialize the variables. While it's unlikely that the
callbacks are ever going to disappear and make that condition false, we
can easily avoid this warning by zero initialize the variables.

Link: ClangBuiltLinux/linux#384
Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit df103170854e87124ee7bdd2bca64b178e653f97)
Signed-off-by: Biao Huang <biao.huang@mediatek.com>
Change-Id: Ibc54ee50c708c9b7ef7e3b878b4f30a6273580ff
CR-Id: AUTO00036953
itisFarzin pushed a commit to itisFarzin-Phone/kernel_daria_mt6877 that referenced this issue Apr 29, 2024
@nathanchance @FloraFu-mediatek
UPSTREAM: net: stmmac: Avoid one more sometimes uninitialized Clang w…
5346e6c 
…arning

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: ClangBuiltLinux/linux#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>
(cherry picked from commit 1f5d861f7fefa971b2c6e766f77932c86419a319)
Signed-off-by: Biao Huang <biao.huang@mediatek.com>
Change-Id: I7fa876c1d4e8c0b6aa116a347c7cbe7f76116ec7
CR-Id: AUTO00036953
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@nathanchance nathanchance

Labels
-Wsometimes-uninitialized [ARCH] arm32 This bug impacts ARCH=arm [BUG] linux A bug that should be fixed in the mainline kernel. [FIXED][LINUX] 5.1 This bug was fixed in Linux 5.1
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@nickdesaulniers @nathanchance