[PATCH] iomem: Adjust address width for 64-bit addresses

Lingxiang Zheng posted 1 patch 2 years, 9 months ago
kernel/resource.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
[PATCH] iomem: Adjust address width for 64-bit addresses
Posted by Lingxiang Zheng 2 years, 9 months ago
Modify the address width determination in /proc/iomem output to better
handle 64-bit addresses. The previous implementation did not correctly
account for 64-bit address space, as it would limit the address width to 8
hexadecimal characters. This change adjusts the address width according to
the following conditions:

1. If the resource's end address is less than 0x10000, set the width to 4.
2. If the resource's end address is greater than 0xFFFFFFFF, set the width to 16.
3. For other cases, set the width to 8.

Signed-off-by: Lingxiang Zheng <lxzheng@gmail.com>
---
 kernel/resource.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/resource.c b/kernel/resource.c
index b1763b2fd7ef..d8f977d628f5 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -110,7 +110,7 @@ static int r_show(struct seq_file *m, void *v)
 	struct resource *root = pde_data(file_inode(m->file));
 	struct resource *r = v, *p;
 	unsigned long long start, end;
-	int width = root->end < 0x10000 ? 4 : 8;
+	int width = root->end < 0x10000 ? 4 : root->end > 0xFFFFFFFF ? 16 : 8;
 	int depth;
 
 	for (depth = 0, p = r; depth < MAX_IORES_LEVEL; depth++, p = p->parent)
-- 
2.17.1
Re: [PATCH] iomem: Adjust address width for 64-bit addresses
Posted by Linus Torvalds 2 years, 9 months ago
On Thu, May 11, 2023 at 9:28 AM Lingxiang Zheng <lxzheng@gmail.com> wrote:
>
> Modify the address width determination in /proc/iomem output to better
> handle 64-bit addresses. The previous implementation did not correctly
> account for 64-bit address space, as it would limit the address width to 8
> hexadecimal characters.

Note that the width is the *minimum* number of characters to print
(with zero padding due to the zero in front in the printf format). Not
the maximum.

I do not believe we actually want to expand the width to be 16
characters wide, just because it's above the 4GB area. That would make
the numbers huge.

The main reason for the 4/8 split is actually for the IO port cases,
ie we do *not* want to show IO ports (that are limited to 16 bits) as
8 hex-char wide.

So think of the 4/8 as a visual distinction between the iomem and
ioports files.

And yes, I'm aware that some platforms have IO ports that are larger
than 16 bits, and on those platforms as a result the iomem and ioports
files will have similar visual behavior.

            Linus