linux-kernel - Re: [PATCH v1 2/3] drivers: clk: tegra: add DFLL support for Tegra 4

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <g7kegtso3opafpwocvibhm3rym35oikxoyq2wmphqy3wjenzpa@m7extntwahau>
Date: Tue, 10 Jun 2025 13:07:34 +0200
From: Thierry Reding <thierry.reding@...il.com>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: Svyatoslav Ryhel <clamor95@...il.com>, 
	Jonathan Hunter <jonathanh@...dia.com>, Peter De Schrijver <pdeschrijver@...dia.com>, 
	Prashant Gaikwad <pgaikwad@...dia.com>, Michael Turquette <mturquette@...libre.com>, 
	Stephen Boyd <sboyd@...nel.org>, "Rafael J. Wysocki" <rafael@...nel.org>, 
	Viresh Kumar <viresh.kumar@...aro.org>, Philipp Zabel <p.zabel@...gutronix.de>, 
	linux-tegra@...r.kernel.org, linux-kernel@...r.kernel.org, linux-clk@...r.kernel.org, 
	linux-pm@...r.kernel.org
Subject: Re: [PATCH v1 2/3] drivers: clk: tegra: add DFLL support for Tegra 4

On Fri, Mar 21, 2025 at 09:50:09PM +0100, Krzysztof Kozlowski wrote:
> On 21/03/2025 10:55, Svyatoslav Ryhel wrote:
> > Extend the Tegra124 driver to include DFLL configuration settings required
> > for Tegra114 compatibility.
> > 
> > Signed-off-by: Svyatoslav Ryhel <clamor95@...il.com>
> 
> <form letter>
> Please use scripts/get_maintainers.pl to get a list of necessary people
> and lists to CC (and consider --no-git-fallback argument, so you will
> not CC people just because they made one commit years ago). It might
> happen, that command when run on an older kernel, gives you outdated
> entries. Therefore please be sure you base your patches on recent Linux
> kernel.
> 
> Tools like b4 or scripts/get_maintainer.pl provide you proper list of
> people, so fix your workflow. Tools might also fail if you work on some
> ancient tree (don't, instead use mainline) or work on fork of kernel
> (don't, instead use mainline). Just use b4 and everything should be
> fine, although remember about `b4 prep --auto-to-cc` if you added new
> patches to the patchset.
> </form letter>
> 
> 
> 
> > +++ b/include/dt-bindings/reset/tegra114-car.h
> 
> Filename based on compatible.
> 
> > @@ -0,0 +1,13 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause */
> > +/*
> > + * This header provides Tegra114-specific constants for binding
> > + * nvidia,tegra114-car.
> > + */
> > +
> > +#ifndef _DT_BINDINGS_RESET_TEGRA114_CAR_H
> > +#define _DT_BINDINGS_RESET_TEGRA114_CAR_H
> > +
> > +#define TEGRA114_RESET(x)		(5 * 32 + (x))
> 
> 
> Does not look like a binding, but some sort of register. Binding IDs
> start from 0 (or 1) and are incremented by 1.

I'll try and clear up some of the confusion around this. The way that
resets are handled on these Tegra devices is that there is a set of
peripheral clocks & resets which are paired up. This is because they
are laid out in banks within the CAR (clock and reset) controller. In
most cases we're referring to those resets, so you'll often see a clock
ID used in conjection with the same reset ID for a given IP block.

In addition to those peripheral resets, there are a number of extra
resets that don't have a corresponding clock and which are exposed in
registers outside of the peripheral banks, but still part of the CAR.
To support those "special" registers, the TEGRA*_RESET() is used to
denote resets outside of the regular peripheral resets. Essentially it
defines the offset within the CAR at which special resets start. In the
above case, Tegra114 has 5 banks with 32 peripheral resets each. The
first special reset, TEGRA114_RESET(0), therefore gets ID 5 * 32 + 0.

So to summarize: We cannot start enumerating these at 0 because that
would fall into the range of peripheral reset IDs.

Thierry

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)