All of lore.kernel.org
 help / color / mirror / Atom feed
From: mark.rutland@arm.com (Mark Rutland)
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 13:38:09 +0100	[thread overview]
Message-ID: <20160912123809.GB13741@leverpostej> (raw)
In-Reply-To: <57D69FB1.2020801@laposte.net>

On Mon, Sep 12, 2016 at 02:29:37PM +0200, Sebastian Frias wrote:
> 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.

I don't follow this part entirely. Why are you expecting thrid parties
to write a driver for those blocks rather than upstreaming a driver for
them?

> 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.

I would generally agree that the hardware should be described in DT.
The difficulty is that without a 'real' user it's not always possible to
tell if we're describing the thing correctly.

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.

> 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.

Unfortunately, I think that the area is sufficiently vague that there
simply is no clear and general answer.

For the sake of discussion, an example of a particular block, along with
what you expect/need to describe would be helpful.

Thanks,
Mark.

WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
To: Sebastian Frias <sf84-QFKgK+z4sOrR7s880joybQ@public.gmane.org>
Cc: Timur Tabi <timur-N01EOCouUvQ@public.gmane.org>,
	devicetree <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Linux ARM
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	Mason <slash.tmp-GANU6spQydw@public.gmane.org>
Subject: Re: ARM,SoC: About the use DT-defined properties by 3rd-party drivers
Date: Mon, 12 Sep 2016 13:38:09 +0100	[thread overview]
Message-ID: <20160912123809.GB13741@leverpostej> (raw)
In-Reply-To: <57D69FB1.2020801-QFKgK+z4sOrR7s880joybQ@public.gmane.org>

On Mon, Sep 12, 2016 at 02:29:37PM +0200, Sebastian Frias wrote:
> 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.

I don't follow this part entirely. Why are you expecting thrid parties
to write a driver for those blocks rather than upstreaming a driver for
them?

> 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.

I would generally agree that the hardware should be described in DT.
The difficulty is that without a 'real' user it's not always possible to
tell if we're describing the thing correctly.

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.

> 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.

Unfortunately, I think that the area is sufficiently vague that there
simply is no clear and general answer.

For the sake of discussion, an example of a particular block, along with
what you expect/need to describe would be helpful.

Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com>
To: Sebastian Frias <sf84@laposte.net>
Cc: Timur Tabi <timur@tabi.org>,
	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 13:38:09 +0100	[thread overview]
Message-ID: <20160912123809.GB13741@leverpostej> (raw)
In-Reply-To: <57D69FB1.2020801@laposte.net>

On Mon, Sep 12, 2016 at 02:29:37PM +0200, Sebastian Frias wrote:
> 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.

I don't follow this part entirely. Why are you expecting thrid parties
to write a driver for those blocks rather than upstreaming a driver for
them?

> 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.

I would generally agree that the hardware should be described in DT.
The difficulty is that without a 'real' user it's not always possible to
tell if we're describing the thing correctly.

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.

> 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.

Unfortunately, I think that the area is sufficiently vague that there
simply is no clear and general answer.

For the sake of discussion, an example of a particular block, along with
what you expect/need to describe would be helpful.

Thanks,
Mark.

  reply	other threads:[~2016-09-12 12:38 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     ` Mark Rutland [this message]
2016-09-12 12:38       ` 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         ` ARM, SoC: " Timur Tabi
2016-09-12 13:23           ` ARM,SoC: " 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=20160912123809.GB13741@leverpostej \
    --to=mark.rutland@arm.com \
    --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.