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:   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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