similar to: [RFC PATCH 7/8] rust: add firmware abstractions

On Fri, Jun 07, 2024 at 09:11:32PM +0900, FUJITA Tomonori wrote: > Hi, > > On Fri, 31 May 2024 11:59:47 +0200 > Danilo Krummrich <dakr at redhat.com> wrote: > > > Once we get to a conclusion I can send a series with only the device and firmare > > abstractions such that we can get them in outside of the scope of the reset of > > both series to get your

On Fri, Jun 07, 2024 at 03:33:39PM +0200, Danilo Krummrich wrote: > On Fri, Jun 07, 2024 at 02:36:50PM +0200, Greg KH wrote: > > Anyway, that's all hand-wavy right now, sorry, to get back to the point > > here, again, let's take this, which will allow the firmware bindings to > > be resubmitted and hopefully accepted, and we can move forward from > > there to

On Thu, May 30, 2024 at 01:24:33PM +0900, FUJITA Tomonori wrote: > Hi, > > On Thu, 30 May 2024 04:01:39 +0200 > Danilo Krummrich <dakr at redhat.com> wrote: > > > On Thu, May 30, 2024 at 08:28:24AM +0900, FUJITA Tomonori wrote: > >> Hi, > >> > >> On Wed, 29 May 2024 21:57:03 +0200 > >> Greg KH <gregkh at linuxfoundation.org>

On Fri, Jun 07, 2024 at 02:36:50PM +0200, Greg KH wrote: > Anyway, that's all hand-wavy right now, sorry, to get back to the point > here, again, let's take this, which will allow the firmware bindings to > be resubmitted and hopefully accepted, and we can move forward from > there to "real" things like a USB or PCI or even platform device and > driver binding

On Thu, May 30, 2024 at 08:28:24AM +0900, FUJITA Tomonori wrote: > Hi, > > On Wed, 29 May 2024 21:57:03 +0200 > Greg KH <gregkh at linuxfoundation.org> wrote: > > >> For a Rust PHY driver, you know that you have a valid pointer to C's > >> device object of C's PHY device during the probe callback. The driver > >> creates a Rust device

On Wed, May 29, 2024 at 09:28:21AM +0900, FUJITA Tomonori wrote: > Hi, > > On Tue, 28 May 2024 14:45:02 +0200 > Greg KH <gregkh at linuxfoundation.org> wrote: > > > On Tue, May 28, 2024 at 02:19:24PM +0200, Danilo Krummrich wrote: > >> However, if you have a driver that needs the firmware abstractions, I would be > >> surprised if there were any

On Mon, Sep 02, 2024 at 06:29:06PM +0200, Daniel Vetter wrote: > On Wed, Jun 19, 2024 at 01:31:39AM +0200, Danilo Krummrich wrote: > > Implement the DRM driver abstractions. > > > > The `Driver` trait provides the interface to the actual driver to fill > > in the driver specific data, such as the `DriverInfo`, driver features > > and IOCTLs. > > > >

On Wed, Jun 19, 2024 at 01:31:36AM +0200, Danilo Krummrich wrote: > This patch series implements some basic DRM Rust abstractions and a stub > implementation of the Nova GPU driver. > > Nova is intended to be developed upstream, starting out with just a stub driver > to lift some initial required infrastructure upstream. A more detailed > explanation can be found in [1]. >

Implement the DRM driver abstractions. The `Driver` trait provides the interface to the actual driver to fill in the driver specific data, such as the `DriverInfo`, driver features and IOCTLs. Co-developed-by: Asahi Lina <lina at asahilina.net> Signed-off-by: Asahi Lina <lina at asahilina.net> Signed-off-by: Danilo Krummrich <dakr at redhat.com> ---

On Wed, Jun 19, 2024 at 01:31:39AM +0200, Danilo Krummrich wrote: > Implement the DRM driver abstractions. > > The `Driver` trait provides the interface to the actual driver to fill > in the driver specific data, such as the `DriverInfo`, driver features > and IOCTLs. > > Co-developed-by: Asahi Lina <lina at asahilina.net> > Signed-off-by: Asahi Lina <lina at

