From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f53.google.com (mail-dl1-f53.google.com [74.125.82.53]) (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 C0845388877 for ; Thu, 14 May 2026 04:25:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778732758; cv=none; b=Xx0yqf9/Maf+71ieIPkrLfAKzbI1a2ACh3pUCkgSbO43UQ+AXPMAqR/jeKfg0guG0yo3za8x9WVpSjVFqC0mW0IqPdVMGaTlyrg2vyniQU/TltSyVzlhHoGuwlQYmKEH8rnf9ljO4ZST9naWRfaDWb/mbAbUjrQxDdIhqp8Gt9I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778732758; c=relaxed/simple; bh=Xk9UOkNIs/6BZtbVkVNxSjWkErNcowjkARNVXgeAc1o=; h=Mime-Version:Content-Type:Date:Message-Id:From:To:Cc:Subject: References:In-Reply-To; b=DRsyZi9Ps8U9e03NtyMlKVD+RXe+ufePjVAhK7CL+qR/GJRb1t0VJVzAe2Qk47k/uWK6/fRPCRrgUepeYyisO4uqY64Lhc/8zFOHwzmZKPUIhRI4fes8xbKF90DWswoe5jE/TsJVO5rUNB0tKe9RcbJEnDWwJ7Lr0UTOl1+odj8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=nexthop.ai; spf=pass smtp.mailfrom=nexthop.ai; dkim=pass (2048-bit key) header.d=nexthop.ai header.i=@nexthop.ai header.b=QU52XJy9; arc=none smtp.client-ip=74.125.82.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=nexthop.ai Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=nexthop.ai Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=nexthop.ai header.i=@nexthop.ai header.b="QU52XJy9" Received: by mail-dl1-f53.google.com with SMTP id a92af1059eb24-1330d6bb78dso4295413c88.1 for ; Wed, 13 May 2026 21:25:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nexthop.ai; s=google; t=1778732756; x=1779337556; darn=vger.kernel.org; h=in-reply-to:references:subject:cc:to:from:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=13EaFGhc9sBhjVtX9ZyJlLsTcSvLGmruzmbLxhBQiPU=; b=QU52XJy9ZlRpHenIyK6djz3UFt5uUyNjvjP+VJMhdCP/KfXAvme8ULuhtDNGJ+mh66 altNc+sGEBOs2j6zO/w+EwJ8lgSMzGs+F0xOZXECk3Hzj/zoMTDPWybUWv3f09+Xz1w1 in2nzydjb5Bbx4ctbEKqsRP4z0KRqtdCaYaiN229N3YAkzFhXItF+xV5FhsQu5QtKd2n 91WnMFmMgGej8cJFsCufEWqZK4Ke3OG48pW9d0wqW9mu4yY10WChZEJFLJO17omUOLyX kgihJ7K77lKVTJ3b5dC7dDc9cD+LSUYZ+0rhS1svBjNhz3F3Au7sfsWBKBAKMK7QuTN7 LECw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778732756; x=1779337556; h=in-reply-to:references:subject:cc:to:from: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=13EaFGhc9sBhjVtX9ZyJlLsTcSvLGmruzmbLxhBQiPU=; b=Jz6WPV977YbH7XKNxn+Q16nCvx/274LOfQkUZXsuMa2qZ1ghZ0WsM0H733hCgo2i7K SbqC2IMRECXofpqpZevAqcHpyCrwTcU41sLlHnfEkcNsY8GjzwGlGCFviF1UgXvRbSUO FuFIXklIrxaVY35bhSAOEkiON+/J78+xcqsBFwWJI56ZpJZ4v3YvJLCNrAItrLx/bg3F IpqU6Fr+Z7xkl2woh66RaHni69e+3gyqj+BDTssA2jiPr0qKgSEHXKS/14NQOup9HEi2 DHbtBEEHEaCyJm1Ch5wOgBOUEnwJx22BJgK2yBO3xng0QSjyM2EZF0cG3ghsj3NUuF8M qVxQ== X-Forwarded-Encrypted: i=1; AFNElJ/H0j17kF3lpvCJOtDf5MVvXs8bwjwl5SxuaTYxlysKzsa2Q6l4iXHu0AHQtHt6V5WS8FboL594AfogDaQ=@vger.kernel.org X-Gm-Message-State: AOJu0Yw+wXSIRB5W9P1HRE2/elqgvoZ7RGc7JaECaW2fLdhUo0D/Wx21 nKpGkfxOUt4JMonLbNMHtaCDnHYtwQbmLIzJ3mkeiZwk6sA1Di1kNApyKQnGOBEgUvY= X-Gm-Gg: Acq92OHXXWZYGUfTcBy7kWy4s+XK0A4uii/rcJtDQv7cA6mNHmSuNmzPr27QnUKUyeV lYjPEvDiuMosa4A/LgJBEiw6VUeiYRqp92+HZoQPX8JnIKexmd4hZ1v2UrAwnAh2K8C4/7CxGua p/zgs90/Njf+GkUIkqrKeqRRzChtbbRmqR97suFAOen8fAtjMh3x3Qq5FbmNPfGIBfJyEx1HziJ K/nlLQ+F3Ck4Ncj3jDYHkf/vSpGtDCBfsrpTD2IV1lhZRCehaaDxS8FX6QHG+XL87etmbwnvCyq vtoKbSZYJ69zmlY5+nNPL9PFZr/O+8sflkE7sx/Ccf/bs/sl+yb9FquMly0KnIwzysPEOsDeth/ Mf0OBqIVGjYM3/2AgLwa1en7brpkWj9Gxo/ebHdPCuuSMrcRp6pTShAH6Byu+CBur8NoX4Y0vo2 ZsvZ/6yppHmMcjsQLh/S09xxFXC4IukISA8g== X-Received: by 2002:a05:7022:f87:b0:12d:ce60:cb52 with SMTP id a92af1059eb24-1343677c21cmr4095334c88.18.1778732755696; Wed, 13 May 2026 21:25:55 -0700 (PDT) Received: from localhost ([50.145.100.174]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-134cbcb93f3sm2645323c88.3.2026.05.13.21.25.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 May 2026 21:25:55 -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: Wed, 13 May 2026 21:25:54 -0700 Message-Id: From: "Abdurrahman Hussain" To: "Guenter Roeck" , "Abdurrahman Hussain" , "Alexandru Tachici" Cc: , , "Alexandre Belloni" , "linux-rtc" , "Guenter Roeck" Subject: Re: [PATCH v3 4/5] hwmon: (pmbus/adm1266) replace probe-time RTC seed with rtc_class device X-Mailer: aerc 0.21.0 References: <20260512-adm1266-v3-0-a81a479b0bb0@nexthop.ai> <20260512-adm1266-v3-4-a81a479b0bb0@nexthop.ai> <045f1907-0180-46df-a123-cd0ce349e86b@roeck-us.net> In-Reply-To: <045f1907-0180-46df-a123-cd0ce349e86b@roeck-us.net> On Wed May 13, 2026 at 7:14 PM PDT, Guenter Roeck wrote: > On 5/12/26 11:56, Abdurrahman Hussain wrote: >> The driver currently writes the device's internal RTC at probe with >> ktime_get_seconds(), which returns CLOCK_MONOTONIC seconds since boot >> and is not a wall-clock value. The resulting timestamps embedded in >> blackbox records are therefore meaningless across reboots, defeating >> the cross-reboot record-correlation use case the field exists for. >>=20 >> Switching the seed to ktime_get_real_seconds() does not actually fix >> this: at probe the system wall clock may not yet have been set (no >> external RTC, no userspace NTP), and seeding unconditionally also >> clobbers whatever valid time the ADM1266 retained across a warm >> reboot. >>=20 >> The data sheet (Rev. D, p. 22) recommends "frequently send the time >> stamp to the ADM1266 to synchronize the UNIX time and reduce the time >> from drifting" when running on the internal oscillator. The clean way >> to expose that policy is an rtc_class device backed by SET_RTC, so >> that userspace tooling (hwclock, chrony, systemd-timesyncd) can drive >> the re-sync against /dev/rtcN once it trusts the system clock - with >> no driver-specific sysfs ABI. >>=20 >> Drop the probe-time seed and adm1266_set_rtc() entirely. Add an >> rtc_class device whose ->read_time and ->set_time callbacks read and >> write the SET_RTC frame. The rtc_class API is second-precision, so >> the SET_RTC fractional-seconds bytes are always written as zero. >>=20 > > This doesn't just set the RTC time, it also acts as a real-time-clock. > That seems undesirable, since it isn't really a real-time clock. > It would also be the first (pseudo) rtc residing outside the rtc > subsystem. > Agreed -- calling it an RTC overstates what the chip does. The register is a 32-bit seconds counter seeded via SET_RTC and stamped into each blackbox record. No battery, no alarm, nothing the RTC API normally implies; treating it as an rtc_class device was the wrong fit. > It seems to me that there must be a better solution. The rtc subsystem > needs to be involved in this discussion. > Would you prefer I drop anything RTC-shaped from this driver altogether and reach for something else (e.g. a read/write debugfs file under pmbus//, consistent with the other debugfs entries this series adds), or would you rather I post a separate thread to linux-rtc asking how a device like this should expose a host-driven seconds counter and wait on their guidance before respinning? The datasheet's intended use is for the host to frequently send the current timestamp to the chip, so the value stamped into each blackbox record reflects wall-clock time at the moment of the event. Either direction works for me; my mild preference is the debugfs path since it lets me close the loop without holding up the rest of the series. > Note - as sent separately - that making this driver dependent on > the RTC subsystem (as would be required by this patch) is unacceptable. > Understood -- I'll drop the rtc_class approach in v4 either way. Thanks for the quick feedback, Abdurrahman