All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sam Edwards <cfsworks@gmail.com>
To: Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Marc Zyngier <maz@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Anshuman Khandual <anshuman.khandual@arm.com>,
	Ard Biesheuvel <ardb@kernel.org>,
	Ryan Roberts <ryan.roberts@arm.com>,
	Baruch Siach <baruch@tkos.co.il>,
	Kevin Brodsky <kevin.brodsky@arm.com>,
	Joey Gouly <joey.gouly@arm.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, Sam Edwards <CFSworks@gmail.com>
Subject: [PATCH 0/3] Type correctness cleanup for ARM64 MMU initialization
Date: Thu, 21 Aug 2025 21:15:35 -0700	[thread overview]
Message-ID: <20250822041538.467514-1-CFSworks@gmail.com> (raw)

Hello list,

This is a small series of type correctness and readability improvements for
ARM64's MMU initialization code. When I first encountered this code, the heavy
use of u64 to represent both virtual and physical addresses made it difficult
to understand where the demarcations were. I made most of the changes in this
series while troubleshooting a different problem (fixed in a separate patch) to
make that boundary a little clearer. I am submitting it now in the hopes that
this will improve maintainability and readability for others.

While nothing in this series represents a change in behavior, it is not merely
cosmetic: I believe these changes better align with the kernel's code
standards, type discipline, and common C idioms.

Happy Thursday,
Sam

Sam Edwards (3):
  arm64: mm: Cast start/end markers to char *, not u64
  arm64: mm: Make map_fdt() return mapped pointer
  arm64: mm: Represent physical memory with phys_addr_t and
    resource_size_t

 arch/arm64/kernel/pi/map_kernel.c | 41 ++++++++++++++++---------------
 arch/arm64/kernel/pi/map_range.c  | 20 +++++++++------
 arch/arm64/kernel/pi/pi.h         |  9 ++++---
 arch/arm64/mm/init.c              |  6 ++---
 arch/arm64/mm/mmu.c               | 17 +++++++------
 5 files changed, 50 insertions(+), 43 deletions(-)

-- 
2.49.1



             reply	other threads:[~2025-08-22 11:48 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-22  4:15 Sam Edwards [this message]
2025-08-22  4:15 ` [PATCH 1/3] arm64: mm: Cast start/end markers to char *, not u64 Sam Edwards
2025-08-22  4:15 ` [PATCH 2/3] arm64: mm: Make map_fdt() return mapped pointer Sam Edwards
2025-08-22  4:15 ` [PATCH 3/3] arm64: mm: Represent physical memory with phys_addr_t and resource_size_t Sam Edwards
2025-08-23 23:57   ` Sam Edwards

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250822041538.467514-1-CFSworks@gmail.com \
    --to=cfsworks@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=anshuman.khandual@arm.com \
    --cc=ardb@kernel.org \
    --cc=baruch@tkos.co.il \
    --cc=catalin.marinas@arm.com \
    --cc=joey.gouly@arm.com \
    --cc=kevin.brodsky@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=ryan.roberts@arm.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.