Documentation/mm/page_tables.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
The documentation incorrectly calculate the pfn value as 0x3fffff,
which should be 0x3ffff instead. It is obtained by right-shifting
0xffffc000 by 14 bits.
This patch corrects the value to prevent any potential confusion
for developers referencing this document.
Signed-off-by: Pengyu Zhang <zpenya1314@gmail.com>
---
Documentation/mm/page_tables.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/mm/page_tables.rst b/Documentation/mm/page_tables.rst
index be47b192a596..e7c69cc32493 100644
--- a/Documentation/mm/page_tables.rst
+++ b/Documentation/mm/page_tables.rst
@@ -29,7 +29,7 @@ address.
With a page granularity of 4KB and a address range of 32 bits, pfn 0 is at
address 0x00000000, pfn 1 is at address 0x00001000, pfn 2 is at 0x00002000
and so on until we reach pfn 0xfffff at 0xfffff000. With 16KB pages pfs are
-at 0x00004000, 0x00008000 ... 0xffffc000 and pfn goes from 0 to 0x3fffff.
+at 0x00004000, 0x00008000 ... 0xffffc000 and pfn goes from 0 to 0x3ffff.
As you can see, with 4KB pages the page base address uses bits 12-31 of the
address, and this is why `PAGE_SHIFT` in this case is defined as 12 and
--
2.25.1
Pengyu Zhang <zpenya1314@gmail.com> writes: > The documentation incorrectly calculate the pfn value as 0x3fffff, > which should be 0x3ffff instead. It is obtained by right-shifting > 0xffffc000 by 14 bits. > > This patch corrects the value to prevent any potential confusion > for developers referencing this document. > > Signed-off-by: Pengyu Zhang <zpenya1314@gmail.com> > --- > Documentation/mm/page_tables.rst | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/mm/page_tables.rst b/Documentation/mm/page_tables.rst > index be47b192a596..e7c69cc32493 100644 > --- a/Documentation/mm/page_tables.rst > +++ b/Documentation/mm/page_tables.rst > @@ -29,7 +29,7 @@ address. > With a page granularity of 4KB and a address range of 32 bits, pfn 0 is at > address 0x00000000, pfn 1 is at address 0x00001000, pfn 2 is at 0x00002000 > and so on until we reach pfn 0xfffff at 0xfffff000. With 16KB pages pfs are > -at 0x00004000, 0x00008000 ... 0xffffc000 and pfn goes from 0 to 0x3fffff. > +at 0x00004000, 0x00008000 ... 0xffffc000 and pfn goes from 0 to 0x3ffff. > Applied, thanks. For future reference, when you submit an updated version of a patch, please make a note of what has changed below the "---" line. Also, you didn't pick up Mike's Reviewed-by from the first version; I've added it. Thanks, jon
On 2024/10/9 22:41, Pengyu Zhang wrote: > The documentation incorrectly calculate the pfn value as 0x3fffff, > which should be 0x3ffff instead. It is obtained by right-shifting > 0xffffc000 by 14 bits. > > This patch corrects the value to prevent any potential confusion > for developers referencing this document. > > Signed-off-by: Pengyu Zhang <zpenya1314@gmail.com> Reviewed-by: Zenghui Yu <zenghui.yu@linux.dev>
On Wed, Oct 9, 2024 at 4:41 PM Pengyu Zhang <zpenya1314@gmail.com> wrote: > The documentation incorrectly calculate the pfn value as 0x3fffff, > which should be 0x3ffff instead. It is obtained by right-shifting > 0xffffc000 by 14 bits. > > This patch corrects the value to prevent any potential confusion > for developers referencing this document. > > Signed-off-by: Pengyu Zhang <zpenya1314@gmail.com> Thanks, I love attention to detail yet make mistakes all the time! Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Yours, Linus Walleij
© 2016 - 2024 Red Hat, Inc.