From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-f42.google.com (mail-ot1-f42.google.com [209.85.210.42]) (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 58C55377A9B for ; Fri, 7 Aug 2026 18:15:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786126505; cv=none; b=sxzjE6Z+Q2iVK8oGC4Neu9/ezbHfI08TcreGkPQG/3D4VIX199tzSvq63mkAZd6pd6AqNnkXimwUvGb4Z9YI3d8P8FmOixsMbv35jX6LJkyeglkyfnuvd8BJYn0dp1PNKxXhAVnzPKVpZ44eYyiUrWAxa6aMNx1pG6kmFWJD/+M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786126505; c=relaxed/simple; bh=s9tjNp6sYyYP4mCT3gXmsSd7L9AQpuVwD/wbCY/jEec=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=k2yRhB72F4zQAEd5SAivlO+uiH0AGKySEmNBweUXzNJkcp8cFWdhN/dzisFY7zEvd0Z4g1xRkZi3gsB0rD0kdD5P3KZTHDSKxjW4yzU7sTTZVrLlXMpXch8NblfORgz/QaTL4A3kz/Ez/44oeofLoahC9EzTWUak+esr8zXZIvw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com; spf=pass smtp.mailfrom=baylibre.com; dkim=pass (2048-bit key) header.d=baylibre.com header.i=@baylibre.com header.b=pYUZhPwS; arc=none smtp.client-ip=209.85.210.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=baylibre.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=baylibre.com header.i=@baylibre.com header.b="pYUZhPwS" Received: by mail-ot1-f42.google.com with SMTP id 46e09a7af769-7ee125ec926so2634068a34.2 for ; Fri, 07 Aug 2026 11:15:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre.com; s=google; t=1786126501; x=1786731301; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=O7m1ciHkvtKCbvcubLILJiqP/goECKk0dZZNr4piEjQ=; b=pYUZhPwSJxeO9WBfXuZFCy+XTWYeJFw2E4CTViQObxGkLsJFuvu2dPDqLak1ROGuz5 P38wMNPMXE2fPz1A5MjSSXe60c7iCLf8PaMyRmZ9p5wZhF7rYakZ92qa6LVEQ1ngj3Hm VAWwkcmHrQKzaDSDRGO4fo26pC+UiHaPvt2TEgEYuVwI+5tIjf1CbyFvNkqHVcAR+8at 57EAPGGpG4CnGeP74WdGT8CZM4REzccVR5ZCrjvcYDDlom6nlCaw8twffqBYr63P+iAv NSJ0En7H+0oKQi49EcP3Z/ukleylKQeHvEem6O3QZ4MnAl2snIkhhTYTXyfUiFwxLqK9 57Zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786126501; x=1786731301; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=O7m1ciHkvtKCbvcubLILJiqP/goECKk0dZZNr4piEjQ=; b=m3nv6iMU5uI2qJ2OAwpoey8qfhPviUD+FcF9oDK4XMemPAR6EwbvI+S4ek8vzTMtih /UBBbG+XwQtuaPDv/e+HG2q89Vm9XNoQFURLzhYocyQ9eL4JUjYK7F8d3i+uSijuMuW2 OpitU1eg5XaysAnKQkj0Lv02lQA4y9bJ8Qhm4uEbo4xDEYGDnp0b8B368Ce8VRgoBQUZ vqrJn4LmKXcpy64aJSJ/Fq0A92Gpn8025HBxhMHIw2U6GGa1A19O1xfrXgpsAfxxIcyo Foj6pl0+CSMK2BWCmHqxPkbotkGtNHSS7iM4ls1obYYI6r1oNOopG+WOcSOldXqjfvsy 2ibA== X-Forwarded-Encrypted: i=1; AHgh+RpIHMV+rsVJJyXRPzrk92ZBaYjF/DWMpodJFhEzOZq6LxWYKxdDwksYpVvygwcVgcTqZTCumJwo6zy72To=@vger.kernel.org X-Gm-Message-State: AOJu0Ywy181t/9n9bo7/CXN0gNgUgVH98NPuU43Sw4X8HbRcYvPh7d4l Z6VSHV3UARWMXw9iCvQWWwq6U6Fmr8lPhGg0SsG8cFrX7yMeUn7XhQcByoEf6ADe90RirbU8mC3 kNYgUJE4= X-Gm-Gg: AR+sD12XSMpan+FwEf9lMkp7ibiDA1Hb1GT6RbYAoJC9/pBes7VXwNne6977fsdQXJ6 Fap98QpE/xYPieAmZsGErw+aOAgm9uLin76tYP2IOG1kc978AEb8zdl09dbqzNS1LiE9RHzQCwf LRopc6NkCpLsQFlfvSguz8ceUwwRTbiJT92e0iInI6ay6e9VMARi8it2mlwYPnACTzymlXbfust 7oMSMwxVTzIdnanUPFY8I8fHryn46h9pkq4VG5paltXwLzum7vhQbjyVLO899MovIgYef4jmCp+ mi6AK0cW4XSS7BmSu0+/CYFdEDyhtwyl21Q/uUQOrCeR25boscaPinzEsgBfz+LelWg4JGykPUe yramQTR9DdakUJfrp/z8rLzT0UXTgXyzH4yfm65EIiIt0b0hJLk+chZCOyKNvVLE48UqBc8DwsT G17A6RlSvkC60hVIyBjObeJG1bnBKbP+KWRKO2IypYjTj7QKhVn2jbb+Of2DtZddtUIBpfZXEBy rs92qXH5/X/mxK8/mJuRVSM7YyPWPGbpPK1yr90n7H0V0dc X-Received: by 2002:a05:6830:6685:b0:7ec:2fe:1ec0 with SMTP id 46e09a7af769-7f1e5ce9482mr16883603a34.4.1786126500710; Fri, 07 Aug 2026 11:15:00 -0700 (PDT) Received: from ?IPV6:2600:8803:e7e4:500:b714:88c:313d:dee2? ([2600:8803:e7e4:500:b714:88c:313d:dee2]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-7f35b563978sm1826299a34.4.2026.08.07.11.14.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 07 Aug 2026 11:15:00 -0700 (PDT) Message-ID: <53ded669-6dec-4472-840c-91052b1afcb3@baylibre.com> Date: Fri, 7 Aug 2026 13:14:59 -0500 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 v4] dt-bindings: iio: proximity: move LIDAR-Lite out of trivial-devices To: Rodrigo Gobbi , jic23@kernel.org, nuno.sa@analog.com, andy@kernel.org, robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org, mranostay@gmail.com Cc: ~lkcamp/patches@lists.sr.ht, linux-iio@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kernel-mentees@lists.linux.dev References: <20260714215433.41259-1-rodrigo.gobbi.7@gmail.com> <7b8973fd-385d-4532-8213-bb0a811081ae@baylibre.com> <0ca14770-bb0c-4be7-a9b0-6e07d521550d@gmail.com> Content-Language: en-US From: David Lechner In-Reply-To: <0ca14770-bb0c-4be7-a9b0-6e07d521550d@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 8/7/26 12:10 PM, Rodrigo Gobbi wrote: > On 7/14/26 19:44, David Lechner wrote: >> >> interrupts: >> description: >> Mode control pin can be used as a status output to provide interrupt. >> maxItems: 1 >> >> Mode control pin can also be clock output, so we could add: >> >> '#clock-cells': >> const: 0 >> >> if: >> required: >> interrupts >> then: >> '#clock-cells': false >> >> I only checked Lidar Lite v3 docs, so we should see if these are available >> on v2 as well. > David, quick pushback on the #clock-cells suggestion: > > The oscillator-output mode, per the Garmin datasheet, page 8 reg 0x4 from [1], isn't really > meant to supply a clock for another device's logic. As I understand it, it exists so the host > can measure it against its own reference and compute a compensation factor for the device's > own distance readings, since the on-chip oscillator is only rated to ~1% accuracy. > > That seems like a different relationship than what #clock-cells models: a provider is > expected to report a rate that a consumer just uses to drive its own logic. Here it's the > opposite — the rate itself is what's untrustworthy and needs an external measurement, and > there's no consumer that would actually want to clock anything off of it. > > Given that, maybe it's better to just describe this rather than model it as a clock property, > or leave it out of the binding entirely for now until there's an actual consumer for it? My > point is more about whether #clock-cells is the right semantics for potential consumers here. Yes, this sounds like one of those cases where there isn't an obvious correct binding and we should leave it until there is an actual use case to make sure we get it right. > > Tks and regards. > > [1] https://static.garmin.com/pumac/LIDAR_Lite_v3_Operation_Manual_and_Technical_Specifications.pdf