From: Anton Vorontsov <avorontsov@ru.mvista.com>
To: Scott Wood <scottwood@freescale.com>
Cc: Linuxppc-dev Development <linuxppc-dev@ozlabs.org>,
Timur Tabi <timur@freescale.com>
Subject: Re: removing get_immrbase()??
Date: Thu, 23 Apr 2009 20:54:30 +0400 [thread overview]
Message-ID: <20090423165430.GA8355@oksana.dev.rtsoft.ru> (raw)
In-Reply-To: <20090423160048.GC19717@ld0162-tx32.am.freescale.net>
On Thu, Apr 23, 2009 at 11:00:48AM -0500, Scott Wood wrote:
> On Thu, Apr 23, 2009 at 05:50:05PM +0400, Anton Vorontsov wrote:
> > As for Freescale parts, all the reference board I've seen were
> > very friendly wrt upgrading their device-trees, i.e. none of
> > the boards were shipping with device-tree soldered into the
> > firmware.
>
> But many of them have broken when a dtb that u-boot didn't like was
> inserted.
Yes, I agree here. And I'm not going to contradict on this
matter. If we stick with these two rules, I think we should always
be OK:
(1) We should avoid any changes that might break compatibility with
an officially supported firmware;
(2) Breaking "new Linux" <-> "old device tree" compatibility should
be OK if (1) is satisfied.
Note that this applies only for targets that have no problem w/
device-tree upgrades.
> > And note that most developers are using up-to-date firmwares
> > (U-Boots), device trees, and kernels.
>
> So then why did we have to make cuImage?
I don't know. I've never used them. ;-) Honestly. But I believe
it's a great stuff for those who use really old and now unsupported
firmwares.
It has nothing to do with device-tree changes though. We can easily
maintain device-tree compatibility w/ firmwares, but what is the
point in maintaining Linux' compatibility for older device trees
when you can easily upgrade it?
That is, I still don't get why somebody don't want to upgrade
device tree along with Linux (assuming it won't cause breakages in
the firmware)?
[...]
> > Sure, there is a completely different story wrt device-tree
> > changes that might break firmwares. And that I believe we'd
> > better avoid. For example device_type = "soc", if removed,
> > most firmwares would not fix-up {clock,bus}-frequency properties.
>
> Even if the given change may not break the firmware, it could force an
> update in which a prior change breaks the firmware.
I'm not sure I'm following here. Could you give an example?
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
next prev parent reply other threads:[~2009-04-23 16:54 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-22 18:38 removing get_immrbase()?? Kumar Gala
2009-04-22 19:35 ` Timur Tabi
2009-04-22 20:16 ` Scott Wood
2009-04-22 20:16 ` Timur Tabi
2009-04-22 20:20 ` Scott Wood
2009-04-22 21:31 ` Kumar Gala
2009-04-22 21:33 ` Timur Tabi
2009-04-22 21:39 ` Kumar Gala
2009-04-22 21:46 ` Timur Tabi
2009-04-22 21:54 ` Kumar Gala
2009-04-22 21:57 ` Timur Tabi
2009-04-22 22:07 ` Kumar Gala
2009-04-22 22:00 ` Scott Wood
2009-04-22 22:00 ` Timur Tabi
2009-04-23 13:54 ` Grant Likely
2009-04-22 21:38 ` Scott Wood
2009-04-22 21:55 ` Kumar Gala
2009-04-22 22:33 ` Scott Wood
2009-04-23 0:03 ` Timur Tabi
2009-04-23 2:26 ` David Gibson
2009-04-23 3:36 ` Kumar Gala
2009-04-23 4:06 ` David Gibson
2009-04-23 4:41 ` Kumar Gala
2009-04-28 4:12 ` David Gibson
2009-04-28 13:48 ` Timur Tabi
2009-04-23 13:07 ` Timur Tabi
2009-04-23 15:56 ` Scott Wood
2009-04-23 13:02 ` Timur Tabi
2009-04-23 13:50 ` Anton Vorontsov
2009-04-23 14:02 ` Timur Tabi
2009-04-23 14:06 ` Kumar Gala
2009-04-23 14:09 ` Timur Tabi
2009-04-24 14:40 ` Wrobel Heinz-R39252
2009-04-23 14:13 ` Anton Vorontsov
2009-04-23 16:00 ` Scott Wood
2009-04-23 16:54 ` Anton Vorontsov [this message]
2009-04-23 17:03 ` Scott Wood
2009-04-23 17:26 ` Anton Vorontsov
2009-04-23 17:59 ` Scott Wood
2009-04-28 4:25 ` David Gibson
2009-04-28 4:21 ` David Gibson
2009-04-23 13:53 ` Grant Likely
2009-04-23 14:03 ` Anton Vorontsov
2009-04-28 4:26 ` David Gibson
2009-04-22 19:44 ` Scott Wood
2009-04-22 20:00 ` Kumar Gala
2009-04-22 20:30 ` Scott Wood
2009-04-23 13:53 ` Arnd Bergmann
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=20090423165430.GA8355@oksana.dev.rtsoft.ru \
--to=avorontsov@ru.mvista.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=scottwood@freescale.com \
--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.