linux-kernel - Re: [PATCH 0/6] Introduce STMicroelectronics MultiFunction eXpander

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:   Thu, 1 Mar 2018 23:28:46 +0100
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Amelie DELAUNAY <amelie.delaunay@...com>
Cc:     Lee Jones <lee.jones@...aro.org>, Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Russell King <linux@...linux.org.uk>,
        Alexandre TORGUE <alexandre.torgue@...com>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 0/6] Introduce STMicroelectronics MultiFunction eXpander

On Thu, Feb 22, 2018 at 4:13 PM, Amelie DELAUNAY <amelie.delaunay@...com> wrote:

> ST MFX is different from STMPE as far as the HW is completely different.
> IDD is a new feature.
> TS management is completely different.
> GPIO management looks like but is also rather different.
> ST MFX counts a first level of 8 interrupts (acked by writing in the ACK
> register), then a second level of 24 interrupts for GPIOs. GPIO IRQ can
> be triggered on low level, falling edge, high level, rising edge. GPIO
> IRQ have to be acked by writing in the GPI_ACK register, GPIO can be
> output open-drain with/without internal pull-up, output push-pull, input
> with pull-up/down, input floating or analog.

Okay I am convinced that we need to model this as its own
driver if it is as different as you say.

But let's keep an eye on STMPE's approaches and what it does
right and wrong.

If I rewrote the STMPE driver today, the major changes would be
to use regmap to pass around to subdrivers, and implement a
combined pin control and GPIO driver, so I think those things should
be nice to have for the next iteration.

Yours,
Linus Walleij