From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 841C3C4167B for ; Fri, 16 Dec 2022 04:03:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229554AbiLPEDK (ORCPT ); Thu, 15 Dec 2022 23:03:10 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36108 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229912AbiLPEDI (ORCPT ); Thu, 15 Dec 2022 23:03:08 -0500 Received: from phobos.denx.de (phobos.denx.de [IPv6:2a01:238:438b:c500:173d:9f52:ddab:ee01]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8B8E72647; Thu, 15 Dec 2022 20:03:06 -0800 (PST) Received: from [127.0.0.1] (p578adb1c.dip0.t-ipconnect.de [87.138.219.28]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: marex@denx.de) by phobos.denx.de (Postfix) with ESMTPSA id 1C97285370; Fri, 16 Dec 2022 05:03:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denx.de; s=phobos-20191101; t=1671163384; bh=Z66WSdoG13b/0o+zn9tABZQi0m18kq28921OI+7DrYA=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=J0K0CR3QIbDYni8VPLkERnEEvJ8pVhk0RkRLuA9xSoT5sqCDc8qRIvaGuIDTD+YzR N7z9AXHUXmVEKqb3Se05QizGCP1qdOPJWhU3y+wORsn3rzOHvdDIEXXlX/ybCJqh7F vwxcosnJk1YDIPEKBQW/zolGoB2X25nMD0dch489VFJIHdGjw79Q9SAeOniaztJiZh CCX1qKtz83Pe7sQNdvVe6oH8zz24x4EIIBrzzx0Pa/yMVGNj/FXbtRnidmWQSzrB0n Y6pVlhI/iWBJyyyjyp+xHjp9TFKxhq64hZdu1eVJREO6p413yuHomRua4VAV9jCXBh 4mfmj5iyriirQ== Message-ID: Date: Thu, 15 Dec 2022 20:39:47 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1 Subject: Re: [PATCH v3 2/2] dt-bindings: rtc: m41t80: Mark the clock: subnode as deprecated To: Sebastian Reichel Cc: devicetree@vger.kernel.org, Krzysztof Kozlowski , Alessandro Zummo , Alexandre Belloni , Rob Herring , Krzysztof Kozlowski , linux-rtc@vger.kernel.org References: <20221211205124.23823-1-marex@denx.de> <20221211205124.23823-2-marex@denx.de> <20221215180659.sa54lkinwxoiz7bb@mercury.elektranox.org> Content-Language: en-US From: Marek Vasut In-Reply-To: <20221215180659.sa54lkinwxoiz7bb@mercury.elektranox.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.103.6 at phobos.denx.de X-Virus-Status: Clean Precedence: bulk List-ID: X-Mailing-List: linux-rtc@vger.kernel.org On 12/15/22 19:06, Sebastian Reichel wrote: > Hi, Hi, > On Sun, Dec 11, 2022 at 09:51:24PM +0100, Marek Vasut wrote: >> The clock {} subnode seems like it is describing an always-on clock >> generated by the PMIC. This should rather be modeled by consumer of >> the clock taking phandle to the RTC node itself, since it already >> does have clock-cells and all. Since there are no users of the clock >> subnode in tree anyway, mark it as deprecated to avoid proliferation >> of this approach. >> >> Acked-by: Krzysztof Kozlowski >> Signed-off-by: Marek Vasut >> --- >> Cc: Alessandro Zummo >> Cc: Alexandre Belloni >> Cc: Rob Herring >> Cc: Krzysztof Kozlowski >> Cc: linux-rtc@vger.kernel.org >> To: devicetree@vger.kernel.org >> --- >> V2: - Add AB from Krzysztof >> V3: - No change >> --- > > I just noticed this by accident. Basically everything in the patch > description is wrong: > > 1. There is a in-tree user: arch/arm/boot/dts/imx6dl-qmx6.dtsi Sorry, I missed this one. > 2. The PMIC has nothing to do with this In [3] the commit message claims the PMIC supplies 32kHz clock to i.MX6 CKIL , which per IMX6DQRM rev.6 Table 18-3 row SNVS indirectly supplies SNVS RTC . This reminded me of commit: 9509593f327ac ("arm64: dts: imx8mm: Model PMIC to SNVS RTC clock path on Data Modul i.MX8M Mini eDM SBC") which solves exactly the same problem, system hangs when 32 kHz clock are stopped, except this time on i.MX8MM, clock are generated by PMIC on I2C (notice how the PMIC is referenced directly) and the clock are supplied to the SVNS RTC XTal terminals. I wonder if this could be reused on the QMX6 board too ? > 3. Directly referencing the RTC does not work, since that introduces > an unsolvable dependency loop on QMX6. This was the solution accepted > by Rob and Saravana: > > [v1] https://lore.kernel.org/lkml/20210222171247.97609-1-sebastian.reichel@collabora.com/ > [v2] https://lore.kernel.org/all/20210428222953.235280-1-sebastian.reichel@collabora.com/ [3] https://lore.kernel.org/linux-clk/20191108170135.9053-1-sebastian.reichel@collabora.com/