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  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, 15 Mar 2019 11:36:04 +0100
From:   "Enrico Weigelt, metux IT consult" <>
To:     Andy Shevchenko <>,
        "Enrico Weigelt, metux IT consult" <>
Cc:     Linux Kernel Mailing List <>,
        Greg Kroah-Hartman <>,
        Eric Anholt <>,
        Stefan Wahren <>,
        Florian Fainelli <>,
        Ray Jui <>,
        Scott Branden <>,
        bcm-kernel-feedback-list <>,
        Andy Shevchenko <>,
        Vladimir Zapolskiy <>,
        Matthias Brugger <>,
        Masahiro Yamada <>,
        Tobias Klauser <>,
        Richard Genoud <>,,
        Uwe Kleine-K├Ânig <>,
        Sascha Hauer <>,,
        Andy Gross <>,
        David Brown <>,
        Shawn Guo <>,
        Sascha Hauer <>,
        Fabio Estevam <>,
        dl-linux-imx <>,,
        Peter Korsgaard <>,
        "open list:SERIAL DRIVERS" <>,,
Subject: Re: serial driver cleanups v2

On 15.03.19 10:12, Andy Shevchenko wrote:

>> Part II will be about moving the mmio range from mapbase and
>> mapsize (which are used quite inconsistently) to a struct resource
>> and using helpers for that. But this one isn't finished yet.
>> (if somebody likes to have a look at it, I can send it, too)
> Let's do that way you are preparing a branch somewhere and anounce
> here as an RFC, since this was neither tested nor correct.

Okay, here it is:

   --> general cleanups, as basis for II

   --> moving towards using struct resource consistently

    --> the final steps, which are yet completely broken
    (more a notepad for things still to do :o)

The actual goal is generalizing the whole iomem handling, so individual
usually just need to call some helpers that do most of the things.
Finally, I also wanted to have all io region information consolidated
in struct resource.

Meanwhile I've learned that I probably was a bit too eager w/ that.
Guess I'll have to rethink my strategy.

> And selling point for many of them is not true: it doesn't make any
> difference in the size in code, but increases a time to run
> (devm_ioremap_resource() does more than plain devm_iomap() call).

Okay, just seen it. Does the the runtime overhead cause any problems ?


Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering -- +49-151-27565287

Powered by blists - more mailing lists