linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).