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 49D4EC433EF for ; Tue, 15 Mar 2022 21:30:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350936AbiCOVbv (ORCPT ); Tue, 15 Mar 2022 17:31:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37048 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350379AbiCOVbq (ORCPT ); Tue, 15 Mar 2022 17:31:46 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A14C15BE4B; Tue, 15 Mar 2022 14:30:33 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 19EA3B81892; Tue, 15 Mar 2022 21:30:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C8E47C340F4; Tue, 15 Mar 2022 21:30:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1647379830; bh=Z+w7qmmwtApw9A0X4lTrxH73AXRGI1t4uG6akIL9azM=; h=In-Reply-To:References:Subject:From:Cc:To:Date:From; b=M4PwMSDorSTfdtY0s/1gMPAGwA76o8BVklHp8cUpOsLR/WrS9AYZ0xQbOt88TuQaH EMQbSpPCoHfLXrEwj2M+QFhUoVpxT++T84P/S7tTMMZOvurhsiRzOWIGXE3vASsh+e 36FI6P9cehMnn4n2+l4rzhjFAqEy35TiQWb3azA3bsUcQzWn2u1GgsQhcX2nilHAfS eF4egGjPLjkS4eVKhpZ2+lctYADUqew2oGAyw1mE8bswn940YdxDiTyWOZ3pAMwYVG +7xrwSWWJ8yHK8a6zeB47BABudr8r8ppqzsH7d+muharC6MX2YyZZNiwVPyxJ/RmZN 4tKFqn7Jr7fVA== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: References: <20220313190419.2207-1-ansuelsmth@gmail.com> <20220313190419.2207-2-ansuelsmth@gmail.com> <20220315175520.32E1AC340EE@smtp.kernel.org> Subject: Re: [PATCH 01/16] clk: permit to define a custom parent for clk_hw_get_parent_index From: Stephen Boyd Cc: Andy Gross , Bjorn Andersson , Jonathan Hunter , Michael Turquette , Peter De Schrijver , Prashant Gaikwad , Rob Herring , Thierry Reding , devicetree@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org, linux-tegra@vger.kernel.org To: Ansuel Smith Date: Tue, 15 Mar 2022 14:30:28 -0700 User-Agent: alot/0.10 Message-Id: <20220315213030.C8E47C340F4@smtp.kernel.org> Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org Quoting Ansuel Smith (2022-03-15 11:07:26) > On Tue, Mar 15, 2022 at 10:55:18AM -0700, Stephen Boyd wrote: > > Quoting Ansuel Smith (2022-03-13 12:04:04) > > > */ > > > -int clk_hw_get_parent_index(struct clk_hw *hw) > > > +int clk_hw_get_parent_index(struct clk_hw *hw, struct clk_hw *parent) > >=20 > > Please introduce another API vs. tacking on an "output" argument to this > > API. That makes the patch less invasive. And it can also return a > > pointer instead of an integer in that case. > > >=20 > Any suggestion about the name? clk_hw_fetch_parent_index? That would be > a direct access of the internal clk_fetch_parent_index. >=20 > The name is already not that intuitive as is. The alternative is to make > it extra long, don't know if that's a problem... > Something like clk_hw_get_parent_index_by_parent? (that is even more > confusing) Haha that's a mouthful. clk_hw_get_index_of_parent()? I realize now that I misread the API because parent wasn't a const pointer. Please make parent argument const as well and return an int as before.