All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Desaulniers <ndesaulniers@google.com>
To: Arnd Bergmann <arnd@kernel.org>
Cc: linux-kbuild@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
	 Linus Torvalds <torvalds@linux-foundation.org>,
	Masahiro Yamada <masahiroy@kernel.org>,
	 llvm@lists.linux.dev, Jonathan Corbet <corbet@lwn.net>,
	 Federico Vaga <federico.vaga@vaga.pv.it>,
	Alex Shi <alexs@kernel.org>,  Hu Haowen <src.res@email.cn>,
	Michal Marek <michal.lkml@markovi.net>,
	linux-doc@vger.kernel.org,  linux-kernel@vger.kernel.org,
	linux-doc-tw-discuss@lists.sourceforge.net,
	 linux-arm-kernel@lists.infradead.org,
	intel-gfx@lists.freedesktop.org,
	 dri-devel@lists.freedesktop.org, greybus-dev@lists.linaro.org,
	 linux-staging@lists.linux.dev, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] [v2] Kbuild: move to -std=gnu11
Date: Mon, 28 Feb 2022 13:03:45 -0800	[thread overview]
Message-ID: <CAKwvOdkLUx1td+qgUYy3w2ojtBG-mJTzpJg3BV8Xv56YHTxHCw@mail.gmail.com> (raw)
In-Reply-To: <20220228103142.3301082-1-arnd@kernel.org>

On Mon, Feb 28, 2022 at 2:32 AM Arnd Bergmann <arnd@kernel.org> wrote:
>
> From: Arnd Bergmann <arnd@arndb.de>
>
> During a patch discussion, Linus brought up the option of changing
> the C standard version from gnu89 to gnu99, which allows using variable
> declaration inside of a for() loop. While the C99, C11 and later standards
> introduce many other features, most of these are already available in
> gnu89 as GNU extensions as well.
>
> An earlier attempt to do this when gcc-5 started defaulting to
> -std=gnu11 failed because at the time that caused warnings about
> designated initializers with older compilers. Now that gcc-5.1 is the
> minimum compiler version used for building kernels, that is no longer a
> concern. Similarly, the behavior of 'inline' functions changes between

More precisely, the semantics of "extern inline" functions changed
between ISO C90 and ISO C99.

That's the only concern I have, which I doubt is an issue. The kernel
is already covered by the function attribute as you note.

Just to have some measure:
$ git grep -rn "extern inline" | wc -l
116

Most of those are in arch/alpha/ which is curious; I wonder if those
were intentional.

(I do worry about Makefiles that completely reset KBUILD_CFLAGS
though; the function attributes still take precedence).

> gnu89 and gnu11, but this was taken care of by defining 'inline' to
> include __attribute__((gnu_inline)) in order to allow building with
> clang a while ago.
>
> One minor issue that remains is an added gcc warning for shifts of
> negative integers when building with -Werror, which happens with the
> 'make W=1' option, as well as for three drivers in the kernel that always
> enable -Werror, but it was only observed with the i915 driver so far.
> To be on the safe side, add -Wno-shift-negative-value to any -Wextra
> in a Makefile.
>
> Nathan Chancellor reported an additional -Wdeclaration-after-statement
> warning that appears in a system header on arm, this still needs a
> workaround.

Ack; I think we can just fix this in clang.

>
> The differences between gnu99, gnu11, gnu1x and gnu17 are fairly
> minimal and mainly impact warnings at the -Wpedantic level that the
> kernel never enables. Between these, gnu11 is the newest version
> that is supported by all supported compiler versions, though it is
> only the default on gcc-5, while all other supported versions of
> gcc or clang default to gnu1x/gnu17.

I agree. With the fixup to s/Werror/Wextra.

Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>

>
> Link: https://lore.kernel.org/lkml/CAHk-=wiyCH7xeHcmiFJ-YgXUy2Jaj7pnkdKpcovt8fYbVFW3TA@mail.gmail.com/
> Link: https://github.com/ClangBuiltLinux/linux/issues/1603
> Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Masahiro Yamada <masahiroy@kernel.org>
> Cc: linux-kbuild@vger.kernel.org
> Cc: llvm@lists.linux.dev
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

