From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) (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 5619D1F5858 for ; Sat, 28 Mar 2026 02:58:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774666738; cv=none; b=gA1ijEyeGzBR1b+xt1KcI5MCMtO43Rvfn7R6ooxIv6ja/ujZlJooxS1caiyQRbSUT3EgFGakV4DgBXTXyXgjb1kxIjjjzgFBw9Yl5N0NhPvbp4qRTZEDYxpiPLTQ5YeQtP1hpZuMAdZdxnijwxeZDRD11Nd6KM2An7GyG8NCJaw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774666738; c=relaxed/simple; bh=olwM+iFW1baLC0frxkhwsk/23pWJgNDyvNMv4ihorwY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=lTHDeCDAFwUTPN50RmRH75KQLBuUddmBv6lUFMKdxQiggCcTSElyclMqn1aLMYOpmX7IeBaZeWMxYLSa3x9mT90QWGMwqpcHoPDtsSzgJdfc4geJNN95zXIEN6pLBFd7rr6HjDgZ1GEJqcXlwiKF4BC9w3OrfF4I2/rJ1sIjCAM= 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=eWJwcpPN; arc=none smtp.client-ip=209.85.221.54 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="eWJwcpPN" Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-439b6d9c981so1719480f8f.1 for ; Fri, 27 Mar 2026 19:58:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774666735; x=1775271535; darn=vger.kernel.org; h=content-transfer-encoding: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; bh=aItUBK61tk6fxXXaFLwlpx4OpsBWZ3pyf1T32wUZFWY=; b=eWJwcpPNWfOLODHUnlNpHde+OXK1Qx0BoC1oMkvd28TCJhqbFUYAbH/b1IuiqC8ANu cV+9HqKZVwZwCzMzDC6L34cY++7p0ZK1wqk+rX6uYLM4EtVpAB9Bnfybnx4MxGIx4SwX xeHBTyCUxkzsMlJWy9xdSP8JmgQ0GRdtj9VJIT3evGaNkKeTixS66DOuGVB56ztk6Rl4 JJ8lWZOgNxpV/Js8NhikTxYGZWY5dlAZqrjH238Gg5jI21Wvg7ovFNEbDvkB5ayWG3Zy zPwUoznKlw7WQGn9JK0zaSTPxl+Ly/C/YnLVi/1xkTf9m3nUqA8HGwii1giekuWYMcgN p5hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774666735; x=1775271535; h=content-transfer-encoding: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; bh=aItUBK61tk6fxXXaFLwlpx4OpsBWZ3pyf1T32wUZFWY=; b=Oun3Rj33+7KWtVXHQwLkKbpKMfu6AgSkQjnCHyhj1ufOV22BdRDfXNua8Par7MFahm t+rQ70tMCKyw/Ss7oeoJIdjkcCfADY9iRIwlce/Imm9VeoEi8KyAxUSJZdTUSkRuxgSU TQPz8PL+EQk3U4IiXvQXtlzJ+9VQNt4R76SvHLhjrZNKpUJHQr0LocnKGGxlKCyJPHve dYWwbMV3KAsxUyD2zjiZpOoq99D7o7Xa351uEOodan2nLP970/L068Jf+jn1Y4Xzqiq+ zVxBhspSGBHcXMbsU/Z6HgvTuLqKHsC1vk0QPeeNGcUXLb6qvfYGxlQpha/nEgv78bzb bWRQ== X-Forwarded-Encrypted: i=1; AJvYcCXkqC/yTYuVeUb9NTsocRvERN1ej9hVC7QwlgWxvw5L1147UEE5i2WDdWSmu7K7rBLKXnMEXrOvdsGpc+Q=@vger.kernel.org X-Gm-Message-State: AOJu0YyNPFQ8Yvb/Zzul9IiBLXXc9o5iRAoMy5n2Gf7Xxoh/ij9q0bZI w/7/eAweDYdbMogH1bfrLN2ygcuQAjX3W35VxNzpO1xfY/GuKQFpjCvw X-Gm-Gg: ATEYQzx0BP2Egyxn8OTwUWdD2jwmCUiHYbXlQchYt1pKG9BpSgZ85n0A4G92XbdeR/Q 89SfWlpmTuEdHbpzG33sP5U0AJ+dABpKbUmUW+QeuIJBxw9kmmh4d+xFQ8EB8+pQ65J49QDljX1 y5u2N+yqHIb9y44z54GJR7fPHiJv0IxUxgR7V0bYvgsa2cXSoa5OfmkKcyUmRw1mhFKDl4ITBpy /URSAsp9N1txUCaQQUB1hxTMqDlvBfo1xxLXmtETsC+TgSDgv4ntJaygwoAgpp8YZ+9csWlwF4z trF0RYVidEVW8JRoReaJ6l4TrqM4CoLaNhDulwqqaxhP7KlV8aPMfYbeJ+VDjRyILgtzIOUHXkK n80eL5lMq53Lr4mCmB4Ra9deoZ68Jc5BAsuUIN4qkBsAcvMX07xKyrYuerDdw8ZBIUquVCoPYcH sG+u+A4c7I8JMEZrlWEYiUdaN3fJQqAmi0fuQ4OwPInixOvRe9 X-Received: by 2002:a05:6000:240d:b0:439:bb46:7457 with SMTP id ffacd0b85a97d-43b97a4b813mr13247505f8f.16.1774666734587; Fri, 27 Mar 2026 19:58:54 -0700 (PDT) Received: from [10.34.37.37] ([185.25.49.104]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43cf245e4f5sm2316659f8f.19.2026.03.27.19.58.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 27 Mar 2026 19:58:53 -0700 (PDT) Message-ID: <8129d377-8a63-4589-820b-930a2b43a2f7@gmail.com> Date: Sat, 28 Mar 2026 03:58:47 +0100 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 2/2] dt-bindings: Add clock guard DT description To: Conor Dooley Cc: Krzysztof Kozlowski , Rob Herring , Vyacheslav Yurkov , Michael Turquette , Stephen Boyd , Krzysztof Kozlowski , Conor Dooley , linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org, devicetree@vger.kernel.org References: <20260318-feature-clock-guard-v1-0-6137cb4084b7@bruker.com> <20260318-feature-clock-guard-v1-2-6137cb4084b7@bruker.com> <20260318225510.GA639444-robh@kernel.org> <7c7034a7-686a-42c2-bdba-6f31b5179f7c@gmail.com> <20260319-yearly-wrongful-883f7fd86a69@spud> <20260323-sanctuary-semantic-432089feb1c7@spud> <8e7d0c53-aa23-4514-81a5-335a76bb0c45@kernel.org> <4d575f17-5cd5-495c-99a9-176b3393d54d@gmail.com> <20260326-nursery-outer-55799f675e14@spud> Content-Language: en-US From: Vyacheslav Yurkov In-Reply-To: <20260326-nursery-outer-55799f675e14@spud> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 26.03.2026 19:32, Conor Dooley wrote: >> I was not sure how to provide a diagram in the mailing list, so I posted in >> on Github https://github.com/OSS-Keepers/clock-controller-guard/issues/1 >> >> It is a driver which models dependencies for other drivers. These are soft >> or "indirect" dependencies, because we cannot access the FPGA unless the >> FPGA_PLL_locked, and GPIO is telling us we are good to go. >> >> Conor, I think this should answer your question as well. > > Not really, but it gets part of the way there. I want to know what this > provider actually is. I now know it is a PLL, not an off-chip > oscillator, but I know nothing about the interface that you have to it > (or if you have one at all). What compatible string/kernel driver does > it use? > > Because SoC-FPGAs can route GPIOs from the SoC part to the FPGA fabric > and use them as if interacting with something off-chip, I'm not sure if > we are dealing with an separate FPGA or a SoC-FPGA. Which is it? > Effectively I want to understand why you cannot just read the lock bit > from the PLL directly. In my experience with *SoC*-FPGAs, things like > PLLs that must lock for the fabric to be usable have a register > interface from which the lock bit can be read, that is of course not > clocked by the PLL output clock and therefore accessible before the > PLL has locked. > > I think more info is needed here to guide you on where such a "helper > driver" should be located and what the dt represetation should be. I really appreciate your feedback on this. Here's an attempt to provide a better exlanation. We have various use cases. Most of the time it's a PLL in the FPGA but it can also be some signal from a custom FPGA IP used to indicate if some preconditions are met and the IP is ready to be used (some kind of inverted reset but exposed by the IP). For a PLL we typically get the signal connected either to a GPIO IP block (altr,pio-1.0) OR to a bit in a custom IP register. In addition, some of the IPs in our design do not have a proper split between registers and IP core, which means that if an external clock and/or PLL lock is missing and we access the registers we won’t ever get an answer and thus stall the CPU. We are using a SoC-FPGA and use some GPIO IP within the FPGA (altr,pio-1.0 for example). The PLL itself doesn't have any registers but the signal indicating that it is locked is available and routed to such a GPIO. The point is that we will have several IPs/drivers that will depend on the same preconditions (clk, gpios being high or low) and we want to use this clk_guard driver as an aggregator for those pre-conditions. Define once, reuse a lot. Slava