From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from szxga05-in.huawei.com ([45.249.212.191]:3779 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754345AbeALJMj (ORCPT ); Fri, 12 Jan 2018 04:12:39 -0500 Subject: Re: [PATCH v3 00/27] kill devm_ioremap_nocache To: Christophe LEROY , Greg KH References: <1514026525-32538-1-git-send-email-xieyisheng1@huawei.com> <20171223134831.GB10103@kroah.com> <8dd19411-5b06-0aa4-fd0e-e5b112c25dcb@huawei.com> <1eb206ed-95e9-5839-485d-0e549ff3f505@c-s.fr> CC: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , From: Yisheng Xie Message-ID: (sfid-20180112_101301_179717_0844FDC5) Date: Fri, 12 Jan 2018 17:12:12 +0800 MIME-Version: 1.0 In-Reply-To: <1eb206ed-95e9-5839-485d-0e549ff3f505@c-s.fr> Content-Type: text/plain; charset="utf-8" Sender: linux-wireless-owner@vger.kernel.org List-ID: 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 > >> From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yisheng Xie Subject: Re: [PATCH v3 00/27] kill devm_ioremap_nocache Date: Fri, 12 Jan 2018 17:12:12 +0800 Message-ID: References: <1514026525-32538-1-git-send-email-xieyisheng1@huawei.com> <20171223134831.GB10103@kroah.com> <8dd19411-5b06-0aa4-fd0e-e5b112c25dcb@huawei.com> <1eb206ed-95e9-5839-485d-0e549ff3f505@c-s.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: <1eb206ed-95e9-5839-485d-0e549ff3f505@c-s.fr> Sender: linux-mmc-owner@vger.kernel.org To: Christophe LEROY , Greg KH Cc: linux-kernel@vger.kernel.org, ysxie@foxmail.com, ulf.hansson@linaro.org, linux-mmc@vger.kernel.org, boris.brezillon@free-electrons.com, richard@nod.at, marek.vasut@gmail.com, cyrille.pitchen@wedev4u.fr, linux-mtd@lists.infradead.org, alsa-devel@alsa-project.org, wim@iguana.be, linux@roeck-us.net, linux-watchdog@vger.kernel.org, b.zolnierkie@samsung.com, linux-fbdev@vger.kernel.org, linus.walleij@linaro.org, linux-gpio@vger.kernel.org, ralf@linux-mips.org, linux-mips@linux-mips.org, lgirdwood@gmail.com, broonie@kernel.org, tglx@linutronix.de, jason@lakedaemon.net, marc.zyngier@arm.com, arnd@arndb.de, andriy.shevchenko@linux.intel.com, industrypack-devel@lists.sourceforge.net, wg@grandegger.com, mkl@pengutronix.deli List-Id: linux-ide@vger.kernel.org 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 > >> From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yisheng Xie Subject: Re: [PATCH v3 00/27] kill devm_ioremap_nocache Date: Fri, 12 Jan 2018 17:12:12 +0800 Message-ID: References: <1514026525-32538-1-git-send-email-xieyisheng1@huawei.com> <20171223134831.GB10103@kroah.com> <8dd19411-5b06-0aa4-fd0e-e5b112c25dcb@huawei.com> <1eb206ed-95e9-5839-485d-0e549ff3f505@c-s.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Cc: , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,
  • , Greg KH Return-path: In-Reply-To: <1eb206ed-95e9-5839-485d-0e549ff3f505@c-s.fr> Sender: linux-mmc-owner@vger.kernel.org List-Id: netdev.vger.kernel.org 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 > >> From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from szxga05-in.huawei.com ([45.249.212.191]:2237 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by eddie.linux-mips.org with ESMTP id S23994652AbeALJMko5QXJ (ORCPT ); Fri, 12 Jan 2018 10:12:40 +0100 Subject: Re: [PATCH v3 00/27] kill devm_ioremap_nocache References: <1514026525-32538-1-git-send-email-xieyisheng1@huawei.com> <20171223134831.GB10103@kroah.com> <8dd19411-5b06-0aa4-fd0e-e5b112c25dcb@huawei.com> <1eb206ed-95e9-5839-485d-0e549ff3f505@c-s.fr> From: Yisheng Xie Message-ID: Date: Fri, 12 Jan 2018 17:12:12 +0800 MIME-Version: 1.0 In-Reply-To: <1eb206ed-95e9-5839-485d-0e549ff3f505@c-s.fr> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Return-Path: Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-subscribe: List-owner: List-post: List-archive: To: Christophe LEROY , Greg KH Cc: linux-kernel@vger.kernel.org, ysxie@foxmail.com, ulf.hansson@linaro.org, linux-mmc@vger.kernel.org, boris.brezillon@free-electrons.com, richard@nod.at, marek.vasut@gmail.com, cyrille.pitchen@wedev4u.fr, linux-mtd@lists.infradead.org, alsa-devel@alsa-project.org, wim@iguana.be, linux@roeck-us.net, linux-watchdog@vger.kernel.org, b.zolnierkie@samsung.com, linux-fbdev@vger.kernel.org, linus.walleij@linaro.org, linux-gpio@vger.kernel.org, ralf@linux-mips.org, linux-mips@linux-mips.org, lgirdwood@gmail.com, broonie@kernel.org, tglx@linutronix.de, jason@lakedaemon.net, marc.zyngier@arm.com, arnd@arndb.de, andriy.shevchenko@linux.intel.com, industrypack-devel@lists.sourceforge.net, wg@grandegger.com, mkl@pengutronix.de, linux-can@vger.kernel.org, mchehab@kernel.org, linux-media@vger.kernel.org, a.zummo@towertech.it, alexandre.belloni@free-electrons.com, linux-rtc@vger.kernel.org, daniel.vetter@intel.com, jani.nikula@linux.intel.com, seanpaul@chromium.org, airlied@linux.ie, dri-devel@lists.freedesktop.org, kvalo@codeaurora.org, linux-wireless@vger.kernel.org, linux-spi@vger.kernel.org, tj@kernel.org, linux-ide@vger.kernel.org, bhelgaas@google.com, linux-pci@vger.kernel.org, devel@driverdev.osuosl.org, dvhart@infradead.org, andy@infradead.org, platform-driver-x86@vger.kernel.org, jakub.kicinski@netronome.com, davem@davemloft.net, nios2-dev@lists.rocketboards.org, netdev@vger.kernel.org, vinod.koul@intel.com, dan.j.williams@intel.com, dmaengine@vger.kernel.org, jslaby@suse.com Message-ID: <20180112091212.2pMpqOu3Wcq3ysHkP9_VPXF4ad89AimbHjJs66V98oQ@z> 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 > >> From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yisheng Xie Date: Fri, 12 Jan 2018 09:12:12 +0000 Subject: Re: [PATCH v3 00/27] kill devm_ioremap_nocache Message-Id: List-Id: References: <1514026525-32538-1-git-send-email-xieyisheng1@huawei.com> <20171223134831.GB10103@kroah.com> <8dd19411-5b06-0aa4-fd0e-e5b112c25dcb@huawei.com> <1eb206ed-95e9-5839-485d-0e549ff3f505@c-s.fr> In-Reply-To: <1eb206ed-95e9-5839-485d-0e549ff3f505@c-s.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: Christophe LEROY , Greg KH Cc: linux-kernel@vger.kernel.org, ysxie@foxmail.com, ulf.hansson@linaro.org, linux-mmc@vger.kernel.org, boris.brezillon@free-electrons.com, richard@nod.at, marek.vasut@gmail.com, cyrille.pitchen@wedev4u.fr, linux-mtd@lists.infradead.org, alsa-devel@alsa-project.org, wim@iguana.be, linux@roeck-us.net, linux-watchdog@vger.kernel.org, b.zolnierkie@samsung.com, linux-fbdev@vger.kernel.org, linus.walleij@linaro.org, linux-gpio@vger.kernel.org, ralf@linux-mips.org, linux-mips@linux-mips.org, lgirdwood@gmail.com, broonie@kernel.org, tglx@linutronix.de, jason@lakedaemon.net, marc.zyngier@arm.com, arnd@arndb.de, andriy.shevchenko@linux.intel.com, industrypack-devel@lists.sourceforge.net, wg@grandegger.com, mkl@pengutronix.deli 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 > >>