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 8DA031C68A6; Sun, 25 May 2025 12:03:37 +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=1748174617; cv=none; b=Yv0mXt0q4lLBkugPdYCYFybXlUHJ022cxmWcQvl2Qlr/KJ9uGomKyM+UB8rL1Ko9PXIjOTH/zrGgdPcNywrBtBz+wLIzN/8qpPkMP2yCLRD4DsQxanIENRLnrT9JPDJSul2TLh29o/QXZHt6MOjOray1wvV3LoaPWqy4iYThbOU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1748174617; c=relaxed/simple; bh=ZroNZhDGWJdIoldyG/mgeggU87AzdoTiS+PmGR/PpdQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=QMyma8HGTxHmXg58RWoVqrjCuPfduFFM9QNXNgIedH4WqigsXrfj2nfBM5etjRzfXVKwUzVbRKXu0v7iNLpcNovFko+r+pryIgBq113MZGziY/c+fsO2dHIedT4jZTF1IWwFBLTbdHytY3OqbVLDTwabuy9UiHIWXTXBDqbgWok= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=FxyrIglo; 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="FxyrIglo" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E3982C4CEEA; Sun, 25 May 2025 12:03:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1748174617; bh=ZroNZhDGWJdIoldyG/mgeggU87AzdoTiS+PmGR/PpdQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=FxyrIgloPxQEkwU/Tn8ICqbDkMKIEsHYjtig4BDG8X627bskdEvhXJB63YMq81H+q A7ueDYXb9mKQwGU2uy72aetT0wubSV6eu1PEQkwavQ2as5t+P87lGWcEK0hLKrmFMx TtDA5/mXAhyH8N8tHeKq/f/45Hl2F1TpDsIG3rTpKnu3rqXbq0wpKOs/IdWN35ZnoL hbHZjbgLeRCSe0QebuwBZjzESJin8R8rKvWQbwp/ChV6AiETfbWXsjcUjM74d0dDMj y7QOdo0yq62XXQ9BzBVxAcT6k6UcCySdzLY4vpnipb4MxjYNX+FrCvyEKTOeqId6mP UVrLZrF4/QB8A== Date: Sun, 25 May 2025 14:03:29 +0200 From: Danilo Krummrich To: Michal Wilczynski Cc: Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= , Miguel Ojeda , Alex Gaynor , Boqun Feng , Gary Guo , =?iso-8859-1?Q?Bj=F6rn?= Roy Baron , Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross , Drew Fustini , Guo Ren , Fu Wei , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Marek Szyprowski , linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org, rust-for-linux@vger.kernel.org, linux-riscv@lists.infradead.org, devicetree@vger.kernel.org Subject: Re: [PATCH RFC 2/6] pwm: Add Rust driver for T-HEAD TH1520 SoC Message-ID: References: <20250524-rust-next-pwm-working-fan-for-sending-v1-0-bdd2d5094ff7@samsung.com> <20250524-rust-next-pwm-working-fan-for-sending-v1-2-bdd2d5094ff7@samsung.com> Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250524-rust-next-pwm-working-fan-for-sending-v1-2-bdd2d5094ff7@samsung.com> On Sat, May 24, 2025 at 11:14:56PM +0200, Michal Wilczynski wrote: > diff --git a/drivers/pwm/pwm_th1520.rs b/drivers/pwm/pwm_th1520.rs > new file mode 100644 > index 0000000000000000000000000000000000000000..4665e293e8d0bdc1a62a4e295cdaf4d47b3dd134 > --- /dev/null > +++ b/drivers/pwm/pwm_th1520.rs > @@ -0,0 +1,272 @@ > +// SPDX-License-Identifier: GPL-2.0 > +// Copyright (c) 2025 Samsung Electronics Co., Ltd. > +// Author: Michal Wilczynski > + > +//! Rust T-HEAD TH1520 PWM driver > +use kernel::{c_st > + > +struct Th1520PwmChipData { > + clk: Clk, > + iomem: kernel::devres::Devres>, Why IoMem<0>? If you put the expected memory region size for this chip instead all your subsequent accesses can be iomem.write() / iomem.read() rather than the fallible try_{read,write}() variants. > +impl Th1520PwmChipData { > + fn _config( > + &self, > + hwpwm: u32, > + duty_ns: u64, > + period_ns: u64, > + target_polarity: pwm::Polarity, > + ) -> Result { > + let regs = self.iomem.try_access().ok_or_else(|| { > + pr_err!("PWM-{}: Failed to access I/O memory in _config\n", hwpwm); Here and throughout the whole driver, please use the dev_*!() print macros. Drivers have no reason to use the pr_*!() macros. > +impl pwm::PwmOps for Th1520PwmChipData { > + // This driver implements get_state > + fn apply( > + pwm_chip_ref: &mut pwm::Chip, > + pwm_dev: &mut pwm::Device, > + target_state: &pwm::State, > + ) -> Result { I assume those callbacks can't race with pwmchip_remove() called from driver remove()? I.e. the callbacks are guaranteed to complete before pwmchip_remove() completes? If so, this function signature can provide the parent device of the pwm::Chip as device::Device reference. This would allow you to access iomem more efficiently. Instead of data.iomem.try_access() you could do data.iomem.access(parent) // [1] which does get you rid of the atomic check and the RCU read side critical section implied by try_access(). Actually, I should have added this comment and explanation to the abstraction patch, but forgot about it. :) [1] https://gitlab.freedesktop.org/drm/kernel/-/blob/drm-next/rust/kernel/devres.rs?ref_type=heads#L213