linux-kernel - Re: [PATCH 0/5] i2c-mux-gpio: Split plat- and dt-specific code up

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] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 24 Apr 2019 21:25:24 +0000
From:   Peter Rosin <peda@...ntia.se>
To:     Serge Semin <fancer.lancer@...il.com>,
        Peter Korsgaard <peter.korsgaard@...co.com>
CC:     Serge Semin <Sergey.Semin@...latforms.ru>,
        "linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/5] i2c-mux-gpio: Split plat- and dt-specific code up

On 2019-04-24 14:34, Serge Semin wrote:
> The main idea of this patchset was to add the dt-based GPIOs support
> in i2c-mux-gpio driver. In particular we needed to have the full GPIOs
> specifier being handled including the dt-flags like GPIO_ACTIVE_HIGH,
> GPIO_ACTIVE_LOW, etc. Due to using a legacy GPIO interface the former
> driver implementation didn't provide this ability.

I'm curious why active low/high is of any importance? That will only affect
the state numbering, but I fail to see any relevance in that numbering. It's
just numbers, no?

If all the pins are inverted (anything else seems very strange), just
reverse the order. I.e. for a 4-way mux, use 3, 2, 1, 0 instead of
0, 1, 2, 3.

Why not?

Cheers,
Peter

> On the way of adding the full dt-GPIO flags support a small set of
> refactorings has been done in order to keep the platform_data-based
> systems support, make the code more readable and the alterations - clearer.
> In general the whole changes might be considered as the plat- and dt-
> specific code split up. In first patch we unpinned the platform-specific
> method of GPIO-chip probing. The second patch makes the driver to return
> an error if of-based (last resort path) failed to retrieve the driver
> private data. The next three patches is the sequence of initial channel
> info retrieval, platform_data-specific code isolation and finally full
> dt-based GPIOs request method introduction. The last patch does what
> we inteded this patchset for in the first place - adds the full dt-GPIO
> specifiers support.
> 
> 
> Serge Semin (5):
>   i2c-mux-gpio: Unpin a platform-based device initialization
>   i2c-mux-gpio: Return an error if no config data found
>   i2c-mux-gpio: Save initial channel number to the idle data field
>   i2c-mux-gpio: Unpin the platform-specific GPIOs request code
>   i2c-mux-gpio: Create of-based GPIOs request method
> 
>  drivers/i2c/muxes/i2c-mux-gpio.c | 224 ++++++++++++++++++++-----------
>  1 file changed, 146 insertions(+), 78 deletions(-)
>