From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-40131.protonmail.ch (mail-40131.protonmail.ch [185.70.40.131]) (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 4E24C1C1F0F for ; Wed, 19 Mar 2025 14:13:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.70.40.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742393590; cv=none; b=ei0191Jh/qqfl6/XME/bvuEKxH86OVZNBAGZSU0DJPa+Y9J19AQJ2lGha84QasPp0qu0Zyxm3EV0byHklgkEruLfqHGMYXD6ABqbYxldQ7T2GMaNwMwhjEaMLECU+uVkunuRfRXyKijdjyakLj19exq3fO7S/hEtfFMOHjaBgWQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742393590; c=relaxed/simple; bh=173mR8ZcqIucBbAsooxSJ7aCrBDlB0BXxLNyDYR2IkI=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=nDhKB2kBDyfK9j/kSpkMGRbxKjabU2PF/7V0v70vPZdwiCGHEox2MpdMVYKzLMlZ6OqtxOZ/reebcoLtrfHZZrST2fKgOR2EGfBrPQXzh2mUycSRTs+K2OvmHdb0II89M2j7igzTyfOeIcH4cxMNXKp4Zfa+gSXB5Chou5dmW2A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=proton.me; spf=pass smtp.mailfrom=proton.me; dkim=pass (2048-bit key) header.d=proton.me header.i=@proton.me header.b=HY5WWWTf; arc=none smtp.client-ip=185.70.40.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=proton.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=proton.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=proton.me header.i=@proton.me header.b="HY5WWWTf" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1742393584; x=1742652784; bh=yYLcfHuvK6FvGpwQFNJmILNKHihIkpgM2uT8zMa5DCs=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=HY5WWWTfyhBjxkHduWvmBtGULW1loewR5xlXgUfO5cZ5gwsKQ+U9rARjqqR/ALYv1 +7y34Ofkw0vwjdy2JiXZ9r2t2yTrNbDQv4pFyhFj6HbWhMoiwWyODDCS8wN+akkQek U+tBqfAGz3XVg7UgROscGQ0kz+AxoH+89vlSLpVSw/YWaUuke9/b0wjvEHxPJW8GXX XSuAJdj9v+KWeco8H7tBOcXAORnJVDPg+YFGFPL88D7x8jhh/8bJEgLGLmUFyqB4r7 QTr4jNb/Wc5AuxkHZDQuAJKR7mGVHgGRU/t8nL6Iu365mtROL9ymCv+eD17DuBCqSu GdmtHSpSs7sng== Date: Wed, 19 Mar 2025 14:13:00 +0000 To: Danilo Krummrich From: Benno Lossin Cc: Daniel Almeida , Miguel Ojeda , Alex Gaynor , Boqun Feng , Gary Guo , =?utf-8?Q?Bj=C3=B6rn_Roy_Baron?= , Andreas Hindborg , Alice Ryhl , Trevor Gross , Greg Kroah-Hartman , "Rafael J. Wysocki" , linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org Subject: Re: [PATCH v7 3/3] rust: platform: allow ioremap of platform resources Message-ID: In-Reply-To: References: <20250318-topics-tyr-platform_iomem-v7-0-7438691d9ef7@collabora.com> <20250318-topics-tyr-platform_iomem-v7-3-7438691d9ef7@collabora.com> Feedback-ID: 71780778:user:proton X-Pm-Message-ID: 72b1eaec6fc8bf9fcfcb1f6690c590f709d0dbd4 Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed Mar 19, 2025 at 12:22 PM CET, Danilo Krummrich wrote: > On Wed, Mar 19, 2025 at 12:48:00AM +0000, Benno Lossin wrote: >> On Tue Mar 18, 2025 at 7:22 PM CET, Daniel Almeida wrote: >> > On 18 Mar 2025, at 14:43, Danilo Krummrich wrote: >> >> On Tue, Mar 18, 2025 at 02:20:43PM -0300, Daniel Almeida wrote: >> >>> + /// // Read and write a 32-bit value at `offset`. Calling `= try_access()` on >> >>> + /// // the `Devres` makes sure that the resource is still v= alid. >> >>> + /// let data =3D iomem.try_access().ok_or(ENODEV)?.readl(of= fset); >> >>> + /// >> >>> + /// iomem.try_access().ok_or(ENODEV)?.writel(data, offset); >> >>=20 >> >> I'd probably write this as >> >>=20 >> >> || -> Result { >> >> let iomem =3D iomem.try_access().ok_or(ENODEV)?; >> >>=20 >> >> iomem.read32(offset); >> >> iomem.write32(data, offset); >> >>=20 >> >> Ok(()) >> >> }()?; >>=20 >> Why use a closure here? > > Calling try_access() only once and not having the closure is fine too. > > But I also think it would be good practice for an example to explicitly l= imit > the scope of the corresponding guard. Ah you're using the closure to limit the lifetime of the guard. You don't need a closure, braces suffice. > Ideally, it uses [1], once available. > > [1] https://lore.kernel.org/rust-for-linux/20250313-try_with-v1-1-adcae7e= d98a9@nvidia.com/ Yeah that sounds best. --- Cheers, Benno