From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailout2.w1.samsung.com (mailout2.w1.samsung.com [210.118.77.12]) (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 9DC49267B65 for ; Tue, 1 Jul 2025 08:25:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=210.118.77.12 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751358306; cv=none; b=NlXlQfEAd1XySx3pxV+lpx/Whu32b9KhORVVy8wCx8hlTW9cTbY07CxFlxioc7AkS3Oiuqi/lKaLc4iVXSzRxYROXoA9upHGaaVC7cZEf4s3UWbYS2c/MHAxsg+pZioI8TrhSXVlvMON4RYq3hVBz9k4UCyH654XGuFDrAQx870= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751358306; c=relaxed/simple; bh=4NBRo7asrbE4jcsC4N5i3/e2ZCZPMxakKBYsVImNKI0=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:From:In-Reply-To: Content-Type:References; b=sKeFIJN0uVlJ5mKJRKv02MX/RUMOBljvwNY0i+vCIKYGnbToqRgnV6tuzRR2zLiQsNzVfTJZYVLggpHb/e4E2/QF5wuwkm7k8MdWSUkABrTnIXr2gretiPi6fi8DUq5/V6CG5bvNFjT/7nDkhBgTpbUcvpasGpmiJMAa35YzWzs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=samsung.com; spf=pass smtp.mailfrom=samsung.com; dkim=pass (1024-bit key) header.d=samsung.com header.i=@samsung.com header.b=PwQsOHJX; arc=none smtp.client-ip=210.118.77.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=samsung.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=samsung.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=samsung.com header.i=@samsung.com header.b="PwQsOHJX" Received: from eucas1p1.samsung.com (unknown [182.198.249.206]) by mailout2.w1.samsung.com (KnoxPortal) with ESMTP id 20250701082456euoutp02dfd76ccb75b18d8d4a6364dd0e121519~OExd623i12192621926euoutp02r for ; Tue, 1 Jul 2025 08:24:56 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout2.w1.samsung.com 20250701082456euoutp02dfd76ccb75b18d8d4a6364dd0e121519~OExd623i12192621926euoutp02r DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1751358296; bh=KfdpUFAVhAyxGqE9eLEIBkkqrEYX2W0imprAxbQivkU=; h=Date:Subject:To:Cc:From:In-Reply-To:References:From; b=PwQsOHJXGkU9mixvHQse3EYengfFoqHmA30yZ29Nwz9nTmg5Vjvv3Mjnkdj2yQTO+ HA7ti9PjBheHdgVw6q3trtWTW6m0QWrOBK8uQ0cUBq4yTUAK1j2qGYkWFUG+eAtdKk Zd1cwp+uPNs5SfmyqgTwNswNIlSbQiMFzoMmeoPY= Received: from eusmtip1.samsung.com (unknown [203.254.199.221]) by eucas1p2.samsung.com (KnoxPortal) with ESMTPA id 20250701082456eucas1p27ac527ab6df65b4ad24af9f1936ee772~OExdUXUK-0564305643eucas1p2z; Tue, 1 Jul 2025 08:24:56 +0000 (GMT) Received: from [192.168.1.44] (unknown [106.210.136.40]) by eusmtip1.samsung.com (KnoxPortal) with ESMTPA id 20250701082454eusmtip179c87208d9c76abee9ff0a1bd9cb19a6~OExcL0hDa2415924159eusmtip1p; Tue, 1 Jul 2025 08:24:54 +0000 (GMT) Message-ID: Date: Tue, 1 Jul 2025 10:24:54 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 1/9] rust: pwm: Add Kconfig and basic data structures To: =?UTF-8?Q?Uwe_Kleine-K=C3=B6nig?= Cc: Miguel Ojeda , Alex Gaynor , Boqun Feng , Gary Guo , =?UTF-8?Q?Bj=C3=B6rn_Roy_Baron?= , Andreas Hindborg , Alice Ryhl , Trevor Gross , Danilo Krummrich , Drew Fustini , Guo Ren , Fu Wei , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Marek Szyprowski , Benno Lossin , Michael Turquette , Stephen Boyd , 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, linux-clk@vger.kernel.org Content-Language: en-US From: Michal Wilczynski In-Reply-To: Content-Transfer-Encoding: 8bit X-CMS-MailID: 20250701082456eucas1p27ac527ab6df65b4ad24af9f1936ee772 X-Msg-Generator: CA Content-Type: text/plain; charset="utf-8" X-RootMTR: 20250623180858eucas1p1815f6d6815b1c715baad94810cefacd5 X-EPHeader: CA X-CMS-RootMailID: 20250623180858eucas1p1815f6d6815b1c715baad94810cefacd5 References: <20250623-rust-next-pwm-working-fan-for-sending-v5-0-0ca23747c23e@samsung.com> <20250623-rust-next-pwm-working-fan-for-sending-v5-1-0ca23747c23e@samsung.com> <1450a457-4bd3-4e9c-a74f-3be15c9ec84f@samsung.com> On 6/29/25 12:29, Uwe Kleine-König wrote: > On Sat, Jun 28, 2025 at 09:47:19PM +0200, Michal Wilczynski wrote: >>>>> + /// Sets the polarity of the PWM signal. >>>>> + pub fn set_polarity(&mut self, polarity: Polarity) { >>>>> + self.0.polarity = polarity.into(); >>>>> + } >>>> >>>> Please don't expose these non-atomic callbacks. pwm_disable() would be >>>> fine. >> >> Hmm, I've just realized that without those setters it would most likely >> impossible to correctly implement the get_state callback. > > You shouldn't implement the get_state callback for a waveform driver. You're right that a new driver using the waveform API shouldn't implement .get_state. My goal for the abstraction layer, however, is to be flexible enough to support writing both modern waveform drivers and legacy style drivers that use the .apply and .get_state callbacks. To implement the .get_state callback, a driver needs the ability to construct a State struct and populate its fields from hardware values before returning it to the PWM core. Without this ability there is no way to implement get_state callback. I think the cleaner way, without the setters would be to update the `new` like so: pub fn new( period: u64, duty_cycle: u64, polarity: Polarity, enabled: bool, usage_power: bool, ) -> Self { let raw_c_state = bindings::pwm_state { period, duty_cycle, polarity: polarity.into(), enabled, usage_power, }; State(raw_c_state) } This way the get_state callback would be responsible for creating new state and initializing it, instead of passing the mutable State to get_state. > > Best regards > Uwe Best regards, -- Michal Wilczynski