linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Rob Herring <robh+dt@kernel.org>
To: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>,
	Maxime Ripard <maxime.ripard@free-electrons.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	ML dri-devel <dri-devel@lists.freedesktop.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	Chen-Yu Tsai <wens@csie.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements
Date: Fri, 24 Feb 2017 07:56:18 -0600	[thread overview]
Message-ID: <CAL_JsqKYSKnYzddh+utr9BUth60xVM7fGN_6yxk3tuGTNabUmg@mail.gmail.com> (raw)
In-Reply-To: <1c13f7a8-b355-b985-c02f-a50bebfc86a7@math.uni-bielefeld.de>

On Fri, Feb 17, 2017 at 9:56 AM, Tobias Jakobi
<tjakobi@math.uni-bielefeld.de> wrote:
> Alexandre Belloni wrote:
>> On 17/02/2017 at 13:45:44 +0100, Tobias Jakobi wrote:
>>>> The device tree is a representation of the hardware itself. The state
>>>> of the driver support doesn't change the hardware you're running on,
>>>> just like your BIOS/UEFI on x86 won't change the device it reports to
>>>> Linux based on whether it has a driver for it.
>>> Like Emil already said, the new bindings and the DT entries are solely
>>> introduced to support a proprietary out-of-tree module.
>>>
>>
>> Because device tree describes the hardware, the added binding doesn't
>> support any particular module. The eventually upstreamed drvier will
>> share the same bindings.
> OK, can we then agree that we _only_ merge the bindings and the entries,
> once this driver is upstream?

Absolutely not.

> Driver upstreaming and DT work go hand-in-hand. It's usually after a lot
> of discussion that new bindings get finalised. And for that discussion
> to happen we need to know how the driver uses the information from the
> DT. Otherwise we have no way to evaluate if the description is in any
> way "appropriate".
>
> And no, I don't follow the "DT is a separate/independent thing" thought.
> It maybe is in an ideal world, but we've seen it now often enough that
> bindings turned out to be poorly designed, even though they looked fine
> at first.

Certainly, that happens (though arguably that was more often from lack
of review). But this one is self contained, using standard, existing
properties. I'm not worried about us getting it right. If this was
something new or different, then certainly yes I would want to see the
code.

Rob

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2017-02-24 13:56 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-16 12:43 Tobias Jakobi
2017-02-16 16:54 ` Emil Velikov
2017-02-17 15:44   ` Maxime Ripard
2017-02-17 20:39     ` Emil Velikov
2017-02-24  0:19       ` Maxime Ripard
2017-02-26 12:14         ` Emil Velikov
2017-02-17 21:56     ` Rask Ingemann Lambertsen
2017-02-16 18:45 ` Maxime Ripard
2017-02-17 12:45   ` Tobias Jakobi
2017-02-17 13:20     ` Emil Velikov
2017-02-17 15:42     ` Alexandre Belloni
2017-02-17 15:56       ` Tobias Jakobi
2017-02-24 13:56         ` Rob Herring [this message]
2017-02-17 15:43     ` Maxime Ripard
2017-02-20 16:49       ` Thierry Reding
2017-02-23  0:44         ` Maxime Ripard
  -- strict thread matches above, loose matches on Subject: below --
2017-02-09 16:39 Maxime Ripard

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=CAL_JsqKYSKnYzddh+utr9BUth60xVM7fGN_6yxk3tuGTNabUmg@mail.gmail.com \
    --to=robh+dt@kernel.org \
    --cc=alexandre.belloni@free-electrons.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mark.rutland@arm.com \
    --cc=maxime.ripard@free-electrons.com \
    --cc=thomas.petazzoni@free-electrons.com \
    --cc=tjakobi@math.uni-bielefeld.de \
    --cc=wens@csie.org \
    /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