On Sat, Sep 20, 2025 at 2:39 AM Joel Fernandes wrote:
>
> The C checks use BUILD_BUG_ON, in rust-for-linux we have build_assert but it
> is fragile and depends on the value being a constant.
What do you mean?
`build_assert!` works essentially like `BUILD_BUG_ON`, i.e. after the
optimizer, and do
On Sun, Sep 21, 2025 at 11:36 AM Greg KH wrote:
>
> And where does this allow us to define things like BIT(2) for values?
> (ok, that's kind of not the point of this patch series, but it will come
> up over time...)
We have the `bits` module since 6.17:
https://rust.docs.kernel.org/kernel/bi
On Mon, Sep 8, 2025 at 7:06 PM Joel Fernandes wrote:
>
> The issue I ran into is, without adding it to prelude, the users of register!
> macro will have to import both bitfield! and register! macros explictly, even
> though they're only using register!. I tried to make it work without adding to
>
On Wed, Aug 13, 2025 at 5:42 PM Tamir Duberstein wrote:
>
> This is series 2b/5 of the migration to `core::ffi::CStr`[0].
> 20250704-core-cstr-prepare-v1-0-a91524037...@gmail.com.
>
> This series depends on the prior series[0] and is intended to go through
> the rust tree to reduce the number of r
On Wed, Aug 13, 2025 at 5:39 PM Tamir Duberstein wrote:
>
> This is series 2a/5 of the migration to `core::ffi::CStr`[0].
> 20250704-core-cstr-prepare-v1-0-a91524037...@gmail.com.
>
> This series depends on the prior series[0] and is intended to go through
> the rust tree to reduce the number of r
On Sat, Sep 13, 2025 at 7:14 PM Joel Fernandes wrote:
>
> I am not alone in that opinion.
Hmm... I am not sure how to read this.
> This should be first-class in a (systems) language, built into
> the language itself?
I would suggest taking a look at our website and the links there (like
issue #
On Wed, Sep 10, 2025 at 7:45 AM Alexandre Courbot wrote:
>
> That would be nice, but also wouldn't cover all the cases where implicit
> panics can happen, like out-of-bounds slice accesses - we can't have a
> "report-and-continue" mode for these.
In principle, it could cover OOBs (even if it is a
On Wed, Sep 10, 2025 at 3:55 PM Alexandre Courbot wrote:
>
> The only two options are either allowing user-space to crash the kernel
> through a module with a missing bound check, or letting it tamper with
So we are definitely not aiming to allow that on purpose, i.e. I know
you said "missing", b
On Tue, Sep 9, 2025 at 11:21 PM Joel Fernandes wrote:
>
> Out of broad need for these macros in Rust, move them out. Several folks
> have shown interest (Nova, Tyr GPU drivers).
Please Cc the rust-for-Linux mailing list, especially so for patches
that add things to the core infrastructure.
I not
On Wed, Jul 30, 2025 at 3:07 PM Miguel Ojeda wrote:
>
> This fixes a handful of broken links and introduces a warning to
> prevent them from happening in the future.
Applied to `rust-next` -- thanks everyone!
I added Cc: sta...@vger.kernel.org on the fixes.
Andreas/Boqun: if you don&#
Hi Joel,
I didn't check the macros, but a couple nits I noticed in this patch
in particular given it moved it to `kernel`...
On Wed, Sep 3, 2025 at 11:54 PM Joel Fernandes wrote:
>
> +//! A library that provides support for defining bit fields in Rust
What about just "Support for defining bit f
On Fri, Aug 29, 2025 at 9:40 AM Danilo Krummrich wrote:
>
> I'm happy about every potential additional reviewer for Nova, but I'm not sure
> it scales very well for the rust-for-linux if we get more drivers. :)
Yeah, it is an informal rule I/we added back then so that people
interested in Rust in
On Thu, Aug 28, 2025 at 9:31 PM Miguel Ojeda
wrote:
>
> and a `DmaAddress`
> newtype, not just a typedef, could perhaps be nice anyway?
The one from your linked patch is not a newtype though, so I guess
there is a reason for that.
Cheers,
Miguel
On Thu, Aug 28, 2025 at 9:24 PM Danilo Krummrich wrote:
>
> Maybe I spoke too soon, it's actually pretty painful to keep 32-bit
> compatibility, even though it would be nice for testing purposes.
>
> I'll paste the diff to fix it below, I think that makes it obvious why I say
> that.
>
> Instead,
Hi Danilo et al.,
In Linus' tree and -next, for an arm32 LLVM defconfig plus Rust build, I see:
error[E0308]: mismatched types
--> drivers/gpu/nova-core/fb.rs:49:59
|
49 | hal::fb_hal(chipset).write_sysmem_flush_page(bar,
page.dma_handle())?;
|
On Thu, Aug 28, 2025 at 1:26 PM Alexandre Courbot wrote:
>
> We got 3 Reviewed-by on this patch - Miguel, are you ok if I merge it
> together with Christian's `from_bytes` patch, since they are closely
> related?
If you are taking this series this cycle, then sure!
Acked
On Wed, Aug 27, 2025 at 10:47 AM Alexandre Courbot wrote:
>
> However, `fw_start + fw_size` can panic in debug configuration if it
> overflows. In a release build I believe it will just happily wrap, and
In the kernel, it is a panic in the default configuration, not just a debug one.
We have deb
On Wed, 27 Aug 2025 18:19:57 +1000 Alistair Popple wrote:
>
> This series builds on top of Alex's series[1] to continue initialising the GSP
> into a state where it becomes active and it starts communicating with the
> host.
No big deal, but in case it helps since probably it was not intentional
On Mon, Aug 18, 2025 at 7:04 AM Rahul Rameshbabu
wrote:
>
> I did toss in two doc comment cleanup patches in the mix. If these need to
> be re-sent individually or split due to the multiple Fixes: tags, do not
> hesitate to let me know.
Thanks!
Normally, if they are independent, like in this cas
On Mon, Aug 18, 2025 at 7:04 AM Rahul Rameshbabu
wrote:
>
> The Rust DRM abstractions would incorrectly reference headers using the
> non-existent path include/linux/drm. Correct the path to include/drm.
>
> Signed-off-by: Rahul Rameshbabu
> Fixes: 9a69570682b1 ("rust: drm: ioctl: Add DRM ioctl a
attaching it for reference in case the now-stable feature is
needed, e.g. if you want to make that `const fn` again.
Cheers,
Miguel
From 3cf24f05614e33493ba086bab1f02f701c894807 Mon Sep 17 00:00:00 2001
From: Miguel Ojeda
Date: Sat, 16 Aug 2025 22:20:29 +0200
Subject: [NOT PATCH] rust: kerne
em `aligned_layout` not
found for this struct
Thus add an equivalent one for `Cmalloc`.
Fixes: fde578c86281 ("rust: alloc: replace aligned_size() with
Kmalloc::aligned_layout()")
Signed-off-by: Miguel Ojeda
---
Danilo, as usual, please feel free to rebase if that is better.
Here I ju
On Thu, Aug 14, 2025 at 10:24 AM Alice Ryhl wrote:
>
> Tamir mentioned to me that he ran into a daily limit on the number of
> emails he could send.
He is posting the updates around the migration in Zulip:
https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/CStr.20migr
On Tue, Aug 12, 2025 at 10:00 PM Danilo Krummrich wrote:
>
> I don't think so, it just lead to pad to the alignment for Vmalloc too.
>
> Technically, this makes no difference, since Vmalloc is always PAGE_SIZE
> aligned
> and the size always a multiple of PAGE_SIZE.
Got it, thanks for the quick
On Thu, Jul 31, 2025 at 5:49 PM Danilo Krummrich wrote:
>
> aligned_size() dates back to when Rust did support kmalloc() only, but
> is now used in ReallocFunc::call() and hence for all allocators.
>
> However, the additional padding applied by aligned_size() is only
> required by the kmalloc() al
u time.
Thanks!
Cheers,
Miguel
From: Miguel Ojeda
Date: Thu, 31 Jul 2025 21:41:37 +0200
Subject: [PATCH] gpu: nova-core: fix up formatting after merge
In the merge 260f6f4fda93 ("Merge tag 'drm-next-2025-07-30' of
https://gitlab.freedesktop.org/drm/kernel";), the formatting i
to include/linux/drm/drm_file.h does not exist
warning: srctree/ link to include/linux/drm/drm_device.h does not exist
Inspired-by: "Onur Özkan"
Link:
https://lore.kernel.org/rust-for-linux/CANiq72=xcya7z7_rxpzzkkkhjs6m7l_xealmuarvn3zacye...@mail.gmail.com/
Signed-off-by: Mi
ect abstraction")
Fixes: 07c9016085f9 ("rust: drm: add driver abstractions")
Fixes: 1e4b8896c0f3 ("rust: drm: add device abstraction")
Fixes: 9a69570682b1 ("rust: drm: ioctl: Add DRM ioctl abstraction")
Signed-off-by: Miguel Ojeda
---
rust/kernel/drm/device.rs | 2
This `srctree/` link pointed to a file with an underscore, but the header
used a dash instead.
Thus fix it.
This cleans a future warning that will check our `srctree/` links.
Fixes: 3253aba3408a ("rust: block: introduce `kernel::block::mq` module")
Signed-off-by: Miguel Ojeda
---
r
these that avoids
repetition or a fancier preprocessing step.
Miguel Ojeda (3):
rust: block: fix `srctree/` links
rust: drm: fix `srctree/` links
rust: warn if `srctree/` links do not exist
rust/Makefile| 6 ++
rust/kernel/block/mq/gen_disk.rs | 2 +-
rust/kernel/drm
On Thu, Jul 24, 2025 at 7:05 PM Danilo Krummrich wrote:
>
> Thanks -- will take it through -fixes once rc-1 is out.
By the way, in that case we should probably:
Cc: sta...@vger.kernel.org
Cheers,
Miguel
On Thu, Jul 24, 2025 at 7:05 PM Danilo Krummrich wrote:
>
> I think I will follow up with a function to perform the conversion in a single
> place, but I really like the idea of a special clippy annotation to tell
> clippy
> to not warn about unnecessary into() conversions for a specific type ali
)` call to support the 32-bit case, while allowing the
Clippy lint that complains in the 64-bit case where the type is the same.
Fixes: cdeaeb9dd762 ("drm: nova-drm: add initial driver skeleton")
Signed-off-by: Miguel Ojeda
---
As discussed, it may be best to have a newtype, or at least a func
On Sun, Jul 20, 2025 at 12:42 AM Tamir Duberstein wrote:
>
> Reduce coupling to implementation details of the formatting machinery by
> avoiding direct use for `core`'s formatting traits and macros.
>
> Acked-by: Greg Kroah-Hartman
> Reviewed-by: Alice Ryhl
> Reviewed-by: Benno Lossin
> Acked-b
On Sun, Jul 20, 2025 at 12:42 AM Tamir Duberstein wrote:
>
> Reduce coupling to implementation details of the formatting machinery by
> avoiding direct use for `core`'s formatting traits and macros.
>
> Acked-by: Greg Kroah-Hartman
> Reviewed-by: Alice Ryhl
> Reviewed-by: Benno Lossin
> Acked-b
On Mon, Jul 21, 2025 at 10:31 PM Tamir Duberstein wrote:
>
> Yes, please do. I did indeed use b4 - and Alice also let me know that
> this was not correct. Sorry about that! Same is true for 2a, I'll
> reply to that email as well.
Sounds good, thanks for confirming!
> I believe it was for everyth
On Sun, Jul 20, 2025 at 12:42 AM Tamir Duberstein wrote:
>
> Subsystem maintainers: I would appreciate your `Acked-by`s so that this
> can be taken through Miguel's tree (where the other series must go).
Same here as in step 2b/5, i.e. Danilo's Acked-by was picked up for
things he didn't Acked-by
On Sun, Jul 20, 2025 at 12:42 AM Tamir Duberstein wrote:
>
> Subsystem maintainers: I would appreciate your `Acked-by`s so that this
> can be taken through Miguel's tree (where the other series must go).
Did you apply this with `b4`? I think you picked Danilo's Acked-by,
which was for a subset, f
On Mon, Jul 21, 2025 at 9:37 AM Viresh Kumar wrote:
>
> Acked-by: Viresh Kumar
Thanks Viresh -- I will add this one if I rebase, since Stephen
already solved a conflict with it (I should have pinged earlier I
guess, sorry; I thought you guys didn't Ack so far since it was
trivial, but thanks to
On Mon, Jul 21, 2025 at 1:04 AM Tamir Duberstein wrote:
>
> Just noticed a tiny typo here: it should say "can *be* taken".
>
> Miguel, if you can fix that on apply, please do - but if not, no worries.
Done! (We could also have removed that sentence too, since it sounds a
bit like something one wo
On Fri, Jul 4, 2025 at 10:16 PM Tamir Duberstein wrote:
>
> As this is a large migration that touches many subsystems, it will take
> place in several cycles, each of which may see multiple series:
Let's start the long road, then...
Applied to `rust-next` -- thanks everyone!
[ Reworded titl
On Fri, Jul 4, 2025 at 10:16 PM Tamir Duberstein wrote:
>
> drivers/cpufreq/rcpufreq_dt.rs| 3 +--
> drivers/gpu/nova-core/firmware.rs | 5 +++--
> rust/kernel/opp.rs| 2 +-
Danilo, Viresh: I assume you are OK with this, but let me know
otherwise, thanks!
Cheers,
Miguel
On Tue, Jun 24, 2025 at 5:28 PM Alice Ryhl wrote:
>
> -let cell_inner = ::core::cell::UnsafeCell::raw_get(self_ptr);
> +let cell_inner =
> ::core::cell::UnsafeCell::cast_into(self_ptr);
Bah, we also missed this one -- I will rebase / send a patch.
Cheers,
Miguel
On Tue, Jun 24, 2025 at 5:28 PM Alice Ryhl wrote:
>
> Since commit b20fbbc08a36 ("rust: check type of `$ptr` in
> `container_of!`") we have enforced that the field pointer passed to
> container_of! must match the declared field. This caused mismatches when
> using a pointer to bindings::x for fiel
On Mon, Jul 14, 2025 at 5:28 PM Tamir Duberstein wrote:
>
> Yep, that's what I was going to do - but do I resend the whole series,
> or somehow just this patch?
Whole series is simpler, I think.
Cheers,
Miguel
On Mon, Jul 14, 2025 at 2:35 PM Tamir Duberstein wrote:
>
> How should I respin this one? the subject should be drm/panic, I think.
I would mimic what the previous commits did, i.e. drm/panic indeed.
(If I happen to pick it up before a resend, I could fix it on my side)
Cheers,
Miguel
On Sun, Jul 6, 2025 at 3:46 PM Miguel Ojeda
wrote:
>
> Added the possibility of catching this automatically in e.g. `rustdoc` to:
>
> https://github.com/Rust-for-Linux/linux/issues/350
Filled: https://github.com/rust-lang/rust-clippy/issues/15245 so that
they have it upstr
On Wed, Jul 2, 2025 at 1:32 PM Alexandre Courbot wrote:
>
> +/// Security mode of the Falcon microprocessor.
> +/// See falcon.rst for more details.
Please add a newline between those -- the first paragraph is a title
("short description"). A few more instances below, too.
`falcon.rst`
> +/
On Wed, Jul 2, 2025 at 1:05 PM Alexandre Courbot wrote:
>
> +/// driver initialization, and before any falcon is reset.
> +//
> /// Users are responsible for manually calling [`Self::unregister`] before
> dropping this object,
Missing slash.
Added the possibility of catching this automatically
On Wed, Jul 2, 2025 at 1:04 PM Alexandre Courbot wrote:
>
> +// Check that FWSEC has lowered its protection level before reading
> the GFW_BOOT status.
`GFW_BOOT` (another one below), since it is written like that above.
> -/* PGC6 */
> +/*
> + * PGC6 register space.
> + *
> + * `GC6` i
On Fri, Jul 4, 2025 at 1:59 PM Tamir Duberstein wrote:
>
> That would probably work. We will probably see regressions because we
> can't just replace `core::fmt` imports with `kernel::fmt`, so new code
> may appear that uses the former.
That is fine -- it happens all the time with this sort of ap
On Fri, Jul 4, 2025 at 12:46 AM Tamir Duberstein wrote:
>
> There's also a tactical question about splitting by subsystem: are
> there any tools that would assist in doing this, or is it a matter of
> manually consulting MAINTAINERS to figure out file groupings?
As Andrew mentioned, you can use t
On Thu, Jul 3, 2025 at 11:28 PM Andrew Lunn wrote:
>
> A small patch tends to be more obviously correct than a big patch. The
> commit message is more focused and helpful because it refers to a
> small chunk of code. Because the commit message is more focused, it
> can answer questions reviewers m
On Thu, Jul 3, 2025 at 3:56 PM Tamir Duberstein wrote:
>
> Can you help me understand why? The changes you ask to be separated
> would all be in different files, so why would separate commits make it
> easier to review?
By the way, if we are talking about splitting, it is easier to land
patches t
On Tue, Jul 1, 2025 at 6:49 PM Tamir Duberstein wrote:
>
> This picks up from Michal Rostecki's work[0]. Per Michal's guidance I
> have omitted Co-authored tags, as the end result is quite different.
>
> Link:
> https://lore.kernel.org/rust-for-linux/20240819153656.28807-2-vadorov...@protonmail.c
On Mon, Jun 30, 2025 at 5:23 PM Daniel Almeida
wrote:
>
> When I said "in development"I was referring to "dead_code" specifically, as we
> will invariably have some of that until the other parts of the driver land.
>
> Just as an example: IMHO it doesn't make much sense to only introduce the
> reg
On Mon, Jun 30, 2025 at 3:52 PM Rob Herring wrote:
>
> No. Drivers rely on empty stubs for all the providers they need. It
> would be pretty unmaintainable to depend on all of them. You want
> enabling drivers for compile testing as easy as possible.
That is fine -- I was referring to the current
On Sat, Jun 28, 2025 at 3:06 PM Daniel Almeida
wrote:
>
> The branch I shared is drm-misc-next plus a few dependencies, i.e.: 10 commits
> total if I counted it correctly - all of which have been sent to the list
> already and most of which have seen a quite a few iterations. I should have
> expli
Hi Daniel,
Some procedural notes and general comments, and please note that some
may apply several times.
On Sat, Jun 28, 2025 at 12:35 AM Daniel Almeida
wrote:
>
> Signed-off-by: Rob Herring
>
> Signed-off-by: Daniel Almeida
No newline.
> [2]: https://gitlab.freedesktop.org/panfrost/linux/-
On Sat, Jun 28, 2025 at 2:13 AM Daniel Almeida
wrote:
>
> Also, for some reason the Clippy lint did not save me this time.
Hmm... it should -- I tried to build it and Clippy reports it. There
is also another warning too [1].
I see the compiler reporting [2] too.
By the way, do you need to depen
On Fri, Jun 27, 2025 at 11:41 AM Jocelyn Falempe wrote:
>
> +/// On arm32 architecture, dividing an u64 by a constant will generate a call
> +/// to __aeabi_uldivmod which is not present in the kernel.
> +/// So use the multiply by inverse method for this architecture.
This sounds more like a nor
On Fri, Jun 27, 2025 at 1:37 PM Alice Ryhl wrote:
>
> I would get rid of this conditional and declare another div10 function
> that just does input/10 on other arches.
Yeah, please keep `cfg`s as local as possible, i.e. inside the
implementation of the function where possible, so that we share ev
On Tue, Jun 24, 2025 at 12:13 AM Daniel Almeida
wrote:
>
> Signed-off-by: Asahi Lina
Patches from others also need to be signed off by you as carrier.
> Changes from v0:
I assume you mean the RFC patch from more than 2 years ago, i.e.
https://lore.kernel.org/rust-for-linux/20230307-rust-
On Mon, Jun 9, 2025 at 2:22 PM Guilherme Giacomo Simoes
wrote:
>
> Commit 38559da6afb2 ("rust: module: introduce `authors` key") introduced
> a new `authors` key to support multiple module authors, while keeping
> the old `author` key for backward compatibility.
>
> Now that all in-tree modules ha
On Thu, Jun 19, 2025 at 3:24 PM Alexandre Courbot wrote:
>
> We will use this error in the nova-core driver.
>
> Reviewed-by: Benno Lossin
> Signed-off-by: Alexandre Courbot
Acked-by: Miguel Ojeda
Cheers,
Miguel
On Thu, Jun 19, 2025 at 3:24 PM Alexandre Courbot wrote:
>
> nova-core will need to use SZ_1M, so make the remaining constants
> available.
>
> Reviewed-by: Boqun Feng
> Signed-off-by: Alexandre Courbot
Acked-by: Miguel Ojeda
Cheers,
Miguel
On Sun, Jun 15, 2025 at 10:55 PM Tamir Duberstein wrote:
>
> This started with a patch that enabled `clippy::ptr_as_ptr`. Benno
> Lossin suggested I also look into `clippy::ptr_cast_constness` and I
> discovered `clippy::as_ptr_cast_mut`. This series now enables all 3
> lints. It also enables `cli
On Wed, Jun 18, 2025 at 7:56 PM Tamir Duberstein wrote:
>
> Miguel, would you mind taking care of this on apply? Quite a big
> series to send again.
Yeah, of course.
Cheers,
Miguel
On Wed, Jun 18, 2025 at 7:44 PM Danilo Krummrich wrote:
>
> Independent from that, won't this potentially leave us with a lot of warnings
> from code that goes through other trees in the upcoming merge window? How do
> we
> deal with that?
Yeah, good question.
Since they are Clippy ones, it sho
On Wed, Jun 18, 2025 at 7:38 PM Danilo Krummrich wrote:
>
> Shouldn't this be `c_long`?
Yeah, agreed, it is clearer -- I mentioned that for similar ones in a
previous version.
Cheers,
Miguel
On Sun, Jun 15, 2025 at 10:55 PM Tamir Duberstein wrote:
>
> rust/kernel/configfs.rs | 20 ++--
> rust/kernel/device_id.rs | 2 +-
> rust/kernel/fs/file.rs | 2 +-
Andreas, Christian, Danilo, Greg: it would be nice to get Acked-by's
for your bits.
(This particular one can be
On Sun, Jun 15, 2025 at 10:55 PM Tamir Duberstein wrote:
>
> rust/kernel/drm/device.rs | 4 ++--
Danilo: for completeness: if you don't want this, please shout. Thanks!
Cheers,
Miguel
On Sun, Jun 15, 2025 at 10:55 PM Tamir Duberstein wrote:
>
> rust/kernel/devres.rs | 2 +-
Danilo, Greg: for completeness: if you don't want this, please shout. Thanks!
Cheers,
Miguel
On Wed, Jun 18, 2025 at 3:52 PM Tamir Duberstein wrote:
>
> @Danilo Krummrich could you please have a look for drm and nova?
Jocelyn, Tomo: it would also be nice to get Acked-by's for your bits.
Thanks!
Cheers,
Miguel
On Wed, Jun 18, 2025 at 3:51 PM Tamir Duberstein wrote:
>
> @Danilo Krummrich could you please have a look for nova?
Alice, Christian, Danilo, Greg, Tejun: it would also be nice to get
Acked-by's for your (other) bits.
Thanks!
Cheers,
Miguel
On Sun, Jun 15, 2025 at 10:55 PM Tamir Duberstein wrote:
>
> Apply these changes and enable the lint -- no functional change
> intended.
We need one more for `opp` [1] -- Viresh: I can do it on apply, unless
you disagree.
Cheers,
Miguel
[1]
diff --git a/rust/kernel/opp.rs b/rust/kernel/opp.rs
On Wed, Jun 18, 2025 at 3:54 PM Tamir Duberstein wrote:
>
> @Andreas Hindborg could you please have a look for configfs?
>
> @Rafael J. Wysocki @Viresh Kumar could you please have a look for cpufreq?
Thanks Tamir.
Christian, Danilo, David, Greg, Tejun: It would also be nice to get
Acked-by's for
On Thu, Jun 12, 2025 at 4:02 PM Alexandre Courbot wrote:
>
> +///
> assert_eq!(PowerOfTwotry_new(16).unwrap().value(), 16);
By the way, we are trying to write examples close to normal kernel
code as possible, so could you please use `?` here instead of
`unwrap()`?
It is not
On Sun, Jun 15, 2025 at 12:58 PM Alexandre Courbot wrote:
>
> Also, although this will work nicely for `impl_fls!` which is a single
> function, I'm afraid this won't scale well for `power_of_two_impl!`,
> which defines 6 functions per type... Any suggestions for this case?
We can always generate
On Thu, Jun 12, 2025 at 4:02 PM Alexandre Courbot wrote:
>
> +/// ```
> +/// use kernel::num::fls_u32;
> +///
> +/// assert_eq!(fls_u32(0x0), 0);
> +/// assert_eq!(fls_u32(0x1), 1);
> +/// assert_eq!(fls_u32(0x10), 5);
> +
On Wed, Jun 11, 2025 at 12:23 PM Tamir Duberstein wrote:
>
> This series depends on "rust: retain pointer mut-ness in
> `container_of!`"[1].
Not anymore! :)
> Signed-off-by: Tamir Duberstein
Thanks for rebasing, Tamir, I appreciate it.
This has a bunch of hits in configfs, cpufreq and Nova [1
On Tue, Jun 10, 2025 at 4:14 PM Tamir Duberstein wrote:
>
> Yeah, I think these are good calls - I'll fix it in v11. When would
> you like me to send it?
Since -rc1 is out, please feel free to send it already if you can. It
would be nice to see if we can apply it all soon in the cycle, but we
wil
On Tue, Jun 10, 2025 at 2:37 PM Guilherme Giacomo Simoes
wrote:
>
> Maybe, after this patch we can make a checkpatch change for check the
> `authors`
> key (and MODULE_AUTHOR for C side), and throw a WARN if the author is a name
> (not a url, or "rust for linux") and don't have a email address.
>
On Tue, Jun 10, 2025 at 12:03 PM Miguel Ojeda
wrote:
>
> I even saw a URL...
i.e. as the sole thing, not as an addition to a company name:
MODULE_AUTHOR("https://www.comedi.org";);
Perhaps we could have a new key or similar for companies/entities, but
I am not sure if it i
On Tue, Jun 10, 2025 at 12:12 PM Benno Lossin wrote:
>
> Hmm, I guess a checkpatch lint fits better then?
Yeah, that would work.
Probably for the C side too -- from a quick grep I don't see it.
Cheers,
Miguel
On Tue, Jun 10, 2025 at 10:58 AM Benno Lossin wrote:
>
> Unrelated to this change, I think we should add email addresses to
> people in authors. Possibly enforce it by scanning each author element
> and checking if there is an email address.
Sounds good to me, but I am not sure if it is possible
On Mon, Jun 9, 2025 at 2:22 PM Guilherme Giacomo Simoes
wrote:
>
> Now that all in-tree modules have migrated to `authors`, remove:
Nit: I would have said "most modules", since we have new/remaining
ones (no need for a new version for this).
I think this patch is OK -- we could wait to do this m
On Fri, Apr 18, 2025 at 5:37 PM Tamir Duberstein wrote:
>
> This started with a patch that enabled `clippy::ptr_as_ptr`. Benno
> Lossin suggested I also look into `clippy::ptr_cast_constness` and I
> discovered `clippy::as_ptr_cast_mut`. This series now enables all 3
> lints. It also enables `clip
On Fri, Apr 18, 2025 at 5:37 PM Tamir Duberstein wrote:
>
> -bindings::BLK_STS_OK as _
> +bindings::BLK_STS_OK as u8
> -unsafe { bindings::blk_mq_end_request(request_ptr,
> bindings::BLK_STS_OK as _) };
> +unsafe { bindings::blk_mq_end_request(request_ptr,
On Tue, Jun 3, 2025 at 11:05 PM Lyude Paul wrote:
>
> Not sure this makes sense - debug_assertions is supposed to be about
> assertions, we probably shouldn't try to use it for other things (especially
> since we've already got dev_dbg! here)
Yeah, we added it in `pr_debug!`, but I think we shoul
On Sat, May 31, 2025 at 4:37 PM Danilo Krummrich wrote:
>
> I agreed to take this code without waiting for those abstractions, but with a
> TODO to fix things up once they land.
That sounds good, yeah.
Cheers,
Miguel
On Fri, May 30, 2025 at 11:51 PM Lyude Paul wrote:
>
> JFYI: You can actually just say Result here, since () is the default type for
> the kernel's Result type
+1
> TBH - we should really add some safe bindings for sleeps instead of calling
> this unsafely, I'd be happy to review them if you do
On Sat, May 24, 2025 at 10:33 PM Tamir Duberstein wrote:
>
> This title is consistent with all other macros' documentation,
> regardless of the number of examples contained in their "Examples"
> sections.
>
> Signed-off-by: Tamir Duberstein
I was going to say that I could take this one independe
On Fri, May 23, 2025 at 8:14 AM Stephen Rothwell wrote:
>
> I fixed it up (see below) 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 your tree
> is submitted for merging
On Thu, May 22, 2025 at 6:01 AM Alexandre Courbot wrote:
>
> Either that, or we enable `#![feature(const_trait_impl)]`. I just tried
> and with it we could indeed define and implement `NumExt` as const,
> which looks like the cleanest way to do this to me.
Hmm... I think that one is actively bein
On Mon, May 12, 2025 at 2:09 PM Danilo Krummrich wrote:
>
> Lyude's series [1] should address this and the other one you pointed out.
Great, thanks!
Cheers,
Miguel
On Mon, May 12, 2025 at 1:41 PM Miguel Ojeda
wrote:
>
> Doing something unrelated, I got a Clippy warning about this public
By the way, this call (and another one here) to `container_of!` goes
through `Opaque`, so it will not pass the future `assert_same_type`
test we want to have:
error
On Fri, Apr 11, 2025 at 1:56 AM Danilo Krummrich wrote:
>
> +fn from_gem_obj(obj: *mut bindings::drm_gem_object) -> *mut Self {
> +// SAFETY: All of our objects are Object.
> +unsafe { crate::container_of!(obj, Object, obj).cast_mut() }
> +}
Doing something unrelated, I go
On Fri, Apr 18, 2025 at 5:09 PM Boqun Feng wrote:
>
> I'm leaning towards to 2 and then 3, because using `as` can sometimes
> surprise you when you change the type. Thoughts?
Having explicit functions sounds good to me, and would also help
migrating later easily to anything else (because all case
On Fri, Apr 18, 2025 at 6:51 PM Jocelyn Falempe wrote:
>
> Link:
> https://lore.kernel.org/dri-devel/caniq72ke45eowckmhwhvmwxc03dxr4rnxxkvx+hvwdblopz...@mail.gmail.com/
> [1]
Thanks for fixing that -- some tags for your consideration:
Reported-by: Miguel Ojeda
Cl
1 - 100 of 205 matches
Mail list logo
