Messages in this thread | | | Subject | Re: [PATCH v2] devres: use MACRO instead of function for devm_ioremap | From | Yisheng Xie <> | Date | Fri, 22 Dec 2017 17:06:46 +0800 |
| |
Hi Greg,
On 2017/12/21 23:08, Greg KH wrote: > On Thu, Dec 21, 2017 at 07:50:16PM +0800, Yisheng Xie wrote: >> Hi Greg, >> >> On 2017/12/19 18:52, Yisheng Xie wrote: >>> Hi Greg, >>> >>> On 2017/12/19 16:46, Greg KH wrote: >>>> On Sat, Nov 25, 2017 at 05:23:33PM +0800, Yisheng Xie wrote: >>>>> Default ioremap is ioremap_nocache, so devm_ioremap has the same function >>>>> with devm_ioremap_nocache, which may just be killed. However, there are >>>>> many places which use devm_ioremap_nocache, while many use devm_ioremap. >>>>> >>>>> This patch is to use MACRO for devm_ioremap, which will reduce the size of >>>>> devres.o from 206824 Bytes to 203768 Bytes. >>>> >>>> Ok, the idea is good, but why not just get rid of the callers of >>>> devm_ioremap_nocache() instead and have them call devm_ioremap() if they >>>> really are the same thing? No need to keep a macro around for the >>>> duplicate thing, just delete the one and things are much better. >>> >>> Yeah, I thought someone may still want to use devm_ioremap_nocache(). >>> >>> I will take your suggestion in next version and kill devm_ioremap_nocache(). >> >> I am trying to kill devm_ioremap_nocache() as your suggestion, however, if >> put it as a single patch it will be a patch really big (the patch file may >> have more than 1k lines), for many places will use devm_ioremap_nocache(). >> But it also makes me fell uncomfortable to separate it to so many litter >> patchs for a litter optimize. :) >> >> So I put the v3 patch in the attachment, please let me know if I should >> separate it to litter patchs :) > > Yes, of course you need to break it up into smaller pieces. > > One per subsystem, make a large patch series, send it out, get a few > merged, refresh, send again, and keep going until all of the users are > out of the tree and then drop the old api call. That's how we do this > all the time, should take about 1 kernel release if you are quick and > lucky :) > > hope this helps,
Yes, it do help.
Thanks for your help. Yisheng Xie
> > greg k-h > > . >
| |