From: timur@tabi.org (Timur Tabi)
To: linux-arm-kernel@lists.infradead.org
Subject: 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.
WARNING: multiple messages have this Message-ID (diff)
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.
next prev parent reply other threads:[~2016-09-12 13:23 UTC|newest]
Thread overview: 71+ 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-24 14:29 ` Sebastian Frias
2016-08-28 20:36 ` ARM, SoC: " Timur Tabi
2016-08-28 20:36 ` ARM,SoC: " Timur Tabi
2016-08-28 20:36 ` ARM, SoC: " Timur Tabi
2016-09-12 12:29 ` Sebastian Frias
2016-09-12 12:29 ` ARM,SoC: " Sebastian Frias
2016-09-12 12:38 ` ARM, SoC: " Mark Rutland
2016-09-12 12:38 ` ARM,SoC: " Mark Rutland
2016-09-12 12:38 ` Mark Rutland
2016-09-12 13:15 ` ARM, SoC: " Sebastian Frias
2016-09-12 13:15 ` ARM,SoC: " Sebastian Frias
2016-09-12 13:23 ` Timur Tabi [this message]
2016-09-12 13:23 ` Timur Tabi
2016-09-12 14:01 ` ARM, SoC: " Mark Rutland
2016-09-12 14:01 ` Mark Rutland
2016-09-12 14:26 ` Warner Losh
2016-09-12 14:26 ` Warner Losh
2016-09-12 14:26 ` Warner Losh
2016-09-12 16:29 ` Sebastian Frias
2016-09-12 16:29 ` Sebastian Frias
2016-09-12 16:45 ` Warner Losh
2016-09-12 16:45 ` Warner Losh
2016-09-12 16:49 ` Timur Tabi
2016-09-12 16:49 ` Timur Tabi
2016-09-12 17:07 ` Mark Rutland
2016-09-12 17:07 ` Mark Rutland
2016-09-12 17:06 ` Mark Rutland
2016-09-12 17:06 ` Mark Rutland
2016-09-12 17:06 ` Mark Rutland
2016-09-12 16:07 ` Sebastian Frias
2016-09-12 16:07 ` Sebastian Frias
2016-09-12 16:07 ` Sebastian Frias
2016-09-12 16:21 ` Timur Tabi
2016-09-12 16:21 ` Timur Tabi
2016-09-12 16:21 ` Timur Tabi
2016-09-12 16:26 ` Sebastian Frias
2016-09-12 16:26 ` Sebastian Frias
2016-09-12 16:26 ` Sebastian Frias
2016-09-12 16:56 ` Mark Rutland
2016-09-12 16:56 ` Mark Rutland
2016-09-12 16:56 ` Mark Rutland
2016-09-13 10:04 ` Sebastian Frias
2016-09-13 10:04 ` Sebastian Frias
2016-09-13 10:04 ` Sebastian Frias
2016-09-13 11:37 ` Timur Tabi
2016-09-13 11:37 ` Timur Tabi
2016-09-13 11:37 ` Timur Tabi
2016-09-13 13:23 ` Mark Rutland
2016-09-13 13:23 ` Mark Rutland
2016-09-13 13:23 ` Mark Rutland
2016-09-13 13:12 ` Mark Rutland
2016-09-13 13:12 ` Mark Rutland
2016-09-13 13:12 ` Mark Rutland
2016-09-13 14:22 ` Sebastian Frias
2016-09-13 14:22 ` Sebastian Frias
2016-09-13 14:22 ` Sebastian Frias
2016-09-13 14:51 ` Mark Rutland
2016-09-13 14:51 ` Mark Rutland
2016-09-13 14:51 ` Mark Rutland
2016-09-14 8:32 ` Sebastian Frias
2016-09-14 8:32 ` Sebastian Frias
2016-09-14 8:32 ` Sebastian Frias
2016-09-13 14:55 ` Sebastian Frias
2016-09-13 14:55 ` Sebastian Frias
2016-09-13 14:55 ` Sebastian Frias
2016-09-13 15:47 ` Mark Rutland
2016-09-13 15:47 ` Mark Rutland
2016-09-13 15:47 ` Mark Rutland
2016-09-14 8:24 ` Sebastian Frias
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=linux-arm-kernel@lists.infradead.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 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.