[patch 3/3] mpc8349emitx.dts: Add ds1339 RTC
segher at kernel.crashing.org
Wed Sep 26 06:33:58 EST 2007
>>> 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".
>>> I think we want to think a bit more carefully about how to do
>>> 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
> 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).
> Real OF has a device_type == "nvram" too, doesn't it?
Yes, same "device support extensions" 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".
>>> 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.
> Absolutely. I was only thinking of defining "device classes" where
> for some reason it is useful to examine them without needing to pick a
> particular driver.
Yeah I understand. In what situations would this be useful?
Answering that question will make the requirements for this more
clear; or maybe it will show we do not need this at all.
>> 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.
> Not necessarily. The new RTC class drivers are just drivers like
> anything other and are not especially instantiated from the platform
I meant "can be nicely side-stepped", or "usually are ..." :-)
Obviously, when you cannot avoid the problem, you have a problem.
> And drat. I was only really mentioning stuff about device_type in
> passing, but it's the only thing anyone's responded to. I was also
> mostly suggesting changing the format of compatible, for greater
> similarity with the existing ds1385 binding.
Okay, quoting from your earlier message:
> I did find one real OF binding for a different Dallas RTC (and NVRAM),
> It's a little different from the example above.
That is a binding for the nvram part only, not for the RTC.
More information about the Linuxppc-dev