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: <b634e7a5-9a30-3bd1-126d-be62e4dd73e1@gmail.com>
Date:   Tue, 19 May 2020 17:05:27 +0300
From:   Dmitry Osipenko <digetx@...il.com>
To:     Ulf Hansson <ulf.hansson@...aro.org>
Cc:     Thierry Reding <thierry.reding@...il.com>,
        Jonathan Hunter <jonathanh@...dia.com>,
        Adrian Hunter <adrian.hunter@...el.com>,
        "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
        linux-tegra <linux-tegra@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1] sdhci: tegra: Remove warnings about missing
 device-tree properties

19.05.2020 10:28, Ulf Hansson пишет:
> On Sat, 16 May 2020 at 17:44, Dmitry Osipenko <digetx@...il.com> wrote:
>>
>> Several people asked me about the MMC warnings in the KMSG log and
>> I had to tell to ignore them because these warning are irrelevant to
>> pre-Tegra210 SoCs.
> 
> Why are the warnings irrelevant?

That's what the DT binding doc says [1].

[1]
https://www.kernel.org/doc/Documentation/devicetree/bindings/mmc/nvidia%2Ctegra20-sdhci.txt

Although, looking at the driver's code and TRM docs, it seems that all
those properties are really irrelevant only to the older Terga20 SoC. So
the binding doc is a bit misleading.

Nevertheless, the binding explicitly says that the properties are
optional, which is correct.

>> It should be up to a board's device-tree writer to
>> properly describe all the necessary properties. Secondly, eventually all
>> device-tree bindings will be converted to YAML, which allows to validate
>> board DT files, giving a warning about missing properties. Hence let's
>> remove the noisy warnings to stop the confusion.
> 
> Yep, makes sense. However, perhaps we should do this conversion then,
> rather than first drop the warnings?

I don't mind to postpone this patch. But again, IIUC, all these
properties are optional, and thus, there is no critical need to verify
them in DT right now, it could be done later on.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