Message-ID: <ff498c83-d1ee-7553-e20c-a07369f8dad6@huawei.com>
Date:   Fri, 12 Jan 2018 17:12:12 +0800
From:   Yisheng Xie <xieyisheng1@...wei.com>
To:     Christophe LEROY <christophe.leroy@....fr>,
        Greg KH <gregkh@...uxfoundation.org>
CC:     <linux-kernel@...r.kernel.org>, <ysxie@...mail.com>,
        <ulf.hansson@...aro.org>, <linux-mmc@...r.kernel.org>,
        <boris.brezillon@...e-electrons.com>, <richard@....at>,
        <marek.vasut@...il.com>, <cyrille.pitchen@...ev4u.fr>,
        <linux-mtd@...ts.infradead.org>, <alsa-devel@...a-project.org>,
        <wim@...ana.be>, <linux@...ck-us.net>,
        <linux-watchdog@...r.kernel.org>, <b.zolnierkie@...sung.com>,
        <linux-fbdev@...r.kernel.org>, <linus.walleij@...aro.org>,
        <linux-gpio@...r.kernel.org>, <ralf@...ux-mips.org>,
        <linux-mips@...ux-mips.org>, <lgirdwood@...il.com>,
        <broonie@...nel.org>, <tglx@...utronix.de>, <jason@...edaemon.net>,
        <marc.zyngier@....com>, <arnd@...db.de>,
        <andriy.shevchenko@...ux.intel.com>,
        <industrypack-devel@...ts.sourceforge.net>, <wg@...ndegger.com>,
        <mkl@...gutronix.de>, <linux-can@...r.kernel.org>,
        <mchehab@...nel.org>, <linux-media@...r.kernel.org>,
        <a.zummo@...ertech.it>, <alexandre.belloni@...e-electrons.com>,
        <linux-rtc@...r.kernel.org>, <daniel.vetter@...el.com>,
        <jani.nikula@...ux.intel.com>, <seanpaul@...omium.org>,
        <airlied@...ux.ie>, <dri-devel@...ts.freedesktop.org>,
        <kvalo@...eaurora.org>, <linux-wireless@...r.kernel.org>,
        <linux-spi@...r.kernel.org>, <tj@...nel.org>,
        <linux-ide@...r.kernel.org>, <bhelgaas@...gle.com>,
        <linux-pci@...r.kernel.org>, <devel@...verdev.osuosl.org>,
        <dvhart@...radead.org>, <andy@...radead.org>,
        <platform-driver-x86@...r.kernel.org>,
        <jakub.kicinski@...ronome.com>, <davem@...emloft.net>,
        <nios2-dev@...ts.rocketboards.org>, <netdev@...r.kernel.org>,
        <vinod.koul@...el.com>, <dan.j.williams@...el.com>,
        <dmaengine@...r.kernel.org>, <jslaby@...e.com>
Subject: Re: [PATCH v3 00/27] kill devm_ioremap_nocache

Hi Christophe ，

On 2018/1/4 16:05, Christophe LEROY wrote:
> 
> 
> Le 25/12/2017 à 02:34, Yisheng Xie a écrit :
>>
>>
>> On 2017/12/24 17:05, christophe leroy wrote:
>>>
>>>
>>> Le 23/12/2017 à 14:48, Greg KH a écrit :
>>>> On Sat, Dec 23, 2017 at 06:55:25PM +0800, Yisheng Xie wrote:
>>>>> Hi all,
>>>>>
>>>>> When I tried to use devm_ioremap function and review related code, I found
>>>>> devm_ioremap and devm_ioremap_nocache is almost the same with each other,
>>>>> except one use ioremap while the other use ioremap_nocache.
>>>>
>>>> For all arches?  Really?  Look at MIPS, and x86, they have different
>>>> functions.
>>>>
>>>>> While ioremap's
>>>>> default function is ioremap_nocache, so devm_ioremap_nocache also have the
>>>>> same function with devm_ioremap, which can just be killed to reduce the size
>>>>> of devres.o(from 20304 bytes to 18992 bytes in my compile environment).
>>>>>
>>>>> I have posted two versions, which use macro instead of function for
>>>>> devm_ioremap_nocache[1] or devm_ioremap[2]. And Greg suggest me to kill
>>>>> devm_ioremap_nocache for no need to keep a macro around for the duplicate
>>>>> thing. So here comes v3 and please help to review.
>>>>
>>>> I don't think this can be done, what am I missing?  These functions are
>>>> not identical, sorry for missing that before.
>>>
>>> devm_ioremap() and devm_ioremap_nocache() are quite similar, both use devm_ioremap_release() for the release, why not just defining:
>>>
>>> static void __iomem *__devm_ioremap(struct device *dev, resource_size_t offset,
>>>                 resource_size_t size, bool nocache)
>>> {
>>> [...]
>>>      if (nocache)
>>>          addr = ioremap_nocache(offset, size);
>>>      else
>>>          addr = ioremap(offset, size);
>>> [...]
>>> }
>>>
>>> then in include/linux/io.h
>>>
>>> static inline void __iomem *devm_ioremap(struct device *dev, resource_size_t offset,
>>>                 resource_size_t size)
>>> {return __devm_ioremap(dev, offset, size, false);}
>>>
>>> static inline void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t offset,
>>>                     resource_size_t size);
>>> {return __devm_ioremap(dev, offset, size, true);}
>>
>> Yeah, this seems good to me, right now we have devm_ioremap, devm_ioremap_wc, devm_ioremap_nocache
>> May be we can use an enum like:
>> typedef enum {
>>     DEVM_IOREMAP = 0,
>>     DEVM_IOREMAP_NOCACHE,
>>     DEVM_IOREMAP_WC,
>> } devm_ioremap_type;
>>
>> static inline void __iomem *devm_ioremap(struct device *dev, resource_size_t offset,
>>                  resource_size_t size)
>>   {return __devm_ioremap(dev, offset, size, DEVM_IOREMAP);}
>>
>>   static inline void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t offset,
>>                      resource_size_t size);
>>   {return __devm_ioremap(dev, offset, size, DEVM_IOREMAP_NOCACHE);}
>>
>>   static inline void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
>>                      resource_size_t size);
>>   {return __devm_ioremap(dev, offset, size, DEVM_IOREMAP_WC);}
>>
>>   static void __iomem *__devm_ioremap(struct device *dev, resource_size_t offset,
>>                  resource_size_t size, devm_ioremap_type type)
>>   {
>>       void __iomem **ptr, *addr = NULL;
>>   [...]
>>       switch (type){
>>       case DEVM_IOREMAP:
>>           addr = ioremap(offset, size);
>>           break;
>>       case DEVM_IOREMAP_NOCACHE:
>>           addr = ioremap_nocache(offset, size);
>>           break;
>>       case DEVM_IOREMAP_WC:
>>           addr = ioremap_wc(offset, size);
>>           break;
>>       }
>>   [...]
>>   }
> 
> 
> That looks good to me, will you submit a v4 ?

Sorry for late response. And I will submit the v4 as your suggestion.

Thanks
Yisheng

> 
> Christophe
> 
>>

Powered by blists - more mailing lists