From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) (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 B66F3257423 for ; Sat, 18 Jul 2026 03:01:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784343713; cv=none; b=W6Elc7oImc4D+yat5Hde8ywJHHij4z0z1IcdIzt+sHq+I1xRPwH/Lg8oT+L4ZrtoQtqGzoJoJ0p7BurKI6TbkCyqTaKsm3hcFSW0d32uZYDRvN9FkiryHHyzqTrpCEY39KckeUPhUrj6G1KcgJCzVPhVSBo8V2xrnAd3Zi9rttw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784343713; c=relaxed/simple; bh=72VpdzycToFx5jYXpTxGZ7WwbQARvNnQ0l5lLRfOF/s=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=WolzUj6NK98BGPG8hNl5XDrhApaq1ozgRQQh+uiIjWTWpwbq+6UkaToryIs8DO3hlniXf2HAYfO2ADvXoQ06NJutVrBEJzN8ZtJh0IKV3TBZfbYa6P3qgpRXkqvpIzuaLgagNt7tXp5SKIXlJXD641BaMEtwm7qBxuH8QL7CAAA= 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=L5mWB3i4; arc=none smtp.client-ip=209.85.214.179 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="L5mWB3i4" Received: by mail-pl1-f179.google.com with SMTP id d9443c01a7336-2cace91f112so85022405ad.0 for ; Fri, 17 Jul 2026 20:01:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784343712; x=1784948512; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=72VpdzycToFx5jYXpTxGZ7WwbQARvNnQ0l5lLRfOF/s=; b=L5mWB3i4qi4xkobO7fZowrtwOMgXzsK3LE0E5vnqPFBD0H8dGWAYfZQC9+L4Jk6J3a Ra3ZTMBO12W9loiu7OIkSoVGwY6p41OJHOYkWSx2NEvIgW+2azJABGPfjS+vreHebJaN owL9eYmBbJwiHlicyWVx15tgoA6EYQ9NNNoVLlmgSz60aU+m8FlBq9SYvrIIN5niluDV uJgEaqohd2NY8Od9QWYxyIfnriFFt89HTtWmdIbSXLAqHqOC5aB5nnUX7XdBlypr9yJh 9oEbCy5gW/KsVohLSUJLXcbda/brHRMz4qOOHt30elP/nHESzqvpzgZH5ja0Hq3xY+OX /Dpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784343712; x=1784948512; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=72VpdzycToFx5jYXpTxGZ7WwbQARvNnQ0l5lLRfOF/s=; b=DKJx+sCtc5kTYogfWMPzihFheC045Wcj+bKxKNpyNxgAkhztvUhm8Q4N70pDA832zj KOdNb15iUXO2vmC0UdaZeH8MvQso18FBOrJ6gJgBMn+9/EsT6BXeWaAhfk3GChxsLCVX JhlRVEXfZFF9mqMaT/WFAuTVde/mrCp8ATmKo4qr/HV2nLSDZ1JFzk60D0gbst375gTU a9/xT/biDAFjerMxLrO59ZZ6bQa7RaWoW6YqFZqqBwSZeEdbKNgKcv77uVnRu0LG0+uc QfUTGPu2sMM5GNWtCv/DD6u3JZaonfmmEaKOXXw8sswhibp+bjrnpBzExlDMGzbtzFLK L/uw== X-Forwarded-Encrypted: i=1; AHgh+RrSpR+zY1CTIJVetbHXnGBDVCG0KbaKCSHriBkVUNPtbhLGC+1N7Y0k4e+MNySbvzNoiPoN627XWouxAq8=@vger.kernel.org X-Gm-Message-State: AOJu0YxPrqj+oTID9Rj+HdY7SHMGhnnQBR/asouU1SXXGzR7rdK6gi6C lycEzX0HId1wl2RoXLUcKz++eoxtbD0TinUEeN1AJ5igLAO4apCsDRy2 X-Gm-Gg: AfdE7clE+99ZaTQRPYMqHlZcphx/5gdhAoQ46i+s5Wx9AMyTFcKaXNdFczVvpUKVMFn uTdL2oAafZgAyxGZmra4dlv9rgYy4Gx50u2ohdlEvo8I+qE2FthNI9cOX7+tQ+w/PwE+8JacgHe VLXzLpyyZ05Urnpq7X6vohX/pXN3vASIU39wzR4txKxes8LQwOBHc+PCATLNrIF7qMK1DnGJ1nq 8NLb4x5+NGFO7dlqFhiu2JOWcXUD7Z4SgK+gZxze/56XF4PukVVR2mD4EcDTIQQWRP4UrQ5Rudn b+j+OSNJa1E70Bx0ui70xLT5CLLYzhIm+1baMQ3/otzX07D2BkOhG+UiyPVKuwBbbogXrT8g4LF VlDPrM26TsSUrJ9CJNeK1MSi16Mmbs+bmaFgGHtTH3e4vXQm5QrYH1H22HHuV/ukV3VZ/hNTuPV Oxf6mKS2KQH3mkIlQ0XihwV6JiqtKaHykzBfwcx3ghpKdvxXdt+dcJ8odBDWlbebmCYE13X1NSO KJW2QaEozXiLCnE8hYYnxJyny0LPOEM4y+mk7dKh6iW8fOfUBHsUZz9BM7zYXJj2VdbKxRTt3Ox Ine4M4MKjbeChp8njNshdqr+CfL+Fzj/oWKx4TTKlh9uCAeucLZeHh04lmOj40OVyRyGec86ymf L2g== X-Received: by 2002:a17:902:c950:b0:2c9:d8c6:1dc3 with SMTP id d9443c01a7336-2cf3463299dmr56325425ad.0.1784343712078; Fri, 17 Jul 2026 20:01:52 -0700 (PDT) Received: from ip-172-31-21-198.us-west-2.compute.internal (ec2-54-213-160-35.us-west-2.compute.amazonaws.com. [54.213.160.35]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2cf3474100fsm20456615ad.66.2026.07.17.20.01.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Jul 2026 20:01:51 -0700 (PDT) From: Bruce Robertson To: Alice Ryhl Cc: rust-for-linux@vger.kernel.org, linux-pm@vger.kernel.org, linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org, sre@kernel.org, ojeda@kernel.org, igor.korotin@linux.dev, gary@garyguo.net, tamird@kernel.org, boqun@kernel.org Subject: Re: [RFC PATCH 2/3] rust: power_supply: add power supply class abstraction Date: Sat, 18 Jul 2026 03:00:58 +0000 Message-ID: <20260718030058.1677-1-brucer42@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Thu, Jul 09, 2026 at 09:04:00 +0000, Alice Ryhl wrote: > > +/// Register a power supply backed by driver `T` against `dev`. > > +pub fn register(dev: &Device) -> Result { > > Should this be &Device? Yes, it should. That also lines up with Danilo's comment on the i2c side of this series that I/O-capable operations need at least the Bound device context. Will fix in v2. Taking &Device also helps with a lifetime problem the cover letter flagged: the trampoline currently recovers the driver's private data via device drvdata, which the i2c core only sets after probe() returns, while power_supply_register() exposes sysfs before that. For v2 I plan to pass the driver data through power_supply_config::drv_data at registration time instead, so the callback never depends on drvdata ordering, and to add a Sync bound on Driver since get_property() can be called concurrently. > This looks like it should be a ::new() method on Registration instead? > > I would compare with existing Registration abstractions and mirror how > they do it. Agreed. I'll rework it as Registration::new(dev: &Device, ...) in v2, following the existing Registration patterns in the tree, and look at tying the descriptor lifetime to devres while I'm there rather than relying on Drop ordering alone. Thanks for the review. Apologies for slow response. Was wilderness camping. Bruce