[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <7d1c834d-bc65-4979-9b72-0d1d91019501@bytedance.com>
Date: Tue, 4 Mar 2025 14:11:24 +0800
From: Qi Zheng <zhengqi.arch@...edance.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: peterz@...radead.org, kevin.brodsky@....com, riel@...riel.com,
vishal.moola@...il.com, david@...hat.com, jannh@...gle.com,
hughd@...gle.com, willy@...radead.org, yuzhao@...gle.com,
muchun.song@...ux.dev, will@...nel.org, aneesh.kumar@...nel.org,
npiggin@...il.com, arnd@...db.de, dave.hansen@...ux.intel.com,
rppt@...nel.org, alexghiti@...osinc.com, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, linux-csky@...r.kernel.org,
linux-hexagon@...r.kernel.org, loongarch@...ts.linux.dev,
linux-m68k@...ts.linux-m68k.org, linux-mips@...r.kernel.org,
linux-openrisc@...r.kernel.org, linux-sh@...r.kernel.org,
linux-um@...ts.infradead.org, Geert Uytterhoeven <geert@...ux-m68k.org>
Subject: Re: [PATCH v2 3/6 update] mm: pgtable: convert some architectures to
use tlb_remove_ptdesc()
On 3/4/25 12:08 PM, Andrew Morton wrote:
> On Tue, 4 Mar 2025 10:31:07 +0800 Qi Zheng <zhengqi.arch@...edance.com> wrote:
>
>>
>>
>> On 3/4/25 7:53 AM, Andrew Morton wrote:
>>> On Mon, 3 Mar 2025 15:26:03 +0800 Qi Zheng <zhengqi.arch@...edance.com> wrote:
>>>
>>>> Now, the nine architectures of csky, hexagon, loongarch, m68k, mips,
>>>> nios2, openrisc, sh and um do not select CONFIG_MMU_GATHER_RCU_TABLE_FREE,
>>>> and just call pagetable_dtor() + tlb_remove_page_ptdesc() (the wrapper of
>>>> tlb_remove_page()). This is the same as the implementation of
>>>> tlb_remove_{ptdesc|table}() under !CONFIG_MMU_GATHER_TABLE_FREE, so
>>>> convert these architectures to use tlb_remove_ptdesc().
>>>>
>>>
>>> checkpatch warns.
>>>
>>> Do these things have to be macros? Switching to static inline fixes
>>> the unused-arg warning in a nice fashion.
>>
>> This can be switched to static inline. In addition, I found that alpha,
>> arc, microblaze, parisc, sparc32 and xtensa also have the unused-arg
>> issue. Do I need to add a new patch to fix all of them, or just fix the
>> newly added 11 warnings?
>
> I guess leave things as they are now. Switching all these to C
> functions can be addressed at a later time?
Okay, let's leave it for later.
Powered by blists - more mailing lists