devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Status variable
@ 2016-01-29  8:43 Ryan
       [not found] ` <CANMsd02jhaouPBuySWXQ2edE+gyMZ3dncobipKa-dg1vLJCE2Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 6+ messages in thread
From: Ryan @ 2016-01-29  8:43 UTC (permalink / raw)
  To: devicetree-u79uwXL29TY76Z2rM5mHXA

Hello,

I am confused about the "status" variables on a device tree. What is
the meaning of
status="okay", status="enabled", status="disabled".

the function: __of_device_is_available returns 1 if the entry itself
is not there.

Why is this?

Thanks for your time.

Thanks,
ryan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Status variable
       [not found] ` <CANMsd02jhaouPBuySWXQ2edE+gyMZ3dncobipKa-dg1vLJCE2Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2016-01-29  8:49   ` Arnd Bergmann
  2016-01-29  9:10     ` Ryan
  2016-01-29  9:23     ` Ryan
  0 siblings, 2 replies; 6+ messages in thread
From: Arnd Bergmann @ 2016-01-29  8:49 UTC (permalink / raw)
  To: Ryan; +Cc: devicetree-u79uwXL29TY76Z2rM5mHXA

On Friday 29 January 2016 14:13:20 Ryan wrote:
> Hello,
> 
> I am confused about the "status" variables on a device tree. What is
> the meaning of
> status="okay", status="enabled", status="disabled".
> 
> the function: __of_device_is_available returns 1 if the entry itself
> is not there.
> 
> Why is this?
> 
> Thanks for your time.

On status="disabled" is defined to have an effect and will prevent
the device from being used. Any other value or an absent status
property is interpreted as a working device.

The common way this is used is that a soc-specific .dtsi file lists
all devices that are present within the soc, but marks the ones as
disabled that are not always usable because they depend on a external
connection (e.g. a uart only makes sense if it talks to something,
while a timer device is always usable). A board specific file then
does not need to define the entire device but just override the
status as "okay".

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Status variable
  2016-01-29  8:49   ` Arnd Bergmann
