On Thu, 29 Jul 2021, at 17:10, Andy Shevchenko wrote:

On Thu, Jul 29, 2021 at 3:39 AM Andrew Jeffery [off-list ref] wrote:

quoted

On Wed, 28 Jul 2021, at 18:43, Andy Shevchenko wrote:

quoted

On Wed, Jul 28, 2021 at 8:43 AM Andrew Jeffery [off-list ref] wrote:

quoted

However, userspace would never have
got the results it expected with the existing driver implementation, so
I guess you could argue that no such (useful) userspace exists. Given
that, we could adopt the strategy of always defining a gpiochip
covering the whole pin space, and parts of the devicetree binding just
become redundant.

I'm lost now. GPIO has its own userspace ABI, how does it work right
now in application to this chip?

As above, it "works" if the GPIOs specified in the devicetree are
contiguous from line 0. It's broken if they're not.

So, "it never works" means there is no bug. Now, what we need is to
keep the same enumeration scheme, but if you wish to be used half/half
(or any other ratio), the driver should do like the above mentioned
PWM, i.e. register entire space and depending on the requestor either
proceed with a line or mark it as BUSY.

Ideally, looking into what the chip can do, this should be indeed
converted to some like pin control + PWM + LED + GPIO drivers. Then
the function in pin mux configuration can show what exactly is enabled
on the certain line(s).

So just to clarify, you want both solutions here?

1. A gpiochip that covers the entire pin space
2. A pinmux implementation that manages pin allocation to the different drivers

In that case we can largely leave this series as is? We only need to 
adjust how we configure the gpiochip by dropping the pin-mapping 
implementation?

I don't have a need to implement a PWM driver for it right now but that 
would make sense to do at some point.

Andrew