From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f175.google.com (mail-pf1-f175.google.com [209.85.210.175]) (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 A88CD392C34 for ; Fri, 7 Aug 2026 17:10:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786122631; cv=none; b=YwAGYKu1l5Rb2ZZ1/3FUk+sVEYCzVIvHqccO3coip0KXcWzI64kUjmaf5COyLnIqlL+w8ybGh+eu6lTRIoosWqhsJokPWyPmnoLjR6PTXeWAo63uD2walJnJebcrqFzUPAX56gUKCnabjKWCQMzIUPWQ1Sr4rtM5YdWQlhP4MMA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786122631; c=relaxed/simple; bh=TmlLgISAnr4rRqg/Ayqw9Wq6LM6PY8bUYPc/LdR0qDM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=eBhJ5bcXaFIT7i6WbqSUOETshUcz0/vJtIRSrXjbFpz50TI4FDsWVHFNuHMkrMDfQ8KYr/jTh+Bx0/fsWflYG5S+2YjsH/vQDfA3+mGsPQzkfWyxGJrrDZ7NGhepOZdQZjSufLp0u6DJQTwc3Hj7K/3XnmcxACgLugVzu9buGH0= 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=G79Go3mp; arc=none smtp.client-ip=209.85.210.175 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="G79Go3mp" Received: by mail-pf1-f175.google.com with SMTP id d2e1a72fcca58-8485b358552so2938032b3a.2 for ; Fri, 07 Aug 2026 10:10:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786122629; x=1786727429; 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=mE3O02OMWkG+4I4n64q608gMiInuxyO9qbByZw9c+TU=; b=G79Go3mp0DSv2cduzO+AHcvddWtrIJPkbEnjr4lwKgV1S1GC+O3UIIgdgFRkJI359E RAMaq0780LhNtvUjJ9ocCTbs9ggrA9LdI7Tixb86DMHzFVAmBhLf3ljOdR6LBw053bQ9 8EPA6Y9KzCC3cbCqDJx1oUmf9dtjYWZWm2tlad6KhBhXO7J3tqjYuz/evGJmDgPZsuco imnIIhG+NTyCbmR9phPq59Whkut8j9UA2haB8W72lkVodO/VY4Yxg8RmArfi5PvW9TyS CnGLHntO9TAoTlA6PR2bfykOdGsohL8s5kPg4OWyQd3kQHHacHnolNBzZwCL3s/AylrU zFiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786122629; x=1786727429; 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=mE3O02OMWkG+4I4n64q608gMiInuxyO9qbByZw9c+TU=; b=N7tUQCdpg6YF/33neStN0a/zz0ZaE4f/ZoJXszKNflFzxSFzPci7Fd3RtDyechqxDh AJiS1ljy5MXEgDGn7ocSKp5NNTOKIf6oBRFmhmIoPa21VgrVw66antr4fzIUwjsQ8M5R eML+d3QHtH9RImVCiCGPvgWH7RHQUFhwuxEJLQvGjrA9RTce+jFgiri/WNxbfVVI0iMN /BI7aldY8AY2w5hrGws/QI4Co2FB/3rRKLf0J5MfFeJk82ldhqDX2fbiLd/VRRE5vLbL vWmyBaptWcVFJr324OZ1412AobsH7VdaEN5GhhlU75nHM2kdvStrF43+mz8/28ChbpQK 285A== X-Forwarded-Encrypted: i=1; AHgh+RpN5gQTxBa0gFkH39mI4BYqNHS8EfQcQRfqXN/IQ6jXE48LrZWJgvdsLs9nfOe2gPv58AEm+IPR3mdXGL8=@vger.kernel.org X-Gm-Message-State: AOJu0YxQdehSDZvvNzKxp83KHlbbVUgdd/BmvKazWC8JU7IDxnuwFam+ mXpJIVQxiElVuRzNeXvN+Yzv097OcFS6CAb3YaXwGNYqDcP7CqTqoqKY X-Gm-Gg: AR+sD10sxOK891YWXvnrVfCABMeH27ZuXyarv1k9E/ZE2a+RwGaeb1PdaBqXAa4Jg5+ 0YZwyPE/CzWZtEkvsBGL4GQ9OqunNHMPTccwTimwIN9Uvyxy7MlPX6Ta2AXJ4hutDSTC57pc+sS D6FpTEutSf+d+cVqlqM0l0+dddD1rdSyGp853Ozcev/eWMWb3AHVm64kJgMcgQAcyJWxGFHe8Kq Aa3v+dnEX/P1jpGYyq7fH73N2pEKZIK1p8StOgTxk3Kfnsjwd2n8hmnXwujkFmNaIKK0v7la0Zv g6SoRQ7tlVViXRiBg891jyoG5xP+5HDUOs/KKlt8meLmd6238Wk4at7rUawMhWbn/HAUtqnUNee SO5eVvAiyxk7W/dKslVY/FaMpJ2qPtsl90J4w8cO1iSn4TYhhcZnZCHjR5pLENNkxrVFz0NfI4S 2KmWM5Mb8eZJYtTKsaq03PBVdlT2GPrJRLSQ8Ji9HSpP4Qs/ts7HHwP8gSblum79K0cidt7EMxH jpK20e6FoUal83A4KHM1yp8jyy8BOYFH/QQdEwq5bYxdRR3Rz7DKbGbW8+Yaf13pkVLW2j4xnv3 4fN/UnU= X-Received: by 2002:a05:6a00:399e:b0:848:4d1a:9556 with SMTP id d2e1a72fcca58-84f2dfd0a11mr24731599b3a.11.1786122627490; Fri, 07 Aug 2026 10:10:27 -0700 (PDT) Received: from ?IPV6:2804:14d:4c64:82a2:a0d:ceb5:202f:6629? ([2804:14d:4c64:82a2:a0d:ceb5:202f:6629]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-84f5a58d82asm1346996b3a.57.2026.08.07.10.10.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 07 Aug 2026 10:10:27 -0700 (PDT) Message-ID: <0ca14770-bb0c-4be7-a9b0-6e07d521550d@gmail.com> Date: Fri, 7 Aug 2026 14:10:21 -0300 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: David Lechner , 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> Content-Language: en-US From: Rodrigo Gobbi In-Reply-To: <7b8973fd-385d-4532-8213-bb0a811081ae@baylibre.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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. Tks and regards. [1] https://static.garmin.com/pumac/LIDAR_Lite_v3_Operation_Manual_and_Technical_Specifications.pdf