linux-kernel - Re: [PATCH 5/5] pinctrl: Add support pin control for UP board CPLD/FPGA

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]

Message-ID: <CACRpkdYfPT6-gt2RCxzPfy+GdkLYo8KP02CLLC+uY512AqPwNw@mail.gmail.com>
Date:   Fri, 21 Oct 2022 11:09:27 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     chengwei <foxfly.lai.tw@...il.com>
Cc:     lee@...nel.org, broonie@...nel.org, rafael@...nel.org,
        mika.westerberg@...ux.intel.com, andriy.shevchenko@...ux.intel.com,
        brgl@...ev.pl, linux-kernel@...r.kernel.org,
        gregkh@...uxfoundation.org, lenb@...nel.org,
        linux-acpi@...r.kernel.org, linux-gpio@...r.kernel.org,
        GaryWang@...on.com.tw, musa.lin@...jingtech.com,
        jack.chang@...jingtech.com, chengwei <larry.lai@...jingtech.com>,
        Javier Arteaga <javier@...tex.com>,
        Nicola Lunghi <nicola.lunghi@...tex.com>
Subject: Re: [PATCH 5/5] pinctrl: Add support pin control for UP board CPLD/FPGA

Hi Chengwei,

thanks for your patch!

On Wed, Oct 19, 2022 at 4:26 AM chengwei <foxfly.lai.tw@...il.com> wrote:

> The UP Squared board <http://www.upboard.com> implements certain
> features (pin control) through an on-board FPGA.
>
> Signed-off-by: Javier Arteaga <javier@...tex.com>
> [merge various fixes]
> Signed-off-by: Nicola Lunghi <nicola.lunghi@...tex.com>
> Signed-off-by: chengwei <larry.lai@...jingtech.com>

I am a bit confused by this driver. Andy pointed out some obvious nits that
need to be fixed but the overall architecture here is also a bit puzzling.

This seems to want to be compatible to Raspberry Pi (RPi), then which one?

The driver seems to translate GPIO calls to "native GPIO" in some cases,
which GPIO controller is that?

Also I don't see why, normally a pin control
driver is an agnostic back-end for a GPIO controller, so the GPIO driver
should be the same (whatever "native") means, and this driver should
not even implement a gpio chip, just let the GPIO driver do its job
and call back into the pin control back-end whenever it needs it.

Also we already have a driver that collects existing GPIOs to a new
GPIO chip, the GPIO aggregator:
drivers/gpio/gpio-aggregator.c

Maybe if you can explain a bit about how this hardware works and why
you have to do indirect calls to another GPIO controller, things will
be easier to understand?

Yours,
Linus Walleij