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]
Message-ID: <20201113093529.xy63ncisl4wuesig@pengutronix.de>
Date:   Fri, 13 Nov 2020 10:35:29 +0100
From:   Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
To:     Bartosz Golaszewski <bgolaszewski@...libre.com>
Cc:     Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Heiko Stübner <heiko@...ech.de>,
        Yangtao Li <tiny.windzz@...il.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        LKML <linux-kernel@...r.kernel.org>, linux-tegra@...r.kernel.org,
        Thierry Reding <thierry.reding@...il.com>,
        linux-riscv@...ts.infradead.org,
        Fabio Estevam <festevam@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>, shc_work@...l.ru,
        Kevin Hilman <khilman@...libre.com>,
        Chen-Yu Tsai <wens@...e.org>,
        Jonathan Hunter <jonathanh@...dia.com>,
        linux-rockchip@...ts.infradead.org,
        Ludovic Desroches <ludovic.desroches@...rochip.com>,
        bcm-kernel-feedback-list@...adcom.com,
        dl-linux-imx <linux-imx@....com>,
        Sylvain Lemieux <slemieux.tyco@...il.com>,
        linux-pwm@...r.kernel.org, Ray Jui <rjui@...adcom.com>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Maxime Ripard <mripard@...nel.org>,
        Vladimir Zapolskiy <vz@...ia.com>,
        "moderated list:ARM/Mediatek SoC..." 
        <linux-mediatek@...ts.infradead.org>,
        linux-rpi-kernel@...ts.infradead.org,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        linux-amlogic@...ts.infradead.org,
        Lee Jones <lee.jones@...aro.org>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        arm-soc <linux-arm-kernel@...ts.infradead.org>,
        Scott Branden <sbranden@...adcom.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Nicolas Ferre <nicolas.ferre@...rochip.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Sascha Hauer <kernel@...gutronix.de>,
        Shawn Guo <shawnguo@...nel.org>, claudiu.beznea@...rochip.com,
        Nicolas Saenz Julienne <nsaenzjulienne@...e.de>
Subject: Re: About devm_platform_ioremap_resource [Was: Re: [PATCH 01/32]
 pwm: sun4i: convert to devm_platform_ioremap_resource]

On Fri, Nov 13, 2020 at 10:12:46AM +0100, Bartosz Golaszewski wrote:
> On Fri, Nov 13, 2020 at 8:04 AM Uwe Kleine-König
> <u.kleine-koenig@...gutronix.de> wrote:
> >
> > Hello,
> >
> > [Added lkml and the people involved in commit 7945f929f1a7
> > ("drivers: provide devm_platform_ioremap_resource()") to Cc:. For the
> > new readers: This is about patches making use of
> > devm_platform_ioremap_resource() instead of open coding it. Full context
> > at https://lore.kernel.org/r/20201112190649.GA908613@ulmo]
> >
> > On Thu, Nov 12, 2020 at 10:14:29PM +0100, Uwe Kleine-König wrote:
> > > On Thu, Nov 12, 2020 at 08:06:49PM +0100, Thierry Reding wrote:
> > > > I also think that it's overly narrow is scope, so you can't actually
> > > > "blindly" use this helper and I've seen quite a few cases where this was
> > > > unknowingly used for cases where it shouldn't have been used and then
> > > > broke things (because some drivers must not do the request_mem_region()
> > > > for example).
> > >
> > > You have a link to such an accident?
> >
> > I got a hint in private here: https://lore.kernel.org/r/1555670144-24220-1-git-send-email-aisheng.dong@nxp.com
> >
> > devm_platform_ioremap_resource() is platform_get_resource() +
> > devm_ioremap_resource() and here it was used to replace
> > platform_get_resource() + devm_ioremap().
> >
> > IMHO the unlucky thing in this situation is that devm_ioremap_resource()
> > and devm_ioremap() are different by more than just how they get the area
> > to remap. (i.e. devm_ioremap_resource() also does
> > devm_request_mem_region().)
> >
> > So the problem is not the added wrapper, but unclear semantics in the
> > functions it uses. In my eyes devm_ioremap() and
> > devm_platform_ioremap_resource() should better be named
> > devm_request_ioremap() and devm_platform_request_ioremap_resource()
> > respectively. Is it worth to rename these for clearity?
> 
> But devm_ioremap() doesn't request the region. Did you mean
> devm_ioremap_resource() should become devm_request_ioremap_resource()?

Yes indeed. The last paragraph should be:

So the problem is not the added wrapper, but unclear semantics in the
functions it uses. In my eyes devm_ioremap_resource() and
devm_platform_ioremap_resource() should better be named
devm_request_ioremap_resource() and
devm_platform_request_ioremap_resource().

(Note that I created a patch series that implements this suggestion, but
you were not on Cc: as I extensively trimmed the recipents assuming most
people are not interested. See https://lore.kernel.org/r/20201113085327.125041-1-u.kleine-koenig@pengutronix.de)

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