-- 
Thanks,
~Nick Desaulniers

WARNING: multiple messages have this Message-ID (diff)
From: Nick Desaulniers <ndesaulniers@google.com>
To: Arnd Bergmann <arnd@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org,
	Michal Marek <michal.lkml@markovi.net>,
	Arnd Bergmann <arnd@arndb.de>, Jonathan Corbet <corbet@lwn.net>,
	linux-staging@lists.linux.dev,
	Masahiro Yamada <masahiroy@kernel.org>,
	llvm@lists.linux.dev, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	greybus-dev@lists.linaro.org, Alex Shi <alexs@kernel.org>,
	Federico Vaga <federico.vaga@vaga.pv.it>,
	Hu Haowen <src.res@email.cn>,
	intel-gfx@lists.freedesktop.org, linux-btrfs@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-doc-tw-discuss@lists.sourceforge.net,
	linux-kbuild@vger.kernel.org
Subject: Re: [PATCH] [v2] Kbuild: move to -std=gnu11
Date: Mon, 28 Feb 2022 13:03:45 -0800	[thread overview]
Message-ID: <CAKwvOdkLUx1td+qgUYy3w2ojtBG-mJTzpJg3BV8Xv56YHTxHCw@mail.gmail.com> (raw)
In-Reply-To: <20220228103142.3301082-1-arnd@kernel.org>

On Mon, Feb 28, 2022 at 2:32 AM Arnd Bergmann <arnd@kernel.org> wrote:
>
> From: Arnd Bergmann <arnd@arndb.de>
>
> During a patch discussion, Linus brought up the option of changing
> the C standard version from gnu89 to gnu99, which allows using variable
> declaration inside of a for() loop. While the C99, C11 and later standards
> introduce many other features, most of these are already available in
> gnu89 as GNU extensions as well.
>
> An earlier attempt to do this when gcc-5 started defaulting to
> -std=gnu11 failed because at the time that caused warnings about
> designated initializers with older compilers. Now that gcc-5.1 is the
> minimum compiler version used for building kernels, that is no longer a
> concern. Similarly, the behavior of 'inline' functions changes between

More precisely, the semantics of "extern inline" functions changed
between ISO C90 and ISO C99.

That's the only concern I have, which I doubt is an issue. The kernel
is already covered by the function attribute as you note.

Just to have some measure:
$ git grep -rn "extern inline" | wc -l
116

Most of those are in arch/alpha/ which is curious; I wonder if those
were intentional.

(I do worry about Makefiles that completely reset KBUILD_CFLAGS
though; the function attributes still take precedence).

> gnu89 and gnu11, but this was taken care of by defining 'inline' to
> include __attribute__((gnu_inline)) in order to allow building with
> clang a while ago.
>
> One minor issue that remains is an added gcc warning for shifts of
> negative integers when building with -Werror, which happens with the
> 'make W=1' option, as well as for three drivers in the kernel that always
> enable -Werror, but it was only observed with the i915 driver so far.
> To be on the safe side, add -Wno-shift-negative-value to any -Wextra
> in a Makefile.
>
> Nathan Chancellor reported an additional -Wdeclaration-after-statement
> warning that appears in a system header on arm, this still needs a
> workaround.

Ack; I think we can just fix this in clang.

>
> The differences between gnu99, gnu11, gnu1x and gnu17 are fairly
> minimal and mainly impact warnings at the -Wpedantic level that the
> kernel never enables. Between these, gnu11 is the newest version
> that is supported by all supported compiler versions, though it is
> only the default on gcc-5, while all other supported versions of
> gcc or clang default to gnu1x/gnu17.

I agree. With the fixup to s/Werror/Wextra.

Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>

>
> Link: https://lore.kernel.org/lkml/CAHk-=wiyCH7xeHcmiFJ-YgXUy2Jaj7pnkdKpcovt8fYbVFW3TA@mail.gmail.com/
> Link: https://github.com/ClangBuiltLinux/linux/issues/1603
> Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Masahiro Yamada <masahiroy@kernel.org>
> Cc: linux-kbuild@vger.kernel.org
> Cc: llvm@lists.linux.dev
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

