On 01/10/2026 12:19 pm, David Hildenbrand (Arm) wrote: > On 9/22/26 19:12, Muhammad Usama Anjum wrote: >> Atomic PTE updates need an lvalue for the bits stored in an HW PTE. >> pte_val() only accepts a SW PTE value, so it cannot operate directly on >> a distinct hw_pte_t. >> >> Add hw_pte_val() to expose the underlying pte_val() lvalue. Access the >> wrapper's __pte member when hw_pte_t is distinct, and use pte_val() >> directly when it remains an alias of pte_t. >> >> Signed-off-by: Muhammad Usama Anjum <[email protected]> >> --- >> Changes in v3: >> - Moved from the arm64 series to generic series as it makes more sense >> to add this in generic with all other changes. Usually we only add >> code where its get used. But this whole series wouldn't get used >> until an arch started using HW PTEs. >> --- >> include/linux/pgtable_types.h | 4 ++++ >> 1 file changed, 4 insertions(+) >> >> diff --git a/include/linux/pgtable_types.h b/include/linux/pgtable_types.h >> index d6c5a7548550b..ee4eace5c3e1c 100644 >> --- a/include/linux/pgtable_types.h >> +++ b/include/linux/pgtable_types.h >> @@ -9,9 +9,13 @@ >> #ifdef CONFIG_ARCH_HAS_HW_PTE_T >> typedef struct __hw_pte_t { pte_t __pte; } hw_pte_t; >> #define __pte_from_hw(pte) ((pte).__pte) >> + >> +#define hw_pte_val(x) pte_val((x).__pte) >> #else >> #define hw_pte_t pte_t >> #define __pte_from_hw(pte) (pte) >> + >> +#define hw_pte_val(x) pte_val(x) >> #endif > > I was just about to say: this series doesn't add any users. You should add > that > detail to the patch description: "prepare for usage in arch code" or sth like > that. > > With that > > Acked-by: David Hildenbrand (Arm) <[email protected]>
I'll add to the description. Thanks for reviewing. -- Thanks, Usama
