All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: 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: Fri, 05 Jun 2015 07:30:03 +0000	[thread overview]
Message-ID: <55714FFB.3000608@roeck-us.net> (raw)
In-Reply-To: <55713BB1.80004-6g8wRflRTwXFdCa3tKVlE6U/zSkkHjvu@public.gmane.org>

Hi Chris,

On 06/04/2015 11:03 PM, Chris Packham wrote:
> Hi,
>
> I'm working on a new board and one feature it as is a plug-in module
> with an ADS7830 voltage monitor on it. This will be used during
> manufacturing to sanity check that various voltage rails are within
> expected ranges.
>
> I have a dts entry for the device as below (with some omissions for the
> sake of clarity)
>
> 	soc {
> 		internal-regs {
> 			i2c@11000 {
> 				ads7830@48 {
> 					compatible = "ads7830";
> 					reg = <0x48>;
> 				};
> 			};
> 		};
> 	};
>
> The problem is that when the manufacturing card is not installed the
> device still shows up in /sys/class/hwmon/hwmon0/ and
> /sys/bus/i2c/devices/0-0048/ despite it not actually being present. If I
> was using an old style initialization I could use
> i2c_new_probed_device() which I think would stop the drivers probe()
> function from being called
>
> Looking at the ads7828_probe() function it doesn't actually do anything
> with the i2c device before calling hwmon_device_register(). Some hwmon
> drivers like lm73_probe() do attempt to read from the device and bail if
> the read fails. I can probably fix my problem by doing something similar
> in the ads7828_probe(), but there are other drivers that have a similar
> probe function.
>
But that would be artificial in this case, and it could not be used to really
detect the chip but would only prove that there is a chip at the selected i2c
address. This is not really useful.

> Is there a better way of getting the devicetree machinery to avoid the
> call to the driver probe function in the first place?
>

The easiest solution would probably be to drop the entry from the
devicetree file and instantiate the driver manually via sysfs when
needed. Another option would be to load a different devicetree file
if the chip is plugged in.

You might also be able to use a devicetree overlay, but that would
probably add too much complexity if the chip is only used in
manufacturing.

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: 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: Fri, 05 Jun 2015 00:30:03 -0700	[thread overview]
Message-ID: <55714FFB.3000608@roeck-us.net> (raw)
In-Reply-To: <55713BB1.80004-6g8wRflRTwXFdCa3tKVlE6U/zSkkHjvu@public.gmane.org>

Hi Chris,

On 06/04/2015 11:03 PM, Chris Packham wrote:
> Hi,
>
> I'm working on a new board and one feature it as is a plug-in module
> with an ADS7830 voltage monitor on it. This will be used during
> manufacturing to sanity check that various voltage rails are within
> expected ranges.
>
> I have a dts entry for the device as below (with some omissions for the
> sake of clarity)
>
> 	soc {
> 		internal-regs {
> 			i2c@11000 {
> 				ads7830@48 {
> 					compatible = "ads7830";
> 					reg = <0x48>;
> 				};
> 			};
> 		};
> 	};
>
> The problem is that when the manufacturing card is not installed the
> device still shows up in /sys/class/hwmon/hwmon0/ and
> /sys/bus/i2c/devices/0-0048/ despite it not actually being present. If I
> was using an old style initialization I could use
> i2c_new_probed_device() which I think would stop the drivers probe()
> function from being called
>
> Looking at the ads7828_probe() function it doesn't actually do anything
> with the i2c device before calling hwmon_device_register(). Some hwmon
> drivers like lm73_probe() do attempt to read from the device and bail if
> the read fails. I can probably fix my problem by doing something similar
> in the ads7828_probe(), but there are other drivers that have a similar
> probe function.
>
But that would be artificial in this case, and it could not be used to really
detect the chip but would only prove that there is a chip at the selected i2c
address. This is not really useful.

> Is there a better way of getting the devicetree machinery to avoid the
> call to the driver probe function in the first place?
>

The easiest solution would probably be to drop the entry from the
devicetree file and instantiate the driver manually via sysfs when
needed. Another option would be to load a different devicetree file
if the chip is plugged in.

You might also be able to use a devicetree overlay, but that would
probably add too much complexity if the chip is only used in
manufacturing.

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

  parent reply	other threads:[~2015-06-05  7:30 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   ` Guenter Roeck [this message]
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=55714FFB.3000608@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 \
    /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.