From: Chris Packham <Chris.Packham@alliedtelesis.co.nz>
To: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Cc: "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"jdelvare-l3A5Bk7waGM@public.gmane.org"
<jdelvare-l3A5Bk7waGM@public.gmane.org>,
"linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org"
<linux-0h96xk9xTtrk1uMJSBkQmQ@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 06:01:42 +0000 [thread overview]
Message-ID: <55752FC5.3040004@alliedtelesis.co.nz> (raw)
In-Reply-To: <2658431.5aULpGi9jh@wuerfel>
On 06/05/2015 07:26 PM, Arnd Bergmann wrote:
> On Friday 05 June 2015 06:03:30 Chris Packham wrote:
>>
>> Is there a better way of getting the devicetree machinery to avoid the
>> call to the driver probe function in the first place?
>>
>>
>
> The newly added DT overlay support should do what you need, but it might
> not be the easiest solution.
>
> To start out with the device not getting probed at first, add a
> 'status="disabled"' property, which will prevent the i2c_device from
> getting added. At runtime you then need a way to change that from
> "disabled" to "ok" and retrigger the probe. I haven't done that myself,
> so it might need some i2c core changes to work correctly.
>
So I pursued this idea a little.
I set the node to status = "disabled" in the dts. Then I added some code
to probe for the i2c device using
i2c_probe_func_quick_read() and updated the device tree to remove the
status property based on the result of the probe.
Then I was able to call of_platform_populate(node->parent, ...). This
got me as far as the platform device being created but none of the i2c
or hwmon code kicked in. I may have missed something, perhaps the
platform bus needs to be re-probed now that there is a new device.
I think I'll look at updating the device tree passed by the bootloader
which should be easier to do at this point.
For future (and current) mailing list readers this is the gist of my
detect function.
static void board_detect(struct device *dev)
{
struct i2c_adapter *adap = i2c_get_adapter(0);
/* Ugly hack. The ads7830 device is a SMBUS device at 0x48.
* SMBUS is not i2c but the quick read should be OK-ish.
*/
if (i2c_probe_func_quick_read(adap, 0x48)) {
int ret;
struct device_node *node;
dev_info(dev, "board detected");
for_each_compatible_node(node, NULL, "ads7830") {
struct property *prop;
const struct of_device_id match_table[] = {
{ .compatible = "ads7830", },
{} /* Empty terminated list */
};
prop = of_find_property(node, "status", NULL);
if (prop)
of_remove_property(node, prop);
ret = of_platform_populate(node->parent,
match_table,
NULL, NULL);
if (ret)
dev_err(dev, "populate failed\n");
}
}
i2c_put_adapter(adap);
return;
}
_______________________________________________
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: Chris Packham <Chris.Packham-6g8wRflRTwXFdCa3tKVlE6U/zSkkHjvu@public.gmane.org>
To: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Cc: "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"jdelvare-l3A5Bk7waGM@public.gmane.org"
<jdelvare-l3A5Bk7waGM@public.gmane.org>,
"linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org"
<linux-0h96xk9xTtrk1uMJSBkQmQ@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, 8 Jun 2015 06:01:42 +0000 [thread overview]
Message-ID: <55752FC5.3040004@alliedtelesis.co.nz> (raw)
In-Reply-To: <2658431.5aULpGi9jh@wuerfel>
On 06/05/2015 07:26 PM, Arnd Bergmann wrote:
> On Friday 05 June 2015 06:03:30 Chris Packham wrote:
>>
>> Is there a better way of getting the devicetree machinery to avoid the
>> call to the driver probe function in the first place?
>>
>>
>
> The newly added DT overlay support should do what you need, but it might
> not be the easiest solution.
>
> To start out with the device not getting probed at first, add a
> 'status="disabled"' property, which will prevent the i2c_device from
> getting added. At runtime you then need a way to change that from
> "disabled" to "ok" and retrigger the probe. I haven't done that myself,
> so it might need some i2c core changes to work correctly.
>
So I pursued this idea a little.
I set the node to status = "disabled" in the dts. Then I added some code
to probe for the i2c device using
i2c_probe_func_quick_read() and updated the device tree to remove the
status property based on the result of the probe.
Then I was able to call of_platform_populate(node->parent, ...). This
got me as far as the platform device being created but none of the i2c
or hwmon code kicked in. I may have missed something, perhaps the
platform bus needs to be re-probed now that there is a new device.
I think I'll look at updating the device tree passed by the bootloader
which should be easier to do at this point.
For future (and current) mailing list readers this is the gist of my
detect function.
static void board_detect(struct device *dev)
{
struct i2c_adapter *adap = i2c_get_adapter(0);
/* Ugly hack. The ads7830 device is a SMBUS device at 0x48.
* SMBUS is not i2c but the quick read should be OK-ish.
*/
if (i2c_probe_func_quick_read(adap, 0x48)) {
int ret;
struct device_node *node;
dev_info(dev, "board detected");
for_each_compatible_node(node, NULL, "ads7830") {
struct property *prop;
const struct of_device_id match_table[] = {
{ .compatible = "ads7830", },
{} /* Empty terminated list */
};
prop = of_find_property(node, "status", NULL);
if (prop)
of_remove_property(node, prop);
ret = of_platform_populate(node->parent,
match_table,
NULL, NULL);
if (ret)
dev_err(dev, "populate failed\n");
}
}
i2c_put_adapter(adap);
return;
}--
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 6:01 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 ` Chris Packham [this message]
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 ` [lm-sensors] " Guenter Roeck
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=55752FC5.3040004@alliedtelesis.co.nz \
--to=chris.packham@alliedtelesis.co.nz \
--cc=arnd-r2nGTMty4D4@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=guillaume.roguez-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/@public.gmane.org \
--cc=jdelvare-l3A5Bk7waGM@public.gmane.org \
--cc=linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org \
--cc=lm-sensors-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org \
--cc=shardy-H+wXaHxf7aLQT0dZR+AlfA@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.