linux-kernel - Re: [PATCH] i2c: mux-gpio: Use "mux" con

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Sun, 16 Jun 2019 09:02:59 +0000
From:   Peter Rosin <peda@...ntia.se>
To:     Serge Semin <fancer.lancer@...il.com>,
        Andy Shevchenko <andy.shevchenko@...il.com>
CC:     Jean Delvare <jdelvare@...e.com>,
        Peter Korsgaard <peter.korsgaard@...co.com>,
        Serge Semin <Sergey.Semin@...latforms.ru>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        linux-i2c <linux-i2c@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] i2c: mux-gpio: Use "mux" con_id to find channel GPIOs

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@...il.com> 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