-- 
Thanks,
~Nick Desaulniers

WARNING: multiple messages have this Message-ID (diff)
From: Nick Desaulniers <ndesaulniers@google.com>
To: Arnd Bergmann <arnd@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org,
	Michal Marek <michal.lkml@markovi.net>,
	Arnd Bergmann <arnd@arndb.de>, Jonathan Corbet <corbet@lwn.net>,
	linux-staging@lists.linux.dev,
	Masahiro Yamada <masahiroy@kernel.org>,
	llvm@lists.linux.dev, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	greybus-dev@lists.linaro.org, Alex Shi <alexs@kernel.org>,
	Federico Vaga <federico.vaga@vaga.pv.it>,
	Hu Haowen <src.res@email.cn>,
	intel-gfx@lists.freedesktop.org, linux-btrfs@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-doc-tw-discuss@lists.sourceforge.net,
	linux-kbuild@vger.kernel.org
Subject: Re: [Intel-gfx] [PATCH] [v2] Kbuild: move to -std=gnu11
Date: Mon, 28 Feb 2022 13:03:45 -0800	[thread overview]
Message-ID: <CAKwvOdkLUx1td+qgUYy3w2ojtBG-mJTzpJg3BV8Xv56YHTxHCw@mail.gmail.com> (raw)
In-Reply-To: <20220228103142.3301082-1-arnd@kernel.org>

On Mon, Feb 28, 2022 at 2:32 AM Arnd Bergmann <arnd@kernel.org> wrote:
>
> From: Arnd Bergmann <arnd@arndb.de>
>
> During a patch discussion, Linus brought up the option of changing
> the C standard version from gnu89 to gnu99, which allows using variable
> declaration inside of a for() loop. While the C99, C11 and later standards
> introduce many other features, most of these are already available in
> gnu89 as GNU extensions as well.
>
> An earlier attempt to do this when gcc-5 started defaulting to
> -std=gnu11 failed because at the time that caused warnings about
> designated initializers with older compilers. Now that gcc-5.1 is the
> minimum compiler version used for building kernels, that is no longer a
> concern. Similarly, the behavior of 'inline' functions changes between

More precisely, the semantics of "extern inline" functions changed
between ISO C90 and ISO C99.

That's the only concern I have, which I doubt is an issue. The kernel
is already covered by the function attribute as you note.

Just to have some measure:
$ git grep -rn "extern inline" | wc -l
116

Most of those are in arch/alpha/ which is curious; I wonder if those
were intentional.

(I do worry about Makefiles that completely reset KBUILD_CFLAGS
though; the function attributes still take precedence).

> gnu89 and gnu11, but this was taken care of by defining 'inline' to
> include __attribute__((gnu_inline)) in order to allow building with
> clang a while ago.
>
> One minor issue that remains is an added gcc warning for shifts of
> negative integers when building with -Werror, which happens with the
> 'make W=1' option, as well as for three drivers in the kernel that always
> enable -Werror, but it was only observed with the i915 driver so far.
> To be on the safe side, add -Wno-shift-negative-value to any -Wextra
> in a Makefile.
>
> Nathan Chancellor reported an additional -Wdeclaration-after-statement
> warning that appears in a system header on arm, this still needs a
> workaround.

Ack; I think we can just fix this in clang.

>
> The differences between gnu99, gnu11, gnu1x and gnu17 are fairly
> minimal and mainly impact warnings at the -Wpedantic level that the
> kernel never enables. Between these, gnu11 is the newest version
> that is supported by all supported compiler versions, though it is
> only the default on gcc-5, while all other supported versions of
> gcc or clang default to gnu1x/gnu17.

I agree. With the fixup to s/Werror/Wextra.

Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>

