On Mon, Sep 7, 2020 at 5:23 PM Geert Uytterhoeven [off-list ref] wrote:

Hi Andy,

On Mon, Sep 7, 2020 at 4:14 PM Andy Shevchenko
[off-list ref] wrote:

quoted

On Mon, Sep 07, 2020 at 03:49:23PM +0200, Bartosz Golaszewski wrote:

quoted

On Mon, Sep 7, 2020 at 2:22 PM Greg Kroah-Hartman
[off-list ref] wrote:

quoted

On Mon, Sep 07, 2020 at 02:06:15PM +0200, Bartosz Golaszewski wrote:

...

quoted

quoted

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