On Mon Jun 22, 2026 at 9:23 PM -03, Alistair Popple wrote: > On 2026-06-23 at 07:02 +1000, Danilo Krummrich <[email protected]> wrote... >> On Mon Jun 22, 2026 at 10:26 PM CEST, Nicolás Antinori wrote: >> > I did my work on rust-next [1] because drm-rust-next does not have the >> > zerocopy crate present yet [2]. linux-next contains both zerocopy [3] >> > and the new users of transmute::FromBytes if I am not mistaken (BitToken, >> > PciRomHeader, and PmuLookupTableEntry), so I can make the changes there. >> >> The drm-rust tree is a bit special, as it remains open for contributions even >> after it has been tagged for inclusion into Linus's (including throughout the >> merge window). However, all changes staged in drm-rust-next are not going >> into >> linux-next until -rc1 is released. >> >> IOW, until -rc1 is released this may or may not resolve all conflicts with >> drm-rust-next. Once -rc1 is released, it is backmerged into drm-rust-next and >> drm-rust-next is picked up by linux-next again. >> >> Usually all of this remains rather transparent to contributors, but you hit >> the >> case of using a new feature introduced through another tree before >> drm-rust-next >> caught up with Linus's tree (which will happen next Sunday). >> >> Before drm-rust-next caught up, this patch can't be applied anyways, so all >> good. >> >> > I am fairly new to kernel development, I apologize for the mix-up. >> >> No worries, you did nothing wrong; thanks for the contribution! > > Yes sorry if I gave the impression you did something wrong - this also took me > a moment to untangle as an experienced contributor so perfectly > understandable. > Appreciate your contribution and hope to see more of them in future. > > - Alistair > >> - Danilo
Thank you both for the clarifications! I'll wait until the backmerge into drm-rust-next happens, then I'll rebase this patch along with the new conversions and send a v2. Regards, Nicolás