>
> Link: https://lore.kernel.org/lkml/CAHk-=wiyCH7xeHcmiFJ-YgXUy2Jaj7pnkdKpcovt8fYbVFW3TA@mail.gmail.com/
> Link: https://github.com/ClangBuiltLinux/linux/issues/1603
> Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Masahiro Yamada <masahiroy@kernel.org>
> Cc: linux-kbuild@vger.kernel.org
> Cc: llvm@lists.linux.dev
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

-- 
Thanks,
~Nick Desaulniers

WARNING: multiple messages have this Message-ID (diff)
From: Nick Desaulniers <ndesaulniers@google.com>
To: Arnd Bergmann <arnd@kernel.org>
Cc: linux-kbuild@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
	 Linus Torvalds <torvalds@linux-foundation.org>,
	Masahiro Yamada <masahiroy@kernel.org>,
	 llvm@lists.linux.dev, Jonathan Corbet <corbet@lwn.net>,
	 Federico Vaga <federico.vaga@vaga.pv.it>,
	Alex Shi <alexs@kernel.org>,  Hu Haowen <src.res@email.cn>,
	Michal Marek <michal.lkml@markovi.net>,
	linux-doc@vger.kernel.org,  linux-kernel@vger.kernel.org,
	linux-doc-tw-discuss@lists.sourceforge.net,
	 linux-arm-kernel@lists.infradead.org,
	intel-gfx@lists.freedesktop.org,
	 dri-devel@lists.freedesktop.org, greybus-dev@lists.linaro.org,
	 linux-staging@lists.linux.dev, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] [v2] Kbuild: move to -std=gnu11
Date: Mon, 28 Feb 2022 13:03:45 -0800	[thread overview]
Message-ID: <CAKwvOdkLUx1td+qgUYy3w2ojtBG-mJTzpJg3BV8Xv56YHTxHCw@mail.gmail.com> (raw)
In-Reply-To: <20220228103142.3301082-1-arnd@kernel.org>

On Mon, Feb 28, 2022 at 2:32 AM Arnd Bergmann <arnd@kernel.org> wrote:
>
> From: Arnd Bergmann <arnd@arndb.de>
>
> During a patch discussion, Linus brought up the option of changing
> the C standard version from gnu89 to gnu99, which allows using variable
> declaration inside of a for() loop. While the C99, C11 and later standards
> introduce many other features, most of these are already available in
> gnu89 as GNU extensions as well.
>
> An earlier attempt to do this when gcc-5 started defaulting to
> -std=gnu11 failed because at the time that caused warnings about
> designated initializers with older compilers. Now that gcc-5.1 is the
> minimum compiler version used for building kernels, that is no longer a
> concern. Similarly, the behavior of 'inline' functions changes between

More precisely, the semantics of "extern inline" functions changed
between ISO C90 and ISO C99.

That's the only concern I have, which I doubt is an issue. The kernel
is already covered by the function attribute as you note.

Just to have some measure:
$ git grep -rn "extern inline" | wc -l
116

Most of those are in arch/alpha/ which is curious; I wonder if those
were intentional.

(I do worry about Makefiles that completely reset KBUILD_CFLAGS
though; the function attributes still take precedence).

> gnu89 and gnu11, but this was taken care of by defining 'inline' to
> include __attribute__((gnu_inline)) in order to allow building with
> clang a while ago.
>
> One minor issue that remains is an added gcc warning for shifts of
> negative integers when building with -Werror, which happens with the
> 'make W=1' option, as well as for three drivers in the kernel that always
> enable -Werror, but it was only observed with the i915 driver so far.
> To be on the safe side, add -Wno-shift-negative-value to any -Wextra
> in a Makefile.
>
> Nathan Chancellor reported an additional -Wdeclaration-after-statement
> warning that appears in a system header on arm, this still needs a
> workaround.

Ack; I think we can just fix this in clang.

>
> The differences between gnu99, gnu11, gnu1x and gnu17 are fairly
> minimal and mainly impact warnings at the -Wpedantic level that the
> kernel never enables. Between these, gnu11 is the newest version
> that is supported by all supported compiler versions, though it is
> only the default on gcc-5, while all other supported versions of
> gcc or clang default to gnu1x/gnu17.

I agree. With the fixup to s/Werror/Wextra.

Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>

