linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Walleij <linus.walleij@linaro.org>
To: "H. Nikolaus Schaller" <hns@goldelico.com>
Cc: Sven Van Asbroeck <thesven73@gmail.com>,
	Mark Brown <broonie@kernel.org>,
	kernel list <linux-kernel@vger.kernel.org>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Discussions about the Letux Kernel 
	<letux-kernel@openphoenux.org>,
	Andreas Kemnade <andreas@kemnade.info>
Subject: Re: [BUG] SPI broken for SPI based panel drivers
Date: Tue, 1 Dec 2020 23:51:26 +0100	[thread overview]
Message-ID: <CACRpkdYNL=PbWgf9wdKpiC2y1iZFG-ZD47O8u2a22zzGus9P2Q@mail.gmail.com> (raw)
In-Reply-To: <BD3995F3-F4E6-4DC9-B0B9-5DCD6655F049@goldelico.com>

On Tue, Dec 1, 2020 at 6:13 PM H. Nikolaus Schaller <hns@goldelico.com> wrote:

> I am not sure if DT maintainers accept that we revert a DT change just to
> handle some change in a driver. Usually they insist on fixing a driver and
> live with the DT. DT is carved in stone or could be ROM...

I usually use this rough consensus: is the DTB flashed into millions of
devices and supplied to the kernel using some bootloader, and
is the kernel upgraded on the device without also upgrading the
DTB?

And I mean in practice, not in theory.

So whether the DTB ABI can be changed or not is a practical
deployment question, not a religious sacrament. It came from systems
such as Sun machines where the DTB was, indeed, in a PROM,
and indeed intended for SunOS so Linux had no control over
it. We had to just treat it as static ABI.

If the actual situation is different, sucn as kernel and DTB are
always updated together, or those are a few custom systems in
a factory floor (not millions of mobile phones or laptops) then
it is fine to change it occasionally even if it is seen as "bad".

Yours,
Linus Walleij

  parent reply	other threads:[~2020-12-01 22:52 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-30 19:03 [BUG] SPI broken for SPI based panel drivers H. Nikolaus Schaller
2020-11-30 20:13 ` Sven Van Asbroeck
2020-11-30 20:22   ` Sven Van Asbroeck
2020-12-01  8:59   ` H. Nikolaus Schaller
2020-12-01 12:16     ` Mark Brown
2020-12-01 14:05       ` H. Nikolaus Schaller
2020-12-01 14:20         ` Linus Walleij
2020-12-01 14:34           ` Sven Van Asbroeck
2020-12-01 14:35           ` H. Nikolaus Schaller
2020-12-01 15:52             ` Sven Van Asbroeck
2020-12-01 16:46               ` H. Nikolaus Schaller
2020-12-01 16:10             ` Sven Van Asbroeck
2020-12-01 16:39               ` H. Nikolaus Schaller
2020-12-01 16:53                 ` Sven Van Asbroeck
2020-12-01 17:10                   ` H. Nikolaus Schaller
2020-12-01 18:43                     ` Sven Van Asbroeck
2020-12-02 12:19                       ` Mark Brown
2020-12-04 10:08                       ` H. Nikolaus Schaller
2020-12-04 13:46                         ` Sven Van Asbroeck
2020-12-04 16:49                           ` H. Nikolaus Schaller
2020-12-04 19:19                             ` Sven Van Asbroeck
2020-12-04 21:31                               ` H. Nikolaus Schaller
2020-12-05  0:25                             ` Linus Walleij
2020-12-05  7:04                               ` H. Nikolaus Schaller
2020-12-09  8:04                                 ` Andreas Kemnade
2020-12-09  8:40                                   ` H. Nikolaus Schaller
2020-12-09  8:38                                 ` Linus Walleij
2020-12-09  8:45                                   ` H. Nikolaus Schaller
2020-12-01 22:51                     ` Linus Walleij [this message]
2020-12-01 16:44               ` [Letux-kernel] " Andreas Kemnade
2020-12-01 16:51                 ` H. Nikolaus Schaller
2020-12-01 16:52                 ` H. Nikolaus Schaller
2020-12-01 16:55                 ` Sven Van Asbroeck
2020-12-01 16:20           ` Mark Brown
2020-12-01 16:41             ` H. Nikolaus Schaller
2020-12-01 17:11               ` Mark Brown
2020-12-01 12:41     ` Sven Van Asbroeck
2020-12-01 13:32       ` H. Nikolaus Schaller
2020-12-01 14:08         ` Sven Van Asbroeck
2020-12-01 15:33           ` Mark Brown
2020-12-05 20:57   ` Pavel Machek
2020-12-07 13:43     ` Mark Brown

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='CACRpkdYNL=PbWgf9wdKpiC2y1iZFG-ZD47O8u2a22zzGus9P2Q@mail.gmail.com' \
    --to=linus.walleij@linaro.org \
    --cc=andreas@kemnade.info \
    --cc=broonie@kernel.org \
    --cc=hns@goldelico.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=letux-kernel@openphoenux.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=thesven73@gmail.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).