On Sat, Jun 8, 2024 at 11:16?PM Asahi Lina <lina at asahilina.net> wrote: > > > > On 5/22/24 6:23 AM, Rob Herring wrote: > > On Mon, May 20, 2024 at 07:20:50PM +0200, Danilo Krummrich wrote: > >> From: Asahi Lina <lina at asahilina.net> > >> > >> Add abstractions for DRM drivers and devices. These go together in one > >> commit

From: Asahi Lina <lina at asahilina.net> DRM drivers need to be able to declare which driver-specific ioctls they support. Add an abstraction implementing the required types and a helper macro to generate the ioctl definition inside the DRM driver. Note that this macro is not usable until further bits of the abstraction are in place (but it will not fail to compile on its own, if not

Hi Lina, Welcome back! On Sun, Jun 09, 2024 at 02:15:57PM +0900, Asahi Lina wrote: > > > On 5/22/24 6:23 AM, Rob Herring wrote: > > On Mon, May 20, 2024 at 07:20:50PM +0200, Danilo Krummrich wrote: > >> From: Asahi Lina <lina at asahilina.net> > > This is missing an entry for DRIVER_GEM_GPUVA. And some others perhaps. > > I suppose some are legacy

This used to be a single patch, but I split it into two with the addition of struct Scatterlist. Again a bit new with Rust submissions. I was told by Gary Guo to rebase on top of rust-next, but it seems *very* behind? The first patch does not build on its own due to a dead_code warning. It is hard to not have dead code when one is adding infrastructure to be used by others at a later

On Tue, Jul 02, 2019 at 10:14:19PM +0900, Hiroyuki Katsura wrote: >From: Hiroyuki_Katsura <hiroyuki.katsura.0513@gmail.com> > >--- > Makefile.am | 4 ++++ > configure.ac | 3 +++ > generator/Makefile.am | 3 +++ > generator/bindtests.ml | 3 +++ > generator/bindtests.mli | 1 + > generator/main.ml | 5 +++++ > generator/rust.ml

On Fri, Sep 27, 2024 at 04:22:32PM +0200, Danilo Krummrich wrote: > > When you say things like this it comes across as though you are > > implying there are two tiers to the community. Ie those that set the > > strategy and those that don't. > > This isn't true, I just ask you to consider the goals that have been set > already, because we have been working on

Dear R-devel community, I'm exploring (experimentally) the integration of the Rust toolchain into Rtools, to enable smoother development and shipping of Rust-based R packages on Windows. I've written a detailed blog post documenting the process, technical rationale and what?s next: https://medium.com/@sunwjie/integrating-the-rust-toolchain-into-rtools-e4c7df40cb82. Currently, Rust is

Congratulations on figuring out how to extend the build of the Rtools installer to add more programs there - it is always good to have a confirmation such things are clear enough from the available documentation and sources. You can see that e.g. QPDF is added this way, but adding a toolchain requires a different approach (more below). What may not have been clear enough - please keep in mind

On Monday, 5 August 2019 08:59:31 CEST Hiroyuki Katsura wrote: > Without clarifying handle's lifetime, it is unable > to see how long the callbacks which the handle > owns will live. Then, Rust compiler will infer > that the callbacks have 'static lifetime. It is > not convenient for users. > --- My initial idea was to split the Handle -> Handle<'a> change

On Fri, Sep 27, 2024 at 09:51:15AM -0300, Jason Gunthorpe wrote: > On Fri, Sep 27, 2024 at 12:42:56AM +0200, Danilo Krummrich wrote: > > On Thu, Sep 26, 2024 at 11:40:57AM -0300, Jason Gunthorpe wrote: > > > On Thu, Sep 26, 2024 at 02:54:38PM +0200, Greg KH wrote: > > > > > > > > No, I do object to "we are ignoring the driver being proposed by the