| Message ID | 20180905132618.31274-2-vincent.whitchurch@axis.com |
|---|---|
| State | Changes Requested, archived |
| Headers | show |
| Series | None | expand |
Hi Vincent, thanks for the patch! Including Bartosz who is kind of default maintainer for this component. On Wed, Sep 5, 2018 at 3:26 PM Vincent Whitchurch <vincent.whitchurch@axis.com> wrote: > > This is a dummy GPIO controller which can be used in place of the real > hardware GPIO controller (for example, an external GPIO expander) before > actual hardware is available. > > Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com> This looks generally helpful. I don't know what the DT maintainers think, but I am positive, I think rapid prototyping is a valid usecase. We used to have the driver for testing only but this usecase is just as valid. > +Required properties: > +- compatible: Should contain "gpio-mockup" > +- gpio-controller : Marks the device node as a gpio controller. > +- #gpio-cells : Should be two. The first cell is the pin number and > + the second cell is used to specify the gpio polarity: > + 0 = active high > + 1 = active low > +- nr-gpios: The number of dummy GPIOs For this there is a standardized binding "ngpios" in gpio.txt so just use that and reference gpio.txt please. Yours, Linus Walleij
2018-09-06 12:16 GMT+02:00 Linus Walleij <linus.walleij@linaro.org>: > Hi Vincent, thanks for the patch! > > Including Bartosz who is kind of default maintainer for this component. > > On Wed, Sep 5, 2018 at 3:26 PM Vincent Whitchurch > <vincent.whitchurch@axis.com> wrote: >> >> This is a dummy GPIO controller which can be used in place of the real >> hardware GPIO controller (for example, an external GPIO expander) before >> actual hardware is available. >> >> Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com> > > This looks generally helpful. I don't know what the DT maintainers > think, but I am positive, I think rapid prototyping is a valid usecase. > We used to have the driver for testing only but this usecase is > just as valid. > >> +Required properties: >> +- compatible: Should contain "gpio-mockup" >> +- gpio-controller : Marks the device node as a gpio controller. >> +- #gpio-cells : Should be two. The first cell is the pin number and >> + the second cell is used to specify the gpio polarity: >> + 0 = active high >> + 1 = active low >> +- nr-gpios: The number of dummy GPIOs > > For this there is a standardized binding "ngpios" in gpio.txt > so just use that and reference gpio.txt please. > > Yours, > Linus Walleij 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. I like the feature, just don't think this needs a binding document. I will review the other patch later today. Also: if you want to get a DT bindings patch merged, you need an Ack from Rob Herring (Cc'ed now). You'll probably need to resend anyway as patchwork won't pick up my Cc here. Best regards, Bartosz Golaszewski
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. Yours, Linus Walleij
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@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. 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.
diff --git a/Documentation/devicetree/bindings/gpio/gpio-mockup.txt b/Documentation/devicetree/bindings/gpio/gpio-mockup.txt new file mode 100644 index 000000000000..585f04e356fc --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-mockup.txt @@ -0,0 +1,22 @@ +Mockup GPIO controller bindings + +This creates a dummy GPIO controller which can be used for testing higher level +drivers or userspace before actual hardware is available. + +Required properties: +- compatible: Should contain "gpio-mockup" +- gpio-controller : Marks the device node as a gpio controller. +- #gpio-cells : Should be two. The first cell is the pin number and + the second cell is used to specify the gpio polarity: + 0 = active high + 1 = active low +- nr-gpios: The number of dummy GPIOs + +Example: + + gpio-mockup0 { + compatible = "gpio-mockup"; + nr-gpios = <32>; + gpio-controller; + #gpio-cells = <2>; + };
This is a dummy GPIO controller which can be used in place of the real hardware GPIO controller (for example, an external GPIO expander) before actual hardware is available. Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com> --- .../devicetree/bindings/gpio/gpio-mockup.txt | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpio/gpio-mockup.txt