thanks.
Missed this one from August, thanks Nick for this cleanup!
Michael, you already picked it up, but you may have my:
Acked-by: Miguel Ojeda
Cheers,
Miguel
On Fri, Oct 26, 2018 at 7:27 PM Colin King wrote:
>
> From: Colin Ian King
>
> Trivial fix to a spelling mistake of the error access name EACCESS,
> rename to EACCES
? It is not a typo, it is the name of the error (POSIX). Same thing
for the rest of the patches.
Cheers,
Miguel
On Fri, Oct 26, 2018 at 8:40 PM Matthew Wilcox wrote:
>
> On Fri, Oct 26, 2018 at 08:20:12PM +0200, Miguel Ojeda wrote:
> > On Fri, Oct 26, 2018 at 7:27 PM Colin King wrote:
> > >
> > > From: Colin Ian King
> > >
> > > Trivial fix to a s
On Fri, Oct 26, 2018 at 8:53 PM Miguel Ojeda
wrote:
>
> On Fri, Oct 26, 2018 at 8:40 PM Matthew Wilcox wrote:
> >
> > On Fri, Oct 26, 2018 at 08:20:12PM +0200, Miguel Ojeda wrote:
> > > On Fri, Oct 26, 2018 at 7:27 PM Colin King
> > > wrote:
On Mon, Jul 10, 2023 at 3:01 PM Thomas Zimmermann wrote:
>
> The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
> fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do
> not set it.
`framebuffer_alloc()` does indeed use `kzalloc()`, but the docs do not
mention the zero
On Mon, Jul 10, 2023 at 5:22 PM Thomas Zimmermann wrote:
>
> I'll append a patch to the series that documents this.
>
> Sure.
Thanks!
If you are planning to take it into some other tree:
Acked-by: Miguel Ojeda
Otherwise, I can take it into the `auxdisplay` tree.
Cheers,
Miguel
On Tue, Jul 11, 2023 at 8:10 AM Thomas Zimmermann wrote:
>
> I'd like to take the patchset into drm-misc. It's part of a larger
> cleanup of the fbdev modules and its interfaces.
Sounds good, thanks!
Cheers,
Miguel
On Thu, Jul 13, 2023 at 3:03 PM Thomas Zimmermann wrote:
>
> Most fbdev drivers depend on framebuffer_alloc() to initialize the
> allocated memory to 0. Document this guarantee.
>
> Suggested-by: Miguel Ojeda
> Signed-off-by: Thomas Zimmermann
> Cc: Helge Deller
Thanks fo
On Wed, Apr 12, 2023 at 8:32 PM wrote:
>
> include/linux/compiler_attributes.h | 12
Acked-by: Miguel Ojeda
Cheers,
Miguel
On Mon, May 29, 2023 at 7:44 AM Maninder Singh wrote:
>
> kallsyms_lookup which in turn calls for kallsyms_lookup_buildid()
> writes on index "KSYM_NAME_LEN - 1".
>
> Thus array size should be KSYM_NAME_LEN.
>
> for powerpc and hexagon it was defined as "128" directly.
> and commit '61968dbc2d5d'
On Mon, May 29, 2023 at 1:08 PM Maninder Singh wrote:
>
> I Will add co-developed-by` tag.
> because this change was identified while we were working on kallsyms some
> time back.
> https://lore.kernel.org/lkml/yontol4zc4cyt...@infradead.org/t/
>
> this patch set is pending and we will start work
On Mon, May 29, 2023 at 1:14 PM Maninder Singh wrote:
>
> +static char tmpstr[KSYM_NAME_LEN];
Reviewed-by: Miguel Ojeda
Side-note: in `get_function_bounds()`, I see `kallsyms_lookup()` being
used, but the name seems discarded? Can
`kallsyms_lookup_size_offset()` be used instead, thus av
ctly.
> and commit '61968dbc2d5d' changed define value to 512,
> So both were missed to update with new size.
>
> Fixes: 61968dbc2d5d ("kallsyms: increase maximum kernel symbol length to 512")
>
> Co-developed-by: Onkarnath
> Signed-off-by: Onkarnath
> Sig
On Thu, Jun 1, 2023 at 4:02 AM Michael Ellerman wrote:
>
> > Side-note: in `get_function_bounds()`, I see `kallsyms_lookup()` being
> > used, but the name seems discarded? Can
> > `kallsyms_lookup_size_offset()` be used instead, thus avoiding the
> > usage of the buffer there to begin with?
>
> A
On Wed, May 31, 2023 at 1:14 AM Kees Cook wrote:
>
> On Mon, May 29, 2023 at 04:50:45PM +0200, Miguel Ojeda wrote:
> > Kees: what is the current stance on `[static N]` parameters? Something like:
> >
> > const char *kallsyms_l
On Wed, Aug 17, 2022 at 6:11 PM Björn Roy Baron
wrote:
>
> There is already a prototype of such a driver. It can be found at
> https://github.com/Rust-GCC/cargo-gccrs. Unlike what the name suggests it is
> not cargo specific. It consists of two binaries. The first calls cargo, but
> tells it to
On Wed, Aug 17, 2022 at 5:51 PM Arnd Bergmann wrote:
>
> Thanks for the explanation. My hope was that building the kernel
Don't mention it!
> would actually be easier here than building the more complicated
> rust user space.
Yeah, the kernel is complicated for them in different ways, so I
assu
On Wed, Jan 18, 2023 at 8:02 AM Masahiro Yamada wrote:
>
> - *.mod.c is kept human readable.
On the topic of `.mod.c` readability: for approaches that may be less
readable, we could improve that by adding some extra comments or
rearrange things in a different way (it is a generated file, afte
Hi Joe,
On Thu, Oct 1, 2020 at 12:56 AM Joe Perches wrote:
>
> So I installed the powerpc cross compiler, and
> nope, that doesn't work, it makes a mess.
Thanks a lot for reviving the script and sending the treewide cleanup!
> So it looks like the best option is to exclude these
> 2 files from
On Thu, Oct 22, 2020 at 4:36 AM Joe Perches wrote:
>
> Use a more generic form for __section that requires quotes to avoid
> complications with clang and gcc differences.
I performed visual inspection (one by one...) and the only thing I saw
is that sometimes the `__attribute__` has a whitespace
1. The amount of changes is
reasonable too, so no need to apply the script directly. In any case,
if you prefer that Linus picks it up himself right away for this -rc1,
it looks good to me (with the caveat that it isn't tested):
Reviewed-by: Miguel Ojeda
Cheers,
Miguel
is always nice); and then he sent yesterday
v2 [1] (to mention the functional change with `BL_CORE_SUSPENDED`
[2]).
Anyway, if it goes via drm-misc, feel free to have my:
Acked-by: Miguel Ojeda
Though it would be nice to have Robin test the change.
Thanks!
[1] https://lore.kernel
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 to
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 gi
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
he previous cover letters.
Boqun Feng (1):
kallsyms: use the correct buffer size for symbols
Gary Guo (2):
rust: add `build_error` crate
vsprintf: add new `%pA` format specifier
Miguel Ojeda (13):
kallsyms: support "big" kernel symbols
kallsyms: increase maximum kernel symbol
Co-developed-by: Dariusz Sosnowski
Signed-off-by: Dariusz Sosnowski
Co-developed-by: Antonio Terceiro
Signed-off-by: Antonio Terceiro
Co-developed-by: Daniel Xu
Signed-off-by: Daniel Xu
Co-developed-by: Miguel Cano
Signed-off-by: Miguel Cano
Signed-off-by: Miguel Ojeda
---
.gitignore
Hi PPC/RCU,
While merging v5.18-rc1 changes I noticed our CI PPC runs broke. I
reproduced the problem in v5.18-rc1 as well as next-20220405, under
both QEMU 4.2.1 and 6.1.0, with `-smp 2`; but I cannot reproduce it in
v5.17 from a few tries.
Sadly, the problem is not deterministic although it is
On Thu, Apr 7, 2022 at 4:27 AM Zhouyi Zhou wrote:
>
> Yes, this happens within 30 seconds after kernel boot. If we take all
> into account (qemu preparing, kernel loading), we can do one test
> within 54 seconds.
When it does not trigger, the run should be 20 seconds quicker than
that (e.g. 10 s
On Thu, Apr 7, 2022 at 5:15 PM Paul E. McKenney wrote:
>
> Ah. So you would instead look for boot to have completed within 10
> seconds? Either way, reliable automation might well more important than
> reduction in time.
No (although I guess that could be an option), I was only pointing out
tha
On Fri, Apr 8, 2022 at 9:23 AM Michael Ellerman wrote:
>
> I haven't seen it in my testing. But using Miguel's config I can
> reproduce it seemingly on every boot.
Hmm... I noticed this for some kernel builds: in some builds/commits,
it triggered the very first time, while in others I had to re-t
On Fri, Apr 8, 2022 at 4:42 PM Michael Ellerman wrote:
>
> The Rust CI has it disabled because I copied that from the x86 defconfig
> they were using back when I added the Rust support. I think that was
> meant to be a stripped down fast config for CI, but the result is it's
Indeed, that was my i
word, joined discussions and contributed in
other ways!
Please see also the acknowledgements on the previous cover letters.
Boqun Feng (1):
kallsyms: avoid hardcoding the buffer size
Gary Guo (2):
rust: add `build_error` crate
vsprintf: add new `%pA` format specifier
Miguel Ojeda (16):
k
Co-developed-by: Dariusz Sosnowski
Signed-off-by: Dariusz Sosnowski
Co-developed-by: Antonio Terceiro
Signed-off-by: Antonio Terceiro
Co-developed-by: Daniel Xu
Signed-off-by: Daniel Xu
Co-developed-by: Miguel Cano
Signed-off-by: Miguel Cano
Signed-off-by: Miguel Ojeda
---
.gitignore
Hi David,
On Sat, May 7, 2022 at 11:29 AM David Gow wrote:
>
> It's great to see some KUnit support here!
Thanks!
> It's also possible to run these tests using the KUnit wrapper tool with:
> $ ./tools/testing/kunit/kunit.py run --kconfig_add CONFIG_RUST=y
> --make_options LLVM=1 --arch x86_64 '
Hi David,
On Tue, May 10, 2022 at 6:45 AM David Gow wrote:
>
> I've just sent out a pull request to get this working under UML as
> well, which would simplify running these further:
> https://github.com/Rust-for-Linux/linux/pull/766
Thanks a lot!
> Yeah, these are all fair points: particularly
On Sat, May 1, 2021 at 5:17 PM Masahiro Yamada wrote:
>
> More cleanups will be possible as follow-up patches, but this one must
> be agreed and applied to the mainline first.
+1 This will allow me to remove the __has_attribute hack in
include/linux/compiler_attributes.h.
Reviewed-b
On Mon, May 3, 2021 at 2:20 PM David Laight wrote:
>
> It would be nice to be able to build current kernels (for local
> use) on the 'new' system - but gcc is already too old.
I have seen such environments too... However, for the kernel in
particular, you could install a newer GCC in the 'new' ma
On Tue, May 4, 2021 at 9:57 AM Ben Dooks wrote:
>
> Some of us are a bit stuck as either customer refuses to upgrade
> their build infrastructure or has paid for some old but safety
> blessed version of gcc. These often lag years behind the recent
> gcc releases :(
In those scenarios, why do you
On Tue, May 4, 2021 at 11:22 AM Michal Suchánek wrote:
>
> Except it makes answering the question "Is this bug we see on this
> ancient system still present in upstream?" needlessly more difficult to
> answer.
Can you please provide some details? If you are talking about testing
a new kernel imag
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 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
On Wed, Oct 27, 2021 at 3:28 PM Arnd Bergmann wrote:
>
> Rather than having CONFIG_FB_BACKLIGHT select CONFIG_BACKLIGHT_CLASS_DEVICE,
> make any driver that needs it have a dependency on the class device
> being available, to prevent circular dependencies.
Acked-by: Miguel Ojeda
Cheers,
Miguel
On Mon, Nov 16, 2020 at 7:26 AM Gustavo A. R. Silva
wrote:
>
> Reviewed-by: Gustavo A. R. Silva
.org :-)
Cheers,
Miguel
asive.
I would add a comment noting this as a reminder -- it also helps to
entice a cleanup.
Acked-by: Miguel Ojeda
Cheers,
Miguel
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/236
> Signed-off-by: Nick Desaulniers
Looks fine on visual inspection:
Reviewed-by: Miguel Ojeda
Cheers,
Miguel
cases.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/236
> Signed-off-by: Nick Desaulniers
It makes things clearer having a `break` added, so I like that warning.
Reviewed-by: Miguel Ojeda
Cheers,
Miguel
On Wed, Nov 18, 2020 at 1:08 AM Nick Desaulniers
wrote:
>
> It was also noted in 6a9dc5fd6170 that we could -D__KERNEL__ and
> -include compiler_types.h like the main kernel does, though testing that
> produces a whole sea of warnings to cleanup.
(Re; for Gustavo to consider since he took it now)
On Sat, May 25, 2019 at 1:50 AM Joel Fernandes (Google)
wrote:
>
> The series removes all users of the API and with this patch, the API
> itself.
>
> Signed-off-by: Joel Fernandes (Google)
> ---
> .clang-format | 1 -
Ack for clang-format, and thanks for removing it there too! :-)
Ch
Hi PPC folks,
Our ppc64le CI deterministically triggers a hard lockup / hang under
QEMU since v5.17-rc1 (upgrading from v5.16).
Bisecting points to 0faf20a1ad16 ("powerpc/64s/interrupt: Don't enable
MSR[EE] in irq handlers unless perf is in use").
Cheers,
Miguel
[ 16.328310] watchdog: CPU 1 d
On Wed, Jan 26, 2022 at 4:03 PM Cédric Le Goater wrote:
>
> Indeed. I could reproduce.
Thanks for the quick confirmation!
> Could you please send the QEMU command line and the full dmesg ? and
> possibly open an issue on :
>
>https://gitlab.com/qemu-project/qemu/-/issues/
>
> I guess it's a
Hi Michael,
On Thu, Jan 27, 2022 at 11:54 AM Michael Ellerman wrote:
>
> It looks like your kernel-ppc64le-release.config does not have the
> hardlockup detector enabled, so I suspect you're hitting the bug
> described in that patch.
On -release it was a hang; but please note that on -debug the
Hi Nicholas,
On Thu, Jan 27, 2022 at 8:47 AM Nicholas Piggin wrote:
>
> That sounds like my fault actually.
>
> https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-January/239178.html
Thanks for the reference & fix! I confirm it works in our CI too.
Closing the QEMU issue then.
Cheers,
Miguel
Hi Russell,
On Sat, Feb 12, 2022 at 3:17 PM Russell King (Oracle)
wrote:
>
> Please don't use CPU_32v6* here.
>
> It probably makes more sense to add a symbol "HAVE_RUST" and have the
> appropriate architecture Kconfig files select HAVE_RUST.
We can do it whatever way arch maintainers prefer, of
On Sat, Feb 12, 2022 at 5:19 PM Russell King (Oracle)
wrote:
>
> Right, so why made it dependent on CPU_32v6 || CPU_32v6K if ARMv7 is
> supported? What about CPU_32v7? What about CPU_32v7M?
>
> I think it would be saner to use the CPU_V6, CPU_V6K, CPU_V7 and maybe
> CPU_V7M here - even bettern to
Hi John Paul,
On Sat, Feb 12, 2022 at 7:27 PM John Paul Adrian Glaubitz
wrote:
>
> Is there any particular reason why this list excludes MIPS*, i386, big-endian
> PowerPC and SPARC targets which are already supported by the Rust programming
> language?
The variations we have so far were intended
ect buffer size for symbols
Gary Guo (2):
rust: add `build_error` crate
vsprintf: add new `%pA` format specifier
Miguel Ojeda (13):
kallsyms: support "big" kernel symbols
kallsyms: increase maximum kernel symbol length to 512
rust: add C helpers
rust: add `compiler_builtin
Signed-off-by: Miguel Cano
Signed-off-by: Miguel Ojeda
---
.gitignore | 5 +
.rustfmt.toml| 12 +
Makefile | 154 +++-
arch/arm/rust/target.json| 27 ++
arch/arm64/rust
On Wed, Aug 14, 2024 at 12:10 PM Madhavan Srinivasan
wrote:
>
> Reported-by: Miguel Ojeda
> Signed-off-by: Madhavan Srinivasan
> Link - https://lore.kernel.org/linuxppc-dev/87ilc8ym6v.fsf@mail.lhotse/
Thanks for fixing this!
The "Link -" should be a tag, i.e. "Link:
vsprintf: add new `%pA` format specifier
Miguel Ojeda (18):
kallsyms: support "big" kernel symbols
kallsyms: increase maximum kernel symbol length to 512
kunit: take `kunit_assert` as `const`
rust: add C helpers
rust: add `compiler_builtins` crate
rust: import upstream `alloc`
Gow
Signed-off-by: Miguel Ojeda
---
.gitignore | 5 +
.rustfmt.toml| 12 +
Makefile | 175 +++-
arch/Kconfig | 6 +
arch/arm/Kconfig
On Mon, May 23, 2022 at 8:45 PM Nick Desaulniers
wrote:
>
> I'm super not into having the rust optimization level differ from the
> C optimization level. This is just someone having too much fun
> wrapping every compiler flag in a kbuild option. Either folks wan't
I mean, `Makefile`s are not my
On Thu, May 26, 2022 at 12:25 AM Nick Desaulniers
wrote:
>
> Is there a reason to not just turn clippy on always? Might be nicer to
> start off with good practices by default. :^)
The idea crossed my mind too [1], but sadly Clippy disables some
optimizations and in general is not intended to be u
ow7pu?= , Saranya Gopal
, Lars-Peter Clausen , Corey Minyard
, Evgeny Novikov , Frank Rowand , Bartosz Golaszewski ,
Manivannan Sadhasivam , Pierre-Louis Bossart
, Minghao Chi ,
linux-...@vger.kernel.org, Nathan Chancellor , MyungJoo Ham
, Charles Gorand , Jagan
Teki , Vijendar Mukunda ,
Migue
Hi Masahiro,
On Sat, Jul 16, 2022 at 10:23 AM Masahiro Yamada wrote:
>
> Is it intentional to print the successful message to stderr?
I think it makes sense to change it to `stdout`, given the message is
the main point of running `rustavailable` for normal users, and those
that just want the sta
Hi Conor,
On Sat, Jul 16, 2022 at 2:42 PM Conor Dooley wrote:
>
> Maybe I am just missing something blatantly obvious here, but trying
> to build rust support in -next fails for me. I am using ClangBuiltLinux
> clang version 15.0.0 5b0788fef86ed7008a11f6ee19b9d86d42b6fcfa and LLD
> 15.0.0. Is it
On Sat, Jul 16, 2022 at 3:51 PM wrote:
>
> Ah right, sorry for the noise so. I checked the ml but didn't see a
> report there.
No apologies needed -- thanks to you for the report, instead! :)
> Thanks Miguel, good to know! I'll just wait around for a new version.
> Just been trying to get my CI
rted issues, tested the project,
helped spread the word, joined discussions and contributed in
other ways!
Please see also the acknowledgements on the previous cover letters.
Boqun Feng (2):
kallsyms: use `sizeof` instead of hardcoded size
kallsyms: avoid hardcoding buffer siz
Gow
Co-developed-by: Tiago Lam
Signed-off-by: Tiago Lam
Co-developed-by: Björn Roy Baron
Signed-off-by: Björn Roy Baron
Co-developed-by: Martin Rodriguez Reboredo
Signed-off-by: Martin Rodriguez Reboredo
Signed-off-by: Miguel Ojeda
---
.gitignore | 6
Hi Willy,
On Tue, Aug 2, 2022 at 2:26 PM Matthew Wilcox wrote:
>
> None of this (afaict) has been discussed on linux-fsdevel. And I may
> have missed somethiing, but I don't see the fs module in this series
> of patches. Could linux-fsdevel be cc'd on the development of Rust
> support for files
On Tue, Aug 2, 2022 at 3:48 PM Christoph Hellwig wrote:
>
> handwaiving and pointing to git trees is not how Linux development
> works. Please make sure all the patches go to the relevant lists
> and maintainers first, and actually do have ACKs.
Which hand-waving? In fact, we were requested to d
On Tue, Aug 2, 2022 at 4:01 PM Matthew Wilcox wrote:
>
> No objections to any of this. I love the idea of being able to write
> filesystems in Rust. I just think it would go more smoothly if
> linux-fsdevel were involved more closely so people at least have the
> option of being able to follow d
On Tue, Aug 2, 2022 at 5:09 PM Miguel Ojeda
wrote:
>
> Yeah, patch 17, exactly (patch 11 is the `alloc` import). I have asked
> Konstantin privately about them.
The patches are showing up now in lore -- not sure if it was just a
delay (which would be consistent with the lack of b
Hi Arnd,
On Wed, Aug 17, 2022 at 4:40 PM Arnd Bergmann wrote:
>
> Hi Miguel,
>
> I tried enabling rust support in the gcc builds I provide at
> https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/arm64/12.1.0/
Thanks for giving it a go!
> to make this more accessible, but it appears t
75 matches
Mail list logo
