linux-mmc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Dmitry Osipenko <digetx@gmail.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Sowjanya Komatineni <skomatineni@nvidia.com>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	linux-tegra <linux-tegra@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v1] sdhci: tegra: Remove warnings about missing device-tree properties
Date: Tue, 19 May 2020 18:24:44 +0200	[thread overview]
Message-ID: <20200519162444.GD2113674@ulmo> (raw)
In-Reply-To: <b634e7a5-9a30-3bd1-126d-be62e4dd73e1@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2533 bytes --]

On Tue, May 19, 2020 at 05:05:27PM +0300, Dmitry Osipenko wrote:
> 19.05.2020 10:28, Ulf Hansson пишет:
> > On Sat, 16 May 2020 at 17:44, Dmitry Osipenko <digetx@gmail.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.

Optional only means that drivers must not fail if these properties
aren't found, it doesn't mean that the driver can't warn that they
are missing.

Quite possibly the only reason why they were made optional is because
they weren't part of the bindings since the beginning. Anything added
to a binding after the first public release has to be optional by
definition, otherwise DT ABI wouldn't be stable.

I think these warnings were added on purpose, though I also see that
there are only values for these in device tree for Tegra186 and Tegra194
but not Tegra210 where these should also be necessary.

Adding Sowjanya who wrote this code. Perhaps she can clarify why the
warnings were added. If these values /should/ be there on a subset of
Tegra, then I think we should keep them, or add them again, but perhaps
add a better way of identifying when they are necessary and when it is
safe to work without them.

That said, looking at those checks I wonder if they are perhaps just
wrong. Or at the very least they seem redundant. It looks to me like
they can just be:

	if (tegra_host->pinctrl_state_XYZ == NULL) {
		...
	}

That !IS_ERR(...) doesn't seem to do anything. But in that case, it's
also obvious why we're warning about them on platforms where these
properties don't exist in DT.

So I think we either need to add those values where appropriate so that
the warning doesn't show, or we need to narrow down where they are
really needed and add a corresponding condition.

But again, perhaps Sowjanya can help clarify if these really are only
needed on Tegra210 and later or if these also apply to older chips.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2020-05-19 16:24 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-16 15:43 [PATCH v1] sdhci: tegra: Remove warnings about missing device-tree properties Dmitry Osipenko
2020-05-19  7:28 ` Ulf Hansson
2020-05-19 14:05   ` Dmitry Osipenko
2020-05-19 15:29     ` Ulf Hansson
2020-05-19 16:24     ` Thierry Reding [this message]
2020-05-19 16:33       ` Dmitry Osipenko
2020-05-19 18:34         ` Sowjanya Komatineni
2020-05-19 18:41           ` Sowjanya Komatineni
2020-05-19 19:07             ` Sowjanya Komatineni
2020-05-19 20:44               ` Sowjanya Komatineni
2020-05-20  2:00                 ` Dmitry Osipenko
2020-05-20 11:26                   ` Ulf Hansson
2020-05-20 16:09                     ` Sowjanya Komatineni
2020-05-22 12:13                       ` Thierry Reding
2020-05-22 12:18                         ` Dmitry Osipenko
2020-05-22 12:34                           ` Thierry Reding
2020-05-22 15:22                             ` Sowjanya Komatineni
2020-05-22 15:26                               ` Thierry Reding
2020-05-22 15:57                                 ` Sowjanya Komatineni
2020-05-25  8:47                         ` Ulf Hansson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200519162444.GD2113674@ulmo \
    --to=thierry.reding@gmail.com \
    --cc=adrian.hunter@intel.com \
    --cc=digetx@gmail.com \
    --cc=jonathanh@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=skomatineni@nvidia.com \
    --cc=ulf.hansson@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).