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 phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id ACB67C433EF for ; Wed, 5 Jan 2022 20:57:48 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 5E77783762; Wed, 5 Jan 2022 21:57:46 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=konsulko.com header.i=@konsulko.com header.b="iDuBTY17"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id BF7AD83762; Wed, 5 Jan 2022 21:57:44 +0100 (CET) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 93CDD83681 for ; Wed, 5 Jan 2022 21:57:39 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qk1-x72f.google.com with SMTP id r139so654068qke.9 for ; Wed, 05 Jan 2022 12:57:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=fO4m/LJ21dNLlZlZk1+dOhd0x2z3KaZlMZQpDaz20G0=; b=iDuBTY17Mp+ccQmZUF8NOJYf7Nf81dXqpjmiqF3XToSdfiHvIK0HSIy8jhA0tuLyhF kl4Zk4Jmco2DyVQ3+zwvJGi13CKJ7u6LCuSKynhdz4T1tM7JMpd8qFuCYkrnmsIqXUPR 6dZPaeG/8U+q1afrcEMnpvgsHEd/JOoa1omZg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=fO4m/LJ21dNLlZlZk1+dOhd0x2z3KaZlMZQpDaz20G0=; b=1B/dITeViz/78IRFBBL6AyvrjPrJN+Itjnx/jX/4GOwxSROkwL5Ct7cSyRpdWiO1BE p97/W71b7It8XXZzfNyOlKTln3XveUfiFofLvlD1wtNBfUQyp8I9M0T9s8W5Z4YBDYQe y4bL7I4h++JnDmiPgyKAdEH8nTU+aHy1NcUWAkWwkyDsxaLH/yF9GiUchmfHW/yJjSjP 8H4bOOk9uFJhALbL4VQ0giik4Pz+RJKSvLdSw8/7pDRGTDkdbhv71wpEYvGUIa0JZRlN P484TuxsgpwSxRSuo/zBHCbKwpbn8jy/XoOjIxd0a45LWGhKaN13C9otA9wGDhp7i2jS o3jQ== X-Gm-Message-State: AOAM531efeKt2EEmVccrZkS4MGI+X4BodOhfKgzjfxtHl2vPO814TYF1 x2dkSAvIIQUOI+DDFtqr0T5Pgg== X-Google-Smtp-Source: ABdhPJy4RINDqAoRSRfuUoJYAY3wWb76cBfhC8juxu0g5HNfCwWO+LXv2LV0Xmmyorjk6/+KwtUgbQ== X-Received: by 2002:a05:620a:4450:: with SMTP id w16mr2344957qkp.189.1641416258255; Wed, 05 Jan 2022 12:57:38 -0800 (PST) Received: from bill-the-cat (2603-6081-7b01-cbda-8841-a9f4-ab99-2748.res6.spectrum.com. [2603:6081:7b01:cbda:8841:a9f4:ab99:2748]) by smtp.gmail.com with ESMTPSA id z4sm36268617qtj.42.2022.01.05.12.57.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Jan 2022 12:57:37 -0800 (PST) Date: Wed, 5 Jan 2022 15:57:35 -0500 From: Tom Rini To: Marek Vasut Cc: Sean Anderson , u-boot@lists.denx.de, Peng Fan , Simon Glass , Mark Kettenis , lukma@denx.de Subject: Re: [PATCH] Revert "clk: Detect failure to set defaults" Message-ID: <20220105205735.GD2773246@bill-the-cat> References: <20220101185139.470786-1-marex@denx.de> <20220105193708.GC2773246@bill-the-cat> <8eeb3c16-10ef-2f06-b211-f34ea7e890ac@denx.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="W+nSBPrhyZdnT2dj" Content-Disposition: inline In-Reply-To: <8eeb3c16-10ef-2f06-b211-f34ea7e890ac@denx.de> X-Clacks-Overhead: GNU Terry Pratchett X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.38 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean --W+nSBPrhyZdnT2dj Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 05, 2022 at 08:56:50PM +0100, Marek Vasut wrote: > On 1/5/22 20:37, Tom Rini wrote: > > On Wed, Jan 05, 2022 at 08:35:19PM +0100, Marek Vasut wrote: > > > On 1/1/22 22:41, Sean Anderson wrote: > > > > Hi Marek, > > >=20 > > > Hi, > > >=20 > > > > Please CC clock maintainers for future patches. > > >=20 > > > btw. I'm surprised the commit 92f1e9a4b31c0bf0f4f61ab823a6a8865732364= 6 has > > > zero reviews/acks from clock maintainers. > > >=20 > > > > On 1/1/22 1:51 PM, Marek Vasut wrote: > > > > > This reverts commit 92f1e9a4b31c0bf0f4f61ab823a6a88657323646. > > > > > The aforementioned patch causes massive breakage on all platforms= which > > > > > have 'assigned-clock' DT property in their DT which references an= y clock > > > > > that are not supported by the platform clock driver. That can eas= ily > > > > > happen either in SPL, or because the clock driver is reduced. Cur= rently > > > > > it seems all iMX8M are affected and fail to boot altogether. > > > > >=20 > > > > > Signed-off-by: Marek Vasut > > > > > Cc: Peng Fan > > > > > Cc: Simon Glass > > > > > --- > > > > > =A0 drivers/clk/clk-uclass.c | 6 +----- > > > > > =A0 1 file changed, 1 insertion(+), 5 deletions(-) > > > > >=20 > > > > > diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c > > > > > index f2d26427543..094b1abf13c 100644 > > > > > --- a/drivers/clk/clk-uclass.c > > > > > +++ b/drivers/clk/clk-uclass.c > > > > > @@ -846,17 +846,13 @@ void devm_clk_put(struct udevice *dev, stru= ct > > > > > clk *clk) > > > > > =A0 int clk_uclass_post_probe(struct udevice *dev) > > > > > =A0 { > > > > > -=A0=A0=A0 int ret; > > > > > - > > > > > =A0=A0=A0=A0=A0 /* > > > > > =A0=A0=A0=A0=A0=A0 * when a clock provider is probed. Call clk_s= et_defaults() > > > > > =A0=A0=A0=A0=A0=A0 * also after the device is probed. This takes= care of cases > > > > > =A0=A0=A0=A0=A0=A0 * where the DT is used to setup default paren= ts and rates > > > > > =A0=A0=A0=A0=A0=A0 * using assigned-clocks > > > > > =A0=A0=A0=A0=A0=A0 */ > > > > > -=A0=A0=A0 ret =3D clk_set_defaults(dev, CLK_DEFAULTS_POST); > > > > > -=A0=A0=A0 if (ret) > > > > > -=A0=A0=A0=A0=A0=A0=A0 return log_ret(ret); > > > > > +=A0=A0=A0 clk_set_defaults(dev, CLK_DEFAULTS_POST); > > > > > =A0=A0=A0=A0=A0 return 0; > > > > > =A0 } > > > > >=20 > > > >=20 > > > > See [1] for previous discussion. For more background, > > > >=20 > > > > - Device trees for i.MX are sync'd with Linux. > > > > - General clock assignments may live in the clock-controller node, > > >=20 > > > clock assignments can be anywhere, even in non-clock-controller nodes. > > >=20 > > > > =A0 including those which U-Boot does not implement, but which Li= nux does. > > > > =A0 It's OK to not set up these clocks, but U-Boot doesn't know t= hat and > > > > =A0 fails. > > > >=20 > > > > We don't necessarily need to revert this commit, but we do need a w= ay to > > > > say "it's OK not to set the defaults, since we can function without > > > > them". Tom suggested doing this in the clock driver last time. I th= ink a > > > > Kconfig or a device tree property would work, perhaps something like > > > > 'u-boot,clock-defaults-optional'. > > >=20 > > > We didn't need custom DT properties before, Linux doesn't need them e= ither, > > > so that approach seems wrong. > > >=20 > > > If the clock driver could say "skip unimplemented clock, because I do= n't > > > implement them and that is OK", that sounds like the right approach. > > >=20 > > > Unless the 2022.01 release should be completely broken for a lot of > > > platforms, I would propose we revert the clock uclass patch now and r= e-add > > > it right after the release, so we would not roll out a completely bro= ken > > > release and would have more time to fix this properly. > >=20 > > It'll be no more broken than v2021.10 was for whatever platforms have > > problems here, yes? Since that's what has the problematic commit. >=20 > So it seems. Does that mean we are OK with releasing such a broken releas= e, > even though there is an easy way to improve the situation ? I will defer to the clock maintainer who I see agrees with your patch. I was just noting that we'd already shipped one release so a last minute revert is not something I'm happy about either. --=20 Tom --W+nSBPrhyZdnT2dj Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmHWBjwACgkQFHw5/5Y0 tyxtiQv+NCYCho7DlnGBa+KnCYoLkNMON2QJQuqa0CMYlnxt8vv/1yM5cXR06J2z hk4XkSmS9YECIjL3PY6WV03xRSTVsoRC9eyWJorGwsGkHnDWL9ByvihzW7/9YQxD C6JQyMEtoOKjdRWVu6CikbOn99j63qO6SUH5NQWLERfJIGyc2KXqiOeNt29e+LUT XBhhfkMq48piQuvKFgmzzkAbI9CnEw5IS2iLPhoijOKq2eYunueJUB4tAHm0Fl6p PSMinWRtZA1X4WUtgLTbeTjlgE4hUzuasxLnrTqf3WXBbTO5VsxP1cFDVYf2oNo8 RU126IOkdA0aruuBLNo3hNfOtwJtIVqyShLhm+EBHz6eURFdADs8QnscIcf7EbTK UWTNx+PsBQtrOkehUNwkBtv0W1gZvCKOu09sehM/mCgxVRYToJt6CeeK9l0g9ZgB w0eDX0TZpxsMJSdpYKag9r6ih2kHmgeD+6bfhgIGbWmmuEij06kIO6qO63EMyMom CVbzUJkP =MciA -----END PGP SIGNATURE----- --W+nSBPrhyZdnT2dj--