linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Timur Tabi <timur@tabi.org>
To: Sebastian Frias <sf84@laposte.net>, Mark Rutland <mark.rutland@arm.com>
Cc: devicetree <devicetree@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Mason <slash.tmp@free.fr>
Subject: Re: ARM,SoC: About the use DT-defined properties by 3rd-party drivers
Date: Mon, 12 Sep 2016 08:23:59 -0500	[thread overview]
Message-ID: <57D6AC6F.5040504@tabi.org> (raw)
In-Reply-To: <57D6AA54.6000208@laposte.net>

Sebastian Frias wrote:
> 3rd parties could choose to write a driver (as opposed to use say, a user-mode
> library) if it fits their programming model better, if they think they would
> have better performance, or other reasons.
>
> The main idea is to make DT the authoritative source of HW description.

Do you really expect the open-source community to make a serious effort 
to support out-of-tree drivers written by developers who have no 
intention of upstreaming?

There's a process for writing a Linux kernel driver with a DT binding. 
That process is not broken.

>> >Putting smoething together that's only sufficient to support some
>> >out-of-tree driver with implicit assumptions that we are not aware of is
>> >far from fantastic.
> That does not seem very positive and it is not the case anyway, otherwise we
> would not be consulting here:-)

Mark is correct.  Trying to create a device tree binding, and getting it 
correct 100% the first time, without an actual drivers is just 
impossible.  To even attempt that is folly.

> Agreed, right now this whole thing seems like a really hypothetical question,

Yes, it is.

> but the intention is good.

I'm not sure I agree with that.

> Actually, I think it would encourage more SoC manufacturers to use DT as a way
> to document their HW, which is a good thing.

No it isn't.  SOC manufacturers should just release the documentation 
they have.

> But if I understood correctly your comment, you are basically saying that
> without an example is hard to say.
> Since the question seems understood, do you have an example of other SoC's
> doing something similar?

Similar to what?  Every upstream driver today is written the way we're 
talking about -- submit the driver with the binding, and both are 
reviewed together.

> I've seen some big DT descriptions, but it is difficult to know if we are the
> first ones trying to use the DT in this way.

Hopefully, you'll be the last.

  reply	other threads:[~2016-09-12 13:24 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-24 14:29 ARM,SoC: About the use DT-defined properties by 3rd-party drivers Sebastian Frias
2016-08-28 20:36 ` Timur Tabi
2016-09-12 12:29   ` Sebastian Frias
2016-09-12 12:38     ` Mark Rutland
2016-09-12 13:15       ` Sebastian Frias
2016-09-12 13:23         ` Timur Tabi [this message]
2016-09-12 14:01         ` ARM, SoC: " Mark Rutland
2016-09-12 14:26           ` Warner Losh
2016-09-12 16:29             ` Sebastian Frias
2016-09-12 16:45               ` Warner Losh
2016-09-12 16:49                 ` Timur Tabi
2016-09-12 17:07                   ` Mark Rutland
2016-09-12 17:06                 ` Mark Rutland
2016-09-12 16:07           ` Sebastian Frias
2016-09-12 16:21             ` Timur Tabi
2016-09-12 16:26             ` Sebastian Frias
2016-09-12 16:56             ` Mark Rutland
2016-09-13 10:04               ` Sebastian Frias
2016-09-13 11:37                 ` Timur Tabi
2016-09-13 13:23                   ` Mark Rutland
2016-09-13 13:12                 ` Mark Rutland
2016-09-13 14:22                   ` Sebastian Frias
2016-09-13 14:51                     ` Mark Rutland
2016-09-14  8:32                       ` Sebastian Frias
2016-09-13 14:55                   ` Sebastian Frias
2016-09-13 15:47                     ` Mark Rutland
2016-09-14  8:24                       ` Sebastian Frias

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=57D6AC6F.5040504@tabi.org \
    --to=timur@tabi.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=sf84@laposte.net \
    --cc=slash.tmp@free.fr \
    /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).