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
| ||
|
Message-ID: <1595423.PPW7Q1vFt0@z50> Date: Wed, 29 Aug 2018 20:16:20 +0200 From: Janusz Krzysztofik <jmkrzyszt@...il.com> To: Linus Walleij <linus.walleij@...aro.org> Cc: Jonathan Corbet <corbet@....net>, Miguel Ojeda Sandonis <miguel.ojeda.sandonis@...il.com>, Peter Korsgaard <peter.korsgaard@...co.com>, Peter Rosin <peda@...ntia.se>, Ulf Hansson <ulf.hansson@...aro.org>, Andrew Lunn <andrew@...n.ch>, Florian Fainelli <f.fainelli@...il.com>, "David S. Miller" <davem@...emloft.net>, Dominik Brodowski <linux@...inikbrodowski.net>, kishon@...com, Lars-Peter Clausen <lars@...afoo.de>, Michael Hennerich <Michael.Hennerich@...log.com>, Jonathan Cameron <jic23@...nel.org>, Hartmut Knaack <knaack.h@....de>, Peter Meerwald <pmeerw@...erw.net>, Greg KH <gregkh@...uxfoundation.org>, Jiri Slaby <jslaby@...e.com>, "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>, linux-doc@...r.kernel.org, linux-i2c@...r.kernel.org, linux-mmc <linux-mmc@...r.kernel.org>, netdev <netdev@...r.kernel.org>, linux-iio@...r.kernel.org, devel@...verdev.osuosl.org, linux-serial@...r.kernel.org, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Janusz Krzysztofik <jmkrzyszt@...il.com> Subject: Re: [RFC RFT PATCH 0/4] gpiolib: speed up GPIO array processing Hi Linus, On Wednesday, August 29, 2018 11:06:21 AM CEST Linus Walleij wrote: > On Tue, Aug 21, 2018 at 1:42 AM Janusz Krzysztofik <jmkrzyszt@...il.com> wrote: > > > This series is a follow up of the former "mtd: rawnand: ams-delta: Use > > gpio-omap accessors for data I/O" which already contained some changes > > to gpiolib. Those previous attempts were commented by Borris Brezillon > > who suggested using GPIO API modified to accept bitmaps, and by Linus > > Walleij who suggested still more great ideas for further immprovement > > of the proposed API changes - thanks! > > > > The goal is to boost performans of get/set array functions while > > processing GPIO arrays which represent pins of a signle chip in > > hardware order. If resulting performance is close to PIO, GPIO API > > can be used for data I/O without much loss of speed. > > Hands down, this is a very pretty patch set. I'm a big fan already. > > This is mainly because it fulfills the requirement for libraries > to be narrow and deep, which is what we want. > This refers to John Ousterhouts software design philosophy, > here is a great lecture if you haven't seen it already: > https://www.youtube.com/watch?v=bmSAYlu0NcY > > Let's get this into v1 and get some testing and merge it for v4.20 > ASAP Please hold on for a while, I'm going to resubmit soon, with the comment from Peter Rosin on i2c-mux-gpio addressed and the error discovered by Miguel Ojeda in hd44780 fixed. Thanks, Janusz > so we get some proper testing before the v4.20 merge > window. It would be excellent if some of the current users of > the array API could provide tested-by's or at least ACKs. > > For example ts-nbus.c must be a big benefactor. > > Yours, > Linus Walleij >
Powered by blists - more mailing lists