devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Bartosz Golaszewski <brgl@bgdev.pl>,
	vincent.whitchurch@axis.com,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>, Rabin Vincent <rabinv@axis.com>
Subject: Re: [PATCH 2/2] dt-bindings: gpio: Add binding for gpio-mockup
Date: Sun, 16 Sep 2018 18:24:52 -0500	[thread overview]
Message-ID: <5b9f3f64.1c69fb81.6cb6.b5ef@mx.google.com> (raw)
In-Reply-To: <CACRpkdaFsdk8LKOQcQ4pab1J_LKo8+StCF9f93+1PX_0hm+Cug@mail.gmail.com>

On Thu, Sep 06, 2018 at 02:47:23PM +0200, Linus Walleij wrote:
> On Thu, Sep 6, 2018 at 1:09 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> 
> > Do we even need DT bindings for this? Device tree bindings mean that
> > we commit to a stable interface so that once a device with given DT
> > blob is released, it will work on every future kernel. Also: DT should
> > only include information about actual HW, not operating system
> > concepts. Meanwhile this is for testing purposes only and it won't end
> > up in any actual DT source file upstream.
> 
> Hm that relates to another discussion I have with the DT maintainers
> about a virtualized display panel.
> 
> I do not know how the DT maintainers feel about supporting things
> in the kernel that uses DT infrastructure and specially tailored
> device trees but include elements with no formal device tree
> bindings. Would be interesting to hear their thoughts on this.

I have one usecase in mind where I think it is valid, but for this case 
in particular, I think it would be better to just provide a sysfs 
interface. If there's no GPIO binding connections to this mockup 
controller, there's no real need for DT. OTOH, if this device allowed 
building a test framework for all the other GPIO based drivers and 
bindings such as LED, PWM, bitbanged buses, etc.

The case I have in mind is where you want to attach a fake DT node to a 
non-DT device for the purposes of defining other downstream devices. For 
example, an FTDI USB to serial chip with downstream SPI, UART, I2C, 
GPIO, etc. devices attached. This could be on an x86 which doesn't have 
a base DT.

Rob

  reply	other threads:[~2018-09-16 23:24 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-05 13:26 [PATCH 1/2] gpio: mockup: Allow probing from device tree Vincent Whitchurch
2018-09-05 13:26 ` [PATCH 2/2] dt-bindings: gpio: Add binding for gpio-mockup Vincent Whitchurch
2018-09-06 10:16   ` Linus Walleij
2018-09-06 11:09     ` Bartosz Golaszewski
2018-09-06 12:47       ` Linus Walleij
2018-09-16 23:24         ` Rob Herring [this message]
2018-09-18 11:25           ` Vincent Whitchurch
2018-09-24 20:39             ` Rob Herring
2018-09-06 10:25 ` [PATCH 1/2] gpio: mockup: Allow probing from device tree Linus Walleij
2018-09-06 16:29 ` Bartosz Golaszewski
2018-09-10  7:05   ` Linus Walleij
2018-09-20 16:28     ` Bartosz Golaszewski
2018-09-21 15:46       ` Linus Walleij

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=5b9f3f64.1c69fb81.6cb6.b5ef@mx.google.com \
    --to=robh@kernel.org \
    --cc=brgl@bgdev.pl \
    --cc=devicetree@vger.kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=rabinv@axis.com \
    --cc=vincent.whitchurch@axis.com \
    /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).