From: Alex Elder <elder@xxxxxxxx> Date: Sun, 5 Mar 2023 10:58:19 -0600 > On 2/17/23 7:04 AM, Alex Elder wrote: >> On 2/17/23 5:57 AM, Alexander Lobakin wrote: >>>>> just devm_platform_ioremap_resource_byname() be used here for >>>>> simplicity? >>>> Previously, virt_raw would be the "real" re-mapped pointer, and then >>>> virt would be adjusted downward from that. It was a weird thing to >>>> do, because the result pointed to a non-mapped address. But all uses >>>> of the virt pointer added an offset that was enough to put the result >>>> into the mapped range. >>>> >>>> The new code updates all offsets to account for what the adjustment >>>> previously did. The test that got removed isn't necessary any more. >>> Yeah I got it, just asked that maybe you can now use >>> platform_ioremap_resource_byname() instead of >>> platform_get_resource_byname() + ioremap() :) >> >> Sorry, I focused on the "devm" part and not this part. >> Yes I like that, but let me do that as a follow-on >> patch, and I think I can do it in more than this >> spot (possibly three, but I have to look closely). > > Looking at this today, the only OF functions that look up a > resource and I/O remap it in one call are devm_*() variants. > There is no platform_ioremap_resource_byname() function. > > One that's available is devm_platform_ioremap_resource_byname(), > which could possibly be used in the two locations that call > platform_get_resource_byname() followed by ioremap(). > > As I said earlier, if I were to use any devm_*() function > calls the driver, I would want to convert *everything* to > use devm_*() variants, and I have no plans to do that at > this time. > > So I will not be implementing your suggestion. Sure. It's fully up to the developers as it doesn't make the code worse in any way. > > -Alex > >> Thanks. >> >> -Alex >> >> > Thanks, Olek
