From: David Gibson <david@gibson.dropbear.id.au>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: linuxppc-dev@ozlabs.org, Timur Tabi <timur@freescale.com>
Subject: Re: [patch 3/3] mpc8349emitx.dts: Add ds1339 RTC
Date: Fri, 28 Sep 2007 12:45:53 +1000 [thread overview]
Message-ID: <20070928024553.GB18840@localhost.localdomain> (raw)
In-Reply-To: <9c20d018e890250443516b886317ceb9@kernel.crashing.org>
On Tue, Sep 25, 2007 at 10:33:58PM +0200, Segher Boessenkool wrote:
> >>> 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.
> >
> > Hrm... perhaps. But is it a realistic danger - I'll have to think
> > more about that.
>
> It is trivial to avoid these dangers completely by not overloading
> the meaning of "device_type".
Hrm. Perhaps.
> >>> 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).
> >
> > Ah.. right. That changes things a bit, in that we might want to
> > include device_type purely for similarity with real OF tree.
>
> You should include the device_type only if you implement its binding,
> and a flat device tree does not, and cannot. (In almost all cases,
> a flat device tree cannot implement device_type's semantics -- this
> means that pretty much the only case where a flat tree should use
> device_type is to have it as a workaround for bad kernel requirements).
I really don't think there's an ambiguity here. A flat-tree can
clearly never implement runtime binding features. This is also true
for a flat tree derived from a real OF, and so full of device_type all
over the place.
> > Real OF has a device_type == "nvram" too, doesn't it?
>
> Yes, same "device support extensions" document.
Erm.. I've lost track amongst our various threads. Which same
document?
> > AFAICT the real
> > OF systems I have (which I think all have ISA-like CMOS RTC/NVRAM
> > chips) the RTC is labelled as "nvram" rather than "rtc".
>
> Sounds buggy.
Why?
[snip]
> > I did find one real OF binding for a different Dallas RTC (and NVRAM),
> > see:
> >
> > http://playground.sun.com/1275/proposals/Closed/Remanded/Accepted/346-
> > it.txt
> >
> > It's a little different from the example above.
>
> That is a binding for the nvram part only, not for the RTC.
Hrm. So how do you suggest we do bindings for combined devices?
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
prev parent reply other threads:[~2007-09-28 2:45 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
2007-09-25 2:11 ` David Gibson
2007-09-25 20:33 ` Segher Boessenkool
2007-09-28 2:45 ` David Gibson [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=20070928024553.GB18840@localhost.localdomain \
--to=david@gibson.dropbear.id.au \
--cc=linuxppc-dev@ozlabs.org \
--cc=segher@kernel.crashing.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox