All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Jason Cooper <jason@lakedaemon.net>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Marc Zyngier <Marc.Zyngier@arm.com>,
	"arm@kernel.org" <arm@kernel.org>,
	Olof Johansson <olof@lixom.net>,
	Thomas Gleixner <tglx@linutronix.de>,
	Linux ARM Kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: irqchip heirarchy DT "break" series awareness?
Date: Tue, 7 Apr 2015 14:37:04 +0100	[thread overview]
Message-ID: <20150407133703.GF4394@leverpostej> (raw)
In-Reply-To: <20150407130638.GE7873@io.lakedaemon.net>

> > If the relationship between the GIC and the shadow interrupt controllers
> > had been described, we would have avoided breaking the compatibility. I
> > guess it was too tempting to reuse pre-DT mechanisms and to forget about
> > this entirely.
> 
> I'm not sure tempting is the right word.  Everyone has known since this
> project began that we were striving to describe the hardware.  I suspect
> the reason we got to where we are is that people *assumed* the code was
> describing the hardware, and so wrote bindings reflecting their
> understanding.  iow, we don't have enough hardware engineers reviewing
> bindings :-P

FWIW when routable-irqs was introduced I negatively reviewed it, stating
that it was backwards, and that the crossbar driver should request the
appropriate domain dynamically [1]. We _knew_ it was wrong at the time,
but people decided to ignore that review because it was easier to do
things in a broken way.

A more general issue is that people hack in the minimal amount of DT
parsing code to an existing driver and rely on platform data and code to
do the heavy lifting, rather than doing a clean break with DT (which
would highlight deficiencies in the bndings). You end up with the worst
of both worlds, because you depend on both an incomplete DT and
implementation-specific platform data/code.

Mark.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-November/211530.html

WARNING: multiple messages have this Message-ID (diff)
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: irqchip heirarchy DT "break" series awareness?
Date: Tue, 7 Apr 2015 14:37:04 +0100	[thread overview]
Message-ID: <20150407133703.GF4394@leverpostej> (raw)
In-Reply-To: <20150407130638.GE7873@io.lakedaemon.net>

> > If the relationship between the GIC and the shadow interrupt controllers
> > had been described, we would have avoided breaking the compatibility. I
> > guess it was too tempting to reuse pre-DT mechanisms and to forget about
> > this entirely.
> 
> I'm not sure tempting is the right word.  Everyone has known since this
> project began that we were striving to describe the hardware.  I suspect
> the reason we got to where we are is that people *assumed* the code was
> describing the hardware, and so wrote bindings reflecting their
> understanding.  iow, we don't have enough hardware engineers reviewing
> bindings :-P

FWIW when routable-irqs was introduced I negatively reviewed it, stating
that it was backwards, and that the crossbar driver should request the
appropriate domain dynamically [1]. We _knew_ it was wrong at the time,
but people decided to ignore that review because it was easier to do
things in a broken way.

A more general issue is that people hack in the minimal amount of DT
parsing code to an existing driver and rely on platform data and code to
do the heavy lifting, rather than doing a clean break with DT (which
would highlight deficiencies in the bndings). You end up with the worst
of both worlds, because you depend on both an incomplete DT and
implementation-specific platform data/code.

Mark.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-November/211530.html

  reply	other threads:[~2015-04-07 13:37 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-06 14:46 irqchip heirarchy DT "break" series awareness? Jason Cooper
2015-04-06 14:46 ` Jason Cooper
     [not found] ` <20150406144647.GC7873-fahSIxCzskDQ+YiMSub0/l6hYfS7NtTn@public.gmane.org>
2015-04-07  9:59   ` Thomas Petazzoni
2015-04-07  9:59     ` Thomas Petazzoni
     [not found]     ` <20150407115922.5d4c6233-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
2015-04-07 10:21       ` Marc Zyngier
2015-04-07 10:21         ` Marc Zyngier
     [not found]         ` <5523AFAF.6040000-5wv7dgnIgG8@public.gmane.org>
2015-04-07 13:06           ` Jason Cooper
2015-04-07 13:06             ` Jason Cooper
2015-04-07 13:37             ` Mark Rutland [this message]
2015-04-07 13:37               ` Mark Rutland
2015-04-07 12:40       ` Jason Cooper
2015-04-07 12:40         ` Jason Cooper
     [not found]         ` <20150407124016.GD7873-fahSIxCzskDQ+YiMSub0/l6hYfS7NtTn@public.gmane.org>
2015-04-07 12:49           ` Thomas Petazzoni
2015-04-07 12:49             ` Thomas Petazzoni

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=20150407133703.GF4394@leverpostej \
    --to=mark.rutland@arm.com \
    --cc=Marc.Zyngier@arm.com \
    --cc=arm@kernel.org \
    --cc=arnd@arndb.de \
    --cc=devicetree@vger.kernel.org \
    --cc=jason@lakedaemon.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=olof@lixom.net \
    --cc=tglx@linutronix.de \
    --cc=thomas.petazzoni@free-electrons.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.