Re: [PATCH] i2c: mux-gpio: Use "mux" con_id to find channel GPIOs

[Peter Rosin]

On 2019-06-16 01:24, Serge Semin wrote:
> On Sat, Jun 15, 2019 at 02:43:09PM +0300, Andy Shevchenko wrote:
>> On Sat, Jun 15, 2019 at 12:51 AM Serge Semin <fancer.lancer@xxxxxxxxx> wrote:
>>>
>>> Recent patch - ("i2c: mux/i801: Switch to use descriptor passing")
>>> altered the i2c-mux-gpio driver to use the GPIO-descriptor
>>> based interface to find and request the GPIOs then being utilized
>>> to select and deselect the channels of GPIO-driven i2c-muxes. Even
>>> though the proposed modification was correct for the platform_data-based
>>> systems, it was invalid for the OF-based ones and caused the kernel
>>> to crash at the driver probe procedure. There were two problems with
>>> that modification. First of all the gpiod_count() and gpiod_get_index()
>>> were called with NULL con_id.
>>
>> I always thought that this means "count me all GPIO's for this device
>> despite their names" and "get me GPIO by index despite it's name".
>> What's went wrong?
>>
> 
> No. It's wrong as far as I can see for kernels 4.4, 4.9 and the modern
> 5.2.0-rcX. dt_gpio_count()/of_find_gpio()will always try to count/request
> either "<con_id>-gpio(s)" or "gpio(s)" GPIOs in the device of-node. While
> platform_gpio_count()/gpiod_find() will take into account GPIOs with matching
> <con_id>'s even if it is NULL.

Right, this is my reading to. For the OF case, gpiod_count calls dt_gpio_count
which has no way to find gpios unless they are explicitly named. And NULL
simply means unnamed (which is not the case here). The function simply does
not do any trawling for gpios it has not been told about.

Linus, care to squash this incremental into your patch and resend with proper
credit added?

Cheers,
Peter