From: Guenter Roeck <linux@roeck-us.net>
To: "Enrico Weigelt,
metux IT consult" <weigelt-d/C+FbuhHiA@public.gmane.org>,
Chris Packham
<Chris.Packham-6g8wRflRTwXFdCa3tKVlE6U/zSkkHjvu@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Cc: "jdelvare-l3A5Bk7waGM@public.gmane.org"
<jdelvare-l3A5Bk7waGM@public.gmane.org>,
"lm-sensors-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org"
<lm-sensors-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org>,
"shardy-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org"
<shardy-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
"guillaume.roguez-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/@public.gmane.org"
<guillaume.roguez-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/@public.gmane.org>
Subject: Re: [lm-sensors] Dealing with optional i2c devices in a devicetree
Date: Mon, 08 Jun 2015 15:03:12 +0000 [thread overview]
Message-ID: <5575AEB0.70807@roeck-us.net> (raw)
In-Reply-To: <55758667.70501-d/C+FbuhHiA@public.gmane.org>
On 06/08/2015 05:11 AM, Enrico Weigelt, metux IT consult wrote:
> Am 08.06.2015 um 08:01 schrieb Chris Packham:
>
> Hi folks,
>
> > Sounds like my best bet is to mark the nodes as disabled in the
> > dts and have my bootloader update them on the way through.
>
> In case your bootloader can take that decision (eg. if the device
> is present at boot time, and the bootloader has the proper probing
> logic or simply knows the device has to be there), that would be
> an pretty easy way.
>
>
> But let me add another usecase, which might be a bit more tricky:
>
> Let's assume we can plug in some more complex device, which consists
> of several (pretty standard) subdevices, behind certain bus'es (maybe
> it's attached via USB, and somewhere behind are some I2C bus'es with
> regulators, pwm-generators, etc).
>
> Let's further assume, we already got some DTS or some piece of memory
> with an DTB subtree for that device (eg. some simple bulk endpoint that
> just gives back a bunch of bytes with the DTB).
>
> Now, when the device is plugged in, I'd like to get that piece of DTB
> loaded and the corresponding drivers initialized. And, of course, when
> it's plugged-out, everything should be shut down cleanly.
>
> How could we achieve that ?
>
Use devicetree overlays.
Guenter
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
WARNING: multiple messages have this Message-ID (diff)
From: Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
To: "Enrico Weigelt,
metux IT consult" <weigelt-d/C+FbuhHiA@public.gmane.org>,
Chris Packham
<Chris.Packham-6g8wRflRTwXFdCa3tKVlE6U/zSkkHjvu@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Cc: "jdelvare-l3A5Bk7waGM@public.gmane.org"
<jdelvare-l3A5Bk7waGM@public.gmane.org>,
"lm-sensors-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org"
<lm-sensors-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org>,
"shardy-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org"
<shardy-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
"guillaume.roguez-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/@public.gmane.org"
<guillaume.roguez-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/@public.gmane.org>
Subject: Re: Dealing with optional i2c devices in a devicetree
Date: Mon, 08 Jun 2015 08:03:12 -0700 [thread overview]
Message-ID: <5575AEB0.70807@roeck-us.net> (raw)
In-Reply-To: <55758667.70501-d/C+FbuhHiA@public.gmane.org>
On 06/08/2015 05:11 AM, Enrico Weigelt, metux IT consult wrote:
> Am 08.06.2015 um 08:01 schrieb Chris Packham:
>
> Hi folks,
>
> > Sounds like my best bet is to mark the nodes as disabled in the
> > dts and have my bootloader update them on the way through.
>
> In case your bootloader can take that decision (eg. if the device
> is present at boot time, and the bootloader has the proper probing
> logic or simply knows the device has to be there), that would be
> an pretty easy way.
>
>
> But let me add another usecase, which might be a bit more tricky:
>
> Let's assume we can plug in some more complex device, which consists
> of several (pretty standard) subdevices, behind certain bus'es (maybe
> it's attached via USB, and somewhere behind are some I2C bus'es with
> regulators, pwm-generators, etc).
>
> Let's further assume, we already got some DTS or some piece of memory
> with an DTB subtree for that device (eg. some simple bulk endpoint that
> just gives back a bunch of bytes with the DTB).
>
> Now, when the device is plugged in, I'd like to get that piece of DTB
> loaded and the corresponding drivers initialized. And, of course, when
> it's plugged-out, everything should be shut down cleanly.
>
> How could we achieve that ?
>
Use devicetree overlays.
Guenter
--
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
next prev parent reply other threads:[~2015-06-08 15:03 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-05 6:03 [lm-sensors] Dealing with optional i2c devices in a devicetree Chris Packham
2015-06-05 6:03 ` Chris Packham
[not found] ` <55713BB1.80004-6g8wRflRTwXFdCa3tKVlE6U/zSkkHjvu@public.gmane.org>
2015-06-05 7:26 ` [lm-sensors] " Arnd Bergmann
2015-06-05 7:26 ` Arnd Bergmann
2015-06-08 6:01 ` [lm-sensors] " Chris Packham
2015-06-08 6:01 ` Chris Packham
2015-06-05 7:30 ` [lm-sensors] " Guenter Roeck
2015-06-05 7:30 ` Guenter Roeck
[not found] ` <55714FFB.3000608-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
2015-06-08 6:01 ` [lm-sensors] " Chris Packham
2015-06-08 6:01 ` Chris Packham
[not found] ` <55752FD4.6050700-6g8wRflRTwXFdCa3tKVlE6U/zSkkHjvu@public.gmane.org>
2015-06-08 12:11 ` [lm-sensors] " Enrico Weigelt, metux IT consult
2015-06-08 12:11 ` Enrico Weigelt, metux IT consult
[not found] ` <55758667.70501-d/C+FbuhHiA@public.gmane.org>
2015-06-08 15:03 ` Guenter Roeck [this message]
2015-06-08 15:03 ` Guenter Roeck
2015-06-05 8:06 ` [lm-sensors] " Jean Delvare
2015-06-05 8:06 ` Jean Delvare
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=5575AEB0.70807@roeck-us.net \
--to=linux@roeck-us.net \
--cc=Chris.Packham-6g8wRflRTwXFdCa3tKVlE6U/zSkkHjvu@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=guillaume.roguez-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/@public.gmane.org \
--cc=jdelvare-l3A5Bk7waGM@public.gmane.org \
--cc=lm-sensors-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org \
--cc=shardy-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=weigelt-d/C+FbuhHiA@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.