Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1883502pxb; Mon, 22 Feb 2021 13:37:20 -0800 (PST) X-Google-Smtp-Source: ABdhPJyE1+vy9gyI0LzJRQkMptMMJSYNYk4FUy9cVmQRXis+ocGgwbJ3Lrk3xNteeA24j24n02qX X-Received: by 2002:a05:6402:190a:: with SMTP id e10mr24814710edz.110.1614029840145; Mon, 22 Feb 2021 13:37:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614029840; cv=none; d=google.com; s=arc-20160816; b=oLymXk/p/k4BuvM1LCStDqJUxNUvFqquj6eraEfFZshnBek0AInkXW5hD94kN5k78F nma9JRaEpda0EMMGu6SRA2W2yo1tz34nj2N7I9n91o1aTnRxFEelYeOKGAirF2H2NiMC KQjRtNZ/SB7C2KLMSaPXOOs8uqp2lH2ueMU+zje/W82seV1ggOXVAAcTej68s1CZAiYC jnaBxQsIu6JftBtu8jZMGLXpL/ZMrpIk+DUf7ljBRITm8bjur0d5hHAgQFYLVXfHu8ax 0qpQ9nDgk7Ln+urzM+v2cYZ3yCXJnUW9DKcn9ku1SYzqEXE0R/zpqE3TeS/1BeBd20VB JSaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=/OrPaEogd8RNApDeVWP5butx5Ch4Ll41voJVZfqddXs=; b=Q2sdGLpeHCJE2iO2sziUTfhGmjjZ+skpIbTQdtnYMfe24hq9Apz5AZDDl1eEUP0NQ8 OUyWRTrC7r/nFmKlfxP9UhAU1BvioSffQvgeyNuCsxnxqk58xGm+pKMJgAhwe3w1s2q5 USfsU3dPo22C4JWPu9odiemV43L6FlQHYLG3gVkXa5uDgfwkZ++oSLiScYH/MEjnZujP qaLUH21wh+gX0Pu9iq36hNqxUQFV0okeoGp8TEv5RtSTP1+RxXoR/SuFou32hGq9gVL7 7ByIiUbGNqRDVt53Pm/OabQnfXma6q2ItsLGdkGk9jorbvNpfk9n0Sv3wntZsufmoX9M IATg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r21si14095655ejo.415.2021.02.22.13.36.57; Mon, 22 Feb 2021 13:37:20 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231815AbhBVV11 (ORCPT + 99 others); Mon, 22 Feb 2021 16:27:27 -0500 Received: from relay6-d.mail.gandi.net ([217.70.183.198]:33165 "EHLO relay6-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231624AbhBVV1Z (ORCPT ); Mon, 22 Feb 2021 16:27:25 -0500 X-Originating-IP: 90.65.108.55 Received: from localhost (lfbn-lyo-1-1676-55.w90-65.abo.wanadoo.fr [90.65.108.55]) (Authenticated sender: alexandre.belloni@bootlin.com) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 2892AC0002; Mon, 22 Feb 2021 21:26:26 +0000 (UTC) Date: Mon, 22 Feb 2021 22:26:26 +0100 From: Alexandre Belloni To: Sebastian Reichel Cc: Philipp Zabel , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , NXP Linux Team , Rob Herring , Alessandro Zummo , David Airlie , Daniel Vetter , Miquel Raynal , devicetree@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-rtc@vger.kernel.org, linux-mtd@lists.infradead.org, kernel@collabora.com Subject: Re: [PATCHv1 1/6] rtc: m41t80: add support for protected clock Message-ID: References: <20210222171247.97609-1-sebastian.reichel@collabora.com> <20210222171247.97609-2-sebastian.reichel@collabora.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 22/02/2021 22:20:47+0100, Alexandre Belloni wrote: > On 22/02/2021 18:12:42+0100, Sebastian Reichel wrote: > > Congatec's QMX6 system on module (SoM) uses a m41t62 as RTC. The > > modules SQW clock output defaults to 32768 Hz. This behaviour is > > used to provide the i.MX6 CKIL clock. Once the RTC driver is probed, > > the clock is disabled and all i.MX6 functionality depending on > > the 32 KHz clock has undefined behaviour. On systems using hardware > > watchdog it seems to likely trigger a lot earlier than configured. > > > > The proper solution would be to describe this dependency in DT, > > but that will result in a deadlock. The kernel will see, that > > i.MX6 system clock needs the RTC clock and do probe deferral. > > But the i.MX6 I2C module never becomes usable without the i.MX6 > > CKIL clock and thus the RTC's clock will not be probed. So from > > the kernel's perspective this is a chicken-and-egg problem. > > > > Reading the previous paragraph, I was going to suggest describing the > dependency and wondering whether this would cause a circular dependency. > I guess this will keep being an issue for clocks on an I2C or SPI bus... > > > Technically everything is fine by not touching anything, since > > the RTC clock correctly enables the clock on reset (i.e. on > > battery backup power loss) and also the bootloader enables it > > in case a kernel without this support has been booted. > > > > The 'protected-clocks' property is already in use for some clocks > > that may not be touched because of firmware limitations and is > > described in Documentation/devicetree/bindings/clock/clock-bindings.txt. > > > > Signed-off-by: Sebastian Reichel > Acked-by: Alexandre Belloni Or maybe you expected me to apply the patch, how are the following patches dependent on this one? -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com