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 X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 34960C4646C for ; Tue, 25 Jun 2019 01:17:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 05B9B20663 for ; Tue, 25 Jun 2019 01:17:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1561425433; bh=+hj47sTwmKBDJvyyLIh4W4IbUA1BkBMWX0D6j641nnw=; h=In-Reply-To:References:To:From:Subject:Cc:Date:List-ID:From; b=Q9gSvQx375dgVoPuf7/3qxn6jbo6cdHFLDTk/S8txehexSVv0JqSluUw2cpZQbuWH 9nOBUj413AirMrggZueCMPBzqyM5VMw6MJcvOVlhNLPnNMYzrv10s0BTMLjer9L3T5 f2XXlTmhdmXOnekvR++6eH5THua2GCqHjqYBmnAY= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728244AbfFYBRM (ORCPT ); Mon, 24 Jun 2019 21:17:12 -0400 Received: from mail.kernel.org ([198.145.29.99]:39756 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725784AbfFYBRM (ORCPT ); Mon, 24 Jun 2019 21:17:12 -0400 Received: from kernel.org (unknown [104.132.0.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 3D2D520663; Tue, 25 Jun 2019 01:17:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1561425431; bh=+hj47sTwmKBDJvyyLIh4W4IbUA1BkBMWX0D6j641nnw=; h=In-Reply-To:References:To:From:Subject:Cc:Date:From; b=OsfmJE8eR++j21vrxJwqy17Yga503MPRPpcQWmjPZI5IAx3z0bk4Ok6+BGvKbjfh5 FTuP81eFgtILbUCGGQiQIb75faVHb0xeUMAht3h9wKbaqfULEZE1MzHcjbMeKUrf2Y ugeu7xYL2CDnBPEFufZFHyCRi9jv9g2nFIfoLTQo= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: <1deb7a85-0859-54f1-950a-33de3a08f9fd@ti.com> References: <1deb7a85-0859-54f1-950a-33de3a08f9fd@ti.com> To: Michael Turquette , Santosh Shilimkar , Tero Kristo , linux-clk From: Stephen Boyd Subject: Re: [GIT PULL] clk: keystone: changes for 5.3 v2 Cc: "linux-arm-kernel@lists.infradead.org" User-Agent: alot/0.8.1 Date: Mon, 24 Jun 2019 18:17:10 -0700 Message-Id: <20190625011711.3D2D520663@mail.kernel.org> Sender: linux-clk-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-clk@vger.kernel.org Quoting Tero Kristo (2019-06-12 04:56:15) > Hi Stephen, Mike, Santosh, >=20 > Here's a 2nd take of the pull request for the clock changes for keystone = > SoC for 5.3. The only change compared to the v1 is to add the required=20 > drivers/firmware change in. This avoids the nasty dependency between the = > pull requests between the clock driver and firmware driver. >=20 > -Tero >=20 > --- Thanks. Pulled into clk-next. I guess we should increase the size of the number of parents that can exist to be more than a u8? We're close to getting there with the new way of specifying clk parents, so maybe we should expand it to an unsigned int, but then we may need to optimize finding parents when searching through all the parents of a clk. Also, there isn't any quantification of how much better it is to scan DT for all the clks that are used and only register those ones. It would be nice to understand how much better it is to do that sort of scan vs. just populating all clks at boot time. It may be useful to make the code generic because NXP folks also want to populate clks from DT so maybe we should provide this from the core framework somehow to ask providers to register a particular clk or not. I haven't thought about it at all, but it may come up that we totally rewrite this code in the future to be shared outside of the TI clk driver. FYI: I had to apply this patch on top to make sparse happy. diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c index b417cef35769..92b77d38dd1f 100644 --- a/drivers/firmware/ti_sci.c +++ b/drivers/firmware/ti_sci.c @@ -2402,12 +2402,13 @@ devm_ti_sci_get_of_resource(const struct ti_sci_han= dle *handle, if (!res) return ERR_PTR(-ENOMEM); =20 - res->sets =3D of_property_count_elems_of_size(dev_of_node(dev), of_prop, + ret =3D of_property_count_elems_of_size(dev_of_node(dev), of_prop, sizeof(u32)); - if (res->sets < 0) { + if (ret < 0) { dev_err(dev, "%s resource type ids not available\n", of_prop); - return ERR_PTR(res->sets); + return ERR_PTR(ret); } + res->sets =3D ret; =20 res->desc =3D devm_kcalloc(dev, res->sets, sizeof(*res->desc), GFP_KERNEL); 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 X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8565EC4646C for ; Tue, 25 Jun 2019 01:17:18 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5AA5720663 for ; Tue, 25 Jun 2019 01:17:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="DAL9vim7"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="OsfmJE8e" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5AA5720663 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Message-Id:Date:Subject:From:To: References:In-Reply-To:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=UK6PQYhJ4i6FWi7ekx3vFC1qthX58vVkEr140HyHpHw=; b=DAL9vim7x/fYZu 2pHKlCdUOOvPu8ChZLVvhZ6yloVEq2BXEh3Bn5GTQJHAMyxOhmFPYVk/IfHetXr2W7DHS4PqYC7Yw cmnlxq9A43EgD0D/XEbCulAKcoHpODXQjiS/j/U0QG/43Qb1oi/Ol8NxUQT53eJ1VkaJn09MDyiEs QM4qgwlP7KbFMFUYBhogjYBoPcQEp2fyUodMjzSFLFYdjMIyeP+snE8XIPfFiYvAofaadaepTYVU5 0FYR/WCHljV0B6KadxF77mQmqikOALeebiWarWAsTLoKpMyf6vlUdZaGMgt9BV8zuBdls7nRYq+VI l8Tuj/12z0trpg1+0nEg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1hfa5C-000450-QR; Tue, 25 Jun 2019 01:17:14 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1hfa59-000444-M6 for linux-arm-kernel@lists.infradead.org; Tue, 25 Jun 2019 01:17:12 +0000 Received: from kernel.org (unknown [104.132.0.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 3D2D520663; Tue, 25 Jun 2019 01:17:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1561425431; bh=+hj47sTwmKBDJvyyLIh4W4IbUA1BkBMWX0D6j641nnw=; h=In-Reply-To:References:To:From:Subject:Cc:Date:From; b=OsfmJE8eR++j21vrxJwqy17Yga503MPRPpcQWmjPZI5IAx3z0bk4Ok6+BGvKbjfh5 FTuP81eFgtILbUCGGQiQIb75faVHb0xeUMAht3h9wKbaqfULEZE1MzHcjbMeKUrf2Y ugeu7xYL2CDnBPEFufZFHyCRi9jv9g2nFIfoLTQo= MIME-Version: 1.0 In-Reply-To: <1deb7a85-0859-54f1-950a-33de3a08f9fd@ti.com> References: <1deb7a85-0859-54f1-950a-33de3a08f9fd@ti.com> To: Michael Turquette , Santosh Shilimkar , Tero Kristo , linux-clk From: Stephen Boyd Subject: Re: [GIT PULL] clk: keystone: changes for 5.3 v2 User-Agent: alot/0.8.1 Date: Mon, 24 Jun 2019 18:17:10 -0700 Message-Id: <20190625011711.3D2D520663@mail.kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190624_181711_749056_98F949DA X-CRM114-Status: GOOD ( 14.86 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Quoting Tero Kristo (2019-06-12 04:56:15) > Hi Stephen, Mike, Santosh, > > Here's a 2nd take of the pull request for the clock changes for keystone > SoC for 5.3. The only change compared to the v1 is to add the required > drivers/firmware change in. This avoids the nasty dependency between the > pull requests between the clock driver and firmware driver. > > -Tero > > --- Thanks. Pulled into clk-next. I guess we should increase the size of the number of parents that can exist to be more than a u8? We're close to getting there with the new way of specifying clk parents, so maybe we should expand it to an unsigned int, but then we may need to optimize finding parents when searching through all the parents of a clk. Also, there isn't any quantification of how much better it is to scan DT for all the clks that are used and only register those ones. It would be nice to understand how much better it is to do that sort of scan vs. just populating all clks at boot time. It may be useful to make the code generic because NXP folks also want to populate clks from DT so maybe we should provide this from the core framework somehow to ask providers to register a particular clk or not. I haven't thought about it at all, but it may come up that we totally rewrite this code in the future to be shared outside of the TI clk driver. FYI: I had to apply this patch on top to make sparse happy. diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c index b417cef35769..92b77d38dd1f 100644 --- a/drivers/firmware/ti_sci.c +++ b/drivers/firmware/ti_sci.c @@ -2402,12 +2402,13 @@ devm_ti_sci_get_of_resource(const struct ti_sci_handle *handle, if (!res) return ERR_PTR(-ENOMEM); - res->sets = of_property_count_elems_of_size(dev_of_node(dev), of_prop, + ret = of_property_count_elems_of_size(dev_of_node(dev), of_prop, sizeof(u32)); - if (res->sets < 0) { + if (ret < 0) { dev_err(dev, "%s resource type ids not available\n", of_prop); - return ERR_PTR(res->sets); + return ERR_PTR(ret); } + res->sets = ret; res->desc = devm_kcalloc(dev, res->sets, sizeof(*res->desc), GFP_KERNEL); _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel