linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Christian Schrefl <chrisi.schrefl@gmail.com>
To: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
	Jocelyn Falempe <jfalempe@redhat.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
	rust-for-linux <rust-for-linux@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Russell King <linux@armlinux.org.uk>,
	Linus Walleij <linus.walleij@linaro.org>
Subject: Re: `u64` by `u64` div/mod in DRM QR for arm32
Date: Mon, 14 Apr 2025 21:21:42 +0200	[thread overview]
Message-ID: <38867e79-c0e3-4bcd-bdf9-3fb5b571d51e@gmail.com> (raw)
In-Reply-To: <CANiq72ke45eOwckMhWHvmwxc03dxr4rnxxKvx+HvWdBLopZfrQ@mail.gmail.com>

Hi Miguel,

On 14.04.25 8:14 PM, Miguel Ojeda wrote:
> Hi Jocelyn, Christian,
> 
> I started build-testing arm 32-bit within my other usual routine
> tests, and I hit:
> 
>     ld.lld: error: undefined symbol: __aeabi_uldivmod
>     >>> referenced by drm_panic_qr.rs:417 (drivers/gpu/drm/drm_panic_qr.rs:417)
>     >>> drivers/gpu/drm/drm_panic_qr.o:(<drm_panic_qr::SegmentIterator
> as core::iter::traits::iterator::Iterator>::next) in archive vmlinux.a
> 
> which comes from both these `u64` by `u64`:
> 
>     let out = (self.carry / pow) as u16;
>     self.carry = self.carry % pow;
> 
> Christian: I guess we can offer a set of `div64` functions using the C
> ones, at least for the time being, and eventually wire the actual
> operator with some support from upstream Rust. Or do you have
> something else in mind? (i.e. I think you have been discussing
> intrinsics lately)

I think using the C implementations is fine. Not sure how much the
FFI is going to matter for performance, but it should be rare enough
that is shouldn't matter (and hopefully we will get cross lang LTO 
or something similar at some point).

We could also just implement the intrinsic(s) ourselves, but then 
the u64 divisions would be implicit which is probably undesired.
We could also rename the intrinsics so they are only usable from 
specific crates. 

I think we need the opinion of the some arm people here.

CC Russell King and Linus Walleij.


I'm not sure what could be done in upstream rust to help here
and that would probably need be a very specific features for the
kernel.


Cheers
Chrisitan


  reply	other threads:[~2025-04-14 20:28 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-14 18:14 `u64` by `u64` div/mod in DRM QR for arm32 Miguel Ojeda
2025-04-14 19:21 ` Christian Schrefl [this message]
2025-04-14 19:46   ` Russell King (Oracle)
2025-04-15  9:14     ` Jocelyn Falempe
2025-04-15 12:50       ` Paolo Bonzini
2025-05-05  7:37     ` Geert Uytterhoeven
2025-04-14 20:04 ` Miguel Ojeda

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=38867e79-c0e3-4bcd-bdf9-3fb5b571d51e@gmail.com \
    --to=chrisi.schrefl@gmail.com \
    --cc=arnd@arndb.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jfalempe@redhat.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux@armlinux.org.uk \
    --cc=miguel.ojeda.sandonis@gmail.com \
    --cc=rust-for-linux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).