Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH v1 04/10] ARM: tegra: Add reg property to Tegra20 EMC
 table device-tree nodes
To:     Thierry Reding <thierry.reding@gmail.com>
Cc:     Jonathan Hunter <jonathanh@nvidia.com>,
        Agneli <poczt@protonmail.ch>, Paul Fertser <fercerpav@gmail.com>,
        Svyatoslav Ryhel <clamor95@gmail.com>,
        linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org
References: <20210510202600.12156-1-digetx@gmail.com>
 <20210510202600.12156-5-digetx@gmail.com> <YLSpCXNtut3z8U9a@orome.fritz.box>
 <1ab11cc8-b45a-0c2d-c0c4-fa5779756c05@gmail.com>
 <YLYZHPpjZB9amRBW@orome.fritz.box>
From:   Dmitry Osipenko <digetx@gmail.com>
Message-ID: <056fed54-b075-443b-a445-ede45bc8eb54@gmail.com>
Date:   Tue, 1 Jun 2021 20:44:18 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.8.1
MIME-Version: 1.0
In-Reply-To: <YLYZHPpjZB9amRBW@orome.fritz.box>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk

01.06.2021 14:25, Thierry Reding пишет:
> On Mon, May 31, 2021 at 11:45:19PM +0300, Dmitry Osipenko wrote:
>> 31.05.2021 12:14, Thierry Reding пишет:
>>> On Mon, May 10, 2021 at 11:25:54PM +0300, Dmitry Osipenko wrote:
>>>> The reg property is now specified for the emc-tables nodes in the Tegra20
>>>> device-tree binding. Add reg property to the EMC table device-tree nodes
>>>> of Tegra20 board device-trees in order to silence dt_binding_check warning
>>>> about the missing property.
>>>>
>>>> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
>>>> ---
>>>>  arch/arm/boot/dts/tegra20-acer-a500-picasso.dts | 4 ++++
>>>>  arch/arm/boot/dts/tegra20-paz00.dts             | 1 +
>>>>  2 files changed, 5 insertions(+)
>>>
>>> In retrospect we should've just used "reg" in the first place rather
>>> than adding the custom "nvidia,ram-code". It's a bit redundant to have
>>> both of them with the same value. I wonder if we should deprecate the
>>> use of "nvidia,ram-code" and at least make the code look at the "reg"
>>> property first and only fall back to "nvidia,ram-code" if "reg" does
>>> not exist. We probably won't ever be able to get rid of the fallback
>>> for backwards-compatibility reasons, but at least that would make the
>>> intent a bit clearer.
>>
>> This may be not doable. We have Asus TF101 which doesn't use RAM code
>> for the memory identification, instead it uses LPDDR chip info [1]. I
>> will send the LPDDR patches later on.
>>
>> [1]
>> https://github.com/grate-driver/linux/blob/master/arch/arm/boot/dts/tegra20-asus-tf101.dts#L1115
> 
> That DTS defines both "jedec,lpddr-manufacturer-id" and "reg" with the
> same value, so we could simply use "reg" there. If you plan to support
> the JEDEC properties, we'll have to add code for that anyway, so there
> is no downside to first trying "reg". 

At least in my mind the reg property is associated with a hardware
register. Changing the purpose of the reg and removing the verbose
properties should create confusion for anyone who looks at device-tree
and not familiar with the binding.

The current main purpose of the reg is "Either an opaque enumerator to
tell different tables apart or the valid frequency for which the table
should be used (in kHz)", like the binding says. It should be better to
keep the reg optional and additional, especially if we will give it
another meaning, IMO.

> And we may not even need to add
> support for any of those JEDEC properties if we can just use the "reg"
> standard property in the first place.

We will need all those JEDEC properties for identifying memory chips,
including information about chip version and h/w geometry. This method
of matching is borrowed from the official downstream kernel of TF101,
apparently board designers decided not to use the RAM code.