From: Sebastian Frias <sf84@laposte.net>
To: Timur Tabi <timur@tabi.org>
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 14:29:37 +0200 [thread overview]
Message-ID: <57D69FB1.2020801@laposte.net> (raw)
In-Reply-To: <CAOZdJXVjsR3NTWiJX33yT3jYk=FU65raWoMooTLD7OMN3sqP-A@mail.gmail.com>
Hi Timur,
On 08/28/2016 10:36 PM, Timur Tabi wrote:
> On Wed, Aug 24, 2016 at 9:29 AM, Sebastian Frias <sf84@laposte.net> wrote:
>>
>> If this is really not possible, it forces the SoC manufacturer to expose
>> those properties in a different way, thus wasting a (seemingly) perfectly
>> fine way of doing so: the DT and its documentation.
>
> When you submit a new driver upstream, that patch also includes the
> new device tree nodes and documentation for those nodes. Everything
> is peer-reviewed together. I don't understand what you think the
> problem is.
>
Thanks for your comment and sorry for the late reply.
My question is about submitting DT properties/nodes (describing some HW) for
which there is no Linux driver. Like register addresses for HW blocks,
including HW capabilities of said HW blocks, which may or may not be setup
by Linux directly.
The idea being that since DT describes the HW and is usually shared with the
bootloader (yet stored in the Linux kernel tree), all layers of the stack
could use the same DT and each layer would use relevant properties. So the
DT would describe the whole SoC even if not all HW blocks have a Linux
driver.
3rd party users of said SoC could then write kernel modules for such HW
blocks using the DT description. The DT would thus become the authoritative
source of information regarding register programming for the SoC.
Currently, HW blocks for which there is no public driver (that it is
accessed through user-mode libraries or firmware) require a separate
HW description (be it Documentation, headers, etc.)
Since the DT describes the HW, it would make sense to expose the HW through
DT, that would centralise the HW description.
However, after discussing over IRC, it looks like there was no guidance on
this. Some people think submitting DT properties/nodes without a corresponding
Linux driver is frowned upon, while others thought it was an odd limitation
and suggested asking here.
Does that clarifies the scope of the question?
Best regards,
Sebastian
next prev parent reply other threads:[~2016-09-12 12:29 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 [this message]
2016-09-12 12:38 ` Mark Rutland
2016-09-12 13:15 ` Sebastian Frias
2016-09-12 13:23 ` Timur Tabi
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=57D69FB1.2020801@laposte.net \
--to=sf84@laposte.net \
--cc=devicetree@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=slash.tmp@free.fr \
--cc=timur@tabi.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;
as well as URLs for NNTP newsgroup(s).