From: Segher Boessenkool <segher@kernel.crashing.org>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: Timur Tabi <timur@freescale.com>, linuxppc-dev@ozlabs.org
Subject: Re: [patch 3/3] mpc8349emitx.dts: Add ds1339 RTC
Date: Mon, 24 Sep 2007 23:11:28 +0200 [thread overview]
Message-ID: <b312e03ef67dcd6cdc5f57e90da746ef@kernel.crashing.org> (raw)
In-Reply-To: <20070924050709.GM8058@localhost.localdomain>
>> Scott> #size-cells is zero on i2c, so it should just be reg = <68>.
>>
>> Scott> You'll probably need to add #address-cells and #size-cells to
>> the
>> Scott> controller node, as well.
>
> Uh.. yes.. i2c interfaces should really always have #a and #s.
More generally, every node that defines a bus needs it (unless the
defaults of 2 resp. 1 are correct for this bus, but even then you
might want it because it makes things more explicit).
>> i2c@3100 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> device_type = "i2c";
>
> Hrm... we probably want an "i2c" device_type class, but I don't think
> we've actually defined one, which is a problem
By defining new device_type's, or new semantics for device_type,
you open the door to (accidentally) becoming incompatible with
"real" OF.
And you don't need to: "real" OF has a mechanism for specifying
the "generic device class" already, if you use the "generic names"
recommended practice (and you do, for both this node and the rtc
node): it's the generic name itself!
>> + rtc@68 {
>> + device_type = "rtc";
>> + compatible = "dallas,ds1339";
>> + reg = <68>;
>> + };
>
> I think we want to think a bit more carefully about how to do bindings
> for RTC devices. No "rtc" device_type is defined, but again we might
> want to.
Actually, "device_type" = "rtc" _is_ defined (in the "device support
extensions" recommended practice), and there is no useful way a flat
device tree can implement it (it merely defines get-time and set-time
methods).
> The fact that NVRAM+RTC chips are so common is a bit of an issue from
> the point of view of defining a device class binding - a device can't
> have type "rtc" and "nvram".
You should match OS drivers on "compatible" only anyway.
Those cases where OS drivers don't nicely 1-1 match device nodes are a
bit of a headache; for RTC/NVRAM devices, these problems are nicely
side-stepped by handling this from platform code.
Segher
next prev parent reply other threads:[~2007-09-24 21:11 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-20 10:42 [patch 0/3] fsl_soc / mpc8349emitx patches Peter Korsgaard
2007-09-20 10:42 ` [patch 1/3] fsl_soc: Fix trivial printk typo Peter Korsgaard
2007-09-20 10:42 ` [patch 2/3] fsl_soc: rtc-ds1307 support Peter Korsgaard
2007-09-20 10:42 ` [patch 3/3] mpc8349emitx.dts: Add ds1339 RTC Peter Korsgaard
2007-09-20 13:35 ` Scott Wood
2007-09-21 7:35 ` Peter Korsgaard
2007-09-24 5:07 ` David Gibson
2007-09-24 5:52 ` Peter Korsgaard
2007-09-25 2:13 ` David Gibson
2007-09-25 5:33 ` Peter Korsgaard
2007-09-25 5:47 ` David Gibson
2007-09-24 6:13 ` Kumar Gala
2007-09-24 14:52 ` Scott Wood
2007-09-25 2:04 ` David Gibson
2007-09-24 21:11 ` Segher Boessenkool [this message]
2007-09-25 2:11 ` David Gibson
2007-09-25 20:33 ` Segher Boessenkool
2007-09-28 2:45 ` David Gibson
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=b312e03ef67dcd6cdc5f57e90da746ef@kernel.crashing.org \
--to=segher@kernel.crashing.org \
--cc=david@gibson.dropbear.id.au \
--cc=linuxppc-dev@ozlabs.org \
--cc=timur@freescale.com \
/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.