linux-kernel - Re: [RFC PATCH 7/8] mtd: rawnand: ams-delta: Check sanity of data GPIO resource

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 29 Jul 2018 23:16:19 +0200
From:   Boris Brezillon <boris.brezillon@...tlin.com>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     Janusz Krzysztofik <jmkrzyszt@...il.com>,
        Miquèl Raynal <miquel.raynal@...tlin.com>,
        ext Tony Lindgren <tony@...mide.com>,
        Aaro Koskinen <aaro.koskinen@....fi>,
        Grygorii Strashko <grygorii.strashko@...com>,
        Santosh Shilimkar <ssantosh@...nel.org>,
        Kevin Hilman <khilman@...nel.org>,
        Richard Weinberger <richard@....at>,
        David Woodhouse <dwmw2@...radead.org>,
        Brian Norris <computersforpeace@...il.com>,
        Mark Vasut <marek.vasut@...il.com>,
        linux-mtd@...ts.infradead.org,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux-OMAP <linux-omap@...r.kernel.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Artem Bityutskiy <artem.bityutskiy@...ux.intel.com>
Subject: Re: [RFC PATCH 7/8] mtd: rawnand: ams-delta: Check sanity of data
 GPIO resource

On Sun, 29 Jul 2018 22:36:49 +0200
Linus Walleij <linus.walleij@...aro.org> wrote:

> On Thu, Jul 19, 2018 at 8:44 AM Boris Brezillon
> <boris.brezillon@...tlin.com> wrote:
> 
> > I guess you'd prefer to have the pin values in a bitmap instead of an
> > array of integers. That's probably something you can discuss with
> > Linus, see if he would accept to change the prototype of
> > gpiod_get_raw_array_value().  
> 
> I am not so smart as to see the overall effects but if what
> you're saying is that we shouldn't have designed these functions
> and callbacks using arrays of integers (or longs) and instead
> pass bitmaps, you may be just right. It intuitively sounds better.

Maybe, maybe not. Only an real evaluation of where the overhead is can
tell us. So I'd suggest trying to use the existing interface and doing
the int_array -> u8 conversion in the NAND driver first, and see how
much moving to a bitmap imprsoves things.

> But I'm not good with bitmaps.
> 
> We would have to refactor the world though.

I checked and, AFAICT, there are no external users of this API (only
core code is using those funcs, for ioctls I guess). Anyway, I think
we should wait for real numbers before we consider doing this change
(It's not unusual to get this sort of things wrong).