Hi Linus,
A clang-format update (trivial).
Cheers,
Miguel
The following changes since commit 1c7fc5cbc33980acd13d668f1c8f0313d6ae9fd8:
Linux 5.0-rc2 (2019-01-14 10:41:12 +1200)
are available in the Git repository at:
https://github.com/ojeda/linux.git tags/clang-format-for-linus-v5.0-rc3
On Sun, Jan 20, 2019 at 3:43 PM Michael S. Tsirkin wrote:
>
> No not yet. Sorry! Pls send this one in, barrier_data will likely miss
> the next merge window.
No worries! Done.
Cheers,
Miguel
Hi Linus,
I picked up this include/linux/compiler*.h fix regarding
OPTIMIZER_HIDE_VAR for clang.
It has been in -next for around 10 days.
Cheers,
Miguel
The following changes since commit bfeffd155283772bbe78c6a05dec7c0128ee500c:
Linux 5.0-rc1 (2019-01-06 17:08:20 -0800)
are available in
Hi Joe,
On Sat, Jan 19, 2019 at 8:45 PM Joe Perches wrote:
>
> I suggest clang-format's ForEachMacros statement vector
> be expanded to support regexes ala
>
> ForEachMacros:
> - Regex:
> '\b(?:(?:[a-z0-9_]+_)?for_each(?:_[a-z_]+)|[a-z0-9_]+_for_each)\b'
Ah, yeah, of course. And it
Hi Joe,
On Sat, Jan 19, 2019 at 8:06 PM Joe Perches wrote:
>
> This misses all the directory/file specific #defines
> outside of include/ with for_each
Indeed, the command only searches the include/ directory, but when
searching for the entire tree, it returns ~500 more entries (vs. the
~300
Hi Michael,
On Wed, Jan 9, 2019 at 3:50 PM Michael S. Tsirkin wrote:
>
> On Wed, Jan 09, 2019 at 11:35:52AM +0100, Miguel Ojeda wrote:
> > Note it would be nice to separate the patch into two (one for the
> > comments, another for OPTIMIZER_HIDE_VAR), and als
Hi Jason,
On Fri, Jan 18, 2019 at 11:57 PM Jason Gunthorpe wrote:
>
> Re-run the shell fragment that generated the original list. In particular
> this adds the missing xarray related functions.
>
> Signed-off-by: Jason Gunthorpe
Thank for the patch! Picking it up.
Cheers,
Miguel
Hi Greg, Nick, Xiaozhou,
On Thu, Dec 6, 2018 at 1:50 PM Greg KH wrote:
>
> If something is fixed in Linus's tree for this, I want to take it into
> the 4.19-stable tree as well.
This ended up in Linus' tree before the holidays, i.e. 4.20 has it,
see commit 71391bdd2e9a
nvert from gnu_printf to printf without any side effects for
> two reasons:
>
> 1. All iavf_debug instances use standard printf formats, as pointed out
>by Miguel Ojeda at the below link, meaning gnu_printf is not strictly
>required.
>
> 2. However, GCC has aliased
Hi Rasmus,
On Fri, Nov 2, 2018 at 11:43 AM Rasmus Villemoes
wrote:
>
> On 2018-11-02 11:36, Miguel Ojeda wrote:
> > Hi Rasmus,
> >
> > On Sat, Oct 27, 2018 at 2:06 PM Miguel Ojeda
> > wrote:
> >>
> >> I did quick check and gcc >= 4.1, cla
On Tue, Jan 8, 2019 at 6:44 PM Nick Desaulniers wrote:
>
> Also for more context, see:
> commit 7829fb09a2b4 ("lib: make memzero_explicit more robust against
> dead store elimination")
By the way, shouldn't that barrier_data() be directly in compiler.h
too, since it is for both gcc & clang?
>
Hi Linus,
I picked this one up even if it is not exactly compiler-attributes.
I would like if you can take a look at the patch, please. The patch is harmless
for the kernel, but v4.19 was released with a few macros exposed to userspace
as the patch explains; which this removes, so it *could*
Hi Linus,
Please consider pulling this small fix for auxdisplay.
It is a bit late, and has been in linux-next for a couple of days only,
but it shouldn't break anything else further, so feel free to pick it
for either 4.20 or maybe afterwards.
Cheers,
Miguel
The following changes since commit
Hi Stephen,
On Sun, Dec 16, 2018 at 6:23 AM Stephen Rothwell wrote:
>
> Added from Monday.
Thanks!
> Out of interest, will this tree be sent directly to
> Linus or merged vi some other tree?
It is sent directly to Linus.
Cheers,
Miguel
Hi Stephen,
Can you please add the auxdisplay tree into linux-next?
https://github.com/ojeda/linux.git auxdisplay
It is extremely low volume, but from time to time there is a patch.
Thank you!
Cheers,
Miguel
On Fri, Dec 14, 2018 at 3:16 PM Xiaozhou Liu wrote:
>
> Macros 'inline' and '__gnu_inline' used to be defined in compiler-gcc.h,
> which was (and is) included entirely in (__KERNEL__ && !__ASSEMBLY__).
> Commit 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h mutually
> exclusive") had
On Fri, Dec 14, 2018 at 1:15 PM Måns Rullgård wrote:
>
> The bad code from that commit was already completely replaced with the
> new parse_xy() function.
Yes, but this fixes something that was broken for a longer time, so it
is good to be able to tell the range of commits that were broken.
On Thu, Dec 13, 2018 at 11:25 PM Nick Desaulniers
wrote:
>
> Moving the __KERNEL__ guard should not affect the kernel, only what
> userspace sees. __gnu_inline only affects which
> implementation/definition you get, so even if userspace doesn't know
> what the kernel's inline is redefined to, it
On Thu, Dec 13, 2018 at 10:59 PM Miguel Ojeda
wrote:
>
> What do you think?
[Cc'ing Nick et. al. as well.]
Cheers,
Miguel
Hi Xiaozhou,
Couple of comments.
On Sun, Dec 9, 2018 at 4:27 AM Xiaozhou Liu wrote:
>
> v2: update commit message.
This line should go below the "---", since it shouldn't be part of the
commit message.
> +#ifdef __KERNEL__
> +
> #ifdef CONFIG_ENABLE_MUST_CHECK
> #define __must_check
Hi Måns,
On Thu, Dec 6, 2018 at 1:06 PM Måns Rullgård wrote:
>
> >> BTW, the parsing of this command has been broken since 3.2-rc1 due to
> >> commit 129957069e6a.
> >
> > Thanks for checking! Are you able to test this?
>
> Yes, that's how I noticed it was broken.
Fantastic, thank you.
Can you
Hi Robert,
On Fri, Dec 7, 2018 at 12:13 AM Robert Abel wrote:
>
> Hi Miguel,
>
> On 05 Dec 2018 17:47, Miguel Ojeda wrote:> Hi Mans,
> >
> > [CC'ing a few people involved previously on this]
>
> Thanks for CC'ing me!
>
> On 06 Dec 2018 11:06, Miguel Ojed
Hi Robert,
On Fri, Dec 7, 2018 at 12:13 AM Robert Abel wrote:
>
> Hi Miguel,
>
> On 05 Dec 2018 17:47, Miguel Ojeda wrote:> Hi Mans,
> >
> > [CC'ing a few people involved previously on this]
>
> Thanks for CC'ing me!
>
> On 06 Dec 2018 11:06, Miguel Ojed
On Wed, Dec 5, 2018 at 6:58 PM Måns Rullgård wrote:
>
> Suppose the command "\e[Lx0y0;" is written to the device. The
> charlcd_write_char() function adds one character at a time to the escape
> sequence buffer.
Ah, yes, that is much more clear. Indeed, parse_xy() expects the
entire command;
On Wed, Dec 5, 2018 at 6:58 PM Måns Rullgård wrote:
>
> Suppose the command "\e[Lx0y0;" is written to the device. The
> charlcd_write_char() function adds one character at a time to the escape
> sequence buffer.
Ah, yes, that is much more clear. Indeed, parse_xy() expects the
entire command;
Hi Mans,
[CC'ing a few people involved previously on this]
On Wed, Dec 5, 2018 at 2:53 PM Mans Rullgard wrote:
>
> Commit b34050fadb86 ("auxdisplay: charlcd: Fix and clean up handling of
> x/y commands") fixed some problems by rewriting the parsing code,
> but also broke things further by
Hi Mans,
[CC'ing a few people involved previously on this]
On Wed, Dec 5, 2018 at 2:53 PM Mans Rullgard wrote:
>
> Commit b34050fadb86 ("auxdisplay: charlcd: Fix and clean up handling of
> x/y commands") fixed some problems by rewriting the parsing code,
> but also broke things further by
On Thu, Nov 29, 2018 at 3:16 AM Xiaozhou Liu wrote:
>
> On Wed, Nov 28, 2018 at 06:35:18PM +0100, Miguel Ojeda wrote:
>
> By `these' I mean inline and the like, to be clear.
Ah, that makes more sense! Sorry.
> > That is not exactly correct -- a3f8a30f3f00 moved some attribu
On Thu, Nov 29, 2018 at 3:16 AM Xiaozhou Liu wrote:
>
> On Wed, Nov 28, 2018 at 06:35:18PM +0100, Miguel Ojeda wrote:
>
> By `these' I mean inline and the like, to be clear.
Ah, that makes more sense! Sorry.
> > That is not exactly correct -- a3f8a30f3f00 moved some attribu
On Wed, Nov 28, 2018 at 6:35 PM Miguel Ojeda
wrote:
>
> If your problem is fixed by putting __gnu_inline into __KERNEL__
s/__gnu_inline/inline/
Cheers,
Miguel
On Wed, Nov 28, 2018 at 6:35 PM Miguel Ojeda
wrote:
>
> If your problem is fixed by putting __gnu_inline into __KERNEL__
s/__gnu_inline/inline/
Cheers,
Miguel
Hi Xiaozhou,
On Wed, Nov 28, 2018 at 3:09 PM Xiaozhou Liu wrote:
>
> Attributes such as `__gnu_inline' are meant to be used within the
> kernel. When userspace somehow includes
> (eg. tools/bpf), compilation errors would be shown:
>
> "error: unknown type name ‘__gnu_inline’"
>
> So
Hi Xiaozhou,
On Wed, Nov 28, 2018 at 3:09 PM Xiaozhou Liu wrote:
>
> Attributes such as `__gnu_inline' are meant to be used within the
> kernel. When userspace somehow includes
> (eg. tools/bpf), compilation errors would be shown:
>
> "error: unknown type name ‘__gnu_inline’"
>
> So
tatic const int x = 0;
> int y = BUILD_BUG_ON_ZERO(x);
>
> Signed-off-by: Masahiro Yamada
> Acked-by: Kees Cook
> Reviewed-by: Luc Van Oostenryck
> Reviewed-by: Nick Desaulniers
> Tested-by: Nick Desaulniers
Nice to see those CHECKER blocks are being reduced!
Acked-by: Miguel Ojeda
Cheers,
Miguel
tatic const int x = 0;
> int y = BUILD_BUG_ON_ZERO(x);
>
> Signed-off-by: Masahiro Yamada
> Acked-by: Kees Cook
> Reviewed-by: Luc Van Oostenryck
> Reviewed-by: Nick Desaulniers
> Tested-by: Nick Desaulniers
Nice to see those CHECKER blocks are being reduced!
Acked-by: Miguel Ojeda
Cheers,
Miguel
On Fri, Nov 23, 2018 at 10:14 PM Luc Van Oostenryck
wrote:
>
> On Thu, Nov 22, 2018 at 12:14:20PM +0900, Masahiro Yamada wrote:
> > When I tried to enable BUILD_BUG_ON for Sparse, the kbuild test robot
> > reported lots of "unknown expression" warnings from container_of(),
> > which seemed false
On Fri, Nov 23, 2018 at 10:14 PM Luc Van Oostenryck
wrote:
>
> On Thu, Nov 22, 2018 at 12:14:20PM +0900, Masahiro Yamada wrote:
> > When I tried to enable BUILD_BUG_ON for Sparse, the kbuild test robot
> > reported lots of "unknown expression" warnings from container_of(),
> > which seemed false
y: Nick Desaulniers
Didn't see v3/v4 (wasn't CC):
Acked-by: Miguel Ojeda
Cheers,
Miguel
y: Nick Desaulniers
Didn't see v3/v4 (wasn't CC):
Acked-by: Miguel Ojeda
Cheers,
Miguel
; > in the kernel source.
> >
> > A fallback for -O0 case is just hypothetical and pointless. Moreover,
> > commit 0bb95f80a38f ("Makefile: Globally enable VLA warning") enabled
> > -Wvla warning. The use of variable length arrays is banned.
> >
> > Signed-
; > in the kernel source.
> >
> > A fallback for -O0 case is just hypothetical and pointless. Moreover,
> > commit 0bb95f80a38f ("Makefile: Globally enable VLA warning") enabled
> > -Wvla warning. The use of variable length arrays is banned.
> >
> > Signed-
On Wed, Oct 31, 2018 at 5:14 PM Masahiro Yamada
wrote:
>
> On Wed, Oct 31, 2018 at 8:28 PM Miguel Ojeda
> wrote:
> >
> > By the way, is it possible that scripts/ and similar stuff uses
> > directly include/linux/compiler_attributes.h (whenever it hits
> > main
On Wed, Oct 31, 2018 at 5:14 PM Masahiro Yamada
wrote:
>
> On Wed, Oct 31, 2018 at 8:28 PM Miguel Ojeda
> wrote:
> >
> > By the way, is it possible that scripts/ and similar stuff uses
> > directly include/linux/compiler_attributes.h (whenever it hits
> > main
Miguel Ojeda (1):
Compiler Attributes: improve explanation of header
ndesaulni...@google.com (1):
include/linux/compiler*.h: define asm_volatile_goto
include/linux/compiler_attributes.h | 14 +-
include/linux/compiler_types.h | 4
2 files changed, 13 insertions
Miguel Ojeda (1):
Compiler Attributes: improve explanation of header
ndesaulni...@google.com (1):
include/linux/compiler*.h: define asm_volatile_goto
include/linux/compiler_attributes.h | 14 +-
include/linux/compiler_types.h | 4
2 files changed, 13 insertions
On Tue, Nov 6, 2018 at 3:46 PM Peter Zijlstra wrote:
>
> If you actually read what I wrote:
You got me, I did read very quickly :)
> Dunno, but that is a far more difficult patch. The proposed one is an
> obvious identify.
I would say they are orthogonal, even if both would solve the problem.
On Tue, Nov 6, 2018 at 3:46 PM Peter Zijlstra wrote:
>
> If you actually read what I wrote:
You got me, I did read very quickly :)
> Dunno, but that is a far more difficult patch. The proposed one is an
> obvious identify.
I would say they are orthogonal, even if both would solve the problem.
On Tue, Nov 6, 2018 at 11:02 AM Peter Zijlstra wrote:
>
> allows adding the "inline" keyword to 'asm ("")' statements. The
> problem is that we're possibly redefining "inline" to
> "inline __attribute__((__always_inline__))" which makes the proposed:
>
> asm volatile inline ("")
>
> (...)
>
>
On Tue, Nov 6, 2018 at 11:02 AM Peter Zijlstra wrote:
>
> allows adding the "inline" keyword to 'asm ("")' statements. The
> problem is that we're possibly redefining "inline" to
> "inline __attribute__((__always_inline__))" which makes the proposed:
>
> asm volatile inline ("")
>
> (...)
>
>
On Wed, Oct 31, 2018 at 8:39 PM wrote:
>
> asm_volatile_goto should also be defined for other compilers that support
> asm goto.
Picking this up into compiler-attributes.
Cheers,
Miguel
On Wed, Oct 31, 2018 at 8:39 PM wrote:
>
> asm_volatile_goto should also be defined for other compilers that support
> asm goto.
Picking this up into compiler-attributes.
Cheers,
Miguel
On Fri, Nov 2, 2018 at 4:56 PM Randy Dunlap wrote:
>
> Hi,
>
> on i386 or x86_64, with gcc (SUSE Linux) 4.8.5, I am seeing this problem:
>
> In file included from :0:0:
> ../include/linux/compiler-gcc.h:75:45: internal compiler error: in
> function_and_variable_visibility, at ipa.c:825
>
On Fri, Nov 2, 2018 at 4:56 PM Randy Dunlap wrote:
>
> Hi,
>
> on i386 or x86_64, with gcc (SUSE Linux) 4.8.5, I am seeing this problem:
>
> In file included from :0:0:
> ../include/linux/compiler-gcc.h:75:45: internal compiler error: in
> function_and_variable_visibility, at ipa.c:825
>
On Fri, Nov 2, 2018 at 2:22 PM Stephen Rothwell wrote:
>
> Its always OK (and actually useful) to move your branch head up to
> where Linus merged it (this is usually a fast forward anyway) since
> that doesn't add any new code to linux-next to conflict with code that
> is still pending to be
On Fri, Nov 2, 2018 at 2:22 PM Stephen Rothwell wrote:
>
> Its always OK (and actually useful) to move your branch head up to
> where Linus merged it (this is usually a fast forward anyway) since
> that doesn't add any new code to linux-next to conflict with code that
> is still pending to be
Hi Stephen,
On Fri, Nov 2, 2018 at 4:33 AM Stephen Rothwell wrote:
>
> Hi all,
>
> Please do not add any v4.21/v5.1 code to your linux-next included trees
> until after the merge window closes.
Is it OK to move forward the branch up to the point where it landed in
mainline, no? What about
Hi Stephen,
On Fri, Nov 2, 2018 at 4:33 AM Stephen Rothwell wrote:
>
> Hi all,
>
> Please do not add any v4.21/v5.1 code to your linux-next included trees
> until after the merge window closes.
Is it OK to move forward the branch up to the point where it landed in
mainline, no? What about
Hi Rasmus,
On Sat, Oct 27, 2018 at 2:06 PM Miguel Ojeda
wrote:
>
> I did quick check and gcc >= 4.1, clang >= 3.0, icc >= 13 compilers
> seem to support it (or at least recognize it, even if they just ignore
> it), so we do not need to make it optional, no? Did I miss
Hi Rasmus,
On Sat, Oct 27, 2018 at 2:06 PM Miguel Ojeda
wrote:
>
> I did quick check and gcc >= 4.1, clang >= 3.0, icc >= 13 compilers
> seem to support it (or at least recognize it, even if they just ignore
> it), so we do not need to make it optional, no? Did I miss
__used)
> -# if __GNUC__ == 3 && __GNUC_MINOR__ < 3
> -# define __used __attribute__((__unused__))
> -# else
> -# define __used __attribute__((__used__))
> -# endif
> +#define __used __attribute__((__used__
__used)
> -# if __GNUC__ == 3 && __GNUC_MINOR__ < 3
> -# define __used __attribute__((__unused__))
> -# else
> -# define __used __attribute__((__used__))
> -# endif
> +#define __used __attribute__((__used__
On Tue, Oct 30, 2018 at 12:49 AM Stephen Rothwell wrote:
>
> Hi all,
>
> On Tue, 30 Oct 2018 10:46:37 +1100 Stephen Rothwell
> wrote:
> >
> > Today's linux-next merge of the compiler-attributes tree got a conflict
> > in:
> >
> > include/linux/compiler-gcc.h
> >
> > between commit:
> >
> >
On Tue, Oct 30, 2018 at 12:49 AM Stephen Rothwell wrote:
>
> Hi all,
>
> On Tue, 30 Oct 2018 10:46:37 +1100 Stephen Rothwell
> wrote:
> >
> > Today's linux-next merge of the compiler-attributes tree got a conflict
> > in:
> >
> > include/linux/compiler-gcc.h
> >
> > between commit:
> >
> >
On Mon, Oct 29, 2018 at 11:20 AM Rasmus Villemoes
wrote:
>
> No idea. I think I didn't really know what was meant by
> required/optional.
Yeah, no worries, "optional" here is intended to mean "we cannot
define it unconditionally (yet)". The word leads to confusion, I
agree. I will improve the
On Mon, Oct 29, 2018 at 11:20 AM Rasmus Villemoes
wrote:
>
> No idea. I think I didn't really know what was meant by
> required/optional.
Yeah, no worries, "optional" here is intended to mean "we cannot
define it unconditionally (yet)". The word leads to confusion, I
agree. I will improve the
Hi Rasmus,
On Sat, Oct 27, 2018 at 1:24 AM Rasmus Villemoes
wrote:
>
> diff --git a/include/linux/compiler_attributes.h
> b/include/linux/compiler_attributes.h
> index 6b28c1b7310c..08264df52322 100644
> --- a/include/linux/compiler_attributes.h
> +++ b/include/linux/compiler_attributes.h
> @@
Hi Rasmus,
On Sat, Oct 27, 2018 at 1:24 AM Rasmus Villemoes
wrote:
>
> diff --git a/include/linux/compiler_attributes.h
> b/include/linux/compiler_attributes.h
> index 6b28c1b7310c..08264df52322 100644
> --- a/include/linux/compiler_attributes.h
> +++ b/include/linux/compiler_attributes.h
> @@
On Sun, Oct 21, 2018 at 8:11 PM Joe Perches wrote:
>
> On Sun, 2018-10-21 at 19:14 +0200, Miguel Ojeda wrote:
> > Let gcc know these cases are meant to fall through to the next label
> > by annotating them with the new __fallthrough statement attribute;
> > and remove the
On Sun, Oct 21, 2018 at 8:11 PM Joe Perches wrote:
>
> On Sun, 2018-10-21 at 19:14 +0200, Miguel Ojeda wrote:
> > Let gcc know these cases are meant to fall through to the next label
> > by annotating them with the new __fallthrough statement attribute;
> > and remove the
Hi Dan,
On Sat, Oct 20, 2018 at 9:22 PM Dan Carpenter wrote:
>
> On Sat, Oct 20, 2018 at 04:42:07PM +0200, Miguel Ojeda wrote:
> > Using an attribute is indeed better whenever possible. In C++17 it is
> > an standard attribute and there have been proposals to include some
Hi Dan,
On Sat, Oct 20, 2018 at 9:22 PM Dan Carpenter wrote:
>
> On Sat, Oct 20, 2018 at 04:42:07PM +0200, Miguel Ojeda wrote:
> > Using an attribute is indeed better whenever possible. In C++17 it is
> > an standard attribute and there have been proposals to include some
+On Wed, Oct 17, 2018 at 8:25 AM Dan Carpenter wrote:
>
> It's not common at all. It should be wrapped in a macro and put into
> compiler.h.
>
> But I hope it does become adopted. It's better than randomly grepping
> for non-standard comments.
Using an attribute is indeed better whenever
+On Wed, Oct 17, 2018 at 8:25 AM Dan Carpenter wrote:
>
> It's not common at all. It should be wrapped in a macro and put into
> compiler.h.
>
> But I hope it does become adopted. It's better than randomly grepping
> for non-standard comments.
Using an attribute is indeed better whenever
On Mon, Oct 15, 2018 at 10:13 PM Nick Desaulniers
wrote:
>
> Looking at commit cb984d101b30 ("compiler-gcc: integrate the various
> compiler-gcc[345].h files") it seems that the comment is referring to
> gcc 4.4 not supporting __builtin_unreachable(). Looks like it was
> added in 4.5 timeframe:
On Mon, Oct 15, 2018 at 10:13 PM Nick Desaulniers
wrote:
>
> Looking at commit cb984d101b30 ("compiler-gcc: integrate the various
> compiler-gcc[345].h files") it seems that the comment is referring to
> gcc 4.4 not supporting __builtin_unreachable(). Looks like it was
> added in 4.5 timeframe:
On Mon, Oct 15, 2018 at 7:22 PM wrote:
>
> Fixes the objtool warning seen with Clang:
> arch/x86/mm/fault.o: warning: objtool: no_context()+0x220: unreachable
> instruction
>
> Fixes commit 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h
> mutually exclusive")
>
> Josh noted that the
On Mon, Oct 15, 2018 at 7:22 PM wrote:
>
> Fixes the objtool warning seen with Clang:
> arch/x86/mm/fault.o: warning: objtool: no_context()+0x220: unreachable
> instruction
>
> Fixes commit 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h
> mutually exclusive")
>
> Josh noted that the
Hi Ted,
On Wed, Oct 10, 2018 at 9:27 PM Theodore Y. Ts'o wrote:
>
> On Wed, Oct 10, 2018 at 04:27:58PM +0200, Arnd Bergmann wrote:
> > The two new variables are only used in an #ifdef, so they cause a
> > warning without CONFIG_QUOTA:
> >
> > fs/ext4/super.c: In function 'parse_options':
> >
Hi Ted,
On Wed, Oct 10, 2018 at 9:27 PM Theodore Y. Ts'o wrote:
>
> On Wed, Oct 10, 2018 at 04:27:58PM +0200, Arnd Bergmann wrote:
> > The two new variables are only used in an #ifdef, so they cause a
> > warning without CONFIG_QUOTA:
> >
> > fs/ext4/super.c: In function 'parse_options':
> >
On Wed, Oct 10, 2018 at 8:12 AM Joel Stanley wrote:
>
> On Thu, 27 Sep 2018 at 05:07, Kees Cook wrote:
> >
> > Yeah, that's what I'd linked to in the patchwork URL. Andrew, can you take
> > this?
>
> clang built -next is blowing up now that Kees' -Wvla patch has been
> included. This patch
On Wed, Oct 10, 2018 at 8:12 AM Joel Stanley wrote:
>
> On Thu, 27 Sep 2018 at 05:07, Kees Cook wrote:
> >
> > Yeah, that's what I'd linked to in the patchwork URL. Andrew, can you take
> > this?
>
> clang built -next is blowing up now that Kees' -Wvla patch has been
> included. This patch
On Mon, Oct 8, 2018 at 5:40 PM Joe Perches wrote:
>
> On Mon, 2018-10-08 at 09:31 +0200, Miguel Ojeda wrote:
> > On Mon, Oct 8, 2018 at 4:01 AM Jason A. Donenfeld wrote:
> > > The shiny new .clang-format file lists a number of nice iterators in
> > > the ForEachMa
On Mon, Oct 8, 2018 at 5:40 PM Joe Perches wrote:
>
> On Mon, 2018-10-08 at 09:31 +0200, Miguel Ojeda wrote:
> > On Mon, Oct 8, 2018 at 4:01 AM Jason A. Donenfeld wrote:
> > > The shiny new .clang-format file lists a number of nice iterators in
> > > the ForEachMa
Hi Jason,
On Mon, Oct 8, 2018 at 4:01 AM Jason A. Donenfeld wrote:
>
> Hi Joe, Miguel, others,
>
> The shiny new .clang-format file lists a number of nice iterators in
> the ForEachMacros category, the consequence being that there is a
> space between the iterator name and the opening
Hi Jason,
On Mon, Oct 8, 2018 at 4:01 AM Jason A. Donenfeld wrote:
>
> Hi Joe, Miguel, others,
>
> The shiny new .clang-format file lists a number of nice iterators in
> the ForEachMacros category, the consequence being that there is a
> space between the iterator name and the opening
Hi Ben,
On Sun, Sep 23, 2018 at 7:26 PM wrote:
> I have removed some unnecessary braces from if statements.
> As well as inspecting the other driverfiles for similar
> style issues.
Thanks for the new version!
> - if (err) {
> + if (err)
> dft_brightness =
Hi Ben,
On Sun, Sep 23, 2018 at 7:26 PM wrote:
> I have removed some unnecessary braces from if statements.
> As well as inspecting the other driverfiles for similar
> style issues.
Thanks for the new version!
> - if (err) {
> + if (err)
> dft_brightness =
Hi Souptick,
On Fri, Oct 5, 2018 at 7:51 AM Souptick Joarder wrote:
>
> On Fri, Oct 5, 2018 at 1:16 AM Miguel Ojeda
> wrote:
> >
> >
> > Also, not sure if you saw my comments/review: if the interface is not
> > going to change, why the name chang
Hi Souptick,
On Fri, Oct 5, 2018 at 7:51 AM Souptick Joarder wrote:
>
> On Fri, Oct 5, 2018 at 1:16 AM Miguel Ojeda
> wrote:
> >
> >
> > Also, not sure if you saw my comments/review: if the interface is not
> > going to change, why the name chang
Hi Greg,
On Tue, Oct 2, 2018 at 8:44 PM Greg KH wrote:
>
> On Tue, Oct 02, 2018 at 08:38:41PM +0200, Miguel Ojeda wrote:
> > Hi Greg,
> >
> > On Tue, Oct 2, 2018 at 8:20 PM Greg KH wrote:
> > >
> > > On Tue, Oct 02, 2018 at 07:53:27PM +0530, Vinod wro
Hi Greg,
On Tue, Oct 2, 2018 at 8:44 PM Greg KH wrote:
>
> On Tue, Oct 02, 2018 at 08:38:41PM +0200, Miguel Ojeda wrote:
> > Hi Greg,
> >
> > On Tue, Oct 2, 2018 at 8:20 PM Greg KH wrote:
> > >
> > > On Tue, Oct 02, 2018 at 07:53:27PM +0530, Vinod wro
Hi Greg,
On Tue, Oct 2, 2018 at 8:20 PM Greg KH wrote:
>
> On Tue, Oct 02, 2018 at 07:53:27PM +0530, Vinod wrote:
> > Hey Greg,
> >
> > Here are the SoundWire updates (again) for 4.20-rc1/5.0-rc1
> > This brings in the multi-link streaming support and rst format
> > corrections. The changes are
Hi Greg,
On Tue, Oct 2, 2018 at 8:20 PM Greg KH wrote:
>
> On Tue, Oct 02, 2018 at 07:53:27PM +0530, Vinod wrote:
> > Hey Greg,
> >
> > Here are the SoundWire updates (again) for 4.20-rc1/5.0-rc1
> > This brings in the multi-link streaming support and rst format
> > corrections. The changes are
1:26 +0200)
--------
Miguel Ojeda (15):
Compiler Attributes: remove unused attributes
Compiler Attributes: always use the extra-underscores syntax
Compiler Attributes: remove unneeded tests
Compiler Attributes: homogenize __must_be_array
1:26 +0200)
--------
Miguel Ojeda (15):
Compiler Attributes: remove unused attributes
Compiler Attributes: always use the extra-underscores syntax
Compiler Attributes: remove unneeded tests
Compiler Attributes: homogenize __must_be_array
On Sun, Sep 30, 2018 at 1:44 PM Miguel Ojeda
wrote:
>
> On Sat, Sep 29, 2018 at 12:03 AM Joe Perches wrote:
> >
> > Please fix this defect appropriately.
>
> Thanks, will send a PR.
>
Done & merged by Greg.
Cheers,
Miguel
On Sun, Sep 30, 2018 at 1:44 PM Miguel Ojeda
wrote:
>
> On Sat, Sep 29, 2018 at 12:03 AM Joe Perches wrote:
> >
> > Please fix this defect appropriately.
>
> Thanks, will send a PR.
>
Done & merged by Greg.
Cheers,
Miguel
lay
- MAINTAINERS reference fix for moved file
Reported by Joe Perches
----
Miguel Ojeda (1):
MAINTAINERS: fix reference to moved drivers/{misc => auxdisplay}/panel.c
MAINTAINERS | 2 +-
1 file changed, 1 insertion
lay
- MAINTAINERS reference fix for moved file
Reported by Joe Perches
----
Miguel Ojeda (1):
MAINTAINERS: fix reference to moved drivers/{misc => auxdisplay}/panel.c
MAINTAINERS | 2 +-
1 file changed, 1 insertion
Hi Joe,
On Sat, Sep 29, 2018 at 12:03 AM Joe Perches wrote:
>
> Please fix this defect appropriately.
Thanks, will send a PR.
Cheers,
Miguel
401 - 500 of 1035 matches
Mail list logo