>
> Link: https://lore.kernel.org/lkml/CAHk-=wiyCH7xeHcmiFJ-YgXUy2Jaj7pnkdKpcovt8fYbVFW3TA@mail.gmail.com/
> Link: https://github.com/ClangBuiltLinux/linux/issues/1603
> Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Masahiro Yamada <masahiroy@kernel.org>
> Cc: linux-kbuild@vger.kernel.org
> Cc: llvm@lists.linux.dev
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

-- 
Thanks,
~Nick Desaulniers

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2022-02-28 21:03 UTC|newest]

Thread overview: 109+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-28 10:27 [PATCH] [v2] Kbuild: move to -std=gnu11 Arnd Bergmann
2022-02-28 10:27 ` [Intel-gfx] " Arnd Bergmann
2022-02-28 10:27 ` Arnd Bergmann
2022-02-28 10:27 ` Arnd Bergmann
2022-02-28 10:50 ` Greg KH
2022-02-28 10:50   ` Greg KH
2022-02-28 10:50   ` [Intel-gfx] " Greg KH
2022-02-28 10:50   ` Greg KH
2022-02-28 11:25 ` Mark Rutland
2022-02-28 11:25   ` [Intel-gfx] " Mark Rutland
2022-02-28 11:25   ` Mark Rutland
2022-02-28 11:25   ` Mark Rutland
2022-02-28 11:37   ` Arnd Bergmann
2022-02-28 11:37     ` [Intel-gfx] " Arnd Bergmann
2022-02-28 11:37     ` Arnd Bergmann
2022-02-28 11:37     ` Arnd Bergmann
2022-02-28 18:40     ` [Intel-gfx] " Linus Torvalds
2022-02-28 18:40       ` Linus Torvalds
2022-02-28 18:40       ` Linus Torvalds
2022-02-28 18:40       ` Linus Torvalds
2022-02-28 17:07   ` Masahiro Yamada
2022-02-28 17:07     ` [Intel-gfx] " Masahiro Yamada
2022-02-28 17:07     ` Masahiro Yamada
2022-02-28 17:07     ` Masahiro Yamada
2022-02-28 11:47 ` Marco Elver
2022-02-28 11:47   ` [Intel-gfx] " Marco Elver
2022-02-28 11:47   ` Marco Elver
2022-02-28 11:47   ` Marco Elver
2022-02-28 11:57   ` Arnd Bergmann
2022-02-28 11:57     ` [Intel-gfx] " Arnd Bergmann
2022-02-28 11:57     ` Arnd Bergmann
2022-02-28 11:57     ` Arnd Bergmann
2022-02-28 16:56     ` Nathan Chancellor
2022-02-28 16:56       ` [Intel-gfx] " Nathan Chancellor
2022-02-28 16:56       ` Nathan Chancellor
2022-02-28 16:56       ` Nathan Chancellor
2022-02-28 12:36 ` Jani Nikula
2022-02-28 12:36   ` Jani Nikula
2022-02-28 12:36   ` [Intel-gfx] " Jani Nikula
2022-02-28 12:36   ` Jani Nikula
2022-02-28 13:01   ` Arnd Bergmann
2022-02-28 13:01     ` [Intel-gfx] " Arnd Bergmann
2022-02-28 13:01     ` Arnd Bergmann
2022-02-28 13:01     ` Arnd Bergmann
2022-02-28 13:19     ` David Sterba
2022-02-28 13:19       ` David Sterba
2022-02-28 13:19       ` [Intel-gfx] " David Sterba
2022-02-28 13:19       ` David Sterba
2022-02-28 12:48 ` Alex Shi
2022-02-28 12:48   ` Alex Shi
2022-02-28 12:48   ` [Intel-gfx] " Alex Shi
2022-02-28 12:48   ` Alex Shi
2022-02-28 12:56 ` David Sterba
2022-02-28 12:56   ` David Sterba
2022-02-28 12:56   ` [Intel-gfx] " David Sterba
2022-02-28 12:56   ` David Sterba
2022-02-28 17:02 ` Masahiro Yamada
2022-02-28 17:02   ` [Intel-gfx] " Masahiro Yamada
2022-02-28 17:02   ` Masahiro Yamada
2022-02-28 17:02   ` Masahiro Yamada
2022-02-28 18:24   ` Arnd Bergmann
2022-02-28 18:24     ` [Intel-gfx] " Arnd Bergmann
2022-02-28 18:24     ` Arnd Bergmann
2022-02-28 18:24     ` Arnd Bergmann
2022-02-28 21:03 ` Nick Desaulniers [this message]
2022-02-28 21:03   ` Nick Desaulniers
2022-02-28 21:03   ` [Intel-gfx] " Nick Desaulniers
2022-02-28 21:03   ` Nick Desaulniers
2022-02-28 21:41   ` Fangrui Song
2022-02-28 21:41     ` [Intel-gfx] " Fangrui Song
2022-02-28 21:41     ` Fangrui Song
2022-02-28 21:41     ` Fangrui Song
2022-03-01 14:45     ` Arnd Bergmann
2022-03-01 14:45       ` [Intel-gfx] " Arnd Bergmann
2022-03-01 14:45       ` Arnd Bergmann
2022-03-01 14:45       ` Arnd Bergmann
2022-02-28 21:41 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for " Patchwork
2022-02-28 22:13 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-03-01  7:30 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2022-03-01 10:24 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Kbuild: move to -std=gnu11 (rev2) Patchwork
2022-03-01 10:43 ` [PATCH] [v2] Kbuild: move to -std=gnu11 Miguel Ojeda
2022-03-01 10:43   ` [Intel-gfx] " Miguel Ojeda
2022-03-01 10:43   ` Miguel Ojeda
2022-03-01 10:43   ` Miguel Ojeda
2022-03-01 14:44   ` Arnd Bergmann
2022-03-01 14:44     ` [Intel-gfx] " Arnd Bergmann
2022-03-01 14:44     ` Arnd Bergmann
2022-03-01 14:44     ` Arnd Bergmann
2022-03-01 10:59 ` [Intel-gfx] ✓ Fi.CI.BAT: success for Kbuild: move to -std=gnu11 (rev2) Patchwork
2022-03-01 17:22 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2022-05-16 13:10 ` [PATCH] [v2] Kbuild: move to -std=gnu11 Guenter Roeck
2022-05-16 13:10   ` Guenter Roeck
2022-05-16 13:10   ` [Intel-gfx] " Guenter Roeck
2022-05-16 13:10   ` Guenter Roeck
2022-05-16 13:31   ` [greybus-dev] " Greg KH
2022-05-16 13:31     ` Greg KH
2022-05-16 13:31     ` [Intel-gfx] " Greg KH
2022-05-16 13:31     ` Greg KH
2022-05-16 14:19     ` Guenter Roeck
2022-05-16 14:19       ` Guenter Roeck
2022-05-16 14:19       ` [Intel-gfx] " Guenter Roeck
2022-05-16 14:19       ` Guenter Roeck
2022-05-18  7:46       ` Arnd Bergmann
2022-05-18  7:46         ` Arnd Bergmann
2022-05-18  7:46         ` Arnd Bergmann
2022-05-18 14:07         ` Guenter Roeck
2022-05-18 14:07           ` Guenter Roeck
2022-05-18 14:07           ` [Intel-gfx] " Guenter Roeck
2022-05-18 14:07           ` Guenter Roeck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAKwvOdkLUx1td+qgUYy3w2ojtBG-mJTzpJg3BV8Xv56YHTxHCw@mail.gmail.com \
    --to=ndesaulniers@google.com \
    --cc=alexs@kernel.org \
    --cc=arnd@arndb.de \
    --cc=arnd@kernel.org \
    --cc=corbet@lwn.net \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=federico.vaga@vaga.pv.it \
    --cc=greybus-dev@lists.linaro.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-doc-tw-discuss@lists.sourceforge.net \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=llvm@lists.linux.dev \
    --cc=masahiroy@kernel.org \
    --cc=michal.lkml@markovi.net \
    --cc=src.res@email.cn \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.