netdev - Re: [PATCH net-next 2/6] net: ipa: kill gsi->virt

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] [day] [month] [year] [list]

Message-ID: <07f6a7ce-ff22-695b-f843-d0d8ba275ae7@intel.com>
Date:   Mon, 6 Mar 2023 11:30:34 +0100
From:   Alexander Lobakin <aleksander.lobakin@...el.com>
To:     Alex Elder <elder@...e.org>
CC:     Alex Elder <elder@...aro.org>, <davem@...emloft.net>,
        <edumazet@...gle.com>, <kuba@...nel.org>, <pabeni@...hat.com>,
        <caleb.connolly@...aro.org>, <mka@...omium.org>,
        <evgreen@...omium.org>, <andersson@...nel.org>,
        <quic_cpratapa@...cinc.com>, <quic_avuyyuru@...cinc.com>,
        <quic_jponduru@...cinc.com>, <quic_subashab@...cinc.com>,
        <elder@...nel.org>, <netdev@...r.kernel.org>,
        <linux-arm-msm@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next 2/6] net: ipa: kill gsi->virt_raw

From: Alex Elder <elder@...e.org>
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