From: Tony Lindgren <tony@atomide.com>
To: Rob Herring <robh+dt@kernel.org>
Cc: Frank Rowand <frowand.list@gmail.com>,
Grant Likely <grant.likely@linaro.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
linux-omap <linux-omap@vger.kernel.org>,
Nishanth Menon <nm@ti.com>, Tero Kristo <t-kristo@ti.com>,
Tom Rini <trini@konsulko.com>
Subject: Re: [PATCH] of: Add generic handling for hardware incomplete fail state
Date: Tue, 12 Apr 2016 15:27:32 -0700 [thread overview]
Message-ID: <20160412222732.GL5995@atomide.com> (raw)
In-Reply-To: <CAL_Jsq+B67np4qcwJ2m1yz3TOzYgb7ZQtRH+vhANm9Snw5QnzQ@mail.gmail.com>
* Rob Herring <robh+dt@kernel.org> [160412 15:22]:
> On Tue, Apr 12, 2016 at 4:41 PM, Frank Rowand <frowand.list@gmail.com> wrote:
> >>> Status of "fail-sss" is meant to indicate an error was detected in
> >>> the device, and that the error might (or might not) be repairable.
> >>>
> >>> So the difference I see is state vs hardware description.
>
> The question to ask is are we indicating the "operational status of a
> device"? If yes, that is the definition of status and using it would
> be appropriate.
>
> IMO, I think we are.
>
> >> OK thanks for the clarification. I don't see why "fail-hw-incomplete"
> >> could not be set dynamically during the probe in some cases based
> >> on the SoC revision detection for example. So from that point of
> >> view using status with the "fail-sss" logic would make more sense.
> >
> > If the probe detects that the device should only be power managed
> > based on the SoC revision, then it would simply be one more
> > test added at the top of probe. The patch would change from:
> >
> > if (of_device_is_incomplete(pdev->dev.of_node)) {
> >
> > to:
> >
> > if (of_device_is_incomplete(pdev->dev.of_node) || socrev == XXX) {
>
> I think Tony meant the bootloader or platform code would do this and
> tweak the DT. We don't have much of a standard API for revision
> checking, so drivers don't check SoC revisions generally.
Yes bootloader may need to set these based on the SoC revision.
There are already many boards with multiple SoC variants
available. Would like to hear Tom's comments on this one as
well from the u-boot point of view.
Regards,
Tony
next prev parent reply other threads:[~2016-04-12 22:27 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-12 18:37 [PATCH] of: Add generic handling for hardware incomplete fail state Tony Lindgren
2016-04-12 20:13 ` Frank Rowand
2016-04-12 20:34 ` Tony Lindgren
[not found] ` <20160412203431.GU5995-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
2016-04-12 21:41 ` Frank Rowand
[not found] ` <570D6B7A.3050203-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-04-12 22:02 ` Tony Lindgren
2016-04-12 22:20 ` Rob Herring
2016-04-12 22:27 ` Tony Lindgren [this message]
2016-04-13 0:11 ` Tom Rini
[not found] ` <CAL_Jsq+B67np4qcwJ2m1yz3TOzYgb7ZQtRH+vhANm9Snw5QnzQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-04-12 22:37 ` Frank Rowand
[not found] ` <570D56FE.2070408-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-04-12 22:39 ` Frank Rowand
[not found] ` <570D7922.5020206-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-04-12 23:18 ` Tony Lindgren
2016-04-12 23:22 ` Tom Rini
2016-04-12 20:24 ` Rob Herring
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=20160412222732.GL5995@atomide.com \
--to=tony@atomide.com \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=grant.likely@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=nm@ti.com \
--cc=robh+dt@kernel.org \
--cc=t-kristo@ti.com \
--cc=trini@konsulko.com \
/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).