All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.