linux-kernel - Re: [PATCH v2 2/2] gpio: fxl6408: add I2C GPIO expander driver

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]

Message-ID: <ZA8gdHWzRx73by5u@francesco-nb.int.toradex.com>
Date:   Mon, 13 Mar 2023 14:09:08 +0100
From:   Francesco Dolcini <francesco@...cini.it>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Francesco Dolcini <francesco@...cini.it>,
        linux-gpio@...r.kernel.org,
        Linus Walleij <linus.walleij@...aro.org>,
        Bartosz Golaszewski <brgl@...ev.pl>,
        Emanuele Ghidoli <emanuele.ghidoli@...adex.com>,
        linux-kernel@...r.kernel.org,
        Francesco Dolcini <francesco.dolcini@...adex.com>
Subject: Re: [PATCH v2 2/2] gpio: fxl6408: add I2C GPIO expander driver

On Mon, Mar 13, 2023 at 02:24:47PM +0200, Andy Shevchenko wrote:
> On Mon, Mar 13, 2023 at 1:33 PM Francesco Dolcini <francesco@...cini.it> wrote:
> > +config GPIO_FXL6408
> > +       tristate "FXL6408 I2C GPIO expander"
> > +       select GPIO_REGMAP
> 
> > +       select REGMAP_I2C
> 
> Somebody pointed out that this might require
> 
>     depends on I2C
> 
> being added as well.

This is already there, I would prefer to not duplicate it neither do it
differently from all the other I2C GPIO drivers.

menu "I2C GPIO expanders"
	depends on I2C

> > +#define FXL6408_MAX_REGISTER           0x13
> 
> This is used as a range, but why? If we can have a proper name for
> this register, why bother dumping all this or even having access to?

So, I see 2 options:
1. Use FXL6408_REG_INPUT_STATUS instead of FXL6408_MAX_REGISTER
2. #define FXL6408_REG_INT_STS 0x13 and use it instead

I think that there are trivial benefits on both, with option 2 being the
correct hardware description and that would not need to be changed when adding
additional functionalities to the driver.

Which solution do we prefer for v3?
My preference would be to define FXL6408_REG_INT_STS and use it instead.

Francesco