Received-SPF: pass (google.com: domain of linux-kernel+bounces-59838-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
From: Kamlesh Gurudasani <kamlesh@ti.com>
To: Nishanth Menon <nm@ti.com>, "Kumar, Udit" <u-kumar1@ti.com>
CC: <kristo@kernel.org>, <ssantosh@kernel.org>, <chandru@ti.com>,
        <rishabh@ti.com>, <vigneshr@ti.com>, <mturquette@baylibre.com>,
        <sboyd@kernel.org>, <linux-arm-kernel@lists.infradead.org>,
        <linux-kernel@vger.kernel.org>, <linux-clk@vger.kernel.org>
Subject: Re: [PATCH v3] clk: keystone: sci-clk: Adding support for non
 contiguous clocks
In-Reply-To: <20240209172555.fxlxijhhbgrkyibo@agreeing>
References: <20240207091100.4001428-1-u-kumar1@ti.com>
 <20240207125410.r2q3jcplvif7dvt2@tumbling>
 <3a7c4a18-5463-414f-82df-39aaed861148@ti.com>
 <20240209172555.fxlxijhhbgrkyibo@agreeing>
Date: Sat, 10 Feb 2024 00:25:45 +0530
Message-ID: <87y1btlb66.fsf@kamlesh.i-did-not-set--mail-host-address--so-tickle-me>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Nishanth Menon <nm@ti.com> writes:

> On 19:53-20240207, Kumar, Udit wrote:
>> Hi=A0Nishanth,
>>=20
>> On 2/7/2024 6:24 PM, Nishanth Menon wrote:
>> > On 14:41-20240207, Udit Kumar wrote:
>> > > Most of clocks and their parents are defined in contiguous range,
>> > > But in few cases, there is gap in clock numbers[0].
>> > > Driver assumes clocks to be in contiguous range, and add their clock
>> > > ids incrementally.
>> > >=20
>> > > New firmware started returning error while calling get_freq and is_on
>> > > API for non-available clock ids.
>> > >=20
>> > > In this fix, driver checks and adds only valid clock ids.
>> > >=20
>> > > Fixes: 3c13933c6033 ("clk: keystone: sci-clk: add support for dynami=
cally probing clocks")
>> > >=20
>> > > [0] https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/j7200/cloc=
ks.html
>> > > Section Clocks for NAVSS0_CPTS_0 Device,
>> > > clock id 12-15 not present.
>> > >=20
>> > > Signed-off-by: Udit Kumar <u-kumar1@ti.com>
>> > > ---
>> > > Changelog
>> > > Changes in v3
>> > > - instead of get_freq, is_auto API is used to check validilty of clo=
ck
>> > > - Address comments of v2, to have preindex increment
>> > > Link to v2 https://lore.kernel.org/all/20240206104357.3803517-1-u-ku=
mar1@ti.com/
>> > >=20
>> > > Changes in v2
>> > > - Updated commit message
>> > > - Simplified logic for valid clock id
>> > > link to v1 https://lore.kernel.org/all/20240205044557.3340848-1-u-ku=
mar1@ti.com/
>> > >=20
>> > >=20
>> > > P.S
>> > > Firmawre returns total num_parents count including non available ids.
>> > > For above device id NAVSS0_CPTS_0, number of parents clocks are 16
>> > > i.e from id 2 to 17. But out of these ids few are not valid.
>> > > So driver adds only valid clock ids out ot total.
>> > >=20
>> > > Original logs
>> > > https://gist.github.com/uditkumarti/de4b36b21247fb36725ad909ce4812f6=
#file-original-logs
>> > > Line 2630 for error
>> > >=20
>> > > Logs with fix v3
>> > > https://gist.github.com/uditkumarti/94e3e28d62282fd708dbfe37435ce1d9=
#file-v3
>> > > Line 2586
>> > >=20
>> > >=20
>> > >   drivers/clk/keystone/sci-clk.c | 12 ++++++++++--
>> > >   1 file changed, 10 insertions(+), 2 deletions(-)
>> > >=20
>> > > diff --git a/drivers/clk/keystone/sci-clk.c b/drivers/clk/keystone/s=
ci-clk.c
>> > > index 35fe197dd303..31b7df05d7bb 100644
>> > > --- a/drivers/clk/keystone/sci-clk.c
>> > > +++ b/drivers/clk/keystone/sci-clk.c
>> > > @@ -516,6 +516,7 @@ static int ti_sci_scan_clocks_from_dt(struct sci=
_clk_provider *provider)
>> > >   	struct sci_clk *sci_clk, *prev;
>> > >   	int num_clks =3D 0;
>> > >   	int num_parents;
>> > > [..]					/* Check if this clock id is valid */
>> > > +					ret =3D provider->ops->is_auto(provider->sci,
>> > > +						sci_clk->dev_id, ++clk_id, &state);
>> > A bit too nice coding ;) =3D> I had been confused momentarily by clk_i=
d =3D args.args[1]
>> > change just above till I saw that you are pre-incrementing
>> > clk_id - Is there a harm in leaving the original clk_id increment logic
>> > alone (it was much simpler to read up)?
>>=20
>> No warm in using original code but want to avoid, two statement for
>> increment in case of failure and success.
>>=20
>> Let me know, if i need to add few comments around this
>>=20
>> or if you think, code is confusing I can move to original one
>
> Yes, please drop the un-necessary changes. In this case, original
> increment code should work just fine.
I wouldn't call it unnecessary, If I have to track increment/addition at
3 different places just to understand the loop, it is hard. On other
hand, pre-increment code is solving the problem by having increment at
only one place(easier to track). On the plus side, every clk_id belonging to
parent is handled completely inside the loop.

For a new person looking at this code, pre-increment code would be
actually easier to undertsand.

Also, Udit feels the same.

Would you please explain why do you think the original increment code
make more sense? It's not simple to understand or track, that's for sure.

Kamlesh
>\
> --=20
> Regards,
> Nishanth Menon
> Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DD=
B5 849D 1736 249D