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 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 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 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
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 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
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
> Signed-off-by
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
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
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 Wed, Apr 12, 2023 at 8:32 PM wrote:
>
> include/linux/compiler_attributes.h | 12
Acked-by: Miguel Ojeda
Cheers,
Miguel
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,
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 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
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
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
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
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
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
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
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
read 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 size
Gary Guo (2):
rust: add `build_error` crate
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
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
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
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
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
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
Gow
Signed-off-by: Miguel Ojeda
---
.gitignore | 5 +
.rustfmt.toml| 12 +
Makefile | 175 +++-
arch/Kconfig | 6 +
arch/arm/Kconfig
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 `
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
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
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
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):
kallsyms: support &quo
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
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
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
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
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
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
revious 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 leng
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
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
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
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 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,
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,
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
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 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
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 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
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 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'
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 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 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
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
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/236
> Signed-off-by: Nick Desaulniers
Looks fine on visual inspection:
Reviewed-by: Miguel Ojeda
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
On Mon, Nov 16, 2020 at 7:26 AM Gustavo A. R. Silva
wrote:
>
> Reviewed-by: Gustavo A. R. Silva
.org :-)
Cheers,
Miguel
f 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
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
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 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 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 Sun, Aug 2, 2020 at 6:41 PM Mike Rapoport wrote:
>
> .clang-format | 3 ++-
The .clang-format bit:
Acked-by: Miguel Ojeda
Cheers,
Miguel
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 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! :-)
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 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 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
74 matches
Mail list logo
