Re: [PATCH 1/9] mm: introduce hw_pte_t for PTE table storage
"David Hildenbrand (Arm)" <[email protected]>
| Newsgroups | org.kernel.vger.linux-parisc,dev.linux.lists.damon,org.freedesktop.lists.dri-devel,org.freedesktop.lists.intel-gfx,org.kernel.vger.bpf,org.kernel.vger.linux-arch,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-perf-users,org.kernel.vger.linux-trace-kernel,org.kvack.linux-mm,org.xenproject.lists.xen-devel |
|---|---|
| Message-ID | <[email protected]> |
On 8/10/26 12:09, Muhammad Usama Anjum wrote:
> On 09/08/2026 6:45 pm, Alexander Gordeev wrote:
>> On Fri, Aug 07, 2026 at 04:24:00PM +0100, Muhammad Usama Anjum wrote:
>>> Thank you for testing it out on s390.
>>>
>>> As __hw_pte_t isn't being used yet in this series, would s390 enablement
>>> patches add __hw_pte_t to this definition?
>>
>> I hope there is a better solution. As I noted m68k, powerpc and sparc
>> may also be affected, so I would suggest to look into those as well.
>> I would prefer s390 to use the generic one rather than circumvent a
>> compile error in a custom way.
> I've just checked all of these architectures by doing dirty conversion and
> reached to same conclusion that __hw_pte_t must be defined like:
>
> typedef struct __hw_pte_t { pte_t __pte; } hw_pte_t;
>
> I'lll add __hw_pte_t to this series. (Initially on last email I'd thought
> that the first user would add __hw_pte_t. But it seems sensible to add it
> now)
Yes, do it as part of the introduction. Also a good idea to mention in the patch
description *why* that is required.
--
Cheers,
David