linux-kernel - Re: [PATCH 38/42] drivers: gpio: vr41xx: use devm_platform_ioremap

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:   Tue, 12 Mar 2019 09:02:32 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     "Enrico Weigelt, metux IT consult" <lkml@...ux.net>,
        Thierry Reding <thierry.reding@...il.com>,
        "Enrico Weigelt, metux IT consult" <info@...ux.net>
Cc:     linux-kernel@...r.kernel.org, linus.walleij@...aro.org,
        bgolaszewski@...libre.com, andrew@...id.au, sbranden@...adcom.com,
        bcm-kernel-feedback-list@...adcom.com, hoan@...amperecomputing.com,
        orsonzhai@...il.com, baolin.wang@...aro.org, zhang.lyra@...il.com,
        keguang.zhang@...il.com, vz@...ia.com, matthias.bgg@...il.com,
        grygorii.strashko@...com, ssantosh@...nel.org, khilman@...nel.org,
        robert.jarzmik@...e.fr, yamada.masahiro@...ionext.com,
        jun.nie@...aro.org, shawnguo@...nel.org,
        linux-gpio@...r.kernel.org, linux-mips@...r.kernel.org,
        linux-pwm@...r.kernel.org, linux-omap@...r.kernel.org,
        linux-tegra@...r.kernel.org
Subject: Re: [PATCH 38/42] drivers: gpio: vr41xx: use
 devm_platform_ioremap_resource()



On 3/12/2019 8:42 AM, Enrico Weigelt, metux IT consult wrote:
> On 12.03.19 12:37, Thierry Reding wrote:
> 
>> The driver currently doesn't request the memory described in the
>> resource, so technically you're changing behaviour here and with your
>> change the driver could now fail if somebody else has already claimed
>> the memory.
> 
> hmm, using w/o requesting/claiming - isn't that a bug ?

Not necessarily, before regmap existed, you could have very well
delegated a subset of a larger resource to a specific driver while a
driver requesting that larger resource would be responsible for doing
the request_mem_region(). As long as both drivers don't stomp on each
other, this is a perfectly valid way to delegate, yet keep things
modular/separate.
-- 
Florian