update:
- Update with the latest for_each macro list (Miguel Ojeda)
Miguel Ojeda (1):
clang-format: Update with the latest for_each macro list
.clang-format | 12
1 file changed, 12 insertions(+)
Hi Linus,
Please pull this trivial change to auxdisplay.
Cheers,
Miguel
The following changes since commit bcf876870b95592b52519ed4aafcf9d95999bc9c:
Linux 5.8 (2020-08-02 14:21:45 -0700)
are available in the Git repository at:
https://github.com/ojeda/linux.git
On Thu, Sep 3, 2020 at 7:28 PM Nathan Chancellor
wrote:
>
> I would say this should go through either Andrew or Masahiro. We do not
> have a formal git tree plus I believe there are other things that need
> to happen before we can push stuff to Linus.
Note that a git.kernel.org repo/account
On Thu, Sep 3, 2020 at 1:21 AM Arvind Sankar wrote:
>
> Changes from v2:
> - Clarify commit log and source comment some more
Much better now, thanks!
Reviewed-by: Miguel Ojeda
Cheers,
Miguel
On Wed, Sep 2, 2020 at 5:33 PM Arvind Sankar wrote:
>
> + * The compiler should not reorder volatile asm, however older versions of
> GCC
> + * had a bug (which was fixed in 8.1, 7.3 and 6.5) where they could sometimes
> + * reorder volatile asm. The write functions are not a problem since they
On Tue, Sep 1, 2020 at 2:23 AM Nick Desaulniers wrote:
>
> do so provides developers
"doing so"? "to do so"?
> include/linux/compiler-gcc.h | 2 +-
Reviewed-by: Miguel Ojeda
Cheers,
Miguel
Hi Luc,
On Fri, Aug 28, 2020 at 10:15 PM Luc Van Oostenryck
wrote:
>
> But to the bot, any change to the content of the warning itself
> or its associated info is presented as a new warning.
> I've talked to the bot's guys about this problem and they've
> replied that they're seriously
Hi Luc,
On Fri, Aug 28, 2020 at 10:53 AM Luc Van Oostenryck
wrote:
>
> Hi Miguel,
>
> Could you also take this patch in your queue?
> It has already be sent twice but ignored by the other channels.
Yeah, no problem. However, what about all those emails from the test
bot? Is the bot using an old
rust
> the keys to the nukes with any one entity. Should Nathan and I find
> ourselves at the same employer, I would gladly step down.
Acked-by: Miguel Ojeda
Cheers,
Miguel
Hi Luc,
On Tue, Aug 25, 2020 at 1:25 AM Luc Van Oostenryck
wrote:
>
> GCC 4.6 is not supported anymore, so remove a reference to it,
> leaving just the part about version prior GCC 5.
>
> Signed-off-by: Luc Van Oostenryck
Queueing this one too, thanks.
Cheers,
Miguel
Hi Luc,
On Tue, Aug 25, 2020 at 1:25 AM Luc Van Oostenryck
wrote:
>
> Sparse supports __has_attribute() since 2018-08-31, so the comment
> is not true anymore but more importantly is rather confusing.
>
> So remove it.
>
> Signed-off-by: Luc Van Oostenryck
Thanks! Queuing it.
Cheers,
Miguel
EADME.rst` to avoid having the version in 2 places (that
doc already links to the other one), but that should be another
patch.]
Reviewed-by: Miguel Ojeda
Cheers,
Miguel
Hi Arvind,
On Sun, Aug 23, 2020 at 11:25 PM Arvind Sankar wrote:
>
> - Using a dummy input operand with an arbitrary constant address for the
> read functions, instead of a global variable. This will prevent reads
> from being reordered across writes, while allowing memory loads to be
>
On Sat, Aug 22, 2020 at 11:52 AM Sedat Dilek wrote:
>
> I am asking myself who is using such ancient compilers?
There are many users/companies using older versions of compilers,
kernels and everything. GCC <= 4.9 will still be used/supported (by
third parties) for a handful of years at least.
On Tue, Aug 18, 2020 at 5:19 PM Mike Rapoport wrote:
>
> .clang-format | 2 ++
For the .clang-format bit:
Acked-by: Miguel Ojeda
Cheers,
Miguel
Hi Alexander,
On Wed, Jul 8, 2020 at 2:56 PM Alexander A. Klimov
wrote:
>
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
>
> Deterministic algorithm:
> For each file:
> If not .svg:
> For each line:
>
Hi Linus,
Please pull this small cleanup which I had in -next since 5.7-rc7
-- I missed the window last time.
Cheers,
Miguel
The following changes since commit 9cb1fd0efd195590b828b9b865421ad345a4a145:
Linux 5.7-rc7 (2020-05-24 15:32:54 -0700)
are available in the Git repository at:
Hi Andy,
On Thu, Aug 6, 2020 at 11:56 AM Andy Shevchenko
wrote:
>
> May I ask which version did you have in mind? Now it's merge window for
> v5.9-rc1 and patch is still not there...
Yeah, apologies, sending it during this merge window... :-)
Cheers,
Miguel
On Sun, Aug 2, 2020 at 6:41 PM Mike Rapoport wrote:
>
> .clang-format | 3 ++-
The .clang-format bit:
Acked-by: Miguel Ojeda
Cheers,
Miguel
On Sun, Aug 2, 2020 at 6:40 PM Mike Rapoport wrote:
>
> .clang-format| 2 +-
The .clang-format bit:
Acked-by: Miguel Ojeda
Cheers,
Miguel
On Sat, Aug 1, 2020 at 2:28 PM Masahiro Yamada wrote:
>
> samples/auxdisplay/Makefile | 3 +--
Acked-by: Miguel Ojeda
Cheers,
Miguel
d this patch to the other to clean this up!
Acked-by: Miguel Ojeda
Cheers,
Miguel
Hi Nick,
On Thu, Jul 9, 2020 at 8:42 PM Nick Desaulniers wrote:
>
> Hello folks,
> I'm working on putting together an LLVM "Micro Conference" for the
> upcoming Linux Plumbers Conf
> (https://www.linuxplumbersconf.org/event/7/page/47-attend). It's not
> solidified yet, but I would really like
Hi Masahiro,
On Sun, Jul 5, 2020 at 5:30 PM Masahiro Yamada wrote:
>
> Hmm, adding '#include ' did not make any difference.
That should have worked, because POSIX defines it to be there. It
sounds like you need --sysroot to point it to the proper ones.
> If I add -std=c99, I get a different
On Fri, Jul 3, 2020 at 10:51 AM Joe Perches wrote:
>
> I'd prefer to delete Lindent instead.
+1, especially since there is `clang-format` now.
Cheers,
Miguel
On Fri, Jul 3, 2020 at 11:19 AM Zong Li wrote:
>
> Yes, as you mentioned, the reformatting tool uses up to the maximum line
> length,
> it seems to me that we don't go this patch if you plan to post the
> patch to delete it,
> otherwise, we could consider to change it to 100.
For reference, we
On Fri, Jul 3, 2020 at 9:44 AM Joe Perches wrote:
>
> And I'd generally not bother with 80 column rewrapping
Thanks for the quick answer Joe -- here I was referring to the cases
where one needs to move all the `=`s to the right like:
static const struct file_operations memtype_fops = {
.open
On Fri, Jul 3, 2020 at 9:31 AM Danny Lin wrote:
>
> Most of the other exceptions can be accomodated for with more specific
> rules below the base [*] section. I just went through most of the
> kernel's files and added rules for the vast majority of the exceptinos
> to the 8-column tab indent
On Thu, Jul 2, 2020 at 3:50 PM Christoph Hellwig wrote:
>
> Do you have a suggestion for an automated replacement which does?
> I'll happily switch over to that.
I guess I'd simply find the unique set of cases that occur and create
a replacement for each manually. A handful of them or so may
Hi Danny,
On Fri, Jul 3, 2020 at 2:16 AM Danny Lin wrote:
>
> +[*]
> +charset = utf-8
> +end_of_line = lf
While UTF-8 and LF are probably OK for all files, I am not 100% sure about:
> +insert_final_newline = true
> +indent_style = tab
> +indent_size = 8
for other languages and non-code files
Hi Christoph,
On Wed, Jul 1, 2020 at 10:25 PM Christoph Hellwig wrote:
>
> Switch over all instances used directly as methods using these sed
> expressions:
>
> sed -i -e 's/\.read\(\s*=\s*\)seq_read/\.read_iter\1seq_read_iter/g'
>
> Signed-off-by: Christoph Hellwig
Nit: the replacements don't
On Tue, Jun 30, 2020 at 6:26 PM Masahiro Yamada wrote:
>
> I can reproduce this in the following
> simple test code:
>
>
> ->8
> #include
>
> int main(void)
> {
> ssize_t x = 1;
>
> printf("%zd", x);
>
> return 0;
> }
>
On Mon, Jun 22, 2020 at 7:29 PM Joe Perches wrote:
>
> scripts/get_maintainer.pl --self-test=links has a reachability test
> using wget.
>
> Perhaps a script like that could be used for http:// vs https://
+1
Not sure about `--no-check-certificate` if the goal is to move to
"proper HTTPS".
On Mon, Jun 22, 2020 at 3:06 PM Jonathan Corbet wrote:
>
> As has been noted elsewhere, checkpatch.pl seems like the appropriate
> place to make this check. As for "the entire tree"...if this job gets
> completed, "git grep" should be a fine way to do that.
`checkpatch` is not really enforced
Hi Joe,
I didn't forget about this -- I was playing the other day with
`ColumnLimit: 0` and the new options up to LLVM 11 to see what we
could do... See below.
On Thu, Jun 11, 2020 at 9:26 PM Joe Perches wrote:
>
> Hey again Miguel:
>
> A little script and some statistics:
>
> Today about 6% of
Hi Luc,
On Sun, Jun 21, 2020 at 4:37 PM Luc Van Oostenryck
wrote:
>
> By popular demand, reorder the defines for sparse annotations
> and group them by functionality.
Thanks!
Acked-by: Miguel Ojeda
Cheers,
Miguel
Hi Alexander,
On Sun, Jun 21, 2020 at 4:30 PM Alexander A. Klimov
wrote:
>
> Which discussion? 93431e0607e5 ? IMAO the patches don't depend on each
> other.
The one we had the other day. It does not matter that the patches
depend on each other. It is information for whoever sees this commit.
>
Alexander A. Klimov
> ---
Looks fine, although it would be nice to have a link to the discussion
(using a `Link: ` line to `lore.kernel.org`). Also having the script
in the kernel would be nice for future re-runs (e.g. you could add it
as a first patch in the series).
Other than that:
Acked-by: Miguel Ojeda
Cheers,
Miguel
On Fri, Jun 19, 2020 at 10:07 AM Geert Uytterhoeven
wrote:
>
> Indeed. It looks like this whole list is completely unsorted, and was created
> by appending new definitions at the bottom.
The "historical ordering" :)
+1 for sorting, whatever the ordering (and perhaps adding a comment
saying
I guess `__kernel` moves to the first place since it uses the first
address space?
Acked-by: Miguel Ojeda
Cheers,
Miguel
lly the list was meant to be used inside
the file itself, but I see it is good to reuse it).
Reviewed-by: Miguel Ojeda
Cheers,
Miguel
On Thu, Jun 11, 2020 at 6:22 PM Joe Perches wrote:
>
> On Thu, 2020-06-11 at 13:54 +0200, Miguel Ojeda wrote:
> > Why is 80 "still preferred" to begin with?
>
> That's neither my nor your issue to solve.
? You (or Linus, I still don't know since the commit is o
On Thu, Jun 11, 2020 at 1:02 PM Alexander A. Klimov
wrote:
>
> Who if not Linus shall review one huge patch spreading across lots of
> subsystems?
Even if a patch is tree-wide, ideally it is first ack'd/reviewed by
each subsystem maintainer. The overall idea is that changes are
reviewed by
ssing every break :-)
Cheers,
Miguel
[*] (please excuse any word-wrap)
>From 3b3cad415b56498534fadf732f2762f4dbe108eb Mon Sep 17 00:00:00 2001
From: Miguel Ojeda
Date: Thu, 11 Jun 2020 13:16:46 +0200
Subject: [PATCH] coding-style: don't mention line length hard limits, add tips
Signed-of
On Thu, Jun 11, 2020 at 9:02 AM Alexander A. Klimov
wrote:
>
> Is any of you familiar with Golang?
Don't worry about that! I'd expect seasoned C programmers to be able
to read Go (or near languages) -- at least to have a general idea of
what an algorithm does.
It is not APL, after all :-)
>
>
Hi Joe,
On Wed, Jun 10, 2020 at 7:13 PM Joe Perches wrote:
>
> Ii think this is a not a good change.
>
> If you read the commit log you provided, it ways
> "staying withing 80 columns is certainly still _preferred_"
Yes, but the related email discussions were not about establishing a
new hard
Hi Christian,
On Wed, Jun 10, 2020 at 2:51 PM Christian Brauner
wrote:
>
> The provided clang-format file wraps at 80 chars. If no one minds, I'd like
> to adjust this limit to 100 similar to what checkpatch (cf. [1]) uses now.
Thanks! Picking this up with a few changes to the commit message.
On Thu, Jun 4, 2020 at 4:56 PM Kees Cook wrote:
>
> Er? That's not what it looked like to me:
>
> #define IS_BUILTIN(option) __is_defined(option)
> #define IS_ENABLED(option) __or(IS_BUILTIN(option), IS_MODULE(option))
>
> But just to be sure, I just tested in with a real build:
>
> [
> +#if __has_attribute(__no_caller_saved_registers__)
> +# define __no_caller_saved_registers
> __attribute__((__no_caller_saved_registers__))
> +#else
> +# define __no_caller_saved_registers
> +#endif
Ditto.
Acked-by: Miguel Ojeda
Cheers,
Miguel
On Thu, Jun 4, 2020 at 9:58 AM Thomas Gleixner wrote:
>
> but if we ever lose the 1 then the above will silently compile the code
> within the IS_ENABLED() section out.
Yeah, I believe `IS_ENABLED()` is only meant for Kconfig symbols, not
macro defs in general. A better option would be
igned-off-by: Kees Cook
> ---
+1, one less trick split between `compiler*` files.
Reviewed-by: Miguel Ojeda
Cheers,
Miguel
On Tue, Jun 2, 2020 at 8:49 PM Nick Desaulniers wrote:
>
> Currently most of our compiler attribute detection is done in
> include/linux/compiler_attributes.h; I think this should be handled
> there. +Miguel Ojeda
Thanks a lot for the CC Nick! Marco is right, since this attribute
Hi Andy,
On Mon, May 18, 2020 at 9:36 PM Andy Shevchenko
wrote:
>
> hex_to_bin() may be used to convert hexdecimal digit to its binary
> representation.
>
> Signed-off-by: Andy Shevchenko
> ---
Looks fine to me and the logic is simpler for the `esc` increase too.
Thanks for the cleanup! Were
Hi Rob,
On Thu, May 14, 2020 at 1:30 PM Geert Uytterhoeven wrote:
>
> Convert the Hitachi HD44780 Character LCD Controller Device Tree binding
> documentation to json-schema.
Do you usually take these ones or should I?
Cheers,
Miguel
On Fri, Oct 18, 2019 at 10:33 PM Nick Desaulniers
wrote:
>
> Sami pointed out to me off thread that __has_attribute would only
> check `no_sanitize`, not `shadow-call-stack`. So maybe best to keep
> the definition here (include/linux/compiler-clang.h), but wrapped in a
> `__has_feature` check so
On Fri, Oct 18, 2019 at 7:11 PM Sami Tolvanen wrote:
>
> On Fri, Oct 18, 2019 at 10:08 AM 'Nick Desaulniers' via Clang Built
> Linux wrote:
> > > diff --git a/include/linux/compiler-clang.h
> > > b/include/linux/compiler-clang.h
> > > index 333a6695a918..9af08391f205 100644
> > > ---
On Thu, Oct 17, 2019 at 10:07 AM Lars Poeschel wrote:
>
> That panel.c doesn't compile is of course a no-go. Sorry. I missed
> something and I will fix this in a next version of the patch. But before
> submitting a next version, I will wait some time, if there is more
> feedback.
I meant I
On Wed, Oct 16, 2019 at 10:24 AM Lars Poeschel wrote:
>
> charlcd.c contains lots of hd44780 hardware specific stuff. It is nearly
> impossible to reuse the interface for other character based displays.
> The current users of charlcd are the hd44780 and the panel drivers.
> This does factor out
On Sat, Oct 12, 2019 at 12:08 AM Kees Cook wrote:
>
> On Fri, Oct 11, 2019 at 08:01:42PM +0200, Miguel Ojeda wrote:
> > Hi Linus,
> >
> > On Fri, Oct 11, 2019 at 6:30 PM Linus Torvalds
> > wrote:
> > >
> > > On Sat, Oct 5, 2019 at 9:46 AM Joe
On Thu, Oct 10, 2019 at 10:37 PM Kees Cook wrote:
>
> On Sat, Oct 05, 2019 at 07:17:36PM +0200, Miguel Ojeda wrote:
> > Hi Joe,
> >
> > On Sat, Oct 5, 2019 at 6:46 PM Joe Perches wrote:
> > >
> > > Reserve the pseudo keyword 'fallthrough' for the abili
Hi Linus,
On Fri, Oct 11, 2019 at 6:30 PM Linus Torvalds
wrote:
>
> On Sat, Oct 5, 2019 at 9:46 AM Joe Perches wrote:
> >
> > Add 'fallthrough' pseudo-keyword to enable the removal of comments
> > like '/* fallthrough */'.
>
> I applied patches 1-3 to my tree just to make it easier for people
Hi Joe,
On Sat, Oct 5, 2019 at 6:47 PM Joe Perches wrote:
>
> diff --git a/scripts/cvt_style.pl b/scripts/cvt_style.pl
> new file mode 100755
> index ..fcbda0b1c67a
> --- /dev/null
> +++ b/scripts/cvt_style.pl
> @@ -0,0 +1,808 @@
> +#!/usr/bin/perl -w
Nit: #!/usr/bin/env perl
Hi Joe,
On Sat, Oct 5, 2019 at 6:46 PM Joe Perches wrote:
>
> Reserve the pseudo keyword 'fallthrough' for the ability to convert the
> various case block /* fallthrough */ style comments to appear to be an
> actual reserved word with the same gcc case block missing fallthrough
> warning
On Thu, Oct 3, 2019 at 7:29 PM Linus Torvalds
wrote:
>
> On Thu, Oct 3, 2019 at 10:24 AM Masahiro Yamada
> wrote:
> >
> > I just want to annotate __always_inline for the case
> > "2. code that if not inlined is somehow not correct."
>
> Oh, I support that entirely - if only for documentation.
>
On Tue, Oct 1, 2019 at 10:53 PM Arnd Bergmann wrote:
>
> 1. is clearly the most common case, but there is also
>
> 4. Some compiler version (possibly long gone, possibly still current)
> makes bad inlining decisions that result in horrible but functionally
> correct object code for a particular
On Mon, Sep 30, 2019 at 11:50 PM Nick Desaulniers
wrote:
>
> So __attribute__((always_inline)) doesn't guarantee that code will be
> inlined. [...] inline and __attribute__((always_inline))
> are a heuristic laden mess and should not be relied upon.
Small note: in GCC,
e I'll need to add:
>
> commit edc966de8725f9186cc9358214da89d335f0e0bd
> Author: Miguel Ojeda
> Date: Fri Aug 2 12:37:56 2019 +0200
>
> Backport minimal compiler_attributes.h to support GCC 9
>
> commit a6e60d84989fa0e91db7f236eda40453b0e44afa
> Author: Miguel Oj
Hi Linus,
Please pull this patch series which make us take advantage of `asm inline`.
You will encounter an easy merge conflict on `init/Kconfig` due to
the (already merged) arm64 tree.
Cheers,
Miguel
The following changes since commit f74c2bb98776e2de508f4d607cd519873065118e:
Linux 5.3-rc8
On Fri, Sep 13, 2019 at 1:26 AM Joe Perches wrote:
>
> Not every project is going to use only the clang-format tool.
Why? The end goal would be to enforce all code to be running under the
same formatting rules (which, in practice, means the same tool at the
moment).
Note that you can use
On Fri, Sep 13, 2019 at 5:21 PM Greg Kroah-Hartman
wrote:
>
> Feel free to also take that patch through any tree, it's "obviously
> correct" :)
OK :) Picked all 6 in compiler-attributes:
https://github.com/ojeda/linux/commits/compiler-attributes
I added Ingo's Acks and fixed a minor typo
On Fri, Sep 13, 2019 at 12:19 AM Rasmus Villemoes
wrote:
>
> Patch 1 has already been picked up by Greg in staging-next, it's
> included here for completeness. I don't know how to route the rest, or
> if they should simply wait for 5.5 given how close we are to the merge
> window for 5.4.
If you
On Thu, Sep 12, 2019 at 11:08 PM Joe Perches wrote:
>
> Please name the major projects and then point to their
> .clang-format equivalents.
>
> Also note the size/scope/complexity of the major projects.
Mozilla, WebKit, LLVM and Microsoft. They have their style distributed
with the official
On Thu, Sep 12, 2019 at 12:18 PM Joe Perches wrote:
>
> I don't think that's close to true yet for clang-format.
I don't expect clang-format to match perfectly our current code style.
However, if core maintainers agree that it is "close enough now"
(specially with newer LLVMs, like 9), then
On Thu, Sep 12, 2019 at 4:00 PM Jeff Moyer wrote:
>
> Joe Perches writes:
>
> > Rather than have a local coding style, use the typical kernel style.
>
> The coding style isn't that different from the core kernel, and it's
> still quite readable. I'd rather avoid the churn and the risk of
>
On Thu, Sep 12, 2019 at 10:15 AM Joe Perches wrote:
>
> I am adding Miguel Ojeda to the cc's.
Thanks Joe!
> Of course you are welcome to try it, but I believe that
> clang-format doesn't work all that well yet.
>
> It's more a work in progress rather than a "standard"
On Thu, Sep 12, 2019 at 9:43 AM Dan Williams wrote:
>
> Now I come to find that CodingStyle has settled on clang-format (in
> the last 15 months) as the new standard which is a much better answer
> to me than a manually specified style open to interpretation. I'll
> take a look at getting
On Thu, Sep 5, 2019 at 3:50 PM Mike Travis wrote:
>
> These patches support upcoming UV systems that do not have a UV HUB.
Please send patches as plain text without attachments. See:
On Tue, Sep 10, 2019 at 10:58 AM Sedat Dilek wrote:
>
> Sorry, I was not precise enough and didn't remember correctly.
>
> I have re-tested with Linux v5.3-rc8. All OK.
No worries at all! I just wanted to clarify it :)
Thanks a lot for confirming it works.
Cheers,
Miguel
On Sun, Sep 8, 2019 at 3:19 PM Miguel Ojeda
wrote:
>
> https://github.com/ojeda/linux.git tags/clang-format-for-linus-v5.3-rc8
Typo in the tag name, you can also use the tag:
https://github.com/ojeda/linux.git
tags/compiler-attributes-for-linus-v5.3-rc8
Cheers,
Miguel
Hi Linus,
Here it is the Oops-fixing cherry-picked commit for -rc8 from the __section
cleanup series.
Cheers,
Miguel
The following changes since commit 089cf7f6ecb266b6a4164919a2e69bd2f938374a:
Linux 5.3-rc7 (2019-09-02 09:57:40 -0700)
are available in the Git repository at:
On Sat, Sep 7, 2019 at 7:50 AM Sedat Dilek wrote:
>
> The compiler-attribute patchset sit for some weeks in linux-next, so I
> have not seen any complains.
It has been there only since Monday (cleanly), not weeks.
Cheers,
Miguel
On Thu, Sep 5, 2019 at 10:53 PM Linus Torvalds
wrote:
>
> That's probably what we should have done originally, avoiding all the
> issues with "what if we have multi-part strings" etc.
>
> But it's not what we did, probably because it looked slightly simpler
> to do the stringification in the
On Thu, Sep 5, 2019 at 7:22 PM Linus Torvalds
wrote:
>
> "Why not just clean up the rest" is how bugs happen.
>
> If it's not a fix, and it's not marked for stable (or a regression
> from the merge window) it shouldn't go in this late in the rc period.
>
> Send me _fixes_. Don't send me stuff
On Thu, Sep 5, 2019 at 6:20 PM Linus Torvalds
wrote:
>
> Macro stringification isn't entirely obvious, and an unquoted string
> could become corrupted if the stringification ends up not happening
> immediately.
Nick, Linus: shouldn't we just simply go for no stringifying at all,
i.e. changing it
On Wed, Sep 4, 2019 at 8:18 PM Miguel Ojeda
wrote:
>
> I was going to send this for 5.4 since it is not that trivial, but since
> you are doing an -rc8, and it fixes an oops, please consider pulling it.
By the way, if you choose to pick it for 5.4 instead, I will take the
chance to impr
On Thu, Sep 5, 2019 at 2:00 AM Nick Desaulniers wrote:
>
> While you're here, would you mind replacing `__attribute__((unused))`
> with `__unused`? I would consider "naked attributes" (haven't been
> feature tested in include/linux/compiler_attributes.h and are verbose)
> to be an antipattern.
On Thu, Sep 5, 2019 at 1:35 AM Joe Perches wrote:
>
> It's a long, long list.
>
> $ git grep -P -h '^\s*#\s*define\s+\w*for_each\w*' | \
> grep -P -oh '\w+for_each\w*' | sort | uniq | wc -l
> 491
>
> Isn't there some way to regexes or automate this?
>
> Maybe just:
> $ git grep -P -h
Miguel Ojeda (1):
clang-format: Update with the latest for_each macro list
.clang-format | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
Hi Linus,
I was going to send this for 5.4 since it is not that trivial, but since
you are doing an -rc8, and it fixes an oops, please consider pulling it.
Cheers,
Miguel
The following changes since commit a55aa89aab90fae7c815b0551b07be37db359d76:
Linux 5.3-rc6 (2019-08-25 12:01:23 -0700)
On Thu, Aug 29, 2019 at 8:13 PM Masahiro Yamada
wrote:
>
> +# W=1 - warnings that may be relevant and does not occur too often
s/does/do/
Acked-by: Miguel Ojeda
Cheers,
Miguel
On Fri, Aug 30, 2019 at 1:09 PM Joe Perches wrote:
>
> On Thu, 2019-08-29 at 14:02 +0200, Michal Suchanek wrote:
> > In particular the default value of 3 does not match the comments like
> > /* falls through to do foobar */
>
> How many comments are there like this in the kernel?
+1 Given we are
On Fri, Aug 30, 2019 at 12:54 AM Miguel Ojeda
wrote:
>
> Yeah, we just saw it, I was about to drop it from the queue. It is
> indeed because we don't have those __* defines within the compilation
> environment of the kernel.
Dropped!
Cheers,
Miguel
On Fri, Aug 30, 2019 at 12:52 AM Stephen Rothwell wrote:
>
> Caused by commit
>
> e81c903fb9e2 ("powerpc: prefer __section and __printf from
> compiler_attributes.h")
>
> I have reverted that commit for today.
>
> gcc v9.2.1 (in case that matters)
>
> The above error is from the PowerPC boot
On Thu, Aug 29, 2019 at 12:55 AM Nick Desaulniers
wrote:
>
> Changes V2 -> V3:
> * s/__attribute__((__section/__attribute__((__section__ in commit
> messages as per Joe.
I have uploaded to -next v3 so that we get some feedback tomorrow
rather than waiting for Monday.
I added a few changes,
On Thu, Aug 29, 2019 at 4:14 PM Miguel Ojeda
wrote:
>
> On Thu, Aug 29, 2019 at 12:56 AM Nick Desaulniers
> wrote:
> >
> > diff --git a/arch/x86/include/asm/iommu_table.h
> > b/arch/x86/include/asm/iommu_table.h
> > index 1fb3fd1a83c2..7d190710eb92 1006
On Thu, Aug 29, 2019 at 12:56 AM Nick Desaulniers
wrote:
>
> diff --git a/arch/x86/include/asm/iommu_table.h
> b/arch/x86/include/asm/iommu_table.h
> index 1fb3fd1a83c2..7d190710eb92 100644
> --- a/arch/x86/include/asm/iommu_table.h
> +++ b/arch/x86/include/asm/iommu_table.h
> @@ -50,9 +50,8 @@
On Wed, Aug 28, 2019 at 6:21 PM Masahiro Yamada
wrote:
>
> Applied to linux-kbuild. Thanks.
>
> (If other clang folks give tags, I will add them later.)
Acked-by: Miguel Ojeda
Cheers,
Miguel
Hi Linus,
Please pull this cleanup.
Cheers,
Miguel
The following changes since commit d1abaeb3be7b5fa6d7a1fbbd2e14e3310005c4c1:
Linux 5.3-rc5 (2019-08-18 14:31:08 -0700)
are available in the Git repository at:
https://github.com/ojeda/linux.git tags/auxdisplay-for-linus-v5.3-rc7
for you
On Tue, Aug 13, 2019 at 10:33 AM Will Deacon wrote:
>
> -ENOCOMMITMESSAGE
>
> Otherwise, patch looks good to me.
Do you want Ack, Review or nothing?
Cheers,
Miguel
On Sat, Aug 24, 2019 at 1:25 PM Will Deacon wrote:
>
> Which bit are you pinging about? This patch (12/16) has been in -next for a
> while and is queued in the arm64 tree for 5.4. The Oops/boot issue is
> addressed in patch 14 which probably needs to be sent as a separate patch
> (with a commit
201 - 300 of 1034 matches
Mail list logo
