linux-kernel - Re: [PATCH v3 4/5] gpio: msc313: Add support for SSD201 and SSD202D

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:   Tue, 21 Dec 2021 00:27:59 +0900
From:   Daniel Palmer <daniel@...f.com>
To:     Bartosz Golaszewski <brgl@...ev.pl>
Cc:     Linus Walleij <linus.walleij@...aro.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 4/5] gpio: msc313: Add support for SSD201 and SSD202D

Hi Bartosz,

On Tue, 21 Dec 2021 at 00:07, Bartosz Golaszewski <brgl@...ev.pl> wrote:
> I took a closer look now and it got even worse. This is some major
> obfuscation with those names being defined as macros defining partial
> lists...

A bit of background because I guess we'll hit this again when I push
the next part of this (interrupt support):

There are lists of pin names and offsets that are put into arrays
because these chips have different mixes of the same sets of pins
with, mostly, the same register offsets for those pins. So it's easier
to create the composite array for a specific chip if the sets of pins
are defined as lists.
It's not possible to have a linear range of gpios based on register
offset and ignore the offsets that don't matter because someone
thought it would be nice to put some clock registers, boot control
registers etc in the unused registers in the gpio block. Hence the
offset arrays to map out the registers that are actually GPIOs.
This driver might need to be changed to use a syscon at some point...

If anyone has any ideas to make it nicer I'll do that change as the
first patch for the next series for this driver.

> Anyway, it was already there when you got there so I guess we can
> address it separately. Queued for v5.17.

Thank you!

Cheers,

Daniel