Hi Nick,
On Mon, Apr 19, 2021 at 10:36 PM Nick Desaulniers
wrote:
>
> This is a much different process than drafts thrown over the wall.
> What hope do any kernel contributors have to participate in the ISO
> WGs, other than hoping their contributions to a draft foresee/address
> any concerns
On Mon, Apr 19, 2021 at 10:18 PM Matthew Wilcox wrote:
>
> Yes, I agree, we need a better story for name mangling.
> My proposal is that we store a pretty name which matches the source
> (eg rust_binder::range_alloc) and a sha1 of the mangled symbol
> (40 bytes of uninteresting hex). Symbol
Hi David,
On Mon, Apr 19, 2021 at 10:01 PM David Sterba wrote:
>
> for simple functions it's barely parseable but the following is hardly
> readable
>
> translates to
>
>core[8787f43e282added]::fmt::Debug>::fmt
Some details can be omitted without much problem, e.g. try the `-i`
option of
On Sat, Apr 17, 2021 at 6:24 AM Willy Tarreau wrote:
>
> My concern was to know what field to look at to reliably detect an error
> from the C side after a sequence doing C -> Rust -> C when the inner C
> code uses NULL to mark an error and the upper C code uses NULL as a valid
> value and needs
On Sat, Apr 17, 2021 at 4:21 PM Willy Tarreau wrote:
>
> Well, I can't express how much I hate abstractions because I constantly
> need to know what it's doing under the hood, and I spend my time reading
> the output asm code because I always want to confirm my assumptions about
> the compiler
On Sat, Apr 17, 2021 at 12:04 AM Willy Tarreau wrote:
>
> But my point remains that the point of extreme care is at the interface
> with the rest of the kernel because there is a change of semantics
> there.
>
> Sure but as I said most often (due to API or ABI inheritance), both
> are already
On Fri, Apr 16, 2021 at 10:58 PM Willy Tarreau wrote:
>
> No, two:
> - ok in %rax (seems like it's "!ok" technically speaking since it
> returns 1 on !ok and 0 on ok)
> - foo_or_err in %rdx
Yes, but that is the implementation -- conceptually you only have one
or the other, and Rust won't
On Fri, Apr 16, 2021 at 10:22 PM Willy Tarreau wrote:
>
> So it simply does the equivalent of:
>
> struct result {
> int status;
> int error;
> };
Not exactly, it is more like a tagged union, as Connor mentioned.
However, and this is the critical bit: it is a compile-time error to
On Sun, Apr 11, 2021 at 11:27 PM Michal Suchánek wrote:
>
> Yes, I do have the rust support.
I applied your patch in rust-next and it is in the latest linux-next,
let me know if that helped.
Masahiro, if you want to apply it on your side, just let me know!
Cheers,
Miguel
On Fri, Apr 16, 2021 at 8:10 PM Al Viro wrote:
>
> How well would ? operator fit that pattern? _If_ it's just a syntax sugar
> along the lines of "if argument matches Err(_), return Err(_)", the types
> shouldn't be an issue, but that might need some fun with releasing resources,
> etc. If it's
On Fri, Apr 16, 2021 at 7:05 PM Linus Torvalds
wrote:
>
> Typical Rust error handling should match the regular kernel
> IS_ERR/ERR_PTR/PTR_ERR model fairly well, although the syntax is
> fairly different (and it's not limited to pointers).
Yeah, exactly. We already have a `KernelResult` type
On Fri, Apr 16, 2021 at 3:38 PM Peter Zijlstra wrote:
>
> So if I read all this right, rust compiles to .o and, like any other .o
> file is then fed into objtool (for x86_64). Did you have any problems
> with objtool? Does it generate correct ORC unwind information?
I opened an issue a while ago
On Fri, Apr 16, 2021 at 6:14 PM Willy Tarreau wrote:
>
> I'm really afraid by languages which force developers to do this or that.
> Many bugs in C come from casts because developers know their use case
> better than the compiler's developers, and result in lack of warnings
> when the code
On Fri, Apr 16, 2021 at 5:43 PM Peter Zijlstra wrote:
>
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2659.htm
>
> That's just not making any damn sense what so ever. That seems to be
> about sprinkling abort() all over the place, which is just total
> rubbish.
No, it is not about that. It
On Fri, Apr 16, 2021 at 4:19 PM Peter Zijlstra wrote:
>
> Does this also not prohibit constructs where modification must be done
> while holding two locks, but reading can be done while holding either
> lock?
Yeah, this came up in some discussions we had. There are some locking
patterns that we
On Fri, Apr 16, 2021 at 1:24 PM Peter Zijlstra wrote:
>
> IMO RAII is over-valued, but just in case you care, the below seems to
> work just fine. No fancy new language needed, works today. Similarly you
> can create refcount_t guards, or with a little more work full blown
> smart_ptr crud.
Hi Stephen,
On Fri, Apr 16, 2021 at 9:58 AM Stephen Rothwell wrote:
>
> from the char-misc tree and commit:
>
> 1fed5dee5fbb ("Android: Binder IPC in Rust (WIP)")
>
> from the rust tree.
If you prefer, I can take out the binder bits from rust-next since
they will be submitted separately
On Thu, Apr 15, 2021 at 8:03 PM Nick Desaulniers
wrote:
>
> Until then, I don't see why we need to permit developers to express
> such flexibility for just the Rust code, or have it differ from the
> intent of the C code. Does it make sense to set RUST_OPT_LEVEL_3 and
> CC_OPTIMIZE_FOR_SIZE? I
On Thu, Apr 15, 2021 at 9:10 AM Greg Kroah-Hartman
wrote:
>
> Let's see what happens here, this patchset is a great start that
> provides the core "here's how to build rust in the kernel build system",
> which was a non-trivial engineering effort. Hats off to them that "all"
> I had to do was
On Thu, Apr 15, 2021 at 3:38 AM Kees Cook wrote:
>
> Before anything else: yay! I'm really glad to see this RFC officially
> hit LKML. :)
Thanks! :)
> When originally learning Rust I was disappointed to see that (by default)
> Rust similarly ignores the overflow problem, but I'm glad to see the
Hi Nathan,
Sorry, with all the other things I ended up not replying to you before
going to sleep.
On Wed, Apr 14, 2021 at 8:59 PM Nathan Chancellor wrote:
>
> Shuffling this around will cause this issue (I never saw you CC'd on the
> thread).
>
>
On Thu, Apr 15, 2021 at 2:23 AM Nick Desaulniers
wrote:
>
> Looks like Wedson's writeup is now live. Nice job Wedson!
> https://security.googleblog.com/2021/04/rust-in-linux-kernel.html
+1 It is very nicely written and explains the semaphore samples
(included in the RFC) he wrote, with nice
On Thu, Apr 15, 2021 at 1:47 AM Nick Desaulniers
wrote:
>
> I'm ok with this approach, but I'm curious:
> If the user made a copy of the CLANG_FLAGS variable and modified its
> copy, would TENTATIVE_CLANG_FLAGS even be necessary? IIUC,
> TENTATIVE_CLANG_FLAGS is used to filter out certain flags
On Thu, Apr 15, 2021 at 1:19 AM Nick Desaulniers
wrote:
>
> Rather than check the origin (yikes, are we intentionally avoiding env
> vars?), can this simply be
> ifneq ($(CLIPPY),)
> KBUILD_CLIPPY := $(CLIPPY)
> endif
>
> Then you can specify whatever value you want, support command line or
>
Hi Nick,
Thanks a lot for looking into this!
On Thu, Apr 15, 2021 at 12:18 AM Nick Desaulniers
wrote:
>
> Was this TODO meant to be removed, or is it still pending? If pending,
> on what? Being able to link back on itself if/once merged?
Still pending -- the plan is to upload the docs to
On Wed, Apr 14, 2021 at 11:55 PM Nick Desaulniers
wrote:
>
> Assuming this will at least be part of Wedson's core responsibilities,
> shouldn't this be "Supported." Per Maintainers:
Yeah, we were waiting until a couple other announcements to change it
-- but it will most likely be "Supported"
On Wed, Apr 14, 2021 at 10:10 PM Matthew Wilcox wrote:
>
> On Wed, Apr 14, 2021 at 08:45:51PM +0200, oj...@kernel.org wrote:
> > - Manish Goregaokar implemented the fallible `Box`, `Arc`, and `Rc`
> > allocator APIs in Rust's `alloc` standard library for us.
>
> There's a philosophical
On Wed, Apr 14, 2021 at 9:45 PM Linus Torvalds
wrote:
>
> With the main point of Rust being safety, there is no way I will ever
> accept "panic dynamically" (whether due to out-of-memory or due to
> anything else - I also reacted to the "floating point use causes
> dynamic panics") as a feature
On Wed, Apr 14, 2021 at 9:45 PM Matthew Wilcox wrote:
>
> How about doing something a bit more utf-8-like?
>
> len = data[0];
> if (len == 0)
> error
> else if (len < 128)
> return len;
> else if (len < 192)
> return
On Wed, Apr 14, 2021 at 9:31 PM Linus Torvalds
wrote:
>
> Again, excuse my lack of internal Rust knowledge, but when do these
> end up being an issue?
>
> If the Rust compiler ends up doing hidden allocations, and they then
> cause panics, then one of the main *points* of Rustification is
>
On Wed, Apr 14, 2021 at 9:34 PM Linus Torvalds
wrote:
>
> Honestly, I'd like to see a real example. This is fine for testing,
> but I'd like to see something a bit more real, and a bit less special
> than the Android "binder" WIP that comes a few patches later.
>
> Would there be some kind of
On Wed, Apr 14, 2021 at 9:19 PM Linus Torvalds
wrote:
>
> Not being a Rust person, I can only guess based on random pattern
> matching, but this _looks_ like these "panicking intrinsics" panic at
> run-time (by calling BUG()).
Your pattern matching works well :)
> Is there some way these things
which is the
best case scenario :)
Reviewed-by: Miguel Ojeda
[1]
https://github.com/facebook/zstd/commit/f2d6db45cd28457fa08467416e8535985f062859
Cheers,
Miguel
On Tue, Mar 30, 2021 at 1:07 PM Jani Nikula wrote:
>
> FWIW, and this should be obvious, I think going with what's natural for
> documenting Rust source code is the right choice. Markdown as parsed by
> rustdoc. People will expect Rust documentation comments to just work,
> without some kernel
On Thu, Mar 25, 2021 at 11:18 PM Matthew Wilcox wrote:
>
> The rust code is alredy coming though ...
>
> rust/kernel/buffer.rs:/// A pre-allocated buffer that implements
> [`core::fmt::Write`].
>
> so now we have three formats. Markdown and RST are _very_ similar, but
> not identical [1]. Oh,
On Mon, Mar 29, 2021 at 9:34 PM Jonathan Corbet wrote:
>
> If we're going to talk about incorporating Rust into the doc system, we
> should probably include some Rust folks - thus, I'm adding Miguel.
Thanks a lot Jonathan for the Cc!
I will read and answer the other emails.
Cheers,
Miguel
at least in the current version in GitHub.
Acked-by: Miguel Ojeda
Cheers,
Miguel
Hi Linus,
Please pull this fix for auxdisplay.
Thanks!
Cheers,
Miguel
The following changes since commit 1e28eed17697bcf343c6743f0028cc3b5dd88bf0:
Linux 5.12-rc3 (2021-03-14 14:41:02 -0700)
are available in the Git repository at:
https://github.com/ojeda/linux.git
On Thu, Mar 25, 2021 at 8:02 AM Masahiro Yamada wrote:
>
> This is sensible for tools that interface to users.
> Users have no interest in which language is used
> internally.
Agreed in the general case (e.g. everyday tools). In the kernel's
case, however, I think it is not as important.
And I
editor-independent manner,
> I think editorconfig (patch [1]) is a saner solution.
>
> [1] https://lore.kernel.org/lkml/20200703073143.423557-1-da...@kdrag0n.dev/
>
> Signed-off-by: Masahiro Yamada
+1 It is great to get rid of those.
For auxdisplay:
Reviewed-by: Miguel Ojeda
F
On Tue, Mar 23, 2021 at 1:16 PM Michael Ellerman wrote:
>
> It would be nice to be in the CI. I was building natively so I haven't
> tried cross compiling yet (which we'll need for CI).
Indeed -- in the CI we already cross-compile arm64 (and run under QEMU
both arm64 as well as x86_64), so it is
Hi Michael,
On Tue, Mar 23, 2021 at 4:27 AM Michael Ellerman wrote:
>
> Hi all,
>
> Here's a first attempt at getting the kernel Rust support building on powerpc.
Thanks a *lot*! It is great to have more architectures rolling.
> It's powerpc64le only for now, as that's what I can easily test
On Tue, Mar 23, 2021 at 4:27 AM Michael Ellerman wrote:
>
> ppc64le only for now. We'll eventually need to come up with some way to
> change the target.json that's used based on more than just $(ARCH).
Indeed, it is one reason I didn't tackle e.g. x86 32-bit, because I
wanted to figure out how
On Mon, Mar 22, 2021 at 1:20 PM Miguel Ojeda
wrote:
>
> I'll take a look at fixing those soon.
For those that may read this or run into the same issue: this started
with the LLVM 12 upgrade in rustc nightlies. Therefore, please avoid
the very latest nightlies (>= nightly-2021-03-05)
On Mon, Mar 22, 2021 at 3:48 PM Geert Uytterhoeven wrote:
>
> You can find an image of the full character set at
> https://drive.google.com/file/d/1h3EYFBWHIjh8B_cwPA5ocAD-lFYipRie/view
Should we put it in e.g. the Docs or just alongside this file?
Cheers,
Miguel
On Mon, Mar 22, 2021 at 3:48 PM Geert Uytterhoeven wrote:
>
> Thanks for your comments!
We could use this as a showcase on how to structure and present a
patch series! ;-)
Cheers,
Miguel
On Mon, Mar 22, 2021 at 3:48 PM Geert Uytterhoeven wrote:
>
> + struct device *dev = >dev;
Do we want helpers like this to be `*const` (assuming they can)? (same
for patch 12).
Cheers,
Miguel
Hi Joshua,
On Mon, Mar 22, 2021 at 3:53 AM Joshua Abraham wrote:
>
> Cheers, using rustc 1.52.0-nightly (9b471a3f5 2021-02-19) fixed the
> issue. Interesting that the newer nightly compiler creates these new
> relocations for the code!
Thanks a lot for the report and for confirming that worked
Hi Alexander,
On Sun, Mar 21, 2021 at 8:14 PM Alexander Lochmann
wrote:
>
> diff --git a/Documentation/dev-tools/kcov.rst
> b/Documentation/dev-tools/kcov.rst
> index d2c4c27e1702..e105ffe6b6e3 100644
> --- a/Documentation/dev-tools/kcov.rst
> +++ b/Documentation/dev-tools/kcov.rst
> @@ -127,6
On Sun, Mar 21, 2021 at 9:03 PM Miguel Ojeda
wrote:
>
> The supported architectures are in
> Documentation/rust/arch-support.rst, so we should link to that.
>
> Yeah, this is mentioned on the bindgen section in quick-start.rst, I
> will try to improve make it more clear, perh
Hi Joshua,
On Mon, Mar 22, 2021 at 1:13 AM Joshua Abraham wrote:
>
> $ rustc --version
> rustc 1.52.0-nightly (61edfd591 2021-03-20)
Please give a go to the nightly from a month ago, i.e. 2021-02-20.
Cheers,
Miguel
On Sun, Mar 21, 2021 at 10:58 PM Miguel Ojeda
wrote:
>
> I tried your config and it worked, so it looks like the problem is
> your old libclang (7) does not recognize some of the flags. If you can
> try a newer LLVM installation, it would be great to confirm it.
Yeah, LLVM introdu
On Sun, Mar 21, 2021 at 9:56 PM Pavel Machek wrote:
>
> Done, in a private message.
I tried your config and it worked, so it looks like the problem is
your old libclang (7) does not recognize some of the flags. If you can
try a newer LLVM installation, it would be great to confirm it.
On Sun, Mar 21, 2021 at 9:56 PM Pavel Machek wrote:
>
> Thanks for your work :-).
You're welcome! We're trying our best :-)
> Actually x86-32 would be useful for me. That's my test machine.
Sorry... :-( x86 32-bits, ppc64el, s390x... are some of the ones we
will look into soon, but possibly
Hi Pavel,
On Sun, Mar 21, 2021 at 8:37 PM Pavel Machek wrote:
>
> First try was on x86-32. It took me a whlie to figure out the problem,
> hence the diff below.
Thanks a lot for trying it out and for the feedback! :-)
The supported architectures are in
Documentation/rust/arch-support.rst, so
On Sun, Mar 21, 2021 at 1:30 PM Michael Ellerman wrote:
>
> Yes. But Monday in UTC+11 :)
Yeah :-) I'm on it.
Cheers,
Miguel
On Sat, Mar 20, 2021 at 6:33 AM Stephen Rothwell wrote:
>
> Daniel Axtens reported the same breakage on powerpc. I bisected it to
> the same commit. More experimentation shows that if you reverse just
> the change to include/linux/moduleparam.h the above warnings go away.
> So
>
> -#define
On Sat, Mar 20, 2021 at 7:07 AM Miguel Ojeda
wrote:
>
> Sorry for that, and thanks a lot for taking a look. For the Rust
> support I had to increase a few limits, mainly the symbol length. Let
> me check and I'll report back.
Reproduced on s390. However, under defconfig, one also nee
On Sat, Mar 20, 2021 at 7:49 AM Miguel Ojeda
wrote:
>
> Reproduced on s390. However, under defconfig, one also needs to revert
> kernel/livepatch/core.c to avoid triggering the assert, i.e.:
Stephen: I will put this in rust-next so that others don't see
problems on their side
On Fri, Mar 19, 2021 at 7:45 PM Ansuel Smith wrote:
>
> Sorry, didn't notice that. Considering that checkpatch complains and
> some reviewers actually state that 100 is the new limit, I think it's
> time to update the file.
IIUC, 80 is still the soft limit, but 100 is now the hard limit.
Cc'ing
On Thu, Mar 18, 2021 at 7:24 AM Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the rust tree, today's linux-next build (htmldocs) produced
> this warning:
>
> Documentation/rust/coding.rst:24: WARNING: Unexpected indentation.
Ah, so docs are built in -next too? That is very nice. I'll fix
On Thu, Mar 18, 2021 at 7:03 AM Valdis Klētnieks
wrote:
>
> Or declare that gcc6 is the minimum for building the kernel.
Cc'ing some interested people in raising GCC's version for one reason
or another, so that we put this as another one in the pile of reasons
:-)
On Thu, Mar 18, 2021 at 5:37 AM Stephen Rothwell wrote:
>
> I fixed it up (see below - I think I got this right ...) and can carry
> the fix as necessary. This is now fixed as far as linux-next is
> concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when
On Thu, Mar 11, 2021 at 11:34 AM Masahiro Yamada wrote:
>
> Hmm, that is a simple, clean idea.
> Then, we can simply read out the file
>
> $ cat scripts/min_versions/gcc
> 4.9.0
Exactly!
> I do not know how to handle
> per-arch versions in this case.
Perhaps we should just push for 5.1.0
.23.0
+1 to creating a central place for all minimum versions.
Acked-by: Miguel Ojeda
I wonder if you considered creating a folder with files like
`scripts/min_versions/gcc` containing the version string. That would
make it easier for reading from other languages or even impor
On Wed, Mar 10, 2021 at 6:51 PM Sebastian Andrzej Siewior
wrote:
>
> I assumed you are going to apply it but I don't see it in -next as of
> today. Is there anything I need to do?
Ah, since you said you were posting a patch, I kept this in the
waiting list. I will apply the latest one then.
t; Fixes: aec6c60a01d3 ("kbuild: check the minimum compiler version in Kconfig")
> Signed-off-by: Masahiro Yamada
Acked-by: Miguel Ojeda
Cheers,
Miguel
On Fri, Mar 5, 2021 at 10:25 PM Linus Torvalds
wrote:
>
> And regardless of even _those_ issues, you still should do all the
> other syntactic tokenization stuff (ie all the quoting, the the
> character handling: 'a' is a valid C token, but if you see the string
> "it's" outside of a comment,
On Thu, Mar 4, 2021 at 1:09 AM Konstantin Komarov
wrote:
>
> - use clang-format 11.0 instead of 10.0 to format code
Out of curiosity: was this due to some specific reason? i.e. have you
found it provides better output? (it is useful to know this to justify
later an increase of the minimum
ove the comment about sparse not being yet able to constant
> fold __builtin_bswap*() and remove the corresponding test of __CHECKER__.
>
> Signed-off-by: Luc Van Oostenryck
Acked-by: Miguel Ojeda
Cheers,
Miguel
On Thu, Feb 25, 2021 at 9:18 PM Nathan Chancellor wrote:
>
> Indeed. Any wins that we can get with compile time, we should take.
> Clang is being widely used in production systems now so I feel like with
> a trivial change plus user visible impact, it should be backported.
>
> Not to mention that
On Thu, Feb 25, 2021 at 9:14 PM Kees Cook wrote:
>
> It's a trivial change, so I think it's worth it?
It is simple, but it is not trivial since it may change codegen.
Acked-by: Miguel Ojeda
Cheers,
Miguel
On Tue, Feb 16, 2021 at 11:22 AM Preeti Nagar wrote:
>
> The changes introduce a new security feature, RunTime Integrity Check
> (RTIC), designed to protect Linux Kernel at runtime. The motivation
> behind these changes is:
> 1. The system protection offered by Security Enhancements(SE) for
>
On Tue, Feb 16, 2021 at 7:26 PM Sebastian Andrzej Siewior
wrote:
>
> That should be part of the commit message. You can always rewind to the
> commit message that introduce something and check if the commit message
> made sense or ignored a detail which made it wrong (or so).
No, it shouldn't.
On Tue, Feb 16, 2021 at 11:28 AM Sebastian Andrzej Siewior
wrote:
>
> Could we please avoid documenting the obvious? It is more or less common
> knowledge that the write callback (like any other) is preemptible user
> context (in which write occurs). The same is true for register/probe
>
Hi Sebastian,
On Sat, Feb 13, 2021 at 5:50 PM Sebastian Andrzej Siewior
wrote:
>
> charlcd_write() is invoked as a VFS->write() callback and as such it is
> always invoked from preemptible context and may sleep.
Can we put this sentence as a comment in the code, right before the
call to
Hi Linus,
A few bits for auxdisplay. Please pull.
Cheers,
Miguel
The following changes since commit 6ee1d745b7c9fd573fba142a2efdad76a9f1cb04:
Linux 5.11-rc5 (2021-01-24 16:47:14 -0800)
are available in the Git repository at:
https://github.com/ojeda/linux.git
Hi Sebastian,
On Tue, Feb 9, 2021 at 10:01 AM Sebastian Andrzej Siewior
wrote:
>
> If I post series with more than just one patch I have a cover letter
> including:
Yeah, it is a bit confusing when reading without the context (it is
hard to keep up with everything going on unless you work
On Mon, Feb 8, 2021 at 9:41 PM Sebastian Andrzej Siewior
wrote:
>
> It hurts to keep in_interrupt() because it is desired to have it removed
> from drivers. The problem is that pattern is often copied and people
> sometimes get it wrong. For instance, the code here invoked schedule()
> based on
On Mon, Feb 8, 2021 at 8:07 PM Sebastian Andrzej Siewior
wrote:
>
> Yes.
In what way?
> No. If you know the context, pass it along like this is done for
> kmalloc() for instance.
What do you mean?
> The long term plan is not make it available to
> divers (i.e. core code only where the context
`in_interrupt()' and use `cond_resched()' to schedule every 32
> iteration if needed.
>
> Cc: Miguel Ojeda Sandonis
> Signed-off-by: Sebastian Andrzej Siewior
Cc'ing Geert and Willy too.
Thanks for the patch!
Cheers,
Miguel
Signed-off-by: Miguel Ojeda
---
.mailmap| 1 +
CREDITS | 9 +++--
Documentation/admin-guide/auxdisplay/cfag12864b.rst | 2 +-
Documentation/admin-guide/auxdisplay/ks0108.rst | 2 +-
MAINTAINERS
-format update
Miguel Ojeda (1):
clang-format: Update with the latest for_each macro list
.clang-format | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
On Mon, Feb 1, 2021 at 5:15 AM Masahiro Yamada wrote:
>
> Use early_param() to define early_param_on_off().
Reviewed-by: Miguel Ojeda
Cheers,
Miguel
On Tue, Jan 26, 2021 at 10:27 PM Nathan Chancellor wrote:
>
> Use my @kernel.org for all points of contact so that I am always
> accessible.
>
> Signed-off-by: Nathan Chancellor
Acked-by: Miguel Ojeda
Cheers,
Miguel
On Mon, Jan 18, 2021 at 1:35 PM Geert Uytterhoeven wrote:
>
> Convert the Holtek HT16K33 LED controller with keyscan Device Tree
> binding documentation to json-schema.
Applied to -next, thanks!
Cheers,
Miguel
On Fri, Jan 22, 2021 at 5:01 PM Geert Uytterhoeven wrote:
>
> A second CHARLCD config symbol was added instead of moving the existing
> one. Fix this by removing the old one.
Applied to -next, thanks!
Cheers,
Miguel
On Fri, Jan 22, 2021 at 4:39 PM Geert Uytterhoeven wrote:
>
> Drop the call to msecs_to_jiffies(), as "HZ / fbdev->refresh_rate" is
> already the number of jiffies to wait.
Applied to -next, thanks!
Cheers,
Miguel
On Mon, Jan 18, 2021 at 1:35 PM Geert Uytterhoeven wrote:
>
> V4 changed the range from 0..15 to 1..16 in the driver, to match the
> dimming set hardware register, but forgot to update the DT binding
> documentation.
Applied to -next, thanks!
Cheers,
Miguel
On Mon, Jan 18, 2021 at 1:35 PM Geert Uytterhoeven wrote:
>
> From: Robin van der Gracht
>
> Keyscan should be optional to support simple LED matrix displays (output
> only).
Applied to -next, thanks!
Cheers,
Miguel
On Mon, Jan 18, 2021 at 2:36 PM robin wrote:
>
> Thanks for digging this up. Not sure why this was dropped. I still think
> it's usefull.
Not intentional -- probably slipped, sorry.
Cheers,
Miguel
On Fri, Jan 15, 2021 at 11:55 PM Masahiro Yamada wrote:
>
> Yes, I plan to merge scripts/ld-version.sh and scripts/lld-version.sh
> in a similar way, and move the version check as well
> once the following cleanups land in the upstream:
>
>
GCC version: 4.9.0
***
Reviewed-by: Miguel Ojeda
Tested-by: Miguel Ojeda
Cheers,
Miguel
On Thu, Jan 14, 2021 at 5:25 AM Masahiro Yamada wrote:
>
> The cc-version.sh also shows the error if the compiler is old:
>
> $ make defconfig CC=clang-9
> *** Default configuration is based on 'x86_64_defconfig'
> ***
> *** Compiler is too old.
> *** Your Clang version:9.0.1
>
On Thu, Jan 14, 2021 at 3:23 AM Nathan Chancellor
wrote:
>
> A clean "make -skj24 htmldocs" takes me a little over three minutes or
> so on my Ryzen 9 3900X. Just to give some perspective.
Oh, wow, that's something...
Thanks a lot for adding this:
Reviewed-by: Miguel Ojeda
Cheers,
Miguel
On Fri, Jan 8, 2021 at 10:52 AM Preeti Nagar wrote:
>
> We want to seek your suggestions and comments on the idea and the changes
> in the patch.
Cc'ing Nick manually since his email domain was (again :-) incorrect.
Cheers,
Miguel
On Fri, Jan 8, 2021 at 10:52 AM Preeti Nagar wrote:
>
> We want to seek your suggestions and comments on the idea and the changes
> in the patch.
Not sure why I was Cc'd, but I have a quick comment nevertheless.
> +#ifdef CONFIG_SECURITY_RTIC
> +struct selinux_state selinux_state __rticdata;
>
erhoeven above your signature.
Rob, if you are taking this on your tree:
Acked-by: Miguel Ojeda
Otherwise, I will pick it up.
Cheers,
Miguel
On Wed, Jan 6, 2021 at 1:12 PM Miguel Ojeda
wrote:
>
> - Normally, you will want to use scripts/get_maintainer.pl to know
> to whom send a given change. In this case, I am Cc'ing Rob, Geert and
> the devicetree mailing list which were missing.
(Actually Cc'ing Rob.)
Cheers,
Miguel
ng out how this is done.
> Thanks to Miguel Ojeda for extensively commenting on my previous patch.
You're welcome!
A couple tips:
- Normally, you will want to use scripts/get_maintainer.pl to know
to whom send a given change. In this case, I am Cc'ing Rob, Geert and
the devicetree mailing list whic
1 - 100 of 1032 matches
Mail list logo
