From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E46312ECD2E; Wed, 8 Oct 2025 15:00:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759935609; cv=none; b=K0/Ejqupsf+7vQ9tLVy1QbBMgrKhsjL/JbN69fu1CPKLoyjZbP+NBqhm/tyDVNd+AE4zHH9fc3g4fXKVbHWDfyucIWLvGeGStqh0Uqm76vjCWXs89+ElC5xUN4i/17k5IIr/TC2Gbv5Us/RAZGITnkeGwsz6NBI7UV6qnuSBsME= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759935609; c=relaxed/simple; bh=Zq4M4h4026xT+BGlmoGtIh/JGWUmGo07HG7ivwnX4b0=; h=Mime-Version:Content-Type:Date:Message-Id:Subject:Cc:To:From: References:In-Reply-To; b=Hh0E8jw20EY6YiJHJaotUsVawLrIm2g4IqO202IyOJqkVEMvwviPvRT52lGvs3BSSPaHUbVQWLoI3CChwvwkfnqF9Rw6YW2SpI1jnUc0p5UAGTiYyEiVTmV6NBgFyUJiZY1SlKUvZuKoMNm8RozL0RBkQ+WW8IUweDlo3tCZ+9A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=izyx4qeJ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="izyx4qeJ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 45284C4CEE7; Wed, 8 Oct 2025 15:00:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1759935608; bh=Zq4M4h4026xT+BGlmoGtIh/JGWUmGo07HG7ivwnX4b0=; h=Date:Subject:Cc:To:From:References:In-Reply-To:From; b=izyx4qeJQb2C5pEgtTwRd/dt0xDjWrxPxH8kFxMtHeiiYKekpB8WovdQserdiWVhd WOo8964xcCQppMRCby6GiMdy3k/9W9KueVb4PjVc0TbTV2r2qhay+jSZxbQPEUQEXt BNeKJsyP43lV8j6MTXpe7eNCCLDDdNYQW2MmEfDDNcS3Rml/gQ9ej2+1l+mP/iyCDf hweGdyr1kKNpG9WbuhWi+TMj7zOmro6ptx9WXG/Hs1/oxvFcdKaGVC9W9zScrvfgjw W3gzBvZLqQbJHyqegaPD1TBtEpyUSdM5DWxRWfath0BAxZ46fkIvwfiikI5d2S+GXB mNg8GebtPo/cQ== Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 08 Oct 2025 17:00:01 +0200 Message-Id: Subject: Re: [PATCH v6 0/5] Introduce bitfield and move register macro to rust/kernel/ Cc: "Joel Fernandes" , "Alexandre Courbot" , , , , "Alistair Popple" , "Miguel Ojeda" , "Alex Gaynor" , "Boqun Feng" , "Gary Guo" , , "Benno Lossin" , "Andreas Hindborg" , "Alice Ryhl" , "Trevor Gross" , "David Airlie" , "Simona Vetter" , "Maarten Lankhorst" , "Maxime Ripard" , "Thomas Zimmermann" , "John Hubbard" , "Timur Tabi" , , "Elle Rhumsaa" , "Daniel Almeida" , "Andrea Righi" , To: "Yury Norov" From: "Danilo Krummrich" References: <20251003154748.1687160-1-joelagnelf@nvidia.com> In-Reply-To: On Wed Oct 8, 2025 at 4:28 PM CEST, Yury Norov wrote: > On Wed, Oct 08, 2025 at 12:08:59AM +0200, Danilo Krummrich wrote: > >> Regarding the bitfields for page table management: Are we >> sure that we can use raw bitfields for this? > > As per my current understanding we can't. Bitfields are not suitable for > direct I/O and considered as a data storage. In the current scheme: > > regs::NV_PFALCON_FALCON_DMATRFBASE::default() > .set_base((dma_start >> 8) as u32) > .write(bar, &E::ID); > > we account for endianess in the .write() method, which would be a part > of register API, not bitfields. I know, I proposed this register API design about a year ago, and Alex came= up with an awesome implementation for it. :) And yes, your understanding is correct, the idea is that the I/O backend th= at knows about the underlying bus, etc. takes care of the endianess. However, we might still be able to use bitfields natively for page table management structures: In [1] I asked for the NV_PMC_BOOT_1 register, which might provide some endianess switch to ensure that we always match CPU endianess. > FYI: ARM64 is in process of dropping BE, and Linus announced the end > of BE support for RISC-V: Yeah, I'm aware of the thread. Also note that for RISC-V it was also clarif= ied that if it turns out that BE for RISC-V becomes relevant it would also find= its way into the kernel. If that's likely is of course a different question. However, there are still architectures such as s390x that could be supporte= d. So, long story short, my question from above is more meant to challenge if = we can really always guarantee that CPU and GPU endianess match for nova-core. [1] https://lore.kernel.org/lkml/DDCV84IJHUML.126CB1CT0XMX5@kernel.org/