From: Hollis Blanchard <hollis_blanchard-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
To: David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>
Cc: Scott Wood <scottwood-KZfg59tc24xl57MIdRCFDg@public.gmane.org>,
Hunter Cobbs
<hunter.cobbs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
Subject: Re: "status" property checks
Date: Fri, 08 Jan 2010 15:58:40 -0800 [thread overview]
Message-ID: <1262995120.31871.105.camel@localhost.localdomain> (raw)
In-Reply-To: <20100108234614.GB2661@yookeroo>
On Sat, 2010-01-09 at 10:46 +1100, David Gibson wrote:
> On Fri, Jan 08, 2010 at 11:45:28AM -0800, Hollis Blanchard wrote:
> > On Fri, 2010-01-08 at 13:28 -0600, Scott Wood wrote:
> > > Hollis Blanchard wrote:
> > > > On Thu, 2010-01-07 at 20:35 -0600, Hunter Cobbs wrote:
> > > >> I think that is definitely a solution. It does centralize the testing
> > > >> for this particular issue. The only thing question I have is if its
> > > >> really better to have the upper level do the check. Shouldn't the
> > > >> driver itself handle the hardware and device node status?
> > > >
> > > > Practically speaking, all drivers doing the checks today just return
> > > > -ENODEV. They don't try to do anything to "handle" the situation.
> > > >
> > > > The definition of the status property implies it's outside of software's
> > > > control, for example:
> > > > "disabled"
> > > > "Indicates that the device is not presently operational, but it
> > > > might become operational in the future (for example, something
> > > > is not plugged in, or switched off)."
> > > >
> > > > If a device is "not operational" in this sense, I don't think there's
> > > > anything for a device driver to do.
> > >
> > > I could see situations where there is some software action that could
> > > enable the device (e.g. multiple devices sharing pins, where only one
> > > can be active at a time) -- but it's likely to not be the driver itself
> > > that knows how to do that.
> > >
> > > If the need arises, there could be a mechanism where the enabling entity
> > > can tell the platform bus that it has enabled a previously-disabled
> > > device, overriding the status in the device tree (and likewise if it
> > > wants take down a device that was previously enabled).
> >
> > OK, that makes sense to me. I'll put together a patch for the original
> > idea, and the enable/disable part can come later as needed.
>
> Sounds good to me to. Only thing I'd add, is that I'd also suggest a
> helper function to do an explicit check on the status property (or do
> we have that already?). This could be useful for drivers which are
> bound primarily to one device tree node, but also need to (possibly
> optionally) check/use some other node.
of_device_is_available() exists and is used already, so I think we're OK
there.
--
Hollis Blanchard
Mentor Graphics, Embedded Systems Division
prev parent reply other threads:[~2010-01-08 23:58 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-07 23:07 "status" property checks Hollis Blanchard
2010-01-08 2:35 ` Hunter Cobbs
2010-01-08 18:34 ` Hollis Blanchard
[not found] ` <1262975655.31871.67.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2010-01-08 19:28 ` Scott Wood
[not found] ` <4B478747.8070009-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
2010-01-08 19:45 ` Hollis Blanchard
2010-01-08 23:46 ` David Gibson
2010-01-08 23:58 ` Hollis Blanchard [this message]
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=1262995120.31871.105.camel@localhost.localdomain \
--to=hollis_blanchard-nmggyn9qbj3qt0dzr+alfa@public.gmane.org \
--cc=david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org \
--cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
--cc=hunter.cobbs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
--cc=scottwood-KZfg59tc24xl57MIdRCFDg@public.gmane.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