Re: [PATCH 4.4 000/124] 4.4.146-stable review
On Sat, Aug 04, 2018 at 10:59:49AM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.146 release. > There are 124 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Mon Aug 6 08:26:39 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.146-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.4.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled with -Werror, and installed onto my Pixel 2 XL. No issues noticed in dmesg or general usage. Thanks! Nathan
Re: [PATCH 4.9 00/32] 4.9.118-stable review
On Sat, Aug 04, 2018 at 11:00:50AM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.118 release. > There are 32 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Mon Aug 6 08:26:35 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.118-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.9.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled with -Werror, and installed onto my OnePlus 6. No issues noticed in dmesg or general usage. Thanks! Nathan
Re: [PATCH 4.9 00/17] 4.9.119-stable review
On Tue, Aug 07, 2018 at 08:51:36PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.119 release. > There are 17 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Aug 9 17:23:30 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.119-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.9.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled with -Werror, and installed onto my OnePlus 6. No initial issues noticed in dmesg or general usage. Thanks! Nathan
Re: [PATCH 4.4 00/12] 4.4.147-stable review
On Tue, Aug 07, 2018 at 08:52:04PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.147 release. > There are 12 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Aug 9 17:23:34 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.147-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.4.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled with -Werror, and installed onto my Pixel 2 XL. No initial issues noticed in dmesg or general usage. Thanks! Nathan
Re: [PATCH 3.18 00/85] 3.18.118-stable review
On Tue, Aug 07, 2018 at 08:51:02PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.118 release. > There are 85 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Aug 9 17:23:43 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.118-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-3.18.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled with -Werror, and installed onto my Pixel XL. No initial issues noticed in dmesg or general usage. Thanks! Nathan
Re: [PATCH 4.9 00/39] 4.9.110-stable review
On Sun, Jun 24, 2018 at 11:23:47PM +0800, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.110 release. > There are 39 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Tue Jun 26 15:23:25 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.110-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.9.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled with -Werror, and installed onto my OnePlus 6. No initial issues noticed in dmesg or general usage. Thanks! Nathan
Re: [PATCH] Trivial numbering change in comments.
On Tue, Aug 28, 2018 at 04:08:18PM -0400, Ray Clinton wrote:
> I'm trying to get my feet wet in kernel dev and while working on a patch
> I noticed in a lengthy comment block that the number "2" was skipped
> in a description of the steps of a protocol. This patch is simply correcting
> this. This is for 4.18.0.
>
> It is a very trivial patch, but this is my first actual try at one and
> thought I
> might start out small (and I don't think you can get smaller than a single
> character change). Any and all advice (about this patch, email, or
> anything else) is very welcome.
>
> Thanks so much!
> Ray
>
> Signed-off-by: Ray Clinton
> ---
> drivers/staging/android/uapi/vsoc_shm.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/android/uapi/vsoc_shm.h
> b/drivers/staging/android/uapi/vsoc_shm.h
> index 6291fb2..0301172 100644
> --- a/drivers/staging/android/uapi/vsoc_shm.h
> +++ b/drivers/staging/android/uapi/vsoc_shm.h
> @@ -92,7 +92,7 @@ struct fd_scoped_permission_arg {
> *The transmitter can choose any appropriate hashing algorithm, including
> *hash = futex_offset & ((1 << num_nodes_lg2) - 1)
> *
> - * 3. The transmitter should atomically compare and swap futex_offset with 0
> + * 2. The transmitter should atomically compare and swap futex_offset with 0
> *at hash. There are 3 possible outcomes
> * a. The swap fails because the futex_offset is already in the table.
> * The transmitter should stop.
> --
> 2.7.4
Hi Ray,
Welcome to Linux kernel development and good first patch. Just a few
words of advice for any future patches that you submit!
Make sure to include what subsystem you are modifying in the commit
title. You can see examples by using 'git log --online '; for
this subsystem, it's usually "staging: android: vsoc:", making this
patch's title "staging: android: vsoc: Trivial numbering change in comments".
I'd recommend keeping author details (such as your experience and other
info) in-between the '---' and the file names modified in the patch so
that they can be read by the maintainers/reviewers but not added to the
commit message by 'git am'. This is also helpful for adding comments
like what changed between versions of the patch or maybe something like
"I'm not sure this change is correct, it could also be done via ,
I'd like some review".
Small nits in the grand scheme of things but they'll come in handy as
you develop more and more complex patches and series.
Reviewed-by: Nathan Chancellor
Cheers!
Nathan
Re: [PATCH 4.9 00/25] 4.9.123-stable review
On Tue, Aug 21, 2018 at 08:21:14AM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.123 release. > There are 25 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Aug 23 05:51:15 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.123-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.9.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled with -Werror, and installed onto my OnePlus 6. No initial issues noticed in dmesg or general usage. Thanks! Nathan
Re: [PATCH 4.9 000/130] 4.9.124-stable review
On Thu, Aug 23, 2018 at 09:51:56AM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.124 release. > There are 130 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sat Aug 25 07:48:45 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.124-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.9.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled with -Werror, and installed onto my OnePlus 6. No initial issues noticed in dmesg or general usage. Thanks! Nathan
Re: [PATCH 3.18 00/56] 3.18.120-stable review
On Sun, Aug 26, 2018 at 08:44:21AM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.120 release. > There are 56 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Tue Aug 28 06:42:19 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.120-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-3.18.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled with -Werror, and installed onto my Pixel XL. No initial issues noticed in dmesg or general usage. Thanks! Nathan
Re: [PATCH 3.18 00/27] 3.18.117-stable review
On Fri, Jul 27, 2018 at 12:26:37PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.117 release. > There are 27 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun Jul 29 10:26:38 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.117-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-3.18.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled with -Werror, and installed onto my Pixel XL. No initial issues noticed in dmesg or general usage. Thanks! Nathan
Re: [PATCH 4.4 00/23] 4.4.145-stable review
On Fri, Jul 27, 2018 at 12:09:01PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.145 release. > There are 23 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun Jul 29 10:08:37 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.145-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.4.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled with -Werror, and installed onto my Pixel 2 XL. No initial issues noticed in dmesg or general usage. Thanks! Nathan
Re: [PATCH 4.9 00/33] 4.9.116-stable review
On Fri, Jul 27, 2018 at 12:08:41PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.116 release. > There are 33 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun Jul 29 10:08:17 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.116-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.9.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled with -Werror, and installed onto my OnePlus 6. No initial issues noticed in dmesg or general usage. Thanks! Nathan
Re: [PATCH] kernel.h: Disable -Wreturn-stack-address for _THIS_IP_
On Mon, Jul 30, 2018 at 10:06:20AM -0700, Nick Desaulniers wrote:
> Starting with Clang-7.0, _THIS_IP_ generates -Wreturn-stack-address
> warnings for almost every translation unit. In general, I'd prefer to
> leave this on (returning the address of a stack allocated variable is in
> general a bad idea) and disable it only at whitelisted call sites.
>
> We can't do something like:
> #pragma clang diagnostic push
> #pragma clang diagnostic ignored "-Wreturn-stack-address"
>
> #pragma clang diagnostic pop
>
> in a GNU Statement Expression or macro, hence we use _Pragma, which is
> its raison d'être: https://gcc.gnu.org/onlinedocs/cpp/Pragmas.html
>
> Cc: sta...@vger.kernel.org # 4.17, 4.14, 4.9, 4.4
> Signed-off-by: Nick Desaulniers
> ---
> include/linux/kernel.h | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index 941dc0a5a877..5906f5727f90 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -168,7 +168,15 @@
>
>
> #define _RET_IP_ (unsigned long)__builtin_return_address(0)
> -#define _THIS_IP_ ({ __label__ __here; __here: (unsigned long)&&__here; })
> +#define _THIS_IP_ ( \
> +{\
> + _Pragma("clang diagnostic push")\
> + _Pragma("clang diagnostic ignored \"-Wreturn-stack-address\"") \
> + __label__ __here; \
> +__here: (unsigned long)&&__here; \
> + _Pragma("clang diagnostic pop") \
> +}\
> +)
>
> #ifdef CONFIG_LBDAF
> # include
> --
> 2.18.0.233.g985f88cf7e-goog
>
This generates a ton of warnings with GCC:
In file included from ./include/linux/spinlock.h:58,
from ./include/linux/mmzone.h:8,
from ./include/linux/gfp.h:6,
from ./include/linux/slab.h:15,
from ./include/linux/crypto.h:24,
from arch/x86/kernel/asm-offsets.c:9:
./include/linux/bottom_half.h: In function ‘local_bh_disable’:
./include/linux/bottom_half.h:19: error: ignoring #pragma clang diagnostic
[-Werror=unknown-pragmas]
__local_bh_disable_ip(_THIS_IP_, SOFTIRQ_DISABLE_OFFSET);
./include/linux/bottom_half.h:19: error: ignoring #pragma clang diagnostic
[-Werror=unknown-pragmas]
./include/linux/bottom_half.h:19: error: ignoring #pragma clang diagnostic
[-Werror=unknown-pragmas]
./include/linux/bottom_half.h: In function ‘local_bh_enable’:
./include/linux/bottom_half.h:32: error: ignoring #pragma clang diagnostic
[-Werror=unknown-pragmas]
__local_bh_enable_ip(_THIS_IP_, SOFTIRQ_DISABLE_OFFSET);
./include/linux/bottom_half.h:32: error: ignoring #pragma clang diagnostic
[-Werror=unknown-pragmas]
./include/linux/bottom_half.h:32: error: ignoring #pragma clang diagnostic
[-Werror=unknown-pragmas]
cc1: all warnings being treated as errors
make[1]: *** [Kbuild:56: arch/x86/kernel/asm-offsets.s] Error 1
make: *** [Makefile:1081: prepare0] Error 2
A proper solution is probably going to involve what was done for the
-Wattribute-alias warnings from GCC 8 in commits 8793bb7f4a9d ("kbuild:
add macro for controlling warnings to linux/compiler.h") and
bee20031772a ("disable -Wattribute-alias warning for SYSCALL_DEFINEx()")
I'll take a look at it in a bit unless someone beats me to it.
Thanks!
Nathan
Re: [PATCH] kernel.h: Disable -Wreturn-stack-address for _THIS_IP_
On Mon, Jul 30, 2018 at 12:48:06PM -0700, Nick Desaulniers wrote:
> On Mon, Jul 30, 2018 at 11:39 AM Nathan Chancellor
> wrote:
> >
> > On Mon, Jul 30, 2018 at 10:06:20AM -0700, Nick Desaulniers wrote:
> > > Starting with Clang-7.0, _THIS_IP_ generates -Wreturn-stack-address
> > > warnings for almost every translation unit. In general, I'd prefer to
> > > leave this on (returning the address of a stack allocated variable is in
> > > general a bad idea) and disable it only at whitelisted call sites.
> > >
> > > We can't do something like:
> > > #pragma clang diagnostic push
> > > #pragma clang diagnostic ignored "-Wreturn-stack-address"
> > >
> > > #pragma clang diagnostic pop
> > >
> > > in a GNU Statement Expression or macro, hence we use _Pragma, which is
> > > its raison d'être: https://gcc.gnu.org/onlinedocs/cpp/Pragmas.html
> > >
> > > Cc: sta...@vger.kernel.org # 4.17, 4.14, 4.9, 4.4
> > > Signed-off-by: Nick Desaulniers
> > > ---
> > > include/linux/kernel.h | 10 +-
> > > 1 file changed, 9 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> > > index 941dc0a5a877..5906f5727f90 100644
> > > --- a/include/linux/kernel.h
> > > +++ b/include/linux/kernel.h
> > > @@ -168,7 +168,15 @@
> > >
> > >
> > > #define _RET_IP_ (unsigned long)__builtin_return_address(0)
> > > -#define _THIS_IP_ ({ __label__ __here; __here: (unsigned long)&&__here;
> > > })
> > > +#define _THIS_IP_ ( \
> > > +{\
> > > + _Pragma("clang diagnostic push")\
> > > + _Pragma("clang diagnostic ignored \"-Wreturn-stack-address\"") \
> > > + __label__ __here; \
> > > +__here: (unsigned long)&&__here; \
> > > + _Pragma("clang diagnostic pop") \
> > > +}\
> > > +)
> > >
> > > #ifdef CONFIG_LBDAF
> > > # include
> > > --
> > > 2.18.0.233.g985f88cf7e-goog
> > >
> >
> > This generates a ton of warnings with GCC:
> >
> > In file included from ./include/linux/spinlock.h:58,
> > from ./include/linux/mmzone.h:8,
> > from ./include/linux/gfp.h:6,
> > from ./include/linux/slab.h:15,
> > from ./include/linux/crypto.h:24,
> > from arch/x86/kernel/asm-offsets.c:9:
> > ./include/linux/bottom_half.h: In function ‘local_bh_disable’:
> > ./include/linux/bottom_half.h:19: error: ignoring #pragma clang diagnostic
> > [-Werror=unknown-pragmas]
> > __local_bh_disable_ip(_THIS_IP_, SOFTIRQ_DISABLE_OFFSET);
> >
> > ./include/linux/bottom_half.h:19: error: ignoring #pragma clang diagnostic
> > [-Werror=unknown-pragmas]
> > ./include/linux/bottom_half.h:19: error: ignoring #pragma clang diagnostic
> > [-Werror=unknown-pragmas]
> > ./include/linux/bottom_half.h: In function ‘local_bh_enable’:
> > ./include/linux/bottom_half.h:32: error: ignoring #pragma clang diagnostic
> > [-Werror=unknown-pragmas]
> > __local_bh_enable_ip(_THIS_IP_, SOFTIRQ_DISABLE_OFFSET);
> >
> > ./include/linux/bottom_half.h:32: error: ignoring #pragma clang diagnostic
> > [-Werror=unknown-pragmas]
> > ./include/linux/bottom_half.h:32: error: ignoring #pragma clang diagnostic
> > [-Werror=unknown-pragmas]
> > cc1: all warnings being treated as errors
> > make[1]: *** [Kbuild:56: arch/x86/kernel/asm-offsets.s] Error 1
> > make: *** [Makefile:1081: prepare0] Error 2
>
> Ah, good catch. I thought I had tested locally with gcc-8, but it
> seems that it was likely only godbolt. I do see the errors locally
> when building with gcc-8.
>
> >
> > A proper solution is probably going to involve what was done for the
> > -Wattribute-alias warnings from GCC 8 in commits 8793bb7f4a9d ("kbuild:
> > add macro for controlling warnings to linux/compiler.h") and
> > bee20031772a ("disable -Wattribute-alias warning for SYSCALL_DEFINEx()")
> >
> > I'll take a look at it in a bit unless someone beats me to it.
>
> I'll fix this up, triple check with gcc-8, and attribute you in the
> Suggested-by tag. Thank you for verifying.
> --
> Thanks,
> ~Nick Desaulniers
I forgot to mention there is a similar macro that will need this same
fix in arch/arm64/include/asm/processor.h (current_text_addr), if you
want to tackle it in v2. Do CC me on the next series so that I can test,
thank you for doing this!
Cheers,
Nathan
Re: [PATCH 3.18 00/29] 3.18.116-stable review
On Fri, Jul 20, 2018 at 02:10:55PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.116 release. > There are 29 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun Jul 22 11:51:47 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.116-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-3.18.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled with -Werror, and installed onto my Pixel XL. No initial issues noticed in dmesg or general usage. Thanks! Nathan
Re: [PATCH 4.4 00/31] 4.4.143-stable review
On Fri, Jul 20, 2018 at 02:13:30PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.143 release. > There are 31 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun Jul 22 12:13:28 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.143-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.4.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled with -Werror, and installed onto my Pixel 2 XL. No initial issues noticed in dmesg or general usage. Thanks! Nathan
Re: [PATCH 4.9 00/66] 4.9.114-stable review
On Fri, Jul 20, 2018 at 02:13:17PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.114 release. > There are 66 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun Jul 22 12:13:47 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.114-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.9.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled with -Werror, and installed onto my OnePlus 6. No initial issues noticed in dmesg or general usage. Thanks! Nathan
Re: [PATCH v2 2/2] kernel.h: Disable -Wreturn-stack-address for _THIS_IP_
On Mon, Jul 30, 2018 at 02:34:12PM -0700, Nick Desaulniers wrote:
> Starting with Clang-7.0, _THIS_IP_ generates -Wreturn-stack-address
> warnings for almost every translation unit. In general, I'd prefer to
> leave this on (returning the address of a stack allocated variable is in
> general a bad idea) and disable it only at whitelisted call sites.
>
> We can't do something like:
> #pragma clang diagnostic push
> #pragma clang diagnostic ignored "-Wreturn-stack-address"
>
> #pragma clang diagnostic pop
>
> in a GNU Statement Expression or macro, hence we use _Pragma, which is
> its raison d'être: https://gcc.gnu.org/onlinedocs/cpp/Pragmas.html
>
> We also can't use compiler specific pragma's without triggering
> -Werror=unknown-pragmas in other compilers, so use __diag.
>
> Cc: sta...@vger.kernel.org # 4.17, 4.14, 4.9, 4.4
> Suggested-by: Nathan Chancellor
> Signed-off-by: Nick Desaulniers
Tested-and-reviewed-by: Nathan Chancellor
> ---
> include/linux/kernel.h | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index 941dc0a5a877..909bb771c0ca 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -168,7 +168,15 @@
>
>
> #define _RET_IP_ (unsigned long)__builtin_return_address(0)
> -#define _THIS_IP_ ({ __label__ __here; __here: (unsigned long)&&__here; })
> +#define _THIS_IP_ ( \
> +{\
> + __label__ __here; \
> + __diag_push() \
> + __diag_ignore(CLANG, 7, "-Wreturn-stack-address", "") \
> +__here: (unsigned long)&&__here; \
> + __diag_pop()\
> +}\
> +)
>
> #ifdef CONFIG_LBDAF
> # include
> --
> 2.18.0.345.g5c9ce644c3-goog
>
Re: [PATCH v2 1/2] compiler-clang.h: Add CLANG_VERSION and __diag macros
On Mon, Jul 30, 2018 at 02:34:11PM -0700, Nick Desaulniers wrote:
> These are needed for doing proper version checks, though feature
> detection via __has_attribute, __has_builtin, and __has_feature should
> be preferred, see:
> https://clang.llvm.org/docs/LanguageExtensions.html#feature-checking-macros
>
> Also adds __diag support, for generating compiler version specific
> _Pragma()'s.
>
> __diag support based on commit 8793bb7f4a9d ("kbuild: add macro for
> controlling warnings to linux/compiler.h")
>
> Cc: sta...@vger.kernel.org # 4.17, 4.14, 4.9, 4.4
> Suggested-by: Nathan Chancellor
> Signed-off-by: Nick Desaulniers
Tested-and-reviewed-by: Nathan Chancellor
> ---
> include/linux/compiler-clang.h | 19 +++
> include/linux/compiler_types.h | 4
> 2 files changed, 23 insertions(+)
>
> diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
> index 7087446c24c8..9442e07a361e 100644
> --- a/include/linux/compiler-clang.h
> +++ b/include/linux/compiler-clang.h
> @@ -7,6 +7,10 @@
> * for Clang compiler
> */
>
> +#define CLANG_VERSION (__clang_major__ * 1 \
> ++ __clang_minor__ * 100 \
> ++ __clang_patchlevel__)
> +
I know this was done to be consistent with GCC_VERSION but certain
toolchains may set the patch level to the SVN revision (at least that's
what it appears to be) like AOSP's clang-4053586, which would make
CLANG_VERSION 350080. For this particular warning, it doesn't matter
since Clang has supported it since 2011 and Clang 5.0 isn't supported
in this tree anyways but maybe relying on just __clang_major__ below
is more ideal.
Other than that, patch functions just as it should.
> #ifdef uninitialized_var
> #undef uninitialized_var
> #define uninitialized_var(x) x = *(&(x))
> @@ -46,3 +50,18 @@
> __has_builtin(__builtin_sub_overflow)
> #define COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW 1
> #endif
> +
> +#define __diag_str1(s) #s
> +#define __diag_str(s) __diag_str1(s)
> +#define __diag(s) _Pragma(__diag_str(clang diagnostic s))
> +#define __diag_CLANG_ignore ignored
> +#define __diag_CLANG_warn warning
> +#define __diag_CLANG_error error
> +#define __diag_CLANG(version, severity, s) \
> + __diag_CLANG_ ## version(__diag_CLANG_ ## severity s)
> +
> +#if CLANG_VERSION >= 7
> +#define __diag_CLANG_7(s) __diag(s)
> +#else
> +#define __diag_CLANG_7(s)
> +#endif
> diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
> index a8ba6b04152c..a04e6bd63476 100644
> --- a/include/linux/compiler_types.h
> +++ b/include/linux/compiler_types.h
> @@ -279,6 +279,10 @@ struct ftrace_likely_data {
> #define __diag_GCC(version, severity, string)
> #endif
>
> +#ifndef __diag_CLANG
> +#define __diag_CLANG(version, severity, string)
> +#endif
> +
> #define __diag_push()__diag(push)
> #define __diag_pop() __diag(pop)
>
> --
> 2.18.0.345.g5c9ce644c3-goog
>
Re: [PATCH v2 2/2] kernel.h: Disable -Wreturn-stack-address for _THIS_IP_
On Tue, Jul 31, 2018 at 09:48:57AM -0700, Nick Desaulniers wrote:
> Does anyone understand this error? The code looks just fine to me,
> and the source file doesn't conflict with any of the macros I've added
> (certainly not in any way that could cause an indentation error as
> reported here).
Unfortunately, I've been trying to work through it this morning and I
can't understand it either. lock_map_acquire_read's defintion does
include _THIS_IP_ and adding curly braces to the if statement fixes it
but that doesn't explain why it's happening.
Maybe this is a GCC bug/issue?
Cheers,
Nathan
> On Tue, Jul 31, 2018 at 3:27 AM kbuild test robot wrote:
> >
> > Hi Nick,
> >
> > Thank you for the patch! Perhaps something to improve:
> >
> > [auto build test WARNING on linus/master]
> > [also build test WARNING on v4.18-rc7 next-20180727]
> > [if your patch is applied to the wrong git tree, please drop us a note to
> > help improve the system]
> >
> > url:
> > https://github.com/0day-ci/linux/commits/Nick-Desaulniers/compiler-clang-h-Add-CLANG_VERSION-and-__diag-macros/20180731-161932
> > config: x86_64-fedora-25 (attached as .config)
> > compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
> > reproduce:
> > # save the attached .config to linux build tree
> > make ARCH=x86_64
> >
> > All warnings (new ones prefixed by >>):
> >
> >drivers/net//wireless/intel/iwlwifi/iwl-trans.c: In function
> > 'iwl_trans_send_cmd':
> > >> drivers/net//wireless/intel/iwlwifi/iwl-trans.c:137:2: warning: this
> > >> 'if' clause does not guard... [-Wmisleading-indentation]
> > if (!(cmd->flags & CMD_ASYNC))
> > ^~
> >drivers/net//wireless/intel/iwlwifi/iwl-trans.c:138:1: note: ...this
> > statement, but the latter is misleadingly indented as if it were guarded by
> > the 'if'
> > lock_map_acquire_read(&trans->sync_cmd_lockdep_map);
> > ^ ~
> >
> > vim +/if +137 drivers/net//wireless/intel/iwlwifi/iwl-trans.c
> >
> > 92fe8343 Emmanuel Grumbach 2015-12-01 116
> > 92fe8343 Emmanuel Grumbach 2015-12-01 117 int iwl_trans_send_cmd(struct
> > iwl_trans *trans, struct iwl_host_cmd *cmd)
> > 92fe8343 Emmanuel Grumbach 2015-12-01 118 {
> > 92fe8343 Emmanuel Grumbach 2015-12-01 119 int ret;
> > 92fe8343 Emmanuel Grumbach 2015-12-01 120
> > 92fe8343 Emmanuel Grumbach 2015-12-01 121 if (unlikely(!(cmd->flags &
> > CMD_SEND_IN_RFKILL) &&
> > 326477e4 Johannes Berg 2017-04-25 122
> > test_bit(STATUS_RFKILL_OPMODE, &trans->status)))
> > 92fe8343 Emmanuel Grumbach 2015-12-01 123 return -ERFKILL;
> > 92fe8343 Emmanuel Grumbach 2015-12-01 124
> > 92fe8343 Emmanuel Grumbach 2015-12-01 125 if
> > (unlikely(test_bit(STATUS_FW_ERROR, &trans->status)))
> > 92fe8343 Emmanuel Grumbach 2015-12-01 126 return -EIO;
> > 92fe8343 Emmanuel Grumbach 2015-12-01 127
> > 92fe8343 Emmanuel Grumbach 2015-12-01 128 if (unlikely(trans->state
> > != IWL_TRANS_FW_ALIVE)) {
> > 92fe8343 Emmanuel Grumbach 2015-12-01 129 IWL_ERR(trans, "%s
> > bad state = %d\n", __func__, trans->state);
> > 92fe8343 Emmanuel Grumbach 2015-12-01 130 return -EIO;
> > 92fe8343 Emmanuel Grumbach 2015-12-01 131 }
> > 92fe8343 Emmanuel Grumbach 2015-12-01 132
> > 92fe8343 Emmanuel Grumbach 2015-12-01 133 if (WARN_ON((cmd->flags &
> > CMD_WANT_ASYNC_CALLBACK) &&
> > 92fe8343 Emmanuel Grumbach 2015-12-01 134 !(cmd->flags &
> > CMD_ASYNC)))
> > 92fe8343 Emmanuel Grumbach 2015-12-01 135 return -EINVAL;
> > 92fe8343 Emmanuel Grumbach 2015-12-01 136
> > 92fe8343 Emmanuel Grumbach 2015-12-01 @137 if (!(cmd->flags &
> > CMD_ASYNC))
> > 92fe8343 Emmanuel Grumbach 2015-12-01 138
> > lock_map_acquire_read(&trans->sync_cmd_lockdep_map);
> > 92fe8343 Emmanuel Grumbach 2015-12-01 139
> > 5b88792c Sara Sharon 2016-08-15 140 if (trans->wide_cmd_header
> > && !iwl_cmd_groupid(cmd->id))
> > 5b88792c Sara Sharon 2016-08-15 141 cmd->id =
> > DEF_ID(cmd->id);
> > 5b88792c Sara Sharon 2016-08-15 142
> > 92fe8343 Emmanuel Grumbach 2015-12-01 143 ret =
> > trans->ops->send_cmd(trans, cmd);
> > 92fe8343 Emmanuel Grumbach 2015-12-01 144
> > 92fe8343 Emmanuel Grumbach 2015-12-01 145 if (!(cmd->flags &
> > CMD_ASYNC))
> > 92fe8343 Emmanuel Grumbach 2015-12-01 146
> > lock_map_release(&trans->sync_cmd_lockdep_map);
> > 92fe8343 Emmanuel Grumbach 2015-12-01 147
> > 0ec971fd Johannes Berg 2017-04-10 148 if (WARN_ON((cmd->flags &
> > CMD_WANT_SKB) && !ret && !cmd->resp_pkt))
> > 0ec971fd Johannes Berg 2017-04-10 149 return -EIO;
> > 0ec971fd Johannes Berg 2017-04-10 150
> > 92fe8343 Emmanuel Grumbach 2015-12-01 151 return ret;
> > 92fe8343 Emmanuel Grumbach 2015-12-01 152 }
> > 92fe8343 Emmanuel Grumbach 2015-12-01 153
> > IWL_EXPORT_SYMBOL(iwl_trans_send_cmd);
> > 39bdb17e Sharon Dvir
Re: [PATCH 4.9 000/144] 4.9.117-stable review
On Wed, Aug 01, 2018 at 06:50:27PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.117 release. > There are 144 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Fri Aug 3 16:49:15 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.117-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.9.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled with -Werror, and installed onto my OnePlus 6. No initial issues noticed in dmesg or general usage. Thanks! Nathan
Re: [PATCH 4.4 000/107] 4.4.144-stable review
On Mon, Jul 23, 2018 at 02:40:54PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.144 release. > There are 107 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed Jul 25 12:23:53 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.144-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.4.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled with -Werror, and installed onto my Pixel 2 XL. No initial issues noticed in dmesg or general usage. Thanks! Nathan
Re: [PATCH 4.9 00/28] 4.9.115-stable review
On Mon, Jul 23, 2018 at 02:25:00PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.115 release. > There are 28 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed Jul 25 12:24:13 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.115-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.9.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled with -Werror, and installed onto my OnePlus 6. No initial issues noticed in dmesg or general usage. Thanks! Nathan
Re: [PATCH 4.4 00/53] 4.4.113-stable review
On Mon, Jan 22, 2018 at 09:39:52AM +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.113 release. > There are 53 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed Jan 24 08:38:52 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.113-rc1.gz > or in the git tree and branch at: > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.4.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled, and flashed onto my Pixel 2 XL and OnePlus 5. Two minor conflicts, nothing major worth noting. No initial issues noticed in general usage or dmesg. Reference trees for Android: https://github.com/android-linux-stable Thanks! Nathan
Re: [PATCH 4.4 00/22] 4.4.111-stable review
On Mon, Jan 08, 2018 at 01:59:27PM +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.111 release. > There are 22 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed Jan 10 12:59:14 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.111-rc1.gz > or in the git tree and branch at: > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.4.y > and the diffstat can be found below. > > thanks, > > greg k-h > > - > Pseudo-Shortlog of commits: > > Greg Kroah-Hartman > Linux 4.4.111-rc1 > > Borislav Petkov > Map the vsyscall page with _PAGE_USER > > Alexey Dobriyan > proc: much faster /proc/vmstat > > Libor Pechacek > module: Issue warnings when tainting kernel > > Miroslav Benes > module: keep percpu symbols in module's symtab > > Michal Marek > genksyms: Handle string literals with spaces in reference files > > Thomas Gleixner > x86/tlb: Drop the _GPL from the cpu_tlbstate export > > Boris Brezillon > mtd: nand: pxa3xx: Fix READOOB implementation > > Helge Deller > parisc: Fix alignment of pa_tlb_lock in assembly on 32-bit SMP kernel > > Tom Lendacky > x86/microcode/AMD: Add support for fam17h microcode loading > > Aaron Ma > Input: elantech - add new icbody type 15 > > Vineet Gupta > ARC: uaccess: dont use "l" gcc inline asm constraint modifier > > Oleg Nesterov > kernel/signal.c: remove the no longer needed SIGNAL_UNKILLABLE check in > complete_signal() > > Oleg Nesterov > kernel/signal.c: protect the SIGNAL_UNKILLABLE tasks from > !sig_kernel_only() signals > > Oleg Nesterov > kernel/signal.c: protect the traced SIGNAL_UNKILLABLE tasks from SIGKILL > > Thiago Rafael Becker > kernel: make groups_sort calling a responsibility group_info allocators > > David Howells > fscache: Fix the default for fscache_maybe_release_page() > > Stefan Brüns > sunxi-rsb: Include OF based modalias in device uevent > > Eric Biggers > crypto: pcrypt - fix freeing pcrypt instances > > Eric Biggers > crypto: chacha20poly1305 - validate the digest size > > Jan Engelhardt > crypto: n2 - cure use after free > > Oleg Nesterov > kernel/acct.c: fix the acct->needcheck check in check_free_space() > > Andrey Ryabinin > x86/kasan: Write protect kasan zero shadow > > > - > > Diffstat: > > Makefile | 4 ++-- > arch/arc/include/asm/uaccess.h| 5 +++-- > arch/parisc/include/asm/ldcw.h| 2 ++ > arch/parisc/kernel/entry.S| 13 +++-- > arch/parisc/kernel/pacache.S | 9 +++-- > arch/s390/kernel/compat_linux.c | 1 + > arch/x86/entry/vsyscall/vsyscall_64.c | 5 + > arch/x86/include/asm/vsyscall.h | 2 ++ > arch/x86/kernel/cpu/microcode/amd.c | 4 > arch/x86/mm/init.c| 2 +- > arch/x86/mm/kaiser.c | 34 ++ > arch/x86/mm/kasan_init_64.c | 10 -- > crypto/chacha20poly1305.c | 6 +- > crypto/pcrypt.c | 19 ++- > drivers/bus/sunxi-rsb.c | 1 + > drivers/crypto/n2_core.c | 3 +++ > drivers/input/mouse/elantech.c| 2 +- > drivers/mtd/nand/pxa3xx_nand.c| 1 + > fs/nfsd/auth.c| 3 +++ > include/linux/cred.h | 1 + > include/linux/fscache.h | 2 +- > kernel/acct.c | 2 +- > kernel/groups.c | 5 +++-- > kernel/module.c | 26 +- > kernel/signal.c | 18 ++ > kernel/uid16.c| 1 + > mm/vmstat.c | 4 +++- > net/sunrpc/auth_gss/gss_rpc_xdr.c | 1 + > net/sunrpc/auth_gss/svcauth_gss.c | 1 + > net/sunrpc/svcauth_unix.c | 2 ++ > scripts/genksyms/genksyms.c | 6 -- > 31 files changed, 149 insertions(+), 46 deletions(-) > > Merged, compiled, and flashed onto my Pixel 2 XL and OnePlus 5. No issues noticed in general usage or dmesg. Thanks! Nathan
Re: [PATCH 4.4 00/74] 4.4.114-stable review
On Mon, Jan 29, 2018 at 01:56:05PM +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.114 release. > There are 74 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed Jan 31 12:38:21 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.114-rc1.gz > or in the git tree and branch at: > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.4.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled, and flashed onto my Pixel 2 XL and OnePlus 5. No conflicts, no initial issues noticed in dmesg or general usage. Reference trees for Android: https://github.com/android-linux-stable Thanks! Nathan
Re: [PATCH 4.4 00/87] 4.4.112-stable review
On Mon, Jan 15, 2018 at 01:33:59PM +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.112 release. > There are 87 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed Jan 17 12:33:11 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.112-rc1.gz > or in the git tree and branch at: > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.4.y > and the diffstat can be found below. > > thanks, > > greg k-h > > - > Pseudo-Shortlog of commits: > > Greg Kroah-Hartman > Linux 4.4.112-rc1 > > Andy Lutomirski > selftests/x86: Add test_vsyscall > > David Woodhouse > x86/alternatives: Add missing '\n' at end of ALTERNATIVE inline asm > > Borislav Petkov > x86/alternatives: Fix optimize_nops() checking > > David Woodhouse > sysfs/cpu: Fix typos in vulnerability documentation > > Thomas Gleixner > x86/cpu: Implement CPU vulnerabilites sysfs functions > > Thomas Gleixner > sysfs/cpu: Add vulnerability folder > > Dave Hansen > x86/Documentation: Add PTI description > > Benjamin Poirier > e1000e: Fix e1000_check_for_copper_link_ich8lan return value. > > Icenowy Zheng > uas: ignore UAS for Norelsys NS1068(X) chips > > Ben Seri > Bluetooth: Prevent stack info leak from the EFS element. > > Viktor Slavkovic > staging: android: ashmem: fix a race condition in ASHMEM_SET_SIZE ioctl > > Shuah Khan > usbip: remove kernel addresses from usb device and urb debug msgs > > Pete Zaitcev > USB: fix usbmon BUG trigger > > Stefan Agner > usb: misc: usb3503: make sure reset is low for at least 100us > > Christian Holl > USB: serial: cp210x: add new device ID ELV ALC 8xxx > > Diego Elio Pettenò > USB: serial: cp210x: add IDs for LifeScan OneTouch Verio IQ > > Nicholas Bellinger > target: Avoid early CMD_T_PRE_EXECUTE failures during ABORT_TASK > > Nicholas Bellinger > iscsi-target: Make TASK_REASSIGN use proper se_cmd->cmd_kref > > Daniel Borkmann > bpf, array: fix overflow in max_entries and undefined behavior in > index_mask > > Alexei Starovoitov > bpf: prevent out-of-bounds speculation > > Alexei Starovoitov > bpf: adjust insn_aux_data when patching insns > > Alexei Starovoitov > bpf: refactor fixup_bpf_calls() > > Alexei Starovoitov > bpf: move fixup_bpf_calls() function > > Jakub Kicinski > bpf: don't (ab)use instructions to store state > > Daniel Borkmann > bpf: add bpf_patch_insn_single helper > > Lepton Wu > kaiser: Set _PAGE_NX only if supported > > Dan Carpenter > drm/vmwgfx: Potential off by one in vmw_view_add() > > Andrew Honig > KVM: x86: Add memory barrier on vmcs field lookup > > Jia Zhang > x86/microcode/intel: Extend BDW late-loading with a revision check > > Ilya Dryomov > rbd: set max_segments to USHRT_MAX > > Eric Biggers > crypto: algapi - fix NULL dereference in crypto_remove_spawns() > > Eric Dumazet > ipv6: fix possible mem leaks in ipv6_make_skb() > > Jerome Brunet > net: stmmac: enable EEE in MII, GMII or RGMII only > > Sergei Shtylyov > sh_eth: fix SH7757 GEther initialization > > Sergei Shtylyov > sh_eth: fix TSU resource handling > > Mohamed Ghannam > RDS: null pointer dereference in rds_atomic_free_op > > Mohamed Ghannam > RDS: Heap OOB write in rds_message_alloc_sgs() > > Andrii Vladyka > net: core: fix module type in sock_diag_bind > > Eli Cooper > ip6_tunnel: disable dst caching if tunnel is dual-stack > > Cong Wang > 8021q: fix a memory leak for VLAN 0 device > > Pavel Tatashin > x86/pti/efi: broken conversion from efi to kernel page table > > Greg Kroah-Hartman > Revert "userfaultfd: selftest: vm: allow to build in vm/ directory" > > Ben Hutchings > xhci: Fix ring leak in failure path of xhci_alloc_virt_device() > > Ani Sinha > sysrq: Fix warning in sysrq generated crash. > > Jiri Slaby > hwrng: core - sleep interruptible in read > > Jiri Kosina > x86/mm/pat, /dev/mem: Remove superfluous error message > > Eric Dumazet > cx82310_eth: use skb_cow_head() to deal with cloned skbs > > Eric Dumazet > smsc75xx: use skb_cow_head() to deal with cloned skbs > > Eric Dumazet > sr9700: use skb_cow_head() to deal with cloned skbs > > Eric Dumazet > lan78xx: use skb_cow_head() to deal with cloned skbs > > hayeswang > r8152: adjust ALDPS function > > hayeswang > r8152: use test_and_clear_bit > > hayeswang > r8152: fix the wake event > > Ulf Hansson > usb: musb: ux500: Fix NULL pointer dereference at system PM > > Oliver Neukum > usbvision f
Re: [PATCH 4.4 00/36] 4.4.121-stable review
On Fri, Mar 09, 2018 at 04:18:16PM -0800, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.121 release. > There are 36 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Mon Mar 12 00:17:54 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.121-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.4.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled, and flashed onto my Pixel 2 XL and OnePlus 5. No merge conflicts and no visible issues in dmesg or general usage. Thanks! Nathan
Re: [PATCH 4.4 00/36] 4.4.121-stable review
On Fri, Mar 09, 2018 at 05:03:12PM -0800, Greg Kroah-Hartman wrote: > On Fri, Mar 09, 2018 at 05:50:35PM -0700, Nathan Chancellor wrote: > > On Fri, Mar 09, 2018 at 04:18:16PM -0800, Greg Kroah-Hartman wrote: > > > This is the start of the stable review cycle for the 4.4.121 release. > > > There are 36 patches in this series, all will be posted as a response > > > to this one. If anyone has any issues with these being applied, please > > > let me know. > > > > > > Responses should be made by Mon Mar 12 00:17:54 UTC 2018. > > > Anything received after that time might be too late. > > > > > > The whole patch series can be found in one patch at: > > > > > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.121-rc1.gz > > > or in the git tree and branch at: > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > > linux-4.4.y > > > and the diffstat can be found below. > > > > > > thanks, > > > > > > greg k-h > > > > > > > Merged, compiled, and flashed onto my Pixel 2 XL and OnePlus 5. > > > > No merge conflicts and no visible issues in dmesg or general usage. > > That was fast, thanks! > > greg k-h I happened to run the stable queue since there was no RC when I decided to build so the timing worked out! Nathan
Re: [PATCH] staging: android: ashmem: Remove deadlock
On Wed, Mar 07, 2018 at 01:40:30PM -0800, Paul Lawrence wrote:
> Regression introduced in commit ce8a3a9e76d0193e2e8d74a06d275b3c324ca652
> ("staging: android: ashmem: Fix a race condition in pin ioctls")
> causing deadlock.
>
> No need to hold ashmem_mutex while copying from user
>
> Stacks are:
>
> ashmem_mmap+0x53/0x400 drivers/staging/android/ashmem.c:379
> mmap_region+0x7dd/0xfd0 mm/mmap.c:1694
> do_mmap+0x57b/0xbe0 mm/mmap.c:1473
>
> and
>
> lock_acquire+0x12e/0x410 kernel/locking/lockdep.c:3756
> __might_fault+0x14a/0x1d0 mm/memory.c:4014
> copy_from_user arch/x86/include/asm/uaccess.h:705 [inline]
> ashmem_pin_unpin drivers/staging/android/ashmem.c:719 [inline]
>
> Signed-off-by: Paul Lawrence
> Cc: # 4.9.x
> Cc: # 4.4.x
> Cc: # 3.18.x: ce8a3a9e76d01
> Cc: # 3.18.x
> Cc: Ben Hutchings
> ---
> drivers/staging/android/ashmem.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/staging/android/ashmem.c
> b/drivers/staging/android/ashmem.c
> index 6dbba5aff191..8c55706c2cfa 100644
> --- a/drivers/staging/android/ashmem.c
> +++ b/drivers/staging/android/ashmem.c
> @@ -702,16 +702,14 @@ static int ashmem_pin_unpin(struct ashmem_area *asma,
> unsigned long cmd,
> size_t pgstart, pgend;
> int ret = -EINVAL;
>
> + if (unlikely(copy_from_user(&pin, p, sizeof(pin
> + return -EFAULT;
> +
> mutex_lock(&ashmem_mutex);
>
> if (unlikely(!asma->file))
> goto out_unlock;
>
> - if (unlikely(copy_from_user(&pin, p, sizeof(pin {
> - ret = -EFAULT;
> - goto out_unlock;
> - }
> -
> /* per custom, you can pass zero for len to mean "everything onward" */
> if (!pin.len)
> pin.len = PAGE_ALIGN(asma->size) - pin.offset;
> --
> 2.16.2.395.g2e18187dfd-goog
>
Hey Paul,
Looks like this same patch is already in Greg's tree:
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/commit/?id=740a5759bf222332fbb5eda42f89aa25ba38f9b2
Cheers!
Nathan Chancellor
Re: [PATCH 4.4 00/72] 4.4.127-stable review
On Fri, Apr 06, 2018 at 03:23:01PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.127 release. > There are 72 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun Apr 8 08:42:48 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.127-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.4.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled, and flashed on my Pixel 2 XL and OnePlus 5. No issues noticed in general usage or dmesg (I've been running the queue over the past few days to stay on top of any issues). Thanks! Nathan
Re: [PATCH 4.4 000/190] 4.4.128-stable review
On Wed, Apr 11, 2018 at 08:34:06PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.128 release. > There are 190 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Fri Apr 13 18:34:54 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.128-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.4.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled, and flashed onto my Pixel 2 XL and OnePlus 5. Ever since switching to Clang on the OP5 back in December, I haven't been compiling with GCC at all which was a mistake. So I have started compiling with Google's GCC 4.9.4, Bootlin's GCC 7.3.0, Google's Clang 5.0, and my own Clang 6.0 and 7.0. All builds completed successfully with -Werror. No initial issues in dmesg or general usage. Thanks! Nathan
Re: [PATCH 4.4 000/134] 4.4.123-stable review
On Mon, Mar 19, 2018 at 07:04:43PM +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.123 release. > There are 134 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed Mar 21 17:18:04 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.123-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.4.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled, and flashed onto my OnePlus 5. No initial issues noticed in general usage or dmesg. Thanks! Nathan
Re: [PATCH 4.4 000/134] 4.4.123-stable review
On Tue, Mar 20, 2018 at 06:32:00AM -0700, Guenter Roeck wrote:
> On 03/19/2018 11:04 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.4.123 release.
> > There are 134 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed Mar 21 17:18:04 UTC 2018.
> > Anything received after that time might be too late.
> >
>
> For v4.4.122-134-gb4e03b4:
>
> Build results:
> total: 145 pass: 140 fail: 5
> Failed builds:
> arm:allmodconfig
> powerpc:defconfig
> powerpc:allmodconfig
> powerpc:cell_defconfig
> powerpc:maple_defconfig
>
> arm:allmodconfig:
>
> drivers/net/ethernet/marvell/mvpp2.c: In function 'mvpp2_probe':
> drivers/net/ethernet/marvell/mvpp2.c:6451:10: error: 'struct mvpp2' has no
> member named 'hw_version'
> if (priv->hw_version == MVPP22) {
> ^
> drivers/net/ethernet/marvell/mvpp2.c:6451:26: error: 'MVPP22' undeclared
> (first use in this function)
> if (priv->hw_version == MVPP22) {
>
Caused by commit 6349601ed3e1 ("net: mvpp2: set dma mask and coherent
dma mask on PPv2.2"), which seems irrelevant for 4.4 since PPv2.2
support was added in 4.12 per upstream commit fc5e1550e5c3 ("net: mvpp2:
finally add the PPv2.2 compatible string").
> powerpc:
>
> arch/powerpc/mm/hugetlbpage.c: In function 'add_huge_page_size':
> arch/powerpc/mm/hugetlbpage.c:840:2: error: implicit declaration of function
> 'radix_enabled'
>
Caused by commit 17cd5e81ded7 ("powerpc/mm/hugetlb: Filter out hugepage
size not supported by page table layout"). It is introduced in 4.7 in
upstream commit 566ca99af026 ("powerpc/mm/radix: Add dummy
radix_enabled()") and not properly turned on until upstream commit
a8ed87c92adf ("powerpc/mm/radix: Add MMU_FTR_RADIX"). I am going to
assume from the fact there is a lot of MMU work after this and the
wording of the Kconfig entry that this is probably not suitable fo
a stable backport.
> Guenter
Cheers,
Nathan
Re: [PATCH 4.4 00/97] 4.4.124-stable review
On Fri, Mar 23, 2018 at 10:53:47AM +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.124 release. > There are 97 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun Mar 25 09:41:34 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.124-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.4.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled, and flashed onto my Pixel 2 XL and OnePlus 5. Couple small conflicts from Qualcomm's changes but nothing major, I'm sure kernel/common will have none. No initial issues in general usage or dmesg. Thanks! Nathan
[PATCH] staging: rtl8723bs: Mark ACPI table declaration as used
Clang emits the following warning:
drivers/staging/rtl8723bs/os_dep/sdio_intf.c:25:36: warning: variable
'acpi_ids' is not needed and will not be emitted
[-Wunneeded-internal-declaration]
static const struct acpi_device_id acpi_ids[] = {
^
1 warning generated.
Mark acpi_ids with the attribute __used, which makes it clear to Clang
that we don't want this warning while not inhibiting Clang's dead code
elimination from removing the unreferenced internal symbol when moving
the data to the globally available symbol with MODULE_DEVICE_TABLE.
$ nm -S drivers/staging/rtl8723bs/os_dep/sdio_intf.o | grep acpi
0040 R __mod_acpi__acpi_ids_device_table
Link: https://github.com/ClangBuiltLinux/linux/issues/169
Suggested-by: Nick Desaulniers
Signed-off-by: Nathan Chancellor
---
drivers/staging/rtl8723bs/os_dep/sdio_intf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
b/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
index 6d02904de63f..7c03b69b8ed3 100644
--- a/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
+++ b/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
@@ -22,7 +22,7 @@ static const struct sdio_device_id sdio_ids[] =
{ SDIO_DEVICE(0x024c, 0xb723), },
{ /* end: all zeroes */ },
};
-static const struct acpi_device_id acpi_ids[] = {
+static const struct acpi_device_id acpi_ids[] __used = {
{"OBDA8723", 0x},
{}
};
--
2.19.0
[PATCH] staging: rtl8188eu: Use proper enum in rtl8188eu_config_rf_reg
Clang warns when an enumerated type is implicitly converted to another. drivers/staging/rtl8188eu/hal/rf_cfg.c:180:25: warning: implicit conversion from enumeration type 'enum rf90_radio_path' to different enumeration type 'enum rf_radio_path' [-Wenum-conversion] rtl_rfreg_delay(adapt, RF90_PATH_A, addr | maskforphyset, ~~~^~~ 1 warning generated. Avoid this by using the equivalent value from the expected type, rf_radio_path: RF90_PATH_A = RF_PATH_A = 0 Link: https://github.com/ClangBuiltLinux/linux/issues/164 Signed-off-by: Nathan Chancellor --- drivers/staging/rtl8188eu/hal/rf_cfg.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rtl8188eu/hal/rf_cfg.c b/drivers/staging/rtl8188eu/hal/rf_cfg.c index 0700d8bd448d..02aeb12c9870 100644 --- a/drivers/staging/rtl8188eu/hal/rf_cfg.c +++ b/drivers/staging/rtl8188eu/hal/rf_cfg.c @@ -177,7 +177,7 @@ static void rtl8188e_config_rf_reg(struct adapter *adapt, u32 content = 0x1000; /*RF Content: radio_a_txt*/ u32 maskforphyset = content & 0xE000; - rtl_rfreg_delay(adapt, RF90_PATH_A, addr | maskforphyset, + rtl_rfreg_delay(adapt, RF_PATH_A, addr | maskforphyset, RFREG_OFFSET_MASK, data); } -- 2.19.0
Re: [PATCH] IB/mlx4: Avoid implicit enumerated type conversion
On Mon, Sep 24, 2018 at 08:37:22PM -0600, Jason Gunthorpe wrote:
> On Mon, Sep 24, 2018 at 03:29:38PM -0700, Nick Desaulniers wrote:
> > On Mon, Sep 24, 2018 at 3:27 PM Nathan Chancellor
> > wrote:
> > >
> > > On Mon, Sep 24, 2018 at 03:24:36PM -0700, Nick Desaulniers wrote:
> > > > On Mon, Sep 24, 2018 at 12:57 PM Nathan Chancellor
> > > > wrote:
> > > > >
> > > > > Clang warns when one enumerated type is implicitly converted to
> > > > > another.
> > > > >
> > > > > drivers/infiniband/hw/mlx4/mad.c:1811:41: warning: implicit conversion
> > > > > from enumeration type 'enum mlx4_ib_qp_flags' to different enumeration
> > > > > type 'enum ib_qp_create_flags' [-Wenum-conversion]
> > > > > qp_init_attr.init_attr.create_flags =
> > > > > MLX4_IB_SRIOV_TUNNEL_QP;
> > > > > ~
> > > > > ^~~
> > > > >
> > > > > drivers/infiniband/hw/mlx4/mad.c:1819:41: warning: implicit conversion
> > > > > from enumeration type 'enum mlx4_ib_qp_flags' to different enumeration
> > > > > type 'enum ib_qp_create_flags' [-Wenum-conversion]
> > > > > qp_init_attr.init_attr.create_flags =
> > > > > MLX4_IB_SRIOV_SQP;
> > > > > ~
> > > > > ^
> > > > >
> > > > > The type mlx4_ib_qp_flags explicitly provides supplemental values to
> > > > > the
> > > > > type ib_qp_create_flags. Make that clear to Clang by changing the
> > > > > create_flags type to u32.
> > > > >
> > > > > Reported-by: Nick Desaulniers
> > > > > Signed-off-by: Nathan Chancellor
> > > > > include/rdma/ib_verbs.h | 2 +-
> > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
> > > > > index e463d3007a35..f6f4d9e3c8ed 100644
> > > > > +++ b/include/rdma/ib_verbs.h
> > > > > @@ -1149,7 +1149,7 @@ struct ib_qp_init_attr {
> > > > > struct ib_qp_capcap;
> > > > > enum ib_sig_typesq_sig_type;
> > > > > enum ib_qp_type qp_type;
> > > > > - enum ib_qp_create_flags create_flags;
> > > > > + u32 create_flags;
> > > >
> > > > I think it might be better to just have explicit casts at the
> > > > assignment. What do the maintainers think?
> > > >
> > >
> > > That's fine with me, I tend to explicitly cast if it is only one
> > > location but it certainly makes sense in this case as well. I'll
> > > wait for the maintainers to weigh in before sending a v2.
> >
> > Yeah, I mean my opinion on this might seem arbitrary, but based on the
> > pattern and the comment in ib_qp_create_flags, those enum values are
> > reserved to be "subclassed" in a sense, so they should always be in
> > sync or this code will have bigger problems.
>
> One should not use an 'enum' type name for bitfield storage, as once
> you start or'ing things together the values no longer fall on the
> enum. Some compilers and tools even give warnings in this case, ie
>
>enum x foo = X_A | X_B;
>
> Is an assignment from 'int' to an 'enum x' with an implicit cast.
>
> For this reason, usually bitfield enum declarations should be
> anonymous.
>
> Jason
Hi Jason,
I apologize for not understanding but how should I adjust my patch so
that it is acceptable? Do you want the explicit casts like Nick
suggested?
Thanks for the comments,
Nathan
[PATCH] RDMA/qedr: Explicitly cast pkt->tx_dest to qed_ll2_tx_dest
Clang warns when one enumerated type is explicitly converted to another. drivers/infiniband/hw/qedr/qedr_roce_cm.c:198:28: warning: implicit conversion from enumeration type 'enum qed_roce_ll2_tx_dest' to different enumeration type 'enum qed_ll2_tx_dest' [-Wenum-conversion] ll2_tx_pkt.tx_dest = pkt->tx_dest; ~ ~^~~ 1 warning generated. Avoid this warning by explicitly casting pkt->tx_dest to qed_112_tx_dest, which has the expected values from the type qed_roce_ll2_tx_dest. Reported-by: Nick Desaulniers Signed-off-by: Nathan Chancellor --- drivers/infiniband/hw/qedr/qedr_roce_cm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/infiniband/hw/qedr/qedr_roce_cm.c b/drivers/infiniband/hw/qedr/qedr_roce_cm.c index 85578887421b..147e0d69003d 100644 --- a/drivers/infiniband/hw/qedr/qedr_roce_cm.c +++ b/drivers/infiniband/hw/qedr/qedr_roce_cm.c @@ -195,7 +195,7 @@ static int qedr_ll2_post_tx(struct qedr_dev *dev, ll2_tx_pkt.num_of_bds = 1 /* hdr */ + pkt->n_seg; ll2_tx_pkt.vlan = 0; - ll2_tx_pkt.tx_dest = pkt->tx_dest; + ll2_tx_pkt.tx_dest = (enum qed_ll2_tx_dest)pkt->tx_dest; ll2_tx_pkt.qed_roce_flavor = roce_flavor; ll2_tx_pkt.first_frag = pkt->header.baddr; ll2_tx_pkt.first_frag_len = pkt->header.len; -- 2.19.0
[PATCH] mfd: cros_ec: Avoid unneeded internal declaration warning
Clang warns:
drivers/mfd/cros_ec_dev.c:509:40: warning: variable 'cros_ec_id' is not
needed and will not be emitted [-Wunneeded-internal-declaration]
static const struct platform_device_id cros_ec_id[] = {
^
1 warning generated.
Avoid this warning by adding it to the cros_ec_dev_driver definition
under the id_table member like all other platform drivers.
Signed-off-by: Nathan Chancellor
---
I looked at several drivers with platform_device_id defintions and I
didn't really find any where the definition wasn't then added to the
platform_driver so I'm not sure if this was just missed in commit
afbf8ec7c4f9 ("platform/chrome: cros_ec_dev - Add a platform
device ID table") or if it was an intentional omission. I'm not super
familiar with the inner workings of platform devices.
Should this commit be undesirable, the warning can be silenced with the
__used attribute but this seemed like a more proper first commit.
drivers/mfd/cros_ec_dev.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
index 999dac752bcc..8f9d6964173e 100644
--- a/drivers/mfd/cros_ec_dev.c
+++ b/drivers/mfd/cros_ec_dev.c
@@ -546,6 +546,7 @@ static struct platform_driver cros_ec_dev_driver = {
.name = DRV_NAME,
.pm = &cros_ec_dev_pm_ops,
},
+ .id_table = cros_ec_id,
.probe = ec_device_probe,
.remove = ec_device_remove,
.shutdown = ec_device_shutdown,
--
2.19.0
[PATCH v2] IB/rxe: Avoid implicit enum conversions in rxe_init functions
Clang warns when an emumerated type is implicitly converted to another.
drivers/infiniband/sw/rxe/rxe.c:106:27: warning: implicit conversion
from enumeration type 'enum rxe_device_param' to different enumeration
type 'enum ib_atomic_cap' [-Wenum-conversion]
rxe->attr.atomic_cap= RXE_ATOMIC_CAP;
~ ^~
drivers/infiniband/sw/rxe/rxe.c:131:22: warning: implicit conversion
from enumeration type 'enum rxe_port_param' to different enumeration
type 'enum ib_port_state' [-Wenum-conversion]
port->attr.state= RXE_PORT_STATE;
~ ^~
drivers/infiniband/sw/rxe/rxe.c:132:24: warning: implicit conversion
from enumeration type 'enum rxe_port_param' to different enumeration
type 'enum ib_mtu' [-Wenum-conversion]
port->attr.max_mtu = RXE_PORT_MAX_MTU;
~ ^~~~
drivers/infiniband/sw/rxe/rxe.c:133:27: warning: implicit conversion
from enumeration type 'enum rxe_port_param' to different enumeration
type 'enum ib_mtu' [-Wenum-conversion]
port->attr.active_mtu = RXE_PORT_ACTIVE_MTU;
~ ^~~
drivers/infiniband/sw/rxe/rxe.c:151:24: warning: implicit conversion
from enumeration type 'enum rxe_port_param' to different enumeration
type 'enum ib_mtu' [-Wenum-conversion]
ib_mtu_enum_to_int(RXE_PORT_ACTIVE_MTU);
~~ ^~~
5 warnings generated.
Use the appropriate values from the expected enumerated type so no
conversion needs to happen.
Reported-by: Nick Desaulniers
Signed-off-by: Nathan Chancellor
---
v1 -> v2:
* Don't cast, just use the expecting enumerated value directly, per
Jason's request
drivers/infiniband/sw/rxe/rxe.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/infiniband/sw/rxe/rxe.c b/drivers/infiniband/sw/rxe/rxe.c
index 10999fa69281..2f4e57886b89 100644
--- a/drivers/infiniband/sw/rxe/rxe.c
+++ b/drivers/infiniband/sw/rxe/rxe.c
@@ -103,7 +103,7 @@ static void rxe_init_device_param(struct rxe_dev *rxe)
rxe->attr.max_res_rd_atom = RXE_MAX_RES_RD_ATOM;
rxe->attr.max_qp_init_rd_atom = RXE_MAX_QP_INIT_RD_ATOM;
rxe->attr.max_ee_init_rd_atom = RXE_MAX_EE_INIT_RD_ATOM;
- rxe->attr.atomic_cap= RXE_ATOMIC_CAP;
+ rxe->attr.atomic_cap= IB_ATOMIC_HCA;
rxe->attr.max_ee= RXE_MAX_EE;
rxe->attr.max_rdd = RXE_MAX_RDD;
rxe->attr.max_mw= RXE_MAX_MW;
@@ -128,9 +128,9 @@ static void rxe_init_device_param(struct rxe_dev *rxe)
/* initialize port attributes */
static int rxe_init_port_param(struct rxe_port *port)
{
- port->attr.state= RXE_PORT_STATE;
- port->attr.max_mtu = RXE_PORT_MAX_MTU;
- port->attr.active_mtu = RXE_PORT_ACTIVE_MTU;
+ port->attr.state= IB_PORT_DOWN;
+ port->attr.max_mtu = IB_MTU_4096;
+ port->attr.active_mtu = IB_MTU_256;
port->attr.gid_tbl_len = RXE_PORT_GID_TBL_LEN;
port->attr.port_cap_flags = RXE_PORT_PORT_CAP_FLAGS;
port->attr.max_msg_sz = RXE_PORT_MAX_MSG_SZ;
@@ -147,8 +147,7 @@ static int rxe_init_port_param(struct rxe_port *port)
port->attr.active_width = RXE_PORT_ACTIVE_WIDTH;
port->attr.active_speed = RXE_PORT_ACTIVE_SPEED;
port->attr.phys_state = RXE_PORT_PHYS_STATE;
- port->mtu_cap =
- ib_mtu_enum_to_int(RXE_PORT_ACTIVE_MTU);
+ port->mtu_cap = ib_mtu_enum_to_int(IB_MTU_256);
port->subnet_prefix = cpu_to_be64(RXE_PORT_SUBNET_PREFIX);
return 0;
--
2.19.0
[PATCH v3] IB/rxe: Remove unnecessary enum values
Clang warns when an emumerated type is implicitly converted to another.
drivers/infiniband/sw/rxe/rxe.c:106:27: warning: implicit conversion
from enumeration type 'enum rxe_device_param' to different enumeration
type 'enum ib_atomic_cap' [-Wenum-conversion]
rxe->attr.atomic_cap= RXE_ATOMIC_CAP;
~ ^~
drivers/infiniband/sw/rxe/rxe.c:131:22: warning: implicit conversion
from enumeration type 'enum rxe_port_param' to different enumeration
type 'enum ib_port_state' [-Wenum-conversion]
port->attr.state= RXE_PORT_STATE;
~ ^~
drivers/infiniband/sw/rxe/rxe.c:132:24: warning: implicit conversion
from enumeration type 'enum rxe_port_param' to different enumeration
type 'enum ib_mtu' [-Wenum-conversion]
port->attr.max_mtu = RXE_PORT_MAX_MTU;
~ ^~~~
drivers/infiniband/sw/rxe/rxe.c:133:27: warning: implicit conversion
from enumeration type 'enum rxe_port_param' to different enumeration
type 'enum ib_mtu' [-Wenum-conversion]
port->attr.active_mtu = RXE_PORT_ACTIVE_MTU;
~ ^~~
drivers/infiniband/sw/rxe/rxe.c:151:24: warning: implicit conversion
from enumeration type 'enum rxe_port_param' to different enumeration
type 'enum ib_mtu' [-Wenum-conversion]
ib_mtu_enum_to_int(RXE_PORT_ACTIVE_MTU);
~~ ^~~
5 warnings generated.
Use the appropriate values from the expected enumerated type so no
conversion needs to happen then remove the unneeded definitions.
Reported-by: Nick Desaulniers
Signed-off-by: Nathan Chancellor
---
v1 -> v2:
* Don't cast, just use the expecting enumerated value directly, per
Jason's request
v2 -> v3:
* Convert two spots from RXE_PORT_MAX_MTU to IB_MTU_4096 then remove
value definitions.
drivers/infiniband/sw/rxe/rxe.c | 13 ++---
drivers/infiniband/sw/rxe/rxe_loc.h | 2 +-
drivers/infiniband/sw/rxe/rxe_param.h | 4
3 files changed, 7 insertions(+), 12 deletions(-)
diff --git a/drivers/infiniband/sw/rxe/rxe.c b/drivers/infiniband/sw/rxe/rxe.c
index 10999fa69281..383e65c7bbc0 100644
--- a/drivers/infiniband/sw/rxe/rxe.c
+++ b/drivers/infiniband/sw/rxe/rxe.c
@@ -103,7 +103,7 @@ static void rxe_init_device_param(struct rxe_dev *rxe)
rxe->attr.max_res_rd_atom = RXE_MAX_RES_RD_ATOM;
rxe->attr.max_qp_init_rd_atom = RXE_MAX_QP_INIT_RD_ATOM;
rxe->attr.max_ee_init_rd_atom = RXE_MAX_EE_INIT_RD_ATOM;
- rxe->attr.atomic_cap= RXE_ATOMIC_CAP;
+ rxe->attr.atomic_cap= IB_ATOMIC_HCA;
rxe->attr.max_ee= RXE_MAX_EE;
rxe->attr.max_rdd = RXE_MAX_RDD;
rxe->attr.max_mw= RXE_MAX_MW;
@@ -128,9 +128,9 @@ static void rxe_init_device_param(struct rxe_dev *rxe)
/* initialize port attributes */
static int rxe_init_port_param(struct rxe_port *port)
{
- port->attr.state= RXE_PORT_STATE;
- port->attr.max_mtu = RXE_PORT_MAX_MTU;
- port->attr.active_mtu = RXE_PORT_ACTIVE_MTU;
+ port->attr.state= IB_PORT_DOWN;
+ port->attr.max_mtu = IB_MTU_4096;
+ port->attr.active_mtu = IB_MTU_256;
port->attr.gid_tbl_len = RXE_PORT_GID_TBL_LEN;
port->attr.port_cap_flags = RXE_PORT_PORT_CAP_FLAGS;
port->attr.max_msg_sz = RXE_PORT_MAX_MSG_SZ;
@@ -147,8 +147,7 @@ static int rxe_init_port_param(struct rxe_port *port)
port->attr.active_width = RXE_PORT_ACTIVE_WIDTH;
port->attr.active_speed = RXE_PORT_ACTIVE_SPEED;
port->attr.phys_state = RXE_PORT_PHYS_STATE;
- port->mtu_cap =
- ib_mtu_enum_to_int(RXE_PORT_ACTIVE_MTU);
+ port->mtu_cap = ib_mtu_enum_to_int(IB_MTU_256);
port->subnet_prefix = cpu_to_be64(RXE_PORT_SUBNET_PREFIX);
return 0;
@@ -300,7 +299,7 @@ void rxe_set_mtu(struct rxe_dev *rxe, unsigned int ndev_mtu)
mtu = eth_mtu_int_to_enum(ndev_mtu);
/* Make sure that new MTU in range */
- mtu = mtu ? min_t(enum ib_mtu, mtu, RXE_PORT_MAX_MTU) : IB_MTU_256;
+ mtu = mtu ? min_t(enum ib_mtu, mtu, IB_MTU_4096) : IB_MTU_256;
port->attr.active_mtu = mtu;
port->mtu_cap = ib_mtu_enum_to_int(mtu);
diff --git a/drivers/infiniband/sw/rxe/rxe_loc.h
b/drivers/infiniband/
[PATCH v2] drm/amd/display: Use proper enums in process_channel_reply
Clang warns when one enumerated type is implicitly converted to another.
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.c:315:19: warning:
implicit conversion from enumeration type 'enum
aux_channel_operation_result' to different enumeration type 'enum
aux_transaction_reply' [-Wenum-conversion]
reply->status = AUX_CHANNEL_OPERATION_FAILED_HPD_DISCON;
~ ^~~
drivers/gpu/drm/amd/amdgpu/../display/dc/i2caux/dce110/aux_engine_dce110.c:349:19:
warning: implicit conversion from enumeration type 'enum
aux_channel_operation_result' to different enumeration type 'enum
aux_transaction_reply' [-Wenum-conversion]
reply->status = AUX_CHANNEL_OPERATION_FAILED_HPD_DISCON;
~ ^~~
The current enum is incorrect, it should be from aux_transaction_reply,
so use AUX_TRANSACTION_REPLY_HPD_DISCON.
Reported-by: Nick Desaulniers
Suggested-by: Nick Desaulniers
Signed-off-by: Nathan Chancellor
---
v1 -> v2:
* Rather than change status to an integer, use the proper enumerated
type from aux_transaction reply as suggested by Nick and confirmed
by Henry.
drivers/gpu/drm/amd/display/dc/dce/dce_aux.c| 2 +-
.../gpu/drm/amd/display/dc/i2caux/dce110/aux_engine_dce110.c| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
b/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
index 3f5b2e6f7553..aaeb7faac0c4 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
@@ -312,7 +312,7 @@ static void process_channel_reply(
/* in case HPD is LOW, exit AUX transaction */
if ((sw_status & AUX_SW_STATUS__AUX_SW_HPD_DISCON_MASK)) {
- reply->status = AUX_CHANNEL_OPERATION_FAILED_HPD_DISCON;
+ reply->status = AUX_TRANSACTION_REPLY_HPD_DISCON;
return;
}
diff --git a/drivers/gpu/drm/amd/display/dc/i2caux/dce110/aux_engine_dce110.c
b/drivers/gpu/drm/amd/display/dc/i2caux/dce110/aux_engine_dce110.c
index 8eee8ace1259..59c3ed43d609 100644
--- a/drivers/gpu/drm/amd/display/dc/i2caux/dce110/aux_engine_dce110.c
+++ b/drivers/gpu/drm/amd/display/dc/i2caux/dce110/aux_engine_dce110.c
@@ -346,7 +346,7 @@ static void process_channel_reply(
/* in case HPD is LOW, exit AUX transaction */
if ((sw_status & AUX_SW_STATUS__AUX_SW_HPD_DISCON_MASK)) {
- reply->status = AUX_CHANNEL_OPERATION_FAILED_HPD_DISCON;
+ reply->status = AUX_TRANSACTION_REPLY_HPD_DISCON;
return;
}
--
2.19.0
Re: [PATCH v2] drm/amd/display: Use proper enums in process_channel_reply
On Thu, Sep 27, 2018 at 11:06:33AM -0700, Nathan Chancellor wrote:
> Clang warns when one enumerated type is implicitly converted to another.
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.c:315:19: warning:
> implicit conversion from enumeration type 'enum
> aux_channel_operation_result' to different enumeration type 'enum
> aux_transaction_reply' [-Wenum-conversion]
> reply->status = AUX_CHANNEL_OPERATION_FAILED_HPD_DISCON;
> ~ ^~~
> drivers/gpu/drm/amd/amdgpu/../display/dc/i2caux/dce110/aux_engine_dce110.c:349:19:
> warning: implicit conversion from enumeration type 'enum
> aux_channel_operation_result' to different enumeration type 'enum
> aux_transaction_reply' [-Wenum-conversion]
> reply->status = AUX_CHANNEL_OPERATION_FAILED_HPD_DISCON;
> ~ ^~~
>
> The current enum is incorrect, it should be from aux_transaction_reply,
> so use AUX_TRANSACTION_REPLY_HPD_DISCON.
>
> Reported-by: Nick Desaulniers
> Suggested-by: Nick Desaulniers
> Signed-off-by: Nathan Chancellor
> ---
>
> v1 -> v2:
>
> * Rather than change status to an integer, use the proper enumerated
> type from aux_transaction reply as suggested by Nick and confirmed
> by Henry.
Sigh Harry, sorry...
>
> drivers/gpu/drm/amd/display/dc/dce/dce_aux.c| 2 +-
> .../gpu/drm/amd/display/dc/i2caux/dce110/aux_engine_dce110.c| 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
> b/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
> index 3f5b2e6f7553..aaeb7faac0c4 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
> @@ -312,7 +312,7 @@ static void process_channel_reply(
>
> /* in case HPD is LOW, exit AUX transaction */
> if ((sw_status & AUX_SW_STATUS__AUX_SW_HPD_DISCON_MASK)) {
> - reply->status = AUX_CHANNEL_OPERATION_FAILED_HPD_DISCON;
> + reply->status = AUX_TRANSACTION_REPLY_HPD_DISCON;
> return;
> }
>
> diff --git a/drivers/gpu/drm/amd/display/dc/i2caux/dce110/aux_engine_dce110.c
> b/drivers/gpu/drm/amd/display/dc/i2caux/dce110/aux_engine_dce110.c
> index 8eee8ace1259..59c3ed43d609 100644
> --- a/drivers/gpu/drm/amd/display/dc/i2caux/dce110/aux_engine_dce110.c
> +++ b/drivers/gpu/drm/amd/display/dc/i2caux/dce110/aux_engine_dce110.c
> @@ -346,7 +346,7 @@ static void process_channel_reply(
>
> /* in case HPD is LOW, exit AUX transaction */
> if ((sw_status & AUX_SW_STATUS__AUX_SW_HPD_DISCON_MASK)) {
> - reply->status = AUX_CHANNEL_OPERATION_FAILED_HPD_DISCON;
> + reply->status = AUX_TRANSACTION_REPLY_HPD_DISCON;
> return;
> }
>
> --
> 2.19.0
>
Re: [PATCH 4.4 00/28] 4.4.159-stable review
On Thu, Sep 27, 2018 at 11:06:24AM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.159 release. > There are 28 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sat Sep 29 09:06:27 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.159-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.4.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled with -Werror, and installed onto my Pixel 2 XL. No initial issues noticed in dmesg or general usage. Thanks! Nathan
Re: [PATCH 4.9 00/44] 4.9.130-stable review
On Thu, Sep 27, 2018 at 11:03:49AM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.130 release. > There are 44 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sat Sep 29 09:00:54 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.130-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.9.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled with -Werror, and installed onto my OnePlus 6. No initial issues noticed in dmesg or general usage. Thanks! Nathan
Re: [PATCH 4.14 00/64] 4.14.73-stable review
On Thu, Sep 27, 2018 at 11:03:17AM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.73 release. > There are 64 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sat Sep 29 09:02:21 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.73-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.14.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled, and installed onto my Raspberry Pi. No initial issues noticed in dmesg or general usage. Thanks! Nathan
Re: [PATCH] IB/mlx4: Avoid implicit enumerated type conversion
On Thu, Sep 27, 2018 at 01:13:31PM -0700, Nick Desaulniers wrote:
> On Wed, Sep 26, 2018 at 9:48 PM Jason Gunthorpe wrote:
> >
> > On Wed, Sep 26, 2018 at 06:08:03PM -0700, Nathan Chancellor wrote:
> > > On Mon, Sep 24, 2018 at 08:37:22PM -0600, Jason Gunthorpe wrote:
> > > > On Mon, Sep 24, 2018 at 03:29:38PM -0700, Nick Desaulniers wrote:
> > > > > On Mon, Sep 24, 2018 at 3:27 PM Nathan Chancellor
> > > > > wrote:
> > > > > >
> > > > > > On Mon, Sep 24, 2018 at 03:24:36PM -0700, Nick Desaulniers wrote:
> > > > > > > On Mon, Sep 24, 2018 at 12:57 PM Nathan Chancellor
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Clang warns when one enumerated type is implicitly converted to
> > > > > > > > another.
> > > > > > > >
> > > > > > > > drivers/infiniband/hw/mlx4/mad.c:1811:41: warning: implicit
> > > > > > > > conversion
> > > > > > > > from enumeration type 'enum mlx4_ib_qp_flags' to different
> > > > > > > > enumeration
> > > > > > > > type 'enum ib_qp_create_flags' [-Wenum-conversion]
> > > > > > > > qp_init_attr.init_attr.create_flags =
> > > > > > > > MLX4_IB_SRIOV_TUNNEL_QP;
> > > > > > > > ~
> > > > > > > > ^~~
> > > > > > > >
> > > > > > > > drivers/infiniband/hw/mlx4/mad.c:1819:41: warning: implicit
> > > > > > > > conversion
> > > > > > > > from enumeration type 'enum mlx4_ib_qp_flags' to different
> > > > > > > > enumeration
> > > > > > > > type 'enum ib_qp_create_flags' [-Wenum-conversion]
> > > > > > > > qp_init_attr.init_attr.create_flags =
> > > > > > > > MLX4_IB_SRIOV_SQP;
> > > > > > > > ~
> > > > > > > > ^
> > > > > > > >
> > > > > > > > The type mlx4_ib_qp_flags explicitly provides supplemental
> > > > > > > > values to the
> > > > > > > > type ib_qp_create_flags. Make that clear to Clang by changing
> > > > > > > > the
> > > > > > > > create_flags type to u32.
> > > > > > > >
> > > > > > > > Reported-by: Nick Desaulniers
> > > > > > > > Signed-off-by: Nathan Chancellor
> > > > > > > > include/rdma/ib_verbs.h | 2 +-
> > > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > > >
> > > > > > > > diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
> > > > > > > > index e463d3007a35..f6f4d9e3c8ed 100644
> > > > > > > > +++ b/include/rdma/ib_verbs.h
> > > > > > > > @@ -1149,7 +1149,7 @@ struct ib_qp_init_attr {
> > > > > > > > struct ib_qp_capcap;
> > > > > > > > enum ib_sig_typesq_sig_type;
> > > > > > > > enum ib_qp_type qp_type;
> > > > > > > > - enum ib_qp_create_flags create_flags;
> > > > > > > > + u32 create_flags;
> > > > > > >
> > > > > > > I think it might be better to just have explicit casts at the
> > > > > > > assignment. What do the maintainers think?
> > > > > > >
> > > > > >
> > > > > > That's fine with me, I tend to explicitly cast if it is only one
> > > > > > location but it certainly makes sense in this case as well. I'll
> > > > > > wait for the maintainers to weigh in before sending a v2.
> > > > >
> > > > > Yeah, I mean my opinion on this might seem arbitrary, but based on the
> > > > > pattern and the comment in ib_qp_create_flags, those enum values are
> > > > > reserved to be "subclassed" in a sense, so they should always be in
> > > > > sync or this code will have bigger problems.
> > > >
> > > > One should not use an 'enum' type name for bitfield storage, as once
> > > > you start or'ing things together the values no longer fall on the
> > > > enum. Some compilers and tools even give warnings in this case, ie
> > > >
> > > >enum x foo = X_A | X_B;
> > > >
> > > > Is an assignment from 'int' to an 'enum x' with an implicit cast.
> > > >
> > > > For this reason, usually bitfield enum declarations should be
> > > > anonymous.
> > > >
> > > > Jason
> > >
> > > Hi Jason,
> > >
> > > I apologize for not understanding but how should I adjust my patch so
> > > that it is acceptable? Do you want the explicit casts like Nick
> > > suggested?
> >
> > No, I think your original patch is fine, I was waiting to see if you
> > or Nick disagreed with my assessment on bitfields..
>
> It wasn't clear to me whether you were ack'ing or nack'ing the patch.
> If we don't change the patch to explicit casts, shouldn't the change
> be to make create_flags an int? (note: signedness)
>
> --
> Thanks,
> ~Nick Desaulniers
Neither ib_qp_create_flags nor mlx4_ib_qp_flags have negative values, is
signedness necessary?
Nathan
Re: [PATCH] RDMA/qedr: Explicitly cast pkt->tx_dest to qed_ll2_tx_dest
On Thu, Sep 27, 2018 at 01:28:12PM -0700, Nick Desaulniers wrote:
> On Wed, Sep 26, 2018 at 6:18 PM Nathan Chancellor
> wrote:
> >
> > Clang warns when one enumerated type is explicitly converted to another.
> >
> > drivers/infiniband/hw/qedr/qedr_roce_cm.c:198:28: warning: implicit
> > conversion from enumeration type 'enum qed_roce_ll2_tx_dest' to
> > different enumeration type 'enum qed_ll2_tx_dest' [-Wenum-conversion]
> > ll2_tx_pkt.tx_dest = pkt->tx_dest;
> >~ ~^~~
> > 1 warning generated.
> >
> > Avoid this warning by explicitly casting pkt->tx_dest to
> > qed_112_tx_dest, which has the expected values from the
> > type qed_roce_ll2_tx_dest.
>
> But these enums are different lengths, which is problematic for this
> patch. Is this code broken, or that it's ok for ll2_tx_pkt.tx_dest to
> have a value that's not a valid enumeration value for enum
> qed_ll2_tx_dest? (QED_LL2_TX_DEST_MAX 's value (3) is outside the
> enumeration values of enum qed_roce_ll2_tx_dest).
>
> include/linux/qed/qed_rdma_if.h:
> 42 enum qed_roce_ll2_tx_dest {
> 43 /* Light L2 TX Destination to the Network */
> 44 QED_ROCE_LL2_TX_DEST_NW,
> 45
> 46 /* Light L2 TX Destination to the Loopback */
> 47 QED_ROCE_LL2_TX_DEST_LB,
> 48 QED_ROCE_LL2_TX_DEST_MAX
> 49 };
>
> include/linux/qed/qed_ll2_if.h:
> 64 enum qed_ll2_tx_dest {
> 65 QED_LL2_TX_DEST_NW, /* Light L2 TX Destination to the
> Network */
> 66 QED_LL2_TX_DEST_LB, /* Light L2 TX Destination to the
> Loopback */
> 67 QED_LL2_TX_DEST_DROP, /* Light L2 Drop the TX packet */
> 68 QED_LL2_TX_DEST_MAX
> 69 };
>
> Maybe the maintainers can clarify?
>
My assumption was that if QED_ROCE_LL2_TX_DEST_MAX was used that the
packet would be dropped.
Turns out that QED_ROCE_LL2_TX_DEST_MAX isn't actually used anywhere in
the tree. I suppose that qed_roce_ll2_tx_dest could just be removed and
all other instances of those values could be converted to
qed_ll2_tx_dest like the rxe patch. I'll test this now and send a patch
along if it works out.
Nathan
> >
> > Reported-by: Nick Desaulniers
> > Signed-off-by: Nathan Chancellor
> > ---
> > drivers/infiniband/hw/qedr/qedr_roce_cm.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/infiniband/hw/qedr/qedr_roce_cm.c
> > b/drivers/infiniband/hw/qedr/qedr_roce_cm.c
> > index 85578887421b..147e0d69003d 100644
> > --- a/drivers/infiniband/hw/qedr/qedr_roce_cm.c
> > +++ b/drivers/infiniband/hw/qedr/qedr_roce_cm.c
> > @@ -195,7 +195,7 @@ static int qedr_ll2_post_tx(struct qedr_dev *dev,
> >
> > ll2_tx_pkt.num_of_bds = 1 /* hdr */ + pkt->n_seg;
> > ll2_tx_pkt.vlan = 0;
> > - ll2_tx_pkt.tx_dest = pkt->tx_dest;
> > + ll2_tx_pkt.tx_dest = (enum qed_ll2_tx_dest)pkt->tx_dest;
> > ll2_tx_pkt.qed_roce_flavor = roce_flavor;
> > ll2_tx_pkt.first_frag = pkt->header.baddr;
> > ll2_tx_pkt.first_frag_len = pkt->header.len;
> > --
> > 2.19.0
> >
>
>
> --
> Thanks,
> ~Nick Desaulniers
Re: [PATCH] IB/mlx4: Avoid implicit enumerated type conversion
On Thu, Sep 27, 2018 at 01:34:16PM -0700, Nick Desaulniers wrote:
> On Thu, Sep 27, 2018 at 1:28 PM Nathan Chancellor
> wrote:
> >
> > On Thu, Sep 27, 2018 at 01:13:31PM -0700, Nick Desaulniers wrote:
> > > On Wed, Sep 26, 2018 at 9:48 PM Jason Gunthorpe wrote:
> > > >
> > > > On Wed, Sep 26, 2018 at 06:08:03PM -0700, Nathan Chancellor wrote:
> > > > > On Mon, Sep 24, 2018 at 08:37:22PM -0600, Jason Gunthorpe wrote:
> > > > > > On Mon, Sep 24, 2018 at 03:29:38PM -0700, Nick Desaulniers wrote:
> > > > > > > On Mon, Sep 24, 2018 at 3:27 PM Nathan Chancellor
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Mon, Sep 24, 2018 at 03:24:36PM -0700, Nick Desaulniers
> > > > > > > > wrote:
> > > > > > > > > On Mon, Sep 24, 2018 at 12:57 PM Nathan Chancellor
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > Clang warns when one enumerated type is implicitly
> > > > > > > > > > converted to another.
> > > > > > > > > >
> > > > > > > > > > drivers/infiniband/hw/mlx4/mad.c:1811:41: warning: implicit
> > > > > > > > > > conversion
> > > > > > > > > > from enumeration type 'enum mlx4_ib_qp_flags' to different
> > > > > > > > > > enumeration
> > > > > > > > > > type 'enum ib_qp_create_flags' [-Wenum-conversion]
> > > > > > > > > > qp_init_attr.init_attr.create_flags =
> > > > > > > > > > MLX4_IB_SRIOV_TUNNEL_QP;
> > > > > > > > > > ~
> > > > > > > > > > ^~~
> > > > > > > > > >
> > > > > > > > > > drivers/infiniband/hw/mlx4/mad.c:1819:41: warning: implicit
> > > > > > > > > > conversion
> > > > > > > > > > from enumeration type 'enum mlx4_ib_qp_flags' to different
> > > > > > > > > > enumeration
> > > > > > > > > > type 'enum ib_qp_create_flags' [-Wenum-conversion]
> > > > > > > > > > qp_init_attr.init_attr.create_flags =
> > > > > > > > > > MLX4_IB_SRIOV_SQP;
> > > > > > > > > > ~
> > > > > > > > > > ^
> > > > > > > > > >
> > > > > > > > > > The type mlx4_ib_qp_flags explicitly provides supplemental
> > > > > > > > > > values to the
> > > > > > > > > > type ib_qp_create_flags. Make that clear to Clang by
> > > > > > > > > > changing the
> > > > > > > > > > create_flags type to u32.
> > > > > > > > > >
> > > > > > > > > > Reported-by: Nick Desaulniers
> > > > > > > > > > Signed-off-by: Nathan Chancellor
> > > > > > > > > > include/rdma/ib_verbs.h | 2 +-
> > > > > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > > > > >
> > > > > > > > > > diff --git a/include/rdma/ib_verbs.h
> > > > > > > > > > b/include/rdma/ib_verbs.h
> > > > > > > > > > index e463d3007a35..f6f4d9e3c8ed 100644
> > > > > > > > > > +++ b/include/rdma/ib_verbs.h
> > > > > > > > > > @@ -1149,7 +1149,7 @@ struct ib_qp_init_attr {
> > > > > > > > > > struct ib_qp_capcap;
> > > > > > > > > > enum ib_sig_typesq_sig_type;
> > > > > > > > > > enum ib_qp_type qp_type;
> > > > > > > > > > - enum ib_qp_create_flags create_flags;
> > > > > > > > > > + u32 create_flags;
> > > > > > > > >
> > > > > > > > > I think it might be better to just have explicit casts at the
> > > > > >
[PATCH v2] IB/mlx4: Avoid implicit enumerated type conversion
Clang warns when one enumerated type is implicitly converted to another.
drivers/infiniband/hw/mlx4/mad.c:1811:41: warning: implicit conversion
from enumeration type 'enum mlx4_ib_qp_flags' to different enumeration
type 'enum ib_qp_create_flags' [-Wenum-conversion]
qp_init_attr.init_attr.create_flags = MLX4_IB_SRIOV_TUNNEL_QP;
~ ^~~
drivers/infiniband/hw/mlx4/mad.c:1819:41: warning: implicit conversion
from enumeration type 'enum mlx4_ib_qp_flags' to different enumeration
type 'enum ib_qp_create_flags' [-Wenum-conversion]
qp_init_attr.init_attr.create_flags = MLX4_IB_SRIOV_SQP;
~ ^
The type mlx4_ib_qp_flags explicitly provides supplemental values to the
type ib_qp_create_flags. Make that clear to Clang by changing the
create_flags type to int.
Reported-by: Nick Desaulniers
Signed-off-by: Nathan Chancellor
---
v1 -> v2:
* Use int instead of u32 since enums are restricted to this range, as
suggested by Nick.
include/rdma/ib_verbs.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index 0d822a9db300..e5ec04e844cd 100644
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@ -1151,7 +1151,7 @@ struct ib_qp_init_attr {
struct ib_qp_capcap;
enum ib_sig_typesq_sig_type;
enum ib_qp_type qp_type;
- enum ib_qp_create_flags create_flags;
+ int create_flags;
/*
* Only needed for special QP types, or when using the RW API.
--
2.19.0
[PATCH v2] RDMA/qedr: Remove enumerated type qed_roce_ll2_tx_dest
Clang warns when one enumerated type is explicitly converted to another.
drivers/infiniband/hw/qedr/qedr_roce_cm.c:198:28: warning: implicit
conversion from enumeration type 'enum qed_roce_ll2_tx_dest' to
different enumeration type 'enum qed_ll2_tx_dest' [-Wenum-conversion]
ll2_tx_pkt.tx_dest = pkt->tx_dest;
~ ~^~~
1 warning generated.
Turns out that QED_ROCE_LL2_TX_DEST_NW and QED_ROCE_LL2_TX_DEST_LB are
only used once in the whole tree and QED_ROCE_LL2_TX_DEST_MAX is used
nowhere. Remove them and use the equivalent values from qed_ll2_tx_dest
in their place.
Reported-by: Nick Desaulniers
Signed-off-by: Nathan Chancellor
---
v1 -> v2:
* Rather than using an explicit cast, just convert the uses to the
appropriate values and delete the duplicated enum.
drivers/infiniband/hw/qedr/qedr_roce_cm.c | 4 ++--
include/linux/qed/qed_rdma_if.h | 11 +--
2 files changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/infiniband/hw/qedr/qedr_roce_cm.c
b/drivers/infiniband/hw/qedr/qedr_roce_cm.c
index 85578887421b..e1ac2fd60bb1 100644
--- a/drivers/infiniband/hw/qedr/qedr_roce_cm.c
+++ b/drivers/infiniband/hw/qedr/qedr_roce_cm.c
@@ -519,9 +519,9 @@ static inline int qedr_gsi_build_packet(struct qedr_dev
*dev,
}
if (ether_addr_equal(udh.eth.smac_h, udh.eth.dmac_h))
- packet->tx_dest = QED_ROCE_LL2_TX_DEST_LB;
+ packet->tx_dest = QED_LL2_TX_DEST_LB;
else
- packet->tx_dest = QED_ROCE_LL2_TX_DEST_NW;
+ packet->tx_dest = QED_LL2_TX_DEST_NW;
packet->roce_mode = roce_mode;
memcpy(packet->header.vaddr, ud_header_buffer, header_size);
diff --git a/include/linux/qed/qed_rdma_if.h b/include/linux/qed/qed_rdma_if.h
index df4d13f7e191..d15f8e4815e3 100644
--- a/include/linux/qed/qed_rdma_if.h
+++ b/include/linux/qed/qed_rdma_if.h
@@ -39,15 +39,6 @@
#include
#include
-enum qed_roce_ll2_tx_dest {
- /* Light L2 TX Destination to the Network */
- QED_ROCE_LL2_TX_DEST_NW,
-
- /* Light L2 TX Destination to the Loopback */
- QED_ROCE_LL2_TX_DEST_LB,
- QED_ROCE_LL2_TX_DEST_MAX
-};
-
#define QED_RDMA_MAX_CNQ_SIZE (0x)
/* rdma interface */
@@ -581,7 +572,7 @@ struct qed_roce_ll2_packet {
int n_seg;
struct qed_roce_ll2_buffer payload[RDMA_MAX_SGE_PER_SQ_WQE];
int roce_mode;
- enum qed_roce_ll2_tx_dest tx_dest;
+ enum qed_ll2_tx_dest tx_dest;
};
enum qed_rdma_type {
--
2.19.0
Re: [PATCH] scsi: bfa: Avoid implicit enum conversion in bfad_im_post_vendor_event
On Thu, Sep 27, 2018 at 04:35:37PM -0700, Nick Desaulniers wrote:
> On Tue, Sep 25, 2018 at 9:58 PM Nathan Chancellor
> wrote:
> >
> > Clang warns when one enumerated type is implicitly converted to another.
> >
> > drivers/scsi/bfa/bfa_fcs_lport.c:379:26: warning: implicit conversion
> > from enumeration type 'enum bfa_lport_aen_event' to different
> > enumeration type 'enum bfa_ioc_aen_event' [-Wenum-conversion]
> > BFA_AEN_CAT_LPORT, event);
> > ^
> >
> > The root cause of these warnings is the bfad_im_post_vendor_event
> > function, which expects a value from enum bfa_ioc_aen_event but there
> > are multiple instances of values from enums bfa_port_aen_event,
> > bfa_audit_aen_event, and bfa_lport_aen_event being used in this
> > function.
>
> Indeed, it seems that bfad_im_post_vendor_event() assigns this parameter to
> 161 entry->aen_type = evt;
>
> which is defined as:
>
> 1456 u32 aen_type;
>
> so already we know that aen_type is meant to be a grab bag of enum
> values. bfad_im_post_vendor_event() is already passed many different
> types of enums, as you mention. Does changing aen_type to an `int`
> produce further warnings, because it would be nice to have that change
> in this one, too. AFAICT, it's only ever saved away in a containing
> struct.
>
No, it doesn't introduce any new warnings. I can send that as a v2 here shortly.
Nathan
> >
> > Given that this doesn't appear to be a problem since cat helps with
> > differentiating the events, just change evt's type to int so that no
> > conversion needs to happen and Clang won't warn.
> >
> > Link: https://github.com/ClangBuiltLinux/linux/issues/147
> > Signed-off-by: Nathan Chancellor
> > ---
> >
> > The alternate way of fixing these warnings is to explicitly cast the
> > conversion when calling the function but since there are about 8-10 of
> > these warnings, it seems logical to just change the function definiton
> > which is cleaner in my opinion.
> >
> > See commits 3eb95feac113 ("mm/zsmalloc.c: change stat type parameter to
> > int") and 04fecbf51b3c ("mm: memcontrol: use int for event/state
> > parameter in several functions") for similar fixes.
> >
> > drivers/scsi/bfa/bfad_im.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/scsi/bfa/bfad_im.h b/drivers/scsi/bfa/bfad_im.h
> > index e61ed8dad0b4..bd4ac187fd8e 100644
> > --- a/drivers/scsi/bfa/bfad_im.h
> > +++ b/drivers/scsi/bfa/bfad_im.h
> > @@ -143,7 +143,7 @@ struct bfad_im_s {
> > static inline void bfad_im_post_vendor_event(struct bfa_aen_entry_s *entry,
> > struct bfad_s *drv, int cnt,
> > enum bfa_aen_category cat,
> > -enum bfa_ioc_aen_event evt)
> > +int evt)
> > {
> > struct timespec64 ts;
> >
> > --
> > 2.19.0
> >
>
>
> --
> Thanks,
> ~Nick Desaulniers
[PATCH v2] scsi: bfa: Avoid implicit enum conversion in bfad_im_post_vendor_event
Clang warns when one enumerated type is implicitly converted to another.
drivers/scsi/bfa/bfa_fcs_lport.c:379:26: warning: implicit conversion
from enumeration type 'enum bfa_lport_aen_event' to different
enumeration type 'enum bfa_ioc_aen_event' [-Wenum-conversion]
BFA_AEN_CAT_LPORT, event);
^
The root cause of these warnings is the bfad_im_post_vendor_event
function, which expects a value from enum bfa_ioc_aen_event but there
are multiple instances of values from enums bfa_port_aen_event,
bfa_audit_aen_event, and bfa_lport_aen_event being used in this
function.
Given that this doesn't appear to be a problem since cat helps with
differentiating the events, just change evt's type to int so that no
conversion needs to happen and Clang won't warn. Update aen_type's type
in bfa_aen_entry_s as members that hold enumerated types should be int.
Link: https://github.com/ClangBuiltLinux/linux/issues/147
Signed-off-by: Nathan Chancellor
---
v1 -> v2:
* Update aen_type's type in bfa_aen_entry_s to match evt
drivers/scsi/bfa/bfa_defs_svc.h | 2 +-
drivers/scsi/bfa/bfad_im.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/bfa/bfa_defs_svc.h b/drivers/scsi/bfa/bfa_defs_svc.h
index 3d0c96a5c873..c19c26e0e405 100644
--- a/drivers/scsi/bfa/bfa_defs_svc.h
+++ b/drivers/scsi/bfa/bfa_defs_svc.h
@@ -1453,7 +1453,7 @@ union bfa_aen_data_u {
struct bfa_aen_entry_s {
struct list_headqe;
enum bfa_aen_category aen_category;
- u32 aen_type;
+ int aen_type;
union bfa_aen_data_uaen_data;
u64 aen_tv_sec;
u64 aen_tv_usec;
diff --git a/drivers/scsi/bfa/bfad_im.h b/drivers/scsi/bfa/bfad_im.h
index e61ed8dad0b4..bd4ac187fd8e 100644
--- a/drivers/scsi/bfa/bfad_im.h
+++ b/drivers/scsi/bfa/bfad_im.h
@@ -143,7 +143,7 @@ struct bfad_im_s {
static inline void bfad_im_post_vendor_event(struct bfa_aen_entry_s *entry,
struct bfad_s *drv, int cnt,
enum bfa_aen_category cat,
-enum bfa_ioc_aen_event evt)
+int evt)
{
struct timespec64 ts;
--
2.19.0
[PATCH] staging: bcm2835-camera: Avoid unneeded internal declaration warning
Clang warns:
drivers/staging/vc04_services/bcm2835-camera/controls.c:59:18: warning:
variable 'mains_freq_qmenu' is not needed and will not be emitted
[-Wunneeded-internal-declaration]
static const s64 mains_freq_qmenu[] = {
^
1 warning generated.
This is because mains_freq_qmenu is currently only used in an ARRAY_SIZE
macro, which is a compile time evaluation in this case. Avoid this by
adding mains_freq_qmenu as the imenu member of this structure, which
matches all other controls that uses the ARRAY_SIZE macro in v4l2_ctrls.
This turns out to be a no-op because V4L2_CID_MPEG_VIDEO_BITRATE_MODE is
defined as a MMAL_CONTROL_TYPE_STD_MENU, which does not pass the imenu
definition along to v4l2_ctrl_new in bm2835_mmal_init_controls.
Link: https://github.com/ClangBuiltLinux/linux/issues/122
Signed-off-by: Nathan Chancellor
---
drivers/staging/vc04_services/bcm2835-camera/controls.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/vc04_services/bcm2835-camera/controls.c
b/drivers/staging/vc04_services/bcm2835-camera/controls.c
index cff7b1e07153..a2c55cb2192a 100644
--- a/drivers/staging/vc04_services/bcm2835-camera/controls.c
+++ b/drivers/staging/vc04_services/bcm2835-camera/controls.c
@@ -1106,7 +1106,7 @@ static const struct bm2835_mmal_v4l2_ctrl
v4l2_ctrls[V4L2_CTRL_COUNT] = {
{
V4L2_CID_POWER_LINE_FREQUENCY, MMAL_CONTROL_TYPE_STD_MENU,
0, ARRAY_SIZE(mains_freq_qmenu) - 1,
- 1, 1, NULL,
+ 1, 1, mains_freq_qmenu,
MMAL_PARAMETER_FLICKER_AVOID,
&ctrl_set_flicker_avoidance,
false
--
2.19.0
Re: [PATCH] mfd: cros_ec: Avoid unneeded internal declaration warning
On Wed, Sep 26, 2018 at 08:33:17PM -0700, Nathan Chancellor wrote:
> Clang warns:
>
> drivers/mfd/cros_ec_dev.c:509:40: warning: variable 'cros_ec_id' is not
> needed and will not be emitted [-Wunneeded-internal-declaration]
> static const struct platform_device_id cros_ec_id[] = {
>^
> 1 warning generated.
>
> Avoid this warning by adding it to the cros_ec_dev_driver definition
> under the id_table member like all other platform drivers.
>
> Signed-off-by: Nathan Chancellor
> ---
>
> I looked at several drivers with platform_device_id defintions and I
> didn't really find any where the definition wasn't then added to the
> platform_driver so I'm not sure if this was just missed in commit
> afbf8ec7c4f9 ("platform/chrome: cros_ec_dev - Add a platform
> device ID table") or if it was an intentional omission. I'm not super
> familiar with the inner workings of platform devices.
>
> Should this commit be undesirable, the warning can be silenced with the
> __used attribute but this seemed like a more proper first commit.
>
> drivers/mfd/cros_ec_dev.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
> index 999dac752bcc..8f9d6964173e 100644
> --- a/drivers/mfd/cros_ec_dev.c
> +++ b/drivers/mfd/cros_ec_dev.c
> @@ -546,6 +546,7 @@ static struct platform_driver cros_ec_dev_driver = {
> .name = DRV_NAME,
> .pm = &cros_ec_dev_pm_ops,
> },
> + .id_table = cros_ec_id,
> .probe = ec_device_probe,
> .remove = ec_device_remove,
> .shutdown = ec_device_shutdown,
> --
> 2.19.0
>
It just occurred to me I probably should have added some of the Chromium
guys who have modified this driver to this patch. I've done that now.
Nathan
Re: [PATCH] staging: bcm2835-camera: Avoid unneeded internal declaration warning
On Fri, Sep 28, 2018 at 10:04:29AM +0100, Dave Stevenson wrote:
> Hi Nate
>
> Thanks for the patch.
>
> On Fri, 28 Sep 2018 at 01:53, Nathan Chancellor
> wrote:
> >
> > Clang warns:
> >
> > drivers/staging/vc04_services/bcm2835-camera/controls.c:59:18: warning:
> > variable 'mains_freq_qmenu' is not needed and will not be emitted
> > [-Wunneeded-internal-declaration]
> > static const s64 mains_freq_qmenu[] = {
> > ^
> > 1 warning generated.
> >
> > This is because mains_freq_qmenu is currently only used in an ARRAY_SIZE
> > macro, which is a compile time evaluation in this case. Avoid this by
> > adding mains_freq_qmenu as the imenu member of this structure, which
> > matches all other controls that uses the ARRAY_SIZE macro in v4l2_ctrls.
> > This turns out to be a no-op because V4L2_CID_MPEG_VIDEO_BITRATE_MODE is
> > defined as a MMAL_CONTROL_TYPE_STD_MENU, which does not pass the imenu
> > definition along to v4l2_ctrl_new in bm2835_mmal_init_controls.
>
> There's a slight confusion betwen V4L2_CID_MPEG_VIDEO_BITRATE_MODE and
> V4L2_CID_POWER_LINE_FREQUENCY in your description.
>
> However you're right that MMAL_CONTROL_TYPE_STD_MENU calls
> v4l2_ctrl_new_std_menu which doesn't need a menu array (it's
> v4l2_ctrl_new_int_menu that does). That means the correct fix is to
> define the max value using the relevant enum (in this case
> V4L2_CID_POWER_LINE_FREQUENCY_AUTO) and remove the array.
>
> The same is true for V4L2_CID_MPEG_VIDEO_BITRATE_MODE - max should be
> V4L2_MPEG_VIDEO_BITRATE_MODE_CBR, and remove the bitrate_mode_qmenu
> array.
>
> Thanks,
> Dave
>
Hi Dave,
Thank you for the review, I appreciate it. I had certainly considered
that solution first butnfigured this was the more conservative change.
I will send a v2 soon with the suggested change.
Nathan
> > Link: https://github.com/ClangBuiltLinux/linux/issues/122
> > Signed-off-by: Nathan Chancellor
> > ---
> > drivers/staging/vc04_services/bcm2835-camera/controls.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/staging/vc04_services/bcm2835-camera/controls.c
> > b/drivers/staging/vc04_services/bcm2835-camera/controls.c
> > index cff7b1e07153..a2c55cb2192a 100644
> > --- a/drivers/staging/vc04_services/bcm2835-camera/controls.c
> > +++ b/drivers/staging/vc04_services/bcm2835-camera/controls.c
> > @@ -1106,7 +1106,7 @@ static const struct bm2835_mmal_v4l2_ctrl
> > v4l2_ctrls[V4L2_CTRL_COUNT] = {
> > {
> > V4L2_CID_POWER_LINE_FREQUENCY, MMAL_CONTROL_TYPE_STD_MENU,
> > 0, ARRAY_SIZE(mains_freq_qmenu) - 1,
> > - 1, 1, NULL,
> > + 1, 1, mains_freq_qmenu,
> > MMAL_PARAMETER_FLICKER_AVOID,
> > &ctrl_set_flicker_avoidance,
> > false
> > --
> > 2.19.0
> >
> >
> > ___
> > linux-rpi-kernel mailing list
> > linux-rpi-ker...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-rpi-kernel
[PATCH] soc/tegra: Fix terminating condition
Clang warns:
drivers/soc/tegra/common.c:27:16: error: address of array
'match->compatible' will always evaluate to 'true'
[-Werror,-Wpointer-bool-conversion]
while (match->compatible) {
~ ~~~^~
1 error generated.
Whoops, we have an infinite loop and QEMU no longer boots...
https://travis-ci.com/ClangBuiltLinux/continuous-integration/jobs/160242918
Check that the first character of the string isn't null so that the loop
properly terminates.
Fixes: c57eff9503a5 ("soc/tegra: refactor soc_is_tegra()")
Signed-off-by: Nathan Chancellor
---
drivers/soc/tegra/common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/tegra/common.c b/drivers/soc/tegra/common.c
index 8a538b968fe9..54627ca957e8 100644
--- a/drivers/soc/tegra/common.c
+++ b/drivers/soc/tegra/common.c
@@ -24,7 +24,7 @@ bool soc_is_tegra(void)
{
const struct of_device_id *match = tegra_machine_match;
- while (match->compatible) {
+ while (match->compatible[0]) {
if (of_machine_is_compatible(match->compatible))
return true;
--
2.20.0.rc1
[PATCH 4.14] kbuild: allow to use GCC toolchain not in Clang search path
From: Stefan Agner commit ef8c4ed9db80261f397f0c0bf723684601ae3b52 upstream. When using a GCC cross toolchain which is not in a compiled in Clang search path, Clang reverts to the system assembler and linker. This leads to assembler or linker errors, depending on which tool is first used for a given architecture. It seems that Clang is not searching $PATH for a matching assembler or linker. Make sure that Clang picks up the correct assembler or linker by passing the cross compilers bin directory as search path. This allows to use Clang provided by distributions with GCC toolchains not in /usr/bin. Link: https://github.com/ClangBuiltLinux/linux/issues/78 Signed-off-by: Stefan Agner Reviewed-and-tested-by: Nick Desaulniers Signed-off-by: Masahiro Yamada [nc: Adjust context] Signed-off-by: Nathan Chancellor --- Makefile | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index 874d72a3e6a7..cb131e135c42 100644 --- a/Makefile +++ b/Makefile @@ -480,13 +480,15 @@ endif ifeq ($(cc-name),clang) ifneq ($(CROSS_COMPILE),) CLANG_TARGET := --target=$(notdir $(CROSS_COMPILE:%-=%)) -GCC_TOOLCHAIN := $(realpath $(dir $(shell which $(LD)))/..) +GCC_TOOLCHAIN_DIR := $(dir $(shell which $(LD))) +CLANG_PREFIX := --prefix=$(GCC_TOOLCHAIN_DIR) +GCC_TOOLCHAIN := $(realpath $(GCC_TOOLCHAIN_DIR)/..) endif ifneq ($(GCC_TOOLCHAIN),) CLANG_GCC_TC := --gcc-toolchain=$(GCC_TOOLCHAIN) endif -KBUILD_CFLAGS += $(CLANG_TARGET) $(CLANG_GCC_TC) -KBUILD_AFLAGS += $(CLANG_TARGET) $(CLANG_GCC_TC) +KBUILD_CFLAGS += $(CLANG_TARGET) $(CLANG_GCC_TC) $(CLANG_PREFIX) +KBUILD_AFLAGS += $(CLANG_TARGET) $(CLANG_GCC_TC) $(CLANG_PREFIX) KBUILD_CFLAGS += $(call cc-option, -no-integrated-as) KBUILD_AFLAGS += $(call cc-option, -no-integrated-as) endif -- 2.20.0.rc1
Re: [PATCH] arm64: io: specify asm operand width for __iormb()
On Thu, Nov 29, 2018 at 10:49:03AM +, Will Deacon wrote:
> On Thu, Nov 29, 2018 at 09:03:54AM +, Julien Thierry wrote:
> >
> >
> > On 29/11/18 04:19, Nick Desaulniers wrote:
> > > Fixes the warning produced from Clang:
> > > ./include/asm-generic/io.h:711:9: warning: value size does not match
> > > register size specified by the constraint and modifier
> > > [-Wasm-operand-widths]
> > > return readl(addr);
> > >^
> > > ./arch/arm64/include/asm/io.h:149:58: note: expanded from macro 'readl'
> > > ^
> > > ./include/asm-generic/io.h:711:9: note: use constraint modifier "w"
> > > ./arch/arm64/include/asm/io.h:149:50: note: expanded from macro 'readl'
> > > ^
> > > ./arch/arm64/include/asm/io.h:118:25: note: expanded from macro '__iormb'
> > > asm volatile("eor %w0, %1, %1\n" \
> > > ^
> >
> > Why does the "eor %0, %1, %1" become "eor %w0, %1, %1" ?
> > The variable passed to the inline assembly for %0 is unsigned long, so
> > always 64-bits wide on arm64. Why is clang trying to use a 32-bit
> > register for it?
Sorry, this was my fault, I accidentally added a w during testing to see
what constraints were valid (given that my assembly knowledge is nearly
non-existence so forgive the non-sensical experimentation) and I used
that message rather than the original one. This is the unadulterated one.
In file included from arch/arm64/kernel/asm-offsets.c:24:
In file included from ./include/linux/dma-mapping.h:11:
In file included from ./include/linux/scatterlist.h:9:
In file included from ./arch/arm64/include/asm/io.h:209:
./include/asm-generic/io.h:695:9: warning: value size does not match register
size specified by the constraint and modifier [-Wasm-operand-widths]
return readb(addr);
^
./arch/arm64/include/asm/io.h:147:58: note: expanded from macro 'readb'
#define readb(c)({ u8 __v = readb_relaxed(c); __iormb(__v);
__v; })
^
./include/asm-generic/io.h:695:9: note: use constraint modifier "w"
./arch/arm64/include/asm/io.h:147:50: note: expanded from macro 'readb'
#define readb(c)({ u8 __v = readb_relaxed(c); __iormb(__v);
__v; })
^
./arch/arm64/include/asm/io.h:118:24: note: expanded from macro '__iormb'
asm volatile("eor %0, %1, %1\n" \
^
>
> Yeah, the message above looks bogus to me. I can see %1 being 32-bit for
> read[bwl], so maybe clang is just getting the diagnostic wrong. If so,
> I wonder if the following fixes the problem:
>
This doesn't appear to work, I get this error:
In file included from arch/arm64/kernel/asm-offsets.c:24:
In file included from ./include/linux/dma-mapping.h:11:
In file included from ./include/linux/scatterlist.h:9:
In file included from ./arch/arm64/include/asm/io.h:209:
./include/asm-generic/io.h:695:9: error: expected expression
return readb(addr);
^
./arch/arm64/include/asm/io.h:147:50: note: expanded from macro 'readb'
#define readb(c)({ u8 __v = readb_relaxed(c); __iormb(__v);
__v; })
^
./arch/arm64/include/asm/io.h:120:28: note: expanded from macro '__iormb'
: "=r" (tmp) : "r" (unsigned long)(v) : "memory"); \
^
>
> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
> index d42d00d8d5b6..13befec8b64e 100644
> --- a/arch/arm64/include/asm/io.h
> +++ b/arch/arm64/include/asm/io.h
> @@ -117,7 +117,7 @@ static inline u64 __raw_readq(const volatile void __iomem
> *addr)
> */ \
> asm volatile("eor %0, %1, %1\n" \
> "cbnz %0, ." \
> -: "=r" (tmp) : "r" (v) : "memory");\
> +: "=r" (tmp) : "r" (unsigned long)(v) : "memory"); \
> })
>
> #define __iowmb() wmb()
>
>
> Will
Re: [PATCH] arm64: io: specify asm operand width for __iormb()
On Thu, Nov 29, 2018 at 04:13:37PM +, Will Deacon wrote:
> On Thu, Nov 29, 2018 at 09:10:39AM -0700, Nathan Chancellor wrote:
> > On Thu, Nov 29, 2018 at 10:49:03AM +, Will Deacon wrote:
> > > On Thu, Nov 29, 2018 at 09:03:54AM +, Julien Thierry wrote:
> > > > On 29/11/18 04:19, Nick Desaulniers wrote:
> > > > > Fixes the warning produced from Clang:
> > > > > ./include/asm-generic/io.h:711:9: warning: value size does not match
> > > > > register size specified by the constraint and modifier
> > > > > [-Wasm-operand-widths]
> > > > > return readl(addr);
> > > > >^
> > > > > ./arch/arm64/include/asm/io.h:149:58: note: expanded from macro
> > > > > 'readl'
> > > > > ^
> > > > > ./include/asm-generic/io.h:711:9: note: use constraint modifier "w"
> > > > > ./arch/arm64/include/asm/io.h:149:50: note: expanded from macro
> > > > > 'readl'
> > > > > ^
> > > > > ./arch/arm64/include/asm/io.h:118:25: note: expanded from macro
> > > > > '__iormb'
> > > > > asm volatile("eor %w0, %1, %1\n" \
> > > > > ^
> > > >
> > > > Why does the "eor %0, %1, %1" become "eor %w0, %1, %1" ?
> > > > The variable passed to the inline assembly for %0 is unsigned long, so
> > > > always 64-bits wide on arm64. Why is clang trying to use a 32-bit
> > > > register for it?
> >
> > Sorry, this was my fault, I accidentally added a w during testing to see
> > what constraints were valid (given that my assembly knowledge is nearly
> > non-existence so forgive the non-sensical experimentation) and I used
> > that message rather than the original one. This is the unadulterated one.
>
> Aha, that explains it. Thanks for clearing that up.
>
> > In file included from arch/arm64/kernel/asm-offsets.c:24:
> > In file included from ./include/linux/dma-mapping.h:11:
> > In file included from ./include/linux/scatterlist.h:9:
> > In file included from ./arch/arm64/include/asm/io.h:209:
> > ./include/asm-generic/io.h:695:9: warning: value size does not match
> > register size specified by the constraint and modifier
> > [-Wasm-operand-widths]
> > return readb(addr);
> >^
> > ./arch/arm64/include/asm/io.h:147:58: note: expanded from macro 'readb'
> > #define readb(c)({ u8 __v = readb_relaxed(c);
> > __iormb(__v); __v; })
> >^
> > ./include/asm-generic/io.h:695:9: note: use constraint modifier "w"
> > ./arch/arm64/include/asm/io.h:147:50: note: expanded from macro 'readb'
> > #define readb(c)({ u8 __v = readb_relaxed(c);
> > __iormb(__v); __v; })
> >^
> > ./arch/arm64/include/asm/io.h:118:24: note: expanded from macro '__iormb'
> > asm volatile("eor %0, %1, %1\n" \
> > ^
> >
> > >
> > > Yeah, the message above looks bogus to me. I can see %1 being 32-bit for
> > > read[bwl], so maybe clang is just getting the diagnostic wrong. If so,
> > > I wonder if the following fixes the problem:
> > >
> >
> > This doesn't appear to work, I get this error:
> >
> > In file included from arch/arm64/kernel/asm-offsets.c:24:
> > In file included from ./include/linux/dma-mapping.h:11:
> > In file included from ./include/linux/scatterlist.h:9:
> > In file included from ./arch/arm64/include/asm/io.h:209:
> > ./include/asm-generic/io.h:695:9: error: expected expression
> > return readb(addr);
> >^
> > ./arch/arm64/include/asm/io.h:147:50: note: expanded from macro 'readb'
> > #define readb(c)({ u8 __v = readb_relaxed(c);
> > __iormb(__v); __v; })
> >^
> > ./arch/arm64/include/asm/io.h:120:28: note: expanded from macro '__iormb'
> > : "=r" (tmp) : "r" (unsigned long)(v) : "memory"); \
> > ^
>
> Can you try throwing another set of brackets around it, please?
>
> ((unsigned long)(v))
>
> Will
Thanks, that fixes the warning as well.
Nathan
Re: [PATCH] pinctrl: zynq: Use define directive for PIN_CONFIG_IO_STANDARD
On Fri, Nov 16, 2018 at 09:40:45AM +0100, Michal Simek wrote:
> On 09. 11. 18 16:36, Nathan Chancellor wrote:
> > On Fri, Nov 09, 2018 at 10:33:00AM +0100, Michal Simek wrote:
> >> On 08. 11. 18 16:01, Nathan Chancellor wrote:
> >>> On Thu, Nov 08, 2018 at 07:45:42AM +0100, Michal Simek wrote:
> >>>> On 07. 11. 18 18:48, Nick Desaulniers wrote:
> >>>>> On Wed, Nov 7, 2018 at 1:01 AM Michal Simek
> >>>>> wrote:
> >>>>>>
> >>>>>> On 07. 11. 18 9:55, Nathan Chancellor wrote:
> >>>>>>> On Wed, Nov 07, 2018 at 09:46:12AM +0100, Michal Simek wrote:
> >>>>>>>> On 01. 11. 18 1:57, Nathan Chancellor wrote:
> >>>>>>>>> Clang warns when one enumerated type is implicitly converted to
> >>>>>>>>> another:
> >>>>>>>>>
> >>>>>>>>> drivers/pinctrl/pinctrl-zynq.c:985:18: warning: implicit conversion
> >>>>>>>>> from
> >>>>>>>>> enumeration type 'enum zynq_pin_config_param' to different
> >>>>>>>>> enumeration
> >>>>>>>>> type 'enum pin_config_param' [-Wenum-conversion]
> >>>>>>>>> {"io-standard", PIN_CONFIG_IOSTANDARD, zynq_iostd_lvcmos18},
> >>>>>>>>> ~ ^
> >>>>>>>>> drivers/pinctrl/pinctrl-zynq.c:990:16: warning: implicit conversion
> >>>>>>>>> from
> >>>>>>>>> enumeration type 'enum zynq_pin_config_param' to different
> >>>>>>>>> enumeration
> >>>>>>>>> type 'enum pin_config_param' [-Wenum-conversion]
> >>>>>>>>> = { PCONFDUMP(PIN_CONFIG_IOSTANDARD, "IO-standard", NULL,
> >>>>>>>>> true),
> >>>>>>>>>
> >>>>>>>>> ~~^
> >>>>>>>>> ./include/linux/pinctrl/pinconf-generic.h:163:11: note: expanded
> >>>>>>>>> from
> >>>>>>>>> macro 'PCONFDUMP'
> >>>>>>>>> .param = a, .display = b, .format = c, .has_arg = d \
> >>>>>>>>> ^
> >>>>>>>>> 2 warnings generated.
> >>>>>>>>
> >>>>>>>> This is interesting. I have never tried to use llvm for building the
> >>>>>>>> kernel. Do you have any description how this can be done?
> >>>>>>>>
> >>>>>>>
> >>>>>>> Depending on what version of Clang you have access to, it is usually
> >>>>>>> just as
> >>>>>>> simple as running 'make ARCH=arm CC=clang
> >>>>>>> CROSS_COMPILE=arm-linux-gnueabi-'.
> >>>>>>>
> >>>>>>> Clang 7.0+ is recommended but 6.0 might work too.
> >>>>>>
> >>>>>> TBH I would expect to download container and run this there to make
> >>>>>> sure
> >>>>>> that I don't break anything else.
> >>>>>
> >>>>> This is the first request we've had for a container in order to test a
> >>>>> patch. If it comes up again from other folks, I think it makes sense
> >>>>> to create one. Until then, its nice to have. It's definitely
> >>>>> overkill for this patch.
> >>>>
> >>>> I have played with it to see that error and here are some steps I did.
> >>>>
> >>>> docker run --name test-clang -it --rm debian:latest bash
> >>>> apt-get update
> >>>> apt-get install gcc-arm-linux-gnueabi gcc-aarch64-linux-gnu clang git bc
> >>>> build-essential bison flex make llvm vim libssl-dev sparse
> >>>>
> >>>> git clone
> >>>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git --depth
> >>>> 1
> >>>> cd linux
> >>>>
> >>>> export ARCH=arm64
> >>>> export CROSS_COMPILE=aarch64-linux-gnu-
> >>>>
> >>>> make defconfig
> >>>
Re: [PATCH] geneve: Add missing braces in addr6 initializer
On Mon, Nov 12, 2018 at 11:19:17PM +0100, Stefano Brivio wrote:
> On Mon, 12 Nov 2018 15:12:48 -0700
> Nathan Chancellor wrote:
>
> > Clang warns:
> >
> > drivers/net/geneve.c:428:29: error: suggest braces around initialization
> > of subobject [-Werror,-Wmissing-braces]
> > struct in6_addr addr6 = { 0 };
> > ^
> > {}
> >
> > Fixes: a07966447f39 ("geneve: ICMP error lookup handler")
> > Signed-off-by: Nathan Chancellor
>
> Thanks for spotting this. By the way, I guess you should indicate in
> the subject when patches are meant for net-next.
>
Sure, I'll be better about that in the future.
> Reviewed-by: Stefano Brivio
>
Thank you for the review!
Nathan
> --
> Stefano
[PATCH 2/2] ARM: Wrap '--pic-veneer' with ld-option
This flag is not supported by lld: ld.lld: error: unknown argument: --pic-veneer Signed-off-by: Nathan Chancellor --- arch/arm/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/Makefile b/arch/arm/Makefile index e2a0baf36766..4fab2aa29570 100644 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@ -10,7 +10,7 @@ # # Copyright (C) 1995-2001 by Russell King -LDFLAGS_vmlinux:= --no-undefined -X --pic-veneer +LDFLAGS_vmlinux:= --no-undefined -X $(call ld-option,--pic-veneer) ifeq ($(CONFIG_CPU_ENDIAN_BE8),y) LDFLAGS_vmlinux+= --be8 KBUILD_LDFLAGS_MODULE += --be8 -- 2.20.0.rc1
[PATCH 1/2] ARM: Remove '-p' from LDFLAGS
This option is not supported by lld:
ld.lld: error: unknown argument: -p
This has been a no-op in binutils since 2004 (see commit dea514f51da1 in
that tree). Given that the lowest officially supported of binutils for
the kernel is 2.20, which was released in 2009, nobody needs this flag
around so just remove it. Commit 1a381d4a0a9a ("arm64: remove no-op -p
linker flag") did the same for arm64.
Signed-off-by: Nathan Chancellor
---
arch/arm/Makefile | 2 +-
arch/arm/boot/compressed/Makefile | 2 --
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 05a91d8b89f3..e2a0baf36766 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -10,7 +10,7 @@
#
# Copyright (C) 1995-2001 by Russell King
-LDFLAGS_vmlinux:=-p --no-undefined -X --pic-veneer
+LDFLAGS_vmlinux:= --no-undefined -X --pic-veneer
ifeq ($(CONFIG_CPU_ENDIAN_BE8),y)
LDFLAGS_vmlinux+= --be8
KBUILD_LDFLAGS_MODULE += --be8
diff --git a/arch/arm/boot/compressed/Makefile
b/arch/arm/boot/compressed/Makefile
index 1f5a5ffe7fcf..dcd07bd24b85 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -131,8 +131,6 @@ endif
ifeq ($(CONFIG_CPU_ENDIAN_BE8),y)
LDFLAGS_vmlinux += --be8
endif
-# ?
-LDFLAGS_vmlinux += -p
# Report unresolved symbol references
LDFLAGS_vmlinux += --no-undefined
# Delete all temporary local symbols
--
2.20.0.rc1
Re: [PATCH 2/2] ARM: Wrap '--pic-veneer' with ld-option
On Wed, Dec 05, 2018 at 08:37:05AM +0100, Ard Biesheuvel wrote: > On Wed, 5 Dec 2018 at 02:42, Nathan Chancellor > wrote: > > > > This flag is not supported by lld: > > > > ld.lld: error: unknown argument: --pic-veneer > > > > Signed-off-by: Nathan Chancellor > > Hi Nate, > > Does this mean ld.lld is guaranteed to produce position independent > veneers if you build kernels that are bigger than the typical range of > a relative branch? > Hi Ard, Honestly, I'm not quite sure. I saw your commit that introduced this flag and I wasn't quite sure what to make of it for lld. What configuration would I use to verify and what would I check for? Additionally, I have filed an LLVM bug for the lld developers to check and see if this is a flag they should support: https://bugs.llvm.org/show_bug.cgi?id=39886 Thanks for the quick reply, Nathan > > --- > > arch/arm/Makefile | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/arch/arm/Makefile b/arch/arm/Makefile > > index e2a0baf36766..4fab2aa29570 100644 > > --- a/arch/arm/Makefile > > +++ b/arch/arm/Makefile > > @@ -10,7 +10,7 @@ > > # > > # Copyright (C) 1995-2001 by Russell King > > > > -LDFLAGS_vmlinux:= --no-undefined -X --pic-veneer > > +LDFLAGS_vmlinux:= --no-undefined -X $(call ld-option,--pic-veneer) > > ifeq ($(CONFIG_CPU_ENDIAN_BE8),y) > > LDFLAGS_vmlinux+= --be8 > > KBUILD_LDFLAGS_MODULE += --be8 > > -- > > 2.20.0.rc1 > >
Re: [PATCH 2/2] ARM: Wrap '--pic-veneer' with ld-option
On Wed, Dec 05, 2018 at 09:09:56AM +0100, Ard Biesheuvel wrote:
> (+ Arnd)
>
> On Wed, 5 Dec 2018 at 09:06, Nathan Chancellor
> wrote:
> >
> > On Wed, Dec 05, 2018 at 08:37:05AM +0100, Ard Biesheuvel wrote:
> > > On Wed, 5 Dec 2018 at 02:42, Nathan Chancellor
> > > wrote:
> > > >
> > > > This flag is not supported by lld:
> > > >
> > > > ld.lld: error: unknown argument: --pic-veneer
> > > >
> > > > Signed-off-by: Nathan Chancellor
> > >
> > > Hi Nate,
> > >
> > > Does this mean ld.lld is guaranteed to produce position independent
> > > veneers if you build kernels that are bigger than the typical range of
> > > a relative branch?
> > >
> >
> > Hi Ard,
> >
> > Honestly, I'm not quite sure. I saw your commit that introduced this
> > flag and I wasn't quite sure what to make of it for lld. What
> > configuration would I use to verify and what would I check for?
> >
>
> Try building allyesconfig, and check the resulting binary for veneers
> (which have 'veneer' in the symbol name, at least when ld.bfd emits
> them). These veneers should not take the [virtual] address of the
> branch target directly, but take a PC relative offset (as in the
> example in the commit log of that patch you are referring to)
>
Alright, compiling with allyesconfig is a little rough at the moment
(bug reports I will file in due time) but I was able to do it. Here's
the disassembly specifically for the functions you had in your commit,
my assembly knowledge is pretty much non-existent unfortunately so I am
not sure what to make of it (it doesn't look like there is a virtual
address for pc in that mix?). I am happy to provide any more information
that is needed.
c03030cc <__enable_mmu>:
c03030cc: e3c2bic r0, r0, #2
c03030d0: e3c00b02bic r0, r0, #2048 ; 0x800
c03030d4: e3c00a01bic r0, r0, #4096 ; 0x1000
c03030d8: e3a05051mov r5, #81 ; 0x51
c03030dc: ee035f10mcr 15, 0, r5, cr3, cr0, {0}
c03030e0: ee024f10mcr 15, 0, r4, cr2, cr0, {0}
c03030e4: eafff3c5b c030 <__turn_mmu_on>
c03030e8: e320f000nop {0}
c03030ec: e320f000nop {0}
c03030f0: e320f000nop {0}
c03030f4: e320f000nop {0}
c03030f8: e320f000nop {0}
c03030fc: e320f000nop {0}
c030 <__turn_mmu_on>:
c030: e1a0nop ; (mov r0, r0)
c034: ee070f95mcr 15, 0, r0, cr7, cr5, {4}
c038: ee010f10mcr 15, 0, r0, cr1, cr0, {0}
c03c: ee103f10mrc 15, 0, r3, cr0, cr0, {0}
c0300010: ee070f95mcr 15, 0, r0, cr7, cr5, {4}
c0300014: e1a03003mov r3, r3
c0300018: e1a0300dmov r3, sp
c030001c: e1a0f003mov pc, r3
Thanks,
Nathan
> > Additionally, I have filed an LLVM bug for the lld developers to
> > check and see if this is a flag they should support:
> >
> > https://bugs.llvm.org/show_bug.cgi?id=39886
> >
> > Thanks for the quick reply,
> > Nathan
> >
> > > > ---
> > > > arch/arm/Makefile | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> > > > index e2a0baf36766..4fab2aa29570 100644
> > > > --- a/arch/arm/Makefile
> > > > +++ b/arch/arm/Makefile
> > > > @@ -10,7 +10,7 @@
> > > > #
> > > > # Copyright (C) 1995-2001 by Russell King
> > > >
> > > > -LDFLAGS_vmlinux:= --no-undefined -X --pic-veneer
> > > > +LDFLAGS_vmlinux:= --no-undefined -X $(call
> > > > ld-option,--pic-veneer)
> > > > ifeq ($(CONFIG_CPU_ENDIAN_BE8),y)
> > > > LDFLAGS_vmlinux+= --be8
> > > > KBUILD_LDFLAGS_MODULE += --be8
> > > > --
> > > > 2.20.0.rc1
> > > >
Re: [PATCH] pinctrl: generic: Avoid several implicit enum conversions
On Fri, Nov 09, 2018 at 10:29:02AM +0100, Linus Walleij wrote: > On Thu, Nov 1, 2018 at 1:03 AM Nathan Chancellor > wrote: > > [Me] > > > A slightly lesser evil variant is to add a few PIN_CONFIG_CUSTOM_1 > > > PIN_CONFIG_CUSTOM_2 etc at the end of the enum and just > > > #define MY_CONFIG PIN_CONFIG_CUSTOM_1 > > > in all drivers that use these. > > > > > > > Some drivers actually just define their pin config params like: > > > > #define VAR (PIN_CONFIG_END + 1) > > > > In fact, more drivers do that than not. I will go ahead and draft some > > patches tonight and send them out tonight to see what driver authors > > think. > > This seems to work. Is your kernel compile working without > warnings after this round of patches? > Yes, there are no more enum-conversion warnings and the tree shows there are no more enums that use PIN_CONFIG_END. > Thanks for driving this BTW. > Thank you for being patient and forcing me to come up with a solution that works for you! Nathan > Yours, > Linus Walleij
Re: [PATCH] pinctrl: zynq: Use define directive for PIN_CONFIG_IO_STANDARD
On Fri, Nov 09, 2018 at 10:33:00AM +0100, Michal Simek wrote:
> On 08. 11. 18 16:01, Nathan Chancellor wrote:
> > On Thu, Nov 08, 2018 at 07:45:42AM +0100, Michal Simek wrote:
> >> On 07. 11. 18 18:48, Nick Desaulniers wrote:
> >>> On Wed, Nov 7, 2018 at 1:01 AM Michal Simek
> >>> wrote:
> >>>>
> >>>> On 07. 11. 18 9:55, Nathan Chancellor wrote:
> >>>>> On Wed, Nov 07, 2018 at 09:46:12AM +0100, Michal Simek wrote:
> >>>>>> On 01. 11. 18 1:57, Nathan Chancellor wrote:
> >>>>>>> Clang warns when one enumerated type is implicitly converted to
> >>>>>>> another:
> >>>>>>>
> >>>>>>> drivers/pinctrl/pinctrl-zynq.c:985:18: warning: implicit conversion
> >>>>>>> from
> >>>>>>> enumeration type 'enum zynq_pin_config_param' to different enumeration
> >>>>>>> type 'enum pin_config_param' [-Wenum-conversion]
> >>>>>>> {"io-standard", PIN_CONFIG_IOSTANDARD, zynq_iostd_lvcmos18},
> >>>>>>> ~ ^
> >>>>>>> drivers/pinctrl/pinctrl-zynq.c:990:16: warning: implicit conversion
> >>>>>>> from
> >>>>>>> enumeration type 'enum zynq_pin_config_param' to different enumeration
> >>>>>>> type 'enum pin_config_param' [-Wenum-conversion]
> >>>>>>> = { PCONFDUMP(PIN_CONFIG_IOSTANDARD, "IO-standard", NULL,
> >>>>>>> true),
> >>>>>>>
> >>>>>>> ~~^
> >>>>>>> ./include/linux/pinctrl/pinconf-generic.h:163:11: note: expanded from
> >>>>>>> macro 'PCONFDUMP'
> >>>>>>> .param = a, .display = b, .format = c, .has_arg = d \
> >>>>>>> ^
> >>>>>>> 2 warnings generated.
> >>>>>>
> >>>>>> This is interesting. I have never tried to use llvm for building the
> >>>>>> kernel. Do you have any description how this can be done?
> >>>>>>
> >>>>>
> >>>>> Depending on what version of Clang you have access to, it is usually
> >>>>> just as
> >>>>> simple as running 'make ARCH=arm CC=clang
> >>>>> CROSS_COMPILE=arm-linux-gnueabi-'.
> >>>>>
> >>>>> Clang 7.0+ is recommended but 6.0 might work too.
> >>>>
> >>>> TBH I would expect to download container and run this there to make sure
> >>>> that I don't break anything else.
> >>>
> >>> This is the first request we've had for a container in order to test a
> >>> patch. If it comes up again from other folks, I think it makes sense
> >>> to create one. Until then, its nice to have. It's definitely
> >>> overkill for this patch.
> >>
> >> I have played with it to see that error and here are some steps I did.
> >>
> >> docker run --name test-clang -it --rm debian:latest bash
> >> apt-get update
> >> apt-get install gcc-arm-linux-gnueabi gcc-aarch64-linux-gnu clang git bc
> >> build-essential bison flex make llvm vim libssl-dev sparse
> >>
> >> git clone
> >> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git --depth 1
> >> cd linux
> >>
> >> export ARCH=arm64
> >> export CROSS_COMPILE=aarch64-linux-gnu-
> >>
> >> make defconfig
> >
> > This should also have 'CC=clang' because compiler detection happens in
> > Kconfig now so compiler flags get properly set. Other than that, looks
> > good and I was able to build pinctrl-zynq.o without any issues with
> > those commands.
>
> For arm32 I am still getting compilation issue (arm64 is fine)
> Below are my steps and version I use. Do you know what could be the
> problem?
>
> Thanks,
> Michal
>
> root@1e15921e6d15:~/linux# arm-linux-gnueabi-gcc --version
> arm-linux-gnueabi-gcc (Debian 6.3.0-18) 6.3.0 20170516
> Copyright (C) 2016 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> root@1e15921e6d15:~/linux# clang --version
> clang version 3.8.1-24 (tags/RELEASE_381/final)
> Target: x86_64-pc-linux-gnu
> Thread model: posix
> InstalledDir: /usr/bin
>
>
> export ARCH=arm
> export CROSS_COMPILE=arm-linux-gnuaebi-
> make CC=clang defconfig
> make CC=clang drivers/pinctrl/pinctrl-zynq.o
>
> and I get
> clang: error: unsupported argument '-W' to option 'Wa,'
> scripts/Makefile.build:305: recipe for target 'scripts/mod/empty.o' failed
> make[2]: *** [scripts/mod/empty.o] Error 1
> scripts/Makefile.build:546: recipe for target 'scripts/mod' failed
>
Ah because Debian's regular Clang is ancient.
For testing, we use the builds from apt.llvm.org. Commands assuming
you're using the normal Debian image:
curl https://apt.llvm.org/llvm-snapshot.gpg.key | apt-key add -
echo "deb http://apt.llvm.org/stretch/ llvm-toolchain-stretch main" | tee -a
/etc/apt/sources.list
apt-get update -qq && apt-get install -y clang-8
Then use `CC=clang-8' instead of 'CC=clang' for all make invocations.
Let me know if there are any more issues!
Nathan
Re: [PATCH 3.18 00/85] 3.18.114-stable review
On Sun, Jul 01, 2018 at 06:01:18PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.114 release. > There are 85 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Tue Jul 3 15:31:04 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.114-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-3.18.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled with -Werror, and installed onto my Pixel XL. No initial issues noticed in dmesg or general usage. Thanks, Nathan
Re: [PATCH 4.4 000/105] 4.4.139-stable review
On Sun, Jul 01, 2018 at 06:01:10PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.139 release. > There are 105 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Tue Jul 3 15:31:30 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.139-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.4.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled with -Werror, and installed onto my Pixel 2 XL and OnePlus 5. No initial issues noticed in dmesg or general usage. Thanks, Nathan
Re: [PATCH 4.9 000/101] 4.9.111-stable review
On Sun, Jul 01, 2018 at 06:20:46PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.111 release. > There are 101 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Tue Jul 3 16:07:40 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.111-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.9.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled with -Werror, and installed onto my OnePlus 6. No initial issues noticed in dmesg or general usage. Thanks, Nathan
Re: [PATCH 3.18 00/23] 3.18.115-stable review
On Tue, Jul 10, 2018 at 08:24:33PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.115 release. > There are 23 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Jul 12 18:22:59 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.115-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-3.18.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled with -Werror, and installed on my Pixel XL. No initial issues noticed in dmesg or general usage. Thanks! Nathan
Re: [PATCH 4.9 00/52] 4.9.112-stable review
On Tue, Jul 10, 2018 at 08:24:28PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.112 release. > There are 52 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Jul 12 18:24:30 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.112-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.9.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled with -Werror, and installed on my OnePlus 6. No initial issues noticed in dmesg or general usage. Thanks! Nathan
Re: [PATCH 4.4 00/47] 4.4.140-stable review
On Tue, Jul 10, 2018 at 08:24:24PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.140 release. > There are 47 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Jul 12 18:23:24 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.140-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.4.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled with -Werror, and installed on my Pixel 2 XL and OnePlus 5. No initial issues noticed in dmesg or general usage. Thanks! Nathan
Re: [PATCH 3.18 00/45] 3.18.110-stable review
On Thu, May 24, 2018 at 11:38:08AM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.110 release. > There are 45 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sat May 26 09:30:59 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.110-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-3.18.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled with -Werror, and installed on my Pixel XL. No issues noticed in dmesg or general usage. Thanks! Nathan
Re: [PATCH 4.4 00/92] 4.4.133-stable review
On Thu, May 24, 2018 at 11:37:37AM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.133 release. > There are 92 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sat May 26 09:31:28 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.133-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.4.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled with -Werror, and installed onto my Pixel 2 XL and OnePlus 5. No initial issues noticed in dmesg or general usage. Thanks! Nathan
Re: [PATCH 4.14 000/165] 4.14.44-stable review
On Thu, May 24, 2018 at 11:36:46AM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.44 release. > There are 165 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sat May 26 09:35:46 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.44-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.14.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled, and installed onto my Raspberry Pi 3. No initial issues noticed in general usage or dmesg. Thanks! Nathan
Re: [PATCH 3.18 00/23] 3.18.109-stable review
On Mon, May 14, 2018 at 08:48:29AM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.109 release. > There are 23 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed May 16 06:46:49 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.109-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-3.18.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled, and installed on to my Pixel XL. No initial issues noticed in general usage or dmesg. Thanks! Nathan
Re: [PATCH 4.4 00/56] 4.4.132-stable review
On Mon, May 14, 2018 at 08:48:05AM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.132 release. > There are 56 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed May 16 06:47:39 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.132-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.4.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled, and installed on to my Pixel 2 XL and OnePlus 5. No initial issues noticed in general usage or dmesg. Thanks! Nathan
Re: [PATCH 4.14 00/62] 4.14.41-stable review
On Mon, May 14, 2018 at 08:48:16AM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.41 release. > There are 62 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed May 16 06:47:52 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.41-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.14.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled, and installed on to my Raspberry Pi 3. No initial issues noticed in general usage or dmesg. Thanks! Nathan
Re: [PATCH 3/7] staging: ks7010: Remove unnecessary limit checks
On Mon, May 14, 2018 at 04:17:36PM +0300, Dan Carpenter wrote: > On Sun, May 06, 2018 at 03:03:00PM -0700, Nathan Chancellor wrote: > > uwrq is an unsigned 32-bit integer, it cannot be less than zero. > > > > Signed-off-by: Nathan Chancellor > > --- > > drivers/staging/ks7010/ks_wlan_net.c | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/staging/ks7010/ks_wlan_net.c > > b/drivers/staging/ks7010/ks_wlan_net.c > > index e96477937f65..0c83d6fe270f 100644 > > --- a/drivers/staging/ks7010/ks_wlan_net.c > > +++ b/drivers/staging/ks7010/ks_wlan_net.c > > @@ -1928,7 +1928,7 @@ static int ks_wlan_set_beacon_lost(struct net_device > > *dev, > > if (priv->sleep_mode == SLP_SLEEP) > > return -EPERM; > > /* for SLEEP MODE */ > > - if (*uwrq < BEACON_LOST_COUNT_MIN || *uwrq > BEACON_LOST_COUNT_MAX) > > + if (*uwrq > BEACON_LOST_COUNT_MAX) > > I believe Smatch is supposed to ignore this sort of code because > comparing "if (foo < 0 || foo > max) " is pretty readable and idiomatic. > > Presumably this was so we could redefine BEACON_LOST_COUNT_MIN, but it's > fine to unused code. The define isn't needed at all, so you can > delete that as well. > > regards, > dan carpenter > Hi Dan, Thanks for the suggestion, I just sent a patch. This warning came from GCC as a -Wtype-limit warning. I should have put that in the commit message to be more clear. I will keep this in mind for the future if I come across any more checks like this with defines. Thanks! Nathan Chancellor
[PATCH] staging: android: ion: Check return value of ion_buffer_kmap_get
GCC warns that vaddr is set but unused. Check the return value of
ion_buffer_kmap_get to make vaddr useful and make sure everything
is properly configured before beginning a DMA.
Suggested-by: Laura Abbott
Signed-off-by: Nathan Chancellor
---
drivers/staging/android/ion/ion.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index d10b60fe4a29..af682cbde767 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -315,6 +315,7 @@ static int ion_dma_buf_begin_cpu_access(struct dma_buf
*dmabuf,
struct ion_buffer *buffer = dmabuf->priv;
void *vaddr;
struct ion_dma_buf_attachment *a;
+ int ret = 0;
/*
* TODO: Move this elsewhere because we don't always need a vaddr
@@ -322,6 +323,10 @@ static int ion_dma_buf_begin_cpu_access(struct dma_buf
*dmabuf,
if (buffer->heap->ops->map_kernel) {
mutex_lock(&buffer->lock);
vaddr = ion_buffer_kmap_get(buffer);
+ if (IS_ERR(vaddr)) {
+ ret = PTR_ERR(vaddr);
+ goto unlock;
+ }
mutex_unlock(&buffer->lock);
}
@@ -330,9 +335,10 @@ static int ion_dma_buf_begin_cpu_access(struct dma_buf
*dmabuf,
dma_sync_sg_for_cpu(a->dev, a->table->sgl, a->table->nents,
direction);
}
- mutex_unlock(&buffer->lock);
- return 0;
+unlock:
+ mutex_unlock(&buffer->lock);
+ return ret;
}
static int ion_dma_buf_end_cpu_access(struct dma_buf *dmabuf,
--
2.17.0
Kconfig warnings with GCC 8.1.0
Hi everyone,
My apologies if this has already been reported in some capacity, I
searched the mailing list and patchwork but I didn't see anything.
With GCC 8.1.0, I am starting to see the following warnings from
Kconfig:
CCscripts/kconfig/zconf.tab.c
LEX scripts/kconfig/zconf.lex.c
HOSTCC scripts/kconfig/zconf.tab.o
In file included from scripts/kconfig/zconf.tab.c:2496:
scripts/kconfig/confdata.c: In function ‘conf_write’:
scripts/kconfig/confdata.c:748:22: warning: ‘%s’ directive writing likely 7 or
more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
sprintf(newname, "%s%s", dirname, basename);
^~
scripts/kconfig/confdata.c:748:19: note: assuming directive output of 7 bytes
sprintf(newname, "%s%s", dirname, basename);
^~
scripts/kconfig/confdata.c:748:2: note: ‘sprintf’ output 1 or more bytes
(assuming 4104) into a destination of size 4097
sprintf(newname, "%s%s", dirname, basename);
^~~
scripts/kconfig/confdata.c:751:23: warning: ‘.tmpconfig.’ directive writing 11
bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
sprintf(tmpname, "%s.tmpconfig.%d", dirname, (int)getpid());
^~~
scripts/kconfig/confdata.c:751:3: note: ‘sprintf’ output between 13 and 4119
bytes into a destination of size 4097
sprintf(tmpname, "%s.tmpconfig.%d", dirname, (int)getpid());
^~~
HOSTCC scripts/kconfig/conf.o
HOSTLD scripts/kconfig/conf
I am not sure if this is a false positive or not, otherwise I would have
sent a patch. I tested on the latest linux-next with Masahiro's for-next
branch, currently at commit 57282f7da50c ("Merge branch 'kconfig' into
for-next").
Thanks!
Nathan
[PATCH] kconfig: Avoid format overflow warning from GCC 8.1
In file included from scripts/kconfig/zconf.tab.c:2485: scripts/kconfig/confdata.c: In function ‘conf_write’: scripts/kconfig/confdata.c:773:22: warning: ‘%s’ directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=] sprintf(newname, "%s%s", dirname, basename); ^~ scripts/kconfig/confdata.c:773:19: note: assuming directive output of 7 bytes sprintf(newname, "%s%s", dirname, basename); ^~ scripts/kconfig/confdata.c:773:2: note: ‘sprintf’ output 1 or more bytes (assuming 4104) into a destination of size 4097 sprintf(newname, "%s%s", dirname, basename); ^~~ scripts/kconfig/confdata.c:776:23: warning: ‘.tmpconfig.’ directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=] sprintf(tmpname, "%s.tmpconfig.%d", dirname, (int)getpid()); ^~~ scripts/kconfig/confdata.c:776:3: note: ‘sprintf’ output between 13 and 4119 bytes into a destination of size 4097 sprintf(tmpname, "%s.tmpconfig.%d", dirname, (int)getpid()); ^~~ Increase the size of tmpname and newname to make GCC happy. Cc: sta...@vger.kernel.org Signed-off-by: Nathan Chancellor --- scripts/kconfig/confdata.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c index 5f87ad561b08..39e20974f4a3 100644 --- a/scripts/kconfig/confdata.c +++ b/scripts/kconfig/confdata.c @@ -720,7 +720,7 @@ int conf_write(const char *name) struct menu *menu; const char *basename; const char *str; - char dirname[PATH_MAX+1], tmpname[PATH_MAX+1], newname[PATH_MAX+1]; + char dirname[PATH_MAX+1], tmpname[PATH_MAX+22], newname[PATH_MAX+8]; char *env; dirname[0] = 0; -- 2.17.1
Re: [PATCH 4.9 00/31] 4.9.108-stable review
On Tue, Jun 12, 2018 at 06:46:03PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.108 release. > There are 31 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Jun 14 16:46:09 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.108-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.9.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled with -Werror, and installed on to my OnePlus 6. No initial issues noticed in dmesg or general usage. Thanks! Nathan
Re: [PATCH 4.4 00/24] 4.4.137-stable review
On Tue, Jun 12, 2018 at 06:51:44PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.137 release. > There are 24 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Jun 14 16:48:07 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.137-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.4.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled with -Werror, and installed on my Pixel 2 XL and OnePlus 5. No initial issues noticed in dmesg or general usage. Thanks! Nathan
Re: [PATCH 3.18 00/21] 3.18.113-stable review
On Tue, Jun 12, 2018 at 06:51:57PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.113 release. > There are 21 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Jun 14 16:48:15 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.113-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-3.18.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled with -Werror, and installed on my Pixel XL. No initial issues noticed in dmesg or general usage. Thanks! Nathan
Re: [PATCH 4.9 00/30] 4.9.109-stable review
On Thu, Jun 14, 2018 at 04:04:41PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.109 release. > There are 30 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sat Jun 16 13:25:48 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.109-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.9.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled with -Werror, and installed onto my OnePlus 6. No initial issues noticed in dmesg or general usage. Thanks! Nathan
Re: [PATCH 4.4 00/24] 4.4.138-stable review
On Thu, Jun 14, 2018 at 04:04:55PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.138 release. > There are 24 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sat Jun 16 13:27:15 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.138-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.4.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled with -Werror, and installed onto my Pixel 2 XL and OnePlus 5. No initial issues noticed in dmesg or general usage. Thanks! Nathan
Re: [PATCH 4.9 000/107] 4.9.120-stable review
On Tue, Aug 14, 2018 at 07:16:23PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.120 release. > There are 107 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Aug 16 17:14:53 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.120-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.9.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled with -Werror, and installed onto my OnePlus 6, which is my daily driver while my Pixel 2 XL is in for another screen RMA... No initial issues noticed in dmesg or general usage. Thanks! Nathan
Re: [PATCH 4.9 000/107] 4.9.120-stable review
On Wed, Aug 15, 2018 at 02:36:00AM +0200, Sebastian Gottschall wrote:
> if SWAP is disabled in kernel config, the following compile error will raise
> up with this release
>
> arch/x86/built-in.o: in function `max_swapfile_size': (.text+0x3bba1):
> undefined reference to `generic_max_swapfile_size'
>
> of course this is simple to fix. the function max_swapfile_size must be
> excluded if CONFIG_SWAP is disabled
>
> Sebastian
>
This is fixed upstream as commmit 792adb90fa72 ("x86/init: fix build
with CONFIG_SWAP=n").
Cheers,
Nathan
Re: [PATCH 3.18 00/15] 3.18.119-stable review
On Thu, Aug 16, 2018 at 08:41:37PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.119 release. > There are 15 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sat Aug 18 17:16:20 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.119-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-3.18.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled with -Werror, and installed onto my Pixel XL. No initial issues noticed in dmesg or general usage. Thanks! Nathan
Re: [PATCH 4.9 00/15] 4.9.121-stable review
On Thu, Aug 16, 2018 at 08:41:53PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.121 release. > There are 15 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sat Aug 18 17:16:11 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.121-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.9.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merged, compiled with -Werror, and installed onto my OnePlus 6. No initial issues noticed in dmesg or general usage. As an aside because I feel it needs to be said out loud, I really want to thank you for all of the work you do coordinating getting all of these fixes out to us, in addition to the developers for writing them. I know it's a pretty thankless job, especially when you have people yelling at you about stuff that "you" broke but it's an invaluable service and we would be worse off without it. Thanks! Nathan
[PATCH] ASoC: simple-card: Dereference pointer for memcpy sizeof in asoc_simple_card_probe
Clang warns:
sound/soc/generic/simple-card.c:462:6: warning: argument to 'sizeof' in
'memcpy' call is the same pointer type 'struct asoc_simple_dai *' as the
source; expected 'struct asoc_simple_dai' or an explicit length
[-Wsizeof-pointer-memaccess]
sizeof(priv->dai_props->cpu_dai));
^~~~
sound/soc/generic/simple-card.c:464:6: warning: argument to 'sizeof' in
'memcpy' call is the same pointer type 'struct asoc_simple_dai *' as the
source; expected 'struct asoc_simple_dai' or an explicit length
[-Wsizeof-pointer-memaccess]
sizeof(priv->dai_props->codec_dai));
^~
2 warnings generated.
Commit 4fb7f4df49d3 ("ASoC: simple-card: use cpu/codec pointer on
simple_dai_props") updated {cpu,codec}_dai to be pointers in struct
simple_dai_props but didn't update these locations to dereference the
pointers to get the proper size of their contents.
Signed-off-by: Nathan Chancellor
---
sound/soc/generic/simple-card.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
index 766123485d7c..d4738d3eb2f1 100644
--- a/sound/soc/generic/simple-card.c
+++ b/sound/soc/generic/simple-card.c
@@ -459,9 +459,9 @@ static int asoc_simple_card_probe(struct platform_device
*pdev)
dai_link->dai_fmt = cinfo->daifmt;
dai_link->init = asoc_simple_card_dai_init;
memcpy(&priv->dai_props->cpu_dai, &cinfo->cpu_dai,
- sizeof(priv->dai_props->cpu_dai));
+ sizeof(*priv->dai_props->cpu_dai));
memcpy(&priv->dai_props->codec_dai, &cinfo->codec_dai,
- sizeof(priv->dai_props->codec_dai));
+ sizeof(*priv->dai_props->codec_dai));
}
snd_soc_card_set_drvdata(card, priv);
--
2.20.0
Re: [PATCH] ASoC: simple-card: Dereference pointer for memcpy sizeof in asoc_simple_card_probe
On Thu, Dec 13, 2018 at 02:07:42PM +0900, Kuninori Morimoto wrote:
>
> Hi Nathan
>
> > sound/soc/generic/simple-card.c:462:6: warning: argument to 'sizeof' in
> > 'memcpy' call is the same pointer type 'struct asoc_simple_dai *' as the
> > source; expected 'struct asoc_simple_dai' or an explicit length
> > [-Wsizeof-pointer-memaccess]
> > sizeof(priv->dai_props->cpu_dai));
> > ^~~~
> > sound/soc/generic/simple-card.c:464:6: warning: argument to 'sizeof' in
> > 'memcpy' call is the same pointer type 'struct asoc_simple_dai *' as the
> > source; expected 'struct asoc_simple_dai' or an explicit length
> > [-Wsizeof-pointer-memaccess]
> > sizeof(priv->dai_props->codec_dai));
> > ^~
> > 2 warnings generated.
> >
> > Commit 4fb7f4df49d3 ("ASoC: simple-card: use cpu/codec pointer on
> > simple_dai_props") updated {cpu,codec}_dai to be pointers in struct
> > simple_dai_props but didn't update these locations to dereference the
> > pointers to get the proper size of their contents.
> >
> > Signed-off-by: Nathan Chancellor
> > ---
> > sound/soc/generic/simple-card.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/sound/soc/generic/simple-card.c
> > b/sound/soc/generic/simple-card.c
> > index 766123485d7c..d4738d3eb2f1 100644
> > --- a/sound/soc/generic/simple-card.c
> > +++ b/sound/soc/generic/simple-card.c
> > @@ -459,9 +459,9 @@ static int asoc_simple_card_probe(struct
> > platform_device *pdev)
> > dai_link->dai_fmt = cinfo->daifmt;
> > dai_link->init = asoc_simple_card_dai_init;
> > memcpy(&priv->dai_props->cpu_dai, &cinfo->cpu_dai,
> > - sizeof(priv->dai_props->cpu_dai));
> > + sizeof(*priv->dai_props->cpu_dai));
> > memcpy(&priv->dai_props->codec_dai, &cinfo->codec_dai,
> > - sizeof(priv->dai_props->codec_dai));
> > + sizeof(*priv->dai_props->codec_dai));
> > }
>
> Ahh.. yes, simple-card is supporting non DT case, too.
> Thank you for your patch.
> But, I think "&priv->dai_props->codec_dai" need to fix, too.
> And it needs to point cpu_dai/codec_dai.
> Thank you for pointing it. I will fixup and post with your name.
>
> Best regards
> ---
> Kuninori Morimoto
Sure, whatever you think is best, thank you for the quick response!
Nathan
Re: [PATCH] ARM: Ensure that NEON code always compiles with Clang
On Mon, Dec 17, 2018 at 01:23:52PM -0500, Nicolas Pitre wrote:
> On Sat, 15 Dec 2018, Nathan Chancellor wrote:
>
> > While building arm32 allyesconfig, I ran into the following errors:
> >
> > arch/arm/lib/xor-neon.c:17:2: error: You should compile this file with
> > '-mfloat-abi=softfp -mfpu=neon'
> >
> > In file included from lib/raid6/neon1.c:27:
> > /home/nathan/cbl/prebuilt/lib/clang/8.0.0/include/arm_neon.h:28:2:
> > error: "NEON support not enabled"
> >
> > Building V=1 showed NEON_FLAGS getting passed along to Clang but
> > __ARM_NEON__ was not getting defined. Ultimately, it boils down to Clang
> > only defining __ARM_NEON__ when targeting armv7, rather than armv6k,
> > which is the '-march' value for allyesconfig.
> >
> > From lib/Basic/Targets/ARM.cpp in the Clang source:
> >
> > // This only gets set when Neon instructions are actually available,
> > unlike
> > // the VFP define, hence the soft float and arch check. This is subtly
> > // different from gcc, we follow the intent which was that it should be
> > set
> > // when Neon instructions are actually available.
> > if ((FPU & NeonFPU) && !SoftFloat && ArchVersion >= 7) {
> > Builder.defineMacro("__ARM_NEON", "1");
> > Builder.defineMacro("__ARM_NEON__");
> > // current AArch32 NEON implementations do not support double-precision
> > // floating-point even when it is present in VFP.
> > Builder.defineMacro("__ARM_NEON_FP",
> > "0x" + Twine::utohexstr(HW_FP & ~HW_FP_DP));
> > }
> >
> > Ard Biesheuvel recommended explicitly adding '-march=armv7-a' at the
> > beginning of the NEON_FLAGS definitions so that __ARM_NEON__ always gets
> > definined by Clang. This doesn't functionally change anything because
> > that code will only run where NEON is supported, which is implicitly
> > armv7.
> >
> > Link: https://github.com/ClangBuiltLinux/linux/issues/287
> > Suggested-by: Ard Biesheuvel
> > Signed-off-by: Nathan Chancellor
>
> Did you test that this doesn't create issues with gcc e.g. complaints
> from the linker that objects have incompatible architecture
> specifications or similar annoyance? This already happened in the past
> but I forget the exact scenario. If you already did, or after you do
> validate with gcc as well, then you may add:
>
> Acked-by: Nicolas Pitre
>
>
Hi Nicolas,
I was 99% sure that I checked GCC before sending this but I just did
another run to confirm and everything links successfully. We still use
binutils for assembling/linking the kernel so I assume that I would have
seen a warning from ld.bfd even with Clang.
Thank you for the review!
Nathan
>
> > ---
> > Documentation/arm/kernel_mode_neon.txt | 4 ++--
> > arch/arm/lib/Makefile | 2 +-
> > arch/arm/lib/xor-neon.c| 2 +-
> > lib/raid6/Makefile | 2 +-
> > 4 files changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/Documentation/arm/kernel_mode_neon.txt
> > b/Documentation/arm/kernel_mode_neon.txt
> > index 525452726d31..b9e060c5b61e 100644
> > --- a/Documentation/arm/kernel_mode_neon.txt
> > +++ b/Documentation/arm/kernel_mode_neon.txt
> > @@ -6,7 +6,7 @@ TL;DR summary
> > * Use only NEON instructions, or VFP instructions that don't rely on
> > support
> >code
> > * Isolate your NEON code in a separate compilation unit, and compile it
> > with
> > - '-mfpu=neon -mfloat-abi=softfp'
> > + '-march=armv7-a -mfpu=neon -mfloat-abi=softfp'
> > * Put kernel_neon_begin() and kernel_neon_end() calls around the calls
> > into your
> >NEON code
> > * Don't sleep in your NEON code, and be aware that it will be executed with
> > @@ -87,7 +87,7 @@ instructions appearing in unexpected places if no special
> > care is taken.
> > Therefore, the recommended and only supported way of using NEON/VFP in the
> > kernel is by adhering to the following rules:
> > * isolate the NEON code in a separate compilation unit and compile it with
> > - '-mfpu=neon -mfloat-abi=softfp';
> > + '-march=armv7-a -mfpu=neon -mfloat-abi=softfp';
> > * issue the calls to kernel_neon_begin(), kernel_neon_end() as well as the
> > calls
> >into the unit containing the NEON code from a compilation unit which is
> > *not*
> >built with the GCC flag '-mfpu=neon&
Re: [PATCH] drm/i915: Disable -Wuninitialized for intel_breadcrumbs.o
On Tue, Dec 18, 2018 at 11:53:06AM +, Chris Wilson wrote:
> Quoting Nick Desaulniers (2018-10-25 23:20:58)
> > On Thu, Oct 25, 2018 at 12:36 PM Nathan Chancellor
> > wrote:
> > >
> > > This warning is disabled by default in scripts/Makefile.extrawarn when
> > > W= is not provided but this Makefile adds -Wall after this warning is
> > > disabled so it shows up in the build when it shouldn't:
> > >
> > > In file included from drivers/gpu/drm/i915/intel_breadcrumbs.c:895:
> > > drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c:350:34: error:
> > > variable 'wq' is uninitialized when used within its own initialization
> > > [-Werror,-Wuninitialized]
> > > DECLARE_WAIT_QUEUE_HEAD_ONSTACK(wq);
> > > ^~
> > > ./include/linux/wait.h:74:63: note: expanded from macro
> > > 'DECLARE_WAIT_QUEUE_HEAD_ONSTACK'
> > > struct wait_queue_head name = __WAIT_QUEUE_HEAD_INIT_ONSTACK(name)
> > > ^~~~
> > > ./include/linux/wait.h:72:33: note: expanded from macro
> > > '__WAIT_QUEUE_HEAD_INIT_ONSTACK'
> > > ({ init_waitqueue_head(&name); name; })
> > >^~~~
> > > 1 error generated.
> > >
> > > This warning looks to be a false positive given that init_waitqueue_head
> > > initializes name before it is used. Rather than disable the warning for
> > > the full folder like commit 46e2068081e9 ("drm/i915: Disable some extra
> >
> > cc author/reviewer of 46e2068081e9.
> >
> > I'm fine with the patch as is, unless others prefer to disable it for
> > the whole subdir? We could be playing whack-a-mole in the future
> > disabling this warning for other translation units.
>
Hi Chris,
> Yes, exactly this since the warning is generated by a core header and a
> fairly common pattern its use is not restricted to any single file.
> (Will not all selftests similarly explode?)
>
Well, -Wuninitialized is turned off for the whole kernel unless W= is
passed. So I suppose it should be turned back on for the whole folder
but I noticed that the i915 Makefile purposefully turns all of the
disabled warnings back on for heavier coverage so it makes some sense to
just leave it off for one translation unit when it's just one
translation unit that has the problem. That said, I'm more than happy to
send a v2 turning it off for the whole folder if you think that best.
> The other false-positive clang-6 gave was for local_clock_us().
> Presumably that one is fixed?
> -Chris
With this patch, I can build i915 using defconfig and allyesconfig
without any warnings with tip-of-tree Clang.
Thank you for the comments!
Nathan
[PATCH] PCI: Remove unused attr variable in pci_dma_configure
Clang warns:
drivers/pci/pci-driver.c:1603:21: error: unused variable 'attr'
[-Werror,-Wunused-variable]
Commit e5361ca29f2f ("ACPI / scan: Refactor _CCA enforcement") removed
attr's use and replaced it with its assigned value so it is no longer
needed.
Signed-off-by: Nathan Chancellor
---
The commit that causes this warning is in Christoph's dma-mapping tree
so I assume this will go there too (roll it into it if need be).
drivers/pci/pci-driver.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index 1b58e058b13f..ea55444e6ead 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -1600,7 +1600,6 @@ static int pci_dma_configure(struct device *dev)
ret = of_dma_configure(dev, bridge->parent->of_node, true);
} else if (has_acpi_companion(bridge)) {
struct acpi_device *adev = to_acpi_device_node(bridge->fwnode);
- enum dev_dma_attr attr = acpi_get_dma_attr(adev);
ret = acpi_dma_configure(dev, acpi_get_dma_attr(adev));
}
--
2.20.0
