Re: [PATCH 2/2] dt-bindings: gpio: Add binding for gpio-mockup

[Vincent Whitchurch <vincent.whitchurch@xxxxxxxx>]

On Sun, Sep 16, 2018 at 06:24:52PM -0500, Rob Herring wrote:
> 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@xxxxxxxx> 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.

My original usecase for this was for leds-gpio.  I used the DT bindings
added by this patch and hooked up a leds-gpio via DT in order to develop
userspace.  Once the hardware with the GPIO expander arrived, the mockup
device in the DT was replaced with the expander.  I don't see how a
sysfs interface would allow the same thing.