From: Frank Rowand <frowand.list@gmail.com>
To: Tony Lindgren <tony@atomide.com>
Cc: Grant Likely <grant.likely@linaro.org>,
Rob Herring <robh+dt@kernel.org>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
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 13:13:50 -0700 [thread overview]
Message-ID: <570D56FE.2070408@gmail.com> (raw)
In-Reply-To: <1460486275-12256-1-git-send-email-tony@atomide.com>
Hi Tony,
I agree with the need for some way of handling the incomplete
hardware issue. I like the idea of having a uniform method for
all nodes.
I am stumbling over what the status property is supposed to convey
and what the "fail-hw-incomplete" is meant to convey.
The status property is meant to convey the current state of the
node.
"fail-hw-incomplete" is meant to describe the node implementation,
saying that some portions of hardware that the driver expects to
be present do not exist. If I understood your explanation at ELC
correctly, an examples of this could be that a uart cell is not
routed to transmit and receive data pins or the interrupt line
from the cell is not routed to an interrupt controller. So the
node is not useful, but it makes sense to be able to power manage
the node, turning off power so that it is not wasting power.
It seems to me that the info that needs to be conveyed is a
description of the hardware, stating:
- some portions or features of the node are not present and/or
are not usable
- power management of the node is possible
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.
I would prefer to come up with a new boolean property (with a
standard name that any node binding could choose to implement)
that says something like "only power management is available for
this node, do not attempt to use any other feature of the node".
With that change, the bulk of your patch looks good, with
minor changes:
__of_device_is_available() would not need to change.
__of_device_is_incomplete() would change to check the new
boolean property. (And I would suggest renaming it to
something that conveys it is ok to power manage the
device, but do not do anything else to the device.)
-Frank
next prev parent reply other threads:[~2016-04-12 20:13 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 [this message]
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
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=570D56FE.2070408@gmail.com \
--to=frowand.list@gmail.com \
--cc=devicetree@vger.kernel.org \
--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=tony@atomide.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).