Devicetree
 help / color / mirror / Atom feed
From: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
To: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Cc: devicetree-discuss
	<devicetree-discuss-mnsaURCQ41sdnm+yROfE0A@public.gmane.org>,
	Ira Snyder <iws-lulEs6mt1IksTUYHLfqkUA@public.gmane.org>
Subject: Re: Freescale i2c probing (commit 618b26d52)
Date: Wed, 22 Oct 2008 09:43:12 +0200	[thread overview]
Message-ID: <48FED990.3000507@grandegger.com> (raw)
In-Reply-To: <fa686aa40810211305j48f997bau706477348d025cbe-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

Grant Likely wrote:
> On Tue, Oct 21, 2008 at 12:58 PM, Ira Snyder <iws-lulEs6mt1IksTUYHLfqkUA@public.gmane.org> wrote:
>> Hello,
>>
>> I'm working on a custom board, which is extremely similar to the
>> mpc8349emds board. I've been using a custom dts file, based on the
>> mpc834x_mds.dts file.
>>
>> One of the things that is present on my board are some i2c
>> temp/voltage/current sensors. I've been working on getting drivers for
>> them into mainline, see the lm-sensors list for the patches. I also have
>> adm1031 and adm1032 sensors on the board, which have long been supported
>> in mainline.
>>
>> In very recent kernels, probing is intentionally disabled by commit
>> 618b26d52.
> 
> That is correct
> 
>> Based on the commit message, I examined the
>> arch/powerpc/boot/dts/tqm85*.dts files. I didn't find anything that
>> would serve as a useful example for me.
>>
>> The ePAPR document describing the device tree didn't help either.
>>
>> Could you please give me a simple example of how to re-enable the
>> probing? I have 11 i2c devices on my board, and I'd rather not have a
>> really long kernel command line with tons of "force=" parameters.
> 
> Since probing is unreliable on i2c busses we've made the decision not
> to support it.  Recommended practice is to list your devices in the
> device tree under the i2c bus node; something like this:
> 
>                 i2c@3000 {
>                         #address-cells = <1>;
>                         #size-cells = <0>;
>                         cell-index = <0>;
>                         compatible = "fsl-i2c";
>                         reg = <0x3000 0x100>;
>                         interrupts = <43 2>;
>                         interrupt-parent = <&mpic>;
>                         dfsrr;
> 
>                         rtc@68 {
>                                 compatible = "dallas,ds1337";
>                                 reg = <0x68>;    /* This is the i2c
> address of the device */
>                         };
>                         rtc@XX { /* replace 'XX' with i2c address */
>                                 compatible = "ADI,adm1031";
>                                 reg = <0xXX>;    /* This is the i2c
> address of the device */
>                         };
>                         rtc@YY { /* replace 'YY' with i2c address */
>                                 compatible = "ADI,adm1032";
>                                 reg = <0xYY>;
>                         };
> 
>                         /* etc */
> 
>                 };
> 
> 
> We're not supporting probing any more.  If you *really* want it then
> add a property to the i2c bus binding (documented in
> arch/powerpc/device-tree/) that turns on probing and post it to the
> devicetree-discuss-mnsaURCQ41sdnm+yROfE0A@public.gmane.org and linuxppc-dev-mnsaURCQ41sdnm+yROfE0A@public.gmane.org mailing
> lists.  Just look at commit 618b26d52 to see what flag needs to be
> turned on when the property is present.  Alternately, get your boot
> firmware to do the probing for you and populate the device tree before
> booting the kernel.

BTW, the CPM I2C bus driver currently supports configuration of bus
probing via FDT property "linux,i2c-class", which is even enabled by
default:

 http://lxr.linux.no/linux+v2.6.27/drivers/i2c/busses/i2c-cpm.c#L505

I think bus probing should not be allowed and we should not open a
backdoor via FDT property. Device probing might only necessary for old
style I2C device drivers. Please convert them to new style to solve the
problem.

Wolfgang.

      parent reply	other threads:[~2008-10-22  7:43 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20081021185856.GF22915@ovro.caltech.edu>
     [not found] ` <20081021185856.GF22915-lulEs6mt1IksTUYHLfqkUA@public.gmane.org>
2008-10-21 20:05   ` Freescale i2c probing (commit 618b26d52) Grant Likely
     [not found]     ` <fa686aa40810211305j48f997bau706477348d025cbe-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-10-22  7:43       ` Wolfgang Grandegger [this message]

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=48FED990.3000507@grandegger.com \
    --to=wg-5yr1bzd7o62+xt7jha+gda@public.gmane.org \
    --cc=devicetree-discuss-mnsaURCQ41sdnm+yROfE0A@public.gmane.org \
    --cc=grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org \
    --cc=iws-lulEs6mt1IksTUYHLfqkUA@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox