Messages in this thread | | | From | Bartosz Golaszewski <> | Date | Mon, 7 Sep 2020 18:08:14 +0200 | Subject | Re: [PATCH 23/23] Documentation: gpio: add documentation for gpio-mockup |
| |
On Mon, Sep 7, 2020 at 5:23 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Andy, > > On Mon, Sep 7, 2020 at 4:14 PM Andy Shevchenko > <andriy.shevchenko@linux.intel.com> wrote: > > On Mon, Sep 07, 2020 at 03:49:23PM +0200, Bartosz Golaszewski wrote: > > > On Mon, Sep 7, 2020 at 2:22 PM Greg Kroah-Hartman > > > <gregkh@linuxfoundation.org> wrote: > > > > On Mon, Sep 07, 2020 at 02:06:15PM +0200, Bartosz Golaszewski wrote: > > > > ... > > > > > > Yes it is. Or at least until you fix all existing users so that if you > > > > do change it, no one notices it happening :) > > > > > > > > > > Then another question is: do we really want to commit to a stable ABI > > > for a module we only use for testing purposes and which doesn't > > > interact with any real hardware. > > > > > > Rewriting this module without any legacy cruft is tempting though. :) > > > > Another thought spoken loudly: maybe it can be unified with GPIO aggregator > > code? In that case it makes sense. > > You want to aggregate GPIOs out of thin air? > > From DT, that would be something like > > gpios = <&gpio1 2>, <0>, <0>, <&gpio2, 5>; > > ? > > For writing into ".../new_device", we could agree on something like "0" > means not backed by an existing GPIO? >
I'm really not sure this makes any sense. Why complicate an otherwise elegant module that is gpio-aggregator with functionalities that obviously don't belong here? I want to add various parameters that would affect the way the simulated chips work - this really doesn't need to go into the aggregator.
Bart
| |