linux-kernel - Re: [PATCH 00/16] gpio: Tight IRQ chip integration and banked infrastructure

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:   Thu, 14 Sep 2017 15:54:56 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Thierry Reding <thierry.reding@...il.com>
Cc:     Jonathan Hunter <jonathanh@...dia.com>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        "linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        ext Tony Lindgren <tony@...mide.com>
Subject: Re: [PATCH 00/16] gpio: Tight IRQ chip integration and banked infrastructure

On Fri, Sep 1, 2017 at 8:57 PM, Thierry Reding <thierry.reding@...il.com> wrote:

> here's the latest series of patches that implement the tighter IRQ chip
> integration as well as the banked GPIO infrastructure that we had
> discussed a couple of weeks/months back.

Yes it has become really tasty now, don't you think :)

I really like the series.

Banks are handled in the core, exactly as I wanted.

I will likely go in and change some things I don't like, like switching
num_pins in the bank to num_lines. I have preferred that terminology
to avoid confusion with pin control. So GPIO chips have lines, not pins.
But it's so minor that I can fix it up if you don't want to.

We also need to go in and patch Documentation/gpio/driver.txt
to represent the current best practice. But that can be later,
separate patch.

> The first couple of patches are mostly preparatory work in order to
> consolidate all IRQ chip related fields in a new structure and create
> the base functionality for adding IRQ chips.
>
> After that, I've added the Tegra186 GPIO support patch that makes use of
> the new tight integration.
>
> To round things off the new banked GPIO infrastructure is added (along
> with some more preparatory work), followed by the conversion of the two
> Tegra GPIO drivers to the new infrastructure.

I have put all on a branch for pushing to the test builders to begin with.

Then I plan to make one branch with all infrastructure patches
(patches 1-10, 12-14) and pull that into devel, then apply patch
11 and 15-16 directly on devel.

That way other subsystems (pinctrl ...) can pull in the infrastructure
for people adding new gpiochips this cycle.

> Any thoughts on this? I'd like to target 4.15 with this,

Me, too.

> unless you'd be
> willing to take this into 4.14, which I doubt at this point. The absence
> of a GPIO driver has been hampering Tegra186 support upstream for a
> while now, so it'd be good to make progress on this.

Sorry about that. Let's move ahead with this now, it is neat and
clean.

What I want (as maintainer) is a bit of fingerpointing at the drivers
that need to be converted to use the new banking infrastructure
so they don't stay with their old crappy design pattern. OMAP is
a clear candidate right? (Added Tony to CC...)

Who else?

Yours,
Linus Walleij