@ 2016-01-29  9:10     ` Ryan
       [not found]       ` <CANMsd01PnqUe+NVp-OGE3aMN=k1b4KX_D5YBnQAbPuHcT1+SWQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  2016-01-29  9:23     ` Ryan
  1 sibling, 1 reply; 6+ messages in thread
From: Ryan @ 2016-01-29  9:10 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: devicetree-u79uwXL29TY76Z2rM5mHXA

Hello Bergman,

Thanks for your help and time. Also I have seen that sometimes we use

i2c0: i2c@44e0b000 {


}

and Sometimes

i2c@44e0b000

Why is that? What is the purpose of adding a i2c0: infront of the i2c
entry. that too in the same file.

Regards,
ryan

On Fri, Jan 29, 2016 at 2:19 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> On Friday 29 January 2016 14:13:20 Ryan wrote:
>> Hello,
>>
>> I am confused about the "status" variables on a device tree. What is
>> the meaning of
>> status="okay", status="enabled", status="disabled".
>>
>> the function: __of_device_is_available returns 1 if the entry itself
>> is not there.
>>
>> Why is this?
>>
>> Thanks for your time.
>
> On status="disabled" is defined to have an effect and will prevent
> the device from being used. Any other value or an absent status
> property is interpreted as a working device.
>
> The common way this is used is that a soc-specific .dtsi file lists
> all devices that are present within the soc, but marks the ones as
> disabled that are not always usable because they depend on a external
> connection (e.g. a uart only makes sense if it talks to something,
> while a timer device is always usable). A board specific file then
> does not need to define the entire device but just override the
> status as "okay".
>
>         Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Status variable
       [not found]       ` <CANMsd01PnqUe+NVp-OGE3aMN=k1b4KX_D5YBnQAbPuHcT1+SWQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2016-01-29  9:18         ` Arnd Bergmann
  0 siblings, 0 replies; 6+ messages in thread
From: Arnd Bergmann @ 2016-01-29  9:18 UTC (permalink / raw)
  To: Ryan; +Cc: devicetree-u79uwXL29TY76Z2rM5mHXA

On Friday 29 January 2016 14:40:33 Ryan wrote:
> Hello Bergman,
> 
> Thanks for your help and time. Also I have seen that sometimes we use
> 
> i2c0: i2c@44e0b000 {
> 
> 
> }
> 
> and Sometimes
> 
> i2c@44e0b000
> 
> Why is that? What is the purpose of adding a i2c0: infront of the i2c
> entry. that too in the same file.

The "i2c0" is a label that can be used to reference the device as a
shortcut, so you don't have to write the entire path. If you
have a device with the full path "/soc/axi/ahb/i2c@44e0b000",
you can add the status="okay" propert by writing

/soc/axi/ahb/i2c@44e0b000 {
	status = "okay";
};

or you can do the shortcut and write

&i2c0 {
	status = "okay";
};

after you have defined the label. Some people prefer the latter
for brevity, others prefer an even more elaborate version by
always writing

/ {
	soc {
		axi {
			ahb {
				i2c0: i2c@44e0b000 {
					status = "okay";
				};
			};
		};
	};
};

which is the same thing as the above two again, but even duplicates
the label. I would recommend one of the first two approaches, and do
it consistently.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Status variable
  2016-01-29  8:49   ` Arnd Bergmann
  2016-01-29  9:10     ` Ryan
@ 2016-01-29  9:23     ` Ryan
       [not found]       ` <CANMsd01ty4H3mP0-6kyc0ZxMBAd7p2Y6o7dHy4sFSGhog22R2w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  1 sibling, 1 reply; 6+ messages in thread
From: Ryan @ 2016-01-29  9:23 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: devicetree-u79uwXL29TY76Z2rM5mHXA

Hello Bergman,

Sorry to bother you again: I was going through this:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/of/base.c#n524

Status should be absent or okay and "ok". Otherwise the entry is
treated as disabled.

Is this understanding correct?


On Fri, Jan 29, 2016 at 2:19 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> On Friday 29 January 2016 14:13:20 Ryan wrote:
>> Hello,
>>
>> I am confused about the "status" variables on a device tree. What is
>> the meaning of
>> status="okay", status="enabled", status="disabled".
>>
>> the function: __of_device_is_available returns 1 if the entry itself
>> is not there.
>>
>> Why is this?
>>
>> Thanks for your time.
>
> On status="disabled" is defined to have an effect and will prevent
> the device from being used. Any other value or an absent status
> property is interpreted as a working device.
>
> The common way this is used is that a soc-specific .dtsi file lists
> all devices that are present within the soc, but marks the ones as
> disabled that are not always usable because they depend on a external
> connection (e.g. a uart only makes sense if it talks to something,
> while a timer device is always usable). A board specific file then
> does not need to define the entire device but just override the
> status as "okay".
>
>         Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Status variable
       [not found]       ` <CANMsd01ty4H3mP0-6kyc0ZxMBAd7p2Y6o7dHy4sFSGhog22R2w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2016-01-29  9:30         ` Arnd Bergmann
  0 siblings, 0 replies; 6+ messages in thread
From: Arnd Bergmann @ 2016-01-29  9:30 UTC (permalink / raw)
  To: Ryan; +Cc: devicetree-u79uwXL29TY76Z2rM5mHXA

On Friday 29 January 2016 14:53:02 Ryan wrote:
> Hello Bergman,
> 
> Sorry to bother you again: I was going through this:
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/of/base.c#n524
> 
> Status should be absent or okay and "ok". Otherwise the entry is
> treated as disabled.
> 
> Is this understanding correct?
> 

Ah, you are right, sorry about my mistake. Please only use "disabled"
and "okay" though if you have a status property.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2016-01-29  9:30 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-01-29  8:43 Status variable Ryan
     [not found] ` <CANMsd02jhaouPBuySWXQ2edE+gyMZ3dncobipKa-dg1vLJCE2Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-01-29  8:49   ` Arnd Bergmann
2016-01-29  9:10     ` Ryan
     [not found]       ` <CANMsd01PnqUe+NVp-OGE3aMN=k1b4KX_D5YBnQAbPuHcT1+SWQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-01-29  9:18         ` Arnd Bergmann
2016-01-29  9:23     ` Ryan
     [not found]       ` <CANMsd01ty4H3mP0-6kyc0ZxMBAd7p2Y6o7dHy4sFSGhog22R2w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-01-29  9:30         ` Arnd Bergmann

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).