From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f174.google.com (mail-pg1-f174.google.com [209.85.215.174]) (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 AECD63BED16 for ; Thu, 26 Mar 2026 09:54:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774518901; cv=none; b=c2j8U6zhwQeRi3FtmKgw8r9D6EYDZxtCIuT215sw55uhwWLfCE7gntm4GMM2cqTcc7GwZ6mYNULqL/jpugdPVAHxtRY5eQlDBkWw/EkQs/4vDVWuJwQoDCe83LJy5+K6G6OaIrNdQs0+wlXkNLB8XXJiLipUO5AxTnEEXGRnWmA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774518901; c=relaxed/simple; bh=PSzU7MOsYUD4Qy7QhpTSQYID0f1netpe1FImIG4kv5E=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=icbMgI1zciGoWAbVEdbviHGsWkdAPcLm6++BFO/k8wGr0zUNnSRjZbhGr22yPNMxxH9ZxsmZynGMyaspkx3cHiDzZ4DafMYIvP4fatPHbKSJ4sYQhZfFq/lwEqEkLs6VaLGGQ6NrcQBein2oZuweiLbtAEhGbYX1mDjmvxF+dwg= 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=du8Sf7qm; arc=none smtp.client-ip=209.85.215.174 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="du8Sf7qm" Received: by mail-pg1-f174.google.com with SMTP id 41be03b00d2f7-c739d32b72cso541540a12.2 for ; Thu, 26 Mar 2026 02:54:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774518899; x=1775123699; 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=v5o9Le9atm4Dc+3pXSi3olgqfG741JnzAoIdgFKRmYM=; b=du8Sf7qm083RkdmQGtuv+Ne0VdgG9dgxIweCFy/tfZQd209n9Yg5CwPGqKweFYSevA fWFAjggS6lyzZYWW+sbNM27f5lSuxv+9BJDiz9chlIkYgFOpRf0srBDaZfnFboZQVrPF c00p/OnuEqRYr7CeL+SOPfHkQX3NVpk3B9189n9hvGebgQaz9HXbW8/3msTkz7nk0sh8 Mx/MPU/Z8VXQEXo/MjBasO1OfV2BXzoOzvi8bX+yTL4RF4dGvHL93oSnH9gXa2dJAInb zXXJvSj6R198xVySeE/Quj8tGXOnDC1BTR4teB20GiMWYzIR0My32CeCG0ymXfAkiUwb eoIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774518899; x=1775123699; 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=v5o9Le9atm4Dc+3pXSi3olgqfG741JnzAoIdgFKRmYM=; b=q4KDtzN97oUPoAx+8+b6ugljCVOsCM1zvLIM5I+mFuCXuNZc4G6Cz0gjFqEnp2QWS4 MzN1cFwPch1skIt0Wd5JP7lJF24dkEIZjOH+KLXrTrijVX2bgYw1ctT887RQF6TL9g49 BUA2trpjSR6iHU03ylNWsl1g558Rdunxf5wqiu8YhyRSvqlIht+0f6wxeHSfgQiNAE2U 9XC/BvqLVHwfyYvxWWswVnXsQRiHpAdw/5+HtjllN9QcglkJymZrrBF2FICerzlOs6Ig w5qJsaL2C50Uyv9m0aXSe05ptNGWRumLJDIBtvxBjvQ5Qi66bT1UYhXC34iezlH6/J9u pj6w== X-Forwarded-Encrypted: i=1; AJvYcCX9t77x4RXlbmAT4++6L4PosSq9wPHjJOVyh4fTRMjmw6l5sAJTneKHp02KxLhZVj0i2HGw8c+sgLndM5c=@vger.kernel.org X-Gm-Message-State: AOJu0Yx2HiLVoG5yFTDaelsc2ceWzURX+IAKFA3TDni+Rqy02P2vcbkL p/TcWU7O6JPYD935PIp6kXEOLmUEyCqlyJcnP8qriFmBSh0Ep4hKZ2df X-Gm-Gg: ATEYQzyN8nfGz1ak9RF5wtKJHgYHazoyYwpI1208afMRmZPhwkVBXH2m9CjxhA+WsJs JxhBxOJIiwfQ6c8952lf1lfNqBsDfusV+iwCo2xhgLMSuNh2qbQG7CWt4ve3bCBkYJj0jpvtjEG F/DuoEnJZvzg/TJ00UGADRvyAdrorMXv5chk06ZTGK4nj3GMh+NmVG+iDDbuxxy1rJrRgi5+IDQ BvNso78bCVCrmgi2RiXoZNrz7uBh/gNFLv9zuozmG1k2H8IOHtH5sKCoihD5g0J4t2Zi5op/Zqk 3Z8IXFoX1WWMs42X71mjxWO0DGr4u890fTrT3Lrpwxu+cKfiuxoHkChsIVb3oNOuhkhFK4WOBFw 1ve03qytrCiJXbsQzYmB3SZAdWtuB0z5vA9+2vzTCxA/ZXFMyTCTrE2ioxnwStX5BPMTi6CZxuE CLM1TcKX1TCR5mF/8r2H3Y1QhY7jckWG2Ghvqsfbdps2qF3wERwA== X-Received: by 2002:a17:903:3c25:b0:2b0:58a8:5f9b with SMTP id d9443c01a7336-2b0b0b45ffcmr84290365ad.49.1774518899022; Thu, 26 Mar 2026 02:54:59 -0700 (PDT) Received: from [10.55.231.75] ([129.227.3.137]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2b0bc7a17c5sm29542245ad.26.2026.03.26.02.54.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 26 Mar 2026 02:54:58 -0700 (PDT) Message-ID: Date: Thu, 26 Mar 2026 10:54:52 +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: 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> Content-Language: en-US From: Vyacheslav Yurkov In-Reply-To: <20260323-sanctuary-semantic-432089feb1c7@spud> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 23.03.2026 21:14, Conor Dooley wrote: > > The binding you've got says "GPIOs used to control or guard the clocks", > which is not what you're saying that is going on in this mail. A more > suitable description would be "GPIOs used to check the status of the > clocks". Agree, the description I provided is not very accurate. > I want to see an example dts user for this please. DTS example: clock_guard: clock_controller_guard { compatible = "clock-controller-guard"; #clock-cells = <1>; clocks = <&h2f_clk 0>, <&clk_fgpa_rx 0>, ; clock-names = "h2f_clk0", "clk_fpga_rx", "clk_fpga_tx"; gpios = <&fpga_ip 0 GPIO_ACTIVE_HIGH>, <&fpga_ip 1 GPIO_ACTIVE_HIGH>; gpio-names = "gpio-input0", "gpio-input1"; clock-output-names = "clkctrl-guard"; }; custom_device { compatible = "..."; ... #clock-cells = <1>; clocks = <&clock_guard 0>; clock-names = "clock-guard"; }; The driver usage exaple: clk = devm_clk_get(dev, "clock-guard"); if (IS_ERR(clk)) return dev_err_probe(dev, PTR_ERR(clk), "failed to get clock\n"); ret = clk_prepare_enable(clk); if (ret) { dev_warn(dev, "Clock is not ready, %d\n", ret); return -EPROBE_DEFER; } > TBH, I don't understand your driver implementation either and why it has > > +static const struct clk_ops clkctrl_guard_ops = { > > + .enable = clkctrl_guard_enable, > + .disable = clkctrl_guard_disable, > + .prepare = clkctrl_guard_prepare, > + .unprepare = clkctrl_guard_unprepare, > + .is_prepared = clkctrl_guard_is_prepared, > > any of these 4 implemented when you have no control over the clock. > I didn't think it was required to call your parent clocks enables in > your own enable either, thought that was handled by the core recursively > calling clk_enable() on clk->parent. The one thing I would expect you to > have implemented ops wise is is_enabled, which you don't have. > Also no sign of any rate acquisition functions, which I thought were > mandatory. > > + .get_parent = clkctrl_guard_get_parent, > +}; Good point on .is_enabled, I indeed missed that. As for the rate acquisition functions I referred to this table https://docs.kernel.org/driver-api/clk.html#id4 , and it see that .set_rate is actually optional.