Devicetree
 help / color / mirror / Atom feed
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

      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