From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f49.google.com (mail-dl1-f49.google.com [74.125.82.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B4B2B322C78 for ; Thu, 18 Jun 2026 15:32:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781796762; cv=none; b=l/rQsWQHcvShwsUBL/3WZFUGlCzJUYxxOwDKDRoxmDDd90dxCvi/J1nB0TWoGqpzk2RVDNn1OmrFpswy9DIMKBjbpVvRNBCJvk0l4rcxh5O0PqEWsa51eY1DLS8f4DvVK/qRPq52a2RhL9nug+fqJxkvrpOX6ygyOvzQMfzYh70= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781796762; c=relaxed/simple; bh=kJtsp1IazgSMj1nbHUhrUJKr18wuS2KWcV03+qv/vOw=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=Gwcqb32a8mkVFiQdnm0uFL5cTQ09KufoJhF5UrLv8++dI80p7wFrOmYUpX+b4h6RxUTaogqNi/5D7i9Tz8YjpQtdfhnpjGwuvuobMHxpE3ogExLXVhjq7iobZ04Yh7FiITzNUDgH+wOly5uXqywctV9C3xu7rymEcp+s3xfLJfs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=hCMMjNch; arc=none smtp.client-ip=74.125.82.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="hCMMjNch" Received: by mail-dl1-f49.google.com with SMTP id a92af1059eb24-1370417c01cso1534474c88.1 for ; Thu, 18 Jun 2026 08:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781796759; x=1782401559; darn=vger.kernel.org; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ZP2Cpfm9UZ2KtOTUXD2ERtet4jXDhXqiOeuJJjteN/I=; b=hCMMjNch8sQeQCnvEEYb2kmp9IObLcmUVeenDwP1KeKxnmEn6Hii0X+DxfkfYt3Iq0 IFZYzXpwCESDrjL++JoiSIz5gDrriumDq5heBUcPyk8cde3kXQhqIY7Txao5kySuHvuX rdYRVGksC3GK0+hWM7/iab13qsAiEi5CgX6nQ50MJIwGLiHKP6ZKX+829J8NzX1/N8Lx uYMLP4KAXB8EK0vpce/Jq1Gk2ZcrWVDlc02dkMXZVDHHND78LLJoBYhtugDYxmLSE2pD ZZEO2D4rQA9PDVTJC1hJXwR8kxDszIxjelvygNzsjGq7IYA5TNWmYMCybaDr1i/Z/M16 AL6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781796759; x=1782401559; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=ZP2Cpfm9UZ2KtOTUXD2ERtet4jXDhXqiOeuJJjteN/I=; b=Y9hyUwTjkLZ4iDOqbAw3e3NU0yEPMRxvTtw9y+bwZ2eAjHaPAGHA6JRqiaB4qN6DYL IZ8i8zvplchDCTNatJiF0JAUC6nU0nJYb4AkvdlW+rYoaXpz0gNs6XwbVqHXjcHYUO5U WDLZQn8HcZuh48k51N24I34QhsJvJCKXLO4to7PocyDRwpcrzGQOOKkdAUKenGp0PsaJ MgALbG6SIKGNt02jfEWhV3bqBhW3712RkZCRbil4cYXmH8vwMjGYa1plQXTDlolw1byk AK6nrG2CTqe19ia5pTFTGPg71R1ZiHbzDsIxUKfD/ori37uwEZ+UkdDAbrqDWScCjv+A AqSw== X-Forwarded-Encrypted: i=1; AFNElJ/Io3X3Drj9tshx3hYywRdPIa2vHKFgc1MGsl2xX7jURopjHqvE6RztcLpfRELx4pQHCnqqACz6rNvvgLo=@vger.kernel.org X-Gm-Message-State: AOJu0Yxd8cUwN1AH+kKkmUFcW3NvSsKOmYM9xOFamGQKwcCtyEbQ/uAT i6q953tICdiZHGfaz+qvKhRhOl7+6u6kDOpcuGNNabpEU1KgX0ZZoV8= X-Gm-Gg: AfdE7clJmxRNPY6JvW1xKLYJvdd6TPit7GYrS9ZXazhgSF0QXSXLMAUVkv6wU7qmhqB eDNgEKihLlGPN7rabqg3yGiV27+Km/rD2mbtOe7UKb2iz0BPIB+t+5FjYx4H/Mn4ZNvjsTNn9Rw 35XNAKm6jwSKdvWbgCdt506Gptejyzav/RPKTKFY4QFLXVN0H2O0ANPD1U4usRylRnbsFWr3Fu8 kGX7uqw4Nd2B/7c71XmFcqUDUgZBkrOCM4jz3oIlizcvqKCIDCudpOVoHfPgUi52F6521doT/4I 2tEWWASJdm4eTzZHhUJDm1FuwFQwM5WaVLrQ3VQzUPcADCutNgjqXuFpd4AXqsZIEjVZPRBVdp3 PsExc6I2a3J8/imuJuqtyXdkoVd2ia7dWz2HEkyoom33al0/oCaju41bJ5Sww7vzgCfLPMWxj9D iJ9FQbEQulJcaNUh8C2ETaNjj+bY1Mqymc2N9HBQMjxNR5HaxM X-Received: by 2002:a05:7022:69a3:b0:138:3613:dc6 with SMTP id a92af1059eb24-139a205f34bmr134839c88.14.1781796758001; Thu, 18 Jun 2026 08:32:38 -0700 (PDT) Received: from localhost ([186.158.238.108]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-1384b964862sm19182868c88.10.2026.06.18.08.32.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 18 Jun 2026 08:32:37 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@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: Thu, 18 Jun 2026 12:32:30 -0300 Message-Id: Cc: "Alexandre Courbot" , "Alice Ryhl" , "Andreas Hindborg" , "Benno Lossin" , =?utf-8?q?Bj=C3=B6rn_Roy_Baron?= , "Boqun Feng" , "Daniel Almeida" , "Danilo Krummrich" , "Miguel Ojeda" , =?utf-8?q?Onur_=C3=96zkan?= , "Shuah Khan" , "Tamir Duberstein" , "Trevor Gross" , , , , "Sashiko" Subject: Re: [PATCH] rust: i2c: avoid locking when calling I2cAdapter::inc_ref From: =?utf-8?q?Nicol=C3=A1s_Antinori?= To: "Gary Guo" , "Igor Korotin" X-Mailer: aerc 0.20.0 References: <20260615201141.8920-1-nico.antinori.7@gmail.com> In-Reply-To: Hello Gary, On Wed Jun 17, 2026 at 11:12 AM -03, Gary Guo wrote: > On Mon Jun 15, 2026 at 9:10 PM BST, Nicol=C3=A1s Antinori wrote: >> diff --git a/rust/kernel/i2c.rs b/rust/kernel/i2c.rs >> index 624b971ca8b0..d89c42691dfe 100644 >> --- a/rust/kernel/i2c.rs >> +++ b/rust/kernel/i2c.rs >> @@ -426,8 +426,11 @@ pub fn get(index: i32) -> Result> { >> // SAFETY: Instances of `I2cAdapter` are always reference-counted. >> unsafe impl AlwaysRefCounted for I2cAdapter { >> fn inc_ref(&self) { >> - // SAFETY: The existence of a shared reference guarantees that = the refcount is non-zero. >> - unsafe { bindings::i2c_get_adapter(self.index()) }; >> + // SAFETY: The existence of a shared reference guarantees that = the refcounts are non-zero. >> + unsafe { >> + bindings::__module_get((*self.as_raw()).owner); >> + bindings::get_device(&raw mut (*self.as_raw()).dev); > > Instead of open coding this sequence, it would be better to add a C API t= hat > does exactly this (getting another reference from existing one). I based this solution on the logic used in I2cClient (where only get_device is needed) and by verifying which counters the C implementation (i2c_get_adapter) increments. The i2c_get_adapter function in i2c-core-base.c performs two increments (module increment is done by calling try_module_get, but in this case, because inc_ref operates on an already live instance, unconditionally=20 incrementing the count with `__module_get` should be safe). If I understand correctly, the idea would be to introduce a helper=20 function on the C side, for example: void i2c_adapter_increment(struct i2c_adap *adap); We would perform the increments there and call it from Rust. Using this=20 in inc_ref would be safe because the existence of &self guarantees that=20 we already have a valid, live instance. Is there any concern regarding this function beign exposed to the C side? To use it safely in C, callers would have to ensure that *adap points to a valid instance. > > That said, is there an actual user that needs this, or are we just implem= enting > AlwaysRefCounted preemptively? The only user I could find at the moment is the example driver (impl platform::Driver for SampleDriver ..) in samples/rust/rust_i2c_client.rs. Implementing AlwaysRefCounted is required for types wrapped in ARef, which is an smart pointer that handles custom reference counting. Since I2cAdapter::get returns an ARef upon success, the=20 trait must be implemented. Thank you! > > Best, > Gary > >> + } >> } >> >> unsafe fn dec_ref(obj: NonNull) { >> -- >> 2.47.3