<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/Documentation/features/vm, branch v6.1.168</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1.168</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1.168'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2022-06-27T11:22:31+00:00</updated>
<entry>
<title>arm64: Add HAVE_IOREMAP_PROT support</title>
<updated>2022-06-27T11:22:31+00:00</updated>
<author>
<name>Kefeng Wang</name>
<email>wangkefeng.wang@huawei.com</email>
</author>
<published>2022-06-07T12:50:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=893dea9ccd08dab924839354aba21d4ed7a9abc0'/>
<id>urn:sha1:893dea9ccd08dab924839354aba21d4ed7a9abc0</id>
<content type='text'>
With ioremap_prot() definition from generic ioremap, also move
pte_pgprot() from hugetlbpage.c into pgtable.h, then arm64 could
have HAVE_IOREMAP_PROT, which will enable generic_access_phys()
code, it is useful for debug, eg, gdb.

Acked-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Reviewed-by: Anshuman Khandual &lt;anshuman.khandual@arm.com&gt;
Signed-off-by: Kefeng Wang &lt;wangkefeng.wang@huawei.com&gt;
Link: https://lore.kernel.org/r/20220607125027.44946-7-wangkefeng.wang@huawei.com
Signed-off-by: Will Deacon &lt;will@kernel.org&gt;
</content>
</entry>
<entry>
<title>Documentation/features: Update the arch support status files</title>
<updated>2022-06-09T15:35:57+00:00</updated>
<author>
<name>Zheng Zengkai</name>
<email>zhengzengkai@huawei.com</email>
</author>
<published>2022-06-09T02:56:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5860800e8696d2cbbd1a0dd60b433549d176e668'/>
<id>urn:sha1:5860800e8696d2cbbd1a0dd60b433549d176e668</id>
<content type='text'>
The arch support status files don't match reality as of v5.19-rc1,
use the features-refresh.sh to refresh all the arch-support.txt files
in place.  The main effect is to add entries for the new loong
architecture.

Signed-off-by: Zheng Zengkai &lt;zhengzengkai@huawei.com&gt;
Link: https://lore.kernel.org/r/20220609025656.143460-1-zhengzengkai@huawei.com
Signed-off-by: Jonathan Corbet &lt;corbet@lwn.net&gt;
</content>
</entry>
<entry>
<title>Merge branch 'remove-h8300' of git://git.infradead.org/users/hch/misc into asm-generic</title>
<updated>2022-04-04T12:42:49+00:00</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2022-04-04T12:42:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fba2689ee77e63b05e203b3f26079ef915e55660'/>
<id>urn:sha1:fba2689ee77e63b05e203b3f26079ef915e55660</id>
<content type='text'>
* 'remove-h8300' of git://git.infradead.org/users/hch/misc:
  remove the h8300 architecture

This is clearly the least actively maintained architecture we have at
the moment, and probably the least useful. It is now the only one that
does not support MMUs at all, and most of the boards only support 4MB
of RAM, out of which the defconfig kernel needs more than half just
for .text/.data.

Guenter Roeck did the original patch to remove the architecture in 2013
after it had already been obsolete for a while, and Yoshinori Sato brought
it back in a much more modern form in 2015. Looking at the git history
since the reinstantiation, it's clear that almost all commits in the tree
are build fixes or cross-architecture cleanups:

$ git log --no-merges --format=%an v4.5.. arch/h8300/  | sort | uniq
-c | sort -rn | head -n 12
     25 Masahiro Yamada
     18 Christoph Hellwig
     14 Mike Rapoport
      9 Arnd Bergmann
      8 Mark Rutland
      7 Peter Zijlstra
      6 Kees Cook
      6 Ingo Molnar
      6 Al Viro
      5 Randy Dunlap
      4 Yury Norov

Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
</content>
</entry>
<entry>
<title>nds32: Remove the architecture</title>
<updated>2022-03-07T12:54:59+00:00</updated>
<author>
<name>Alan Kao</name>
<email>alankao@andestech.com</email>
</author>
<published>2022-03-02T07:42:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=aec499c75cf8e0b599be4d559e6922b613085f8f'/>
<id>urn:sha1:aec499c75cf8e0b599be4d559e6922b613085f8f</id>
<content type='text'>
The nds32 architecture, also known as AndeStar V3, is a custom 32-bit
RISC target designed by Andes Technologies. Support was added to the
kernel in 2016 as the replacement RISC-V based V5 processors were
already announced, and maintained by (current or former) Andes
employees.

As explained by Alan Kao, new customers are now all using RISC-V,
and all known nds32 users are already on longterm stable kernels
provided by Andes, with no development work going into mainline
support any more.

While the port is still in a reasonably good shape, it only gets
worse over time without active maintainers, so it seems best
to remove it before it becomes unusable. As always, if it turns
out that there are mainline users after all, and they volunteer
to maintain the port in the future, the removal can be reverted.

Link: https://lore.kernel.org/linux-mm/YhdWNLUhk+x9RAzU@yamatobi.andestech.com/
Link: https://lore.kernel.org/lkml/20220302065213.82702-1-alankao@andestech.com/
Link: https://www.andestech.com/en/products-solutions/andestar-architecture/
Signed-off-by: Alan Kao &lt;alankao@andestech.com&gt;
[arnd: rewrite changelog to provide more background]
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
</content>
</entry>
<entry>
<title>remove the h8300 architecture</title>
<updated>2022-02-23T07:52:50+00:00</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2022-02-23T07:47:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1c4b5ecb7ea190fa3e9f9d6891e6c90b60e04f24'/>
<id>urn:sha1:1c4b5ecb7ea190fa3e9f9d6891e6c90b60e04f24</id>
<content type='text'>
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
</content>
</entry>
<entry>
<title>Merge tag 'riscv-for-linus-5.15-mw1' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux</title>
<updated>2021-09-11T21:29:42+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2021-09-11T21:29:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b79bd0d5102b4a3ea908018fda6b84a4c8fd6235'/>
<id>urn:sha1:b79bd0d5102b4a3ea908018fda6b84a4c8fd6235</id>
<content type='text'>
Pull more RISC-V updates from Palmer Dabbelt:

 - A pair of defconfig additions, for NVMe and the EFI filesystem
   localization options.

 - A larger address space for stack randomization.

 - A cleanup to our install rules.

 - A DTS update for the Microchip Icicle board, to fix the serial
   console.

 - Support for build-time table sorting, which allows us to have
   __ex_table read-only.

* tag 'riscv-for-linus-5.15-mw1' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
  riscv: Move EXCEPTION_TABLE to RO_DATA segment
  riscv: Enable BUILDTIME_TABLE_SORT
  riscv: dts: microchip: mpfs-icicle: Fix serial console
  riscv: move the (z)install rules to arch/riscv/Makefile
  riscv: Improve stack randomisation on RV64
  riscv: defconfig: enable NLS_CODEPAGE_437, NLS_ISO8859_1
  riscv: defconfig: enable BLK_DEV_NVME
</content>
</entry>
<entry>
<title>riscv: Improve stack randomisation on RV64</title>
<updated>2021-09-11T05:25:34+00:00</updated>
<author>
<name>Kefeng Wang</name>
<email>wangkefeng.wang@huawei.com</email>
</author>
<published>2021-08-12T11:47:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d5935537c8256fc63c77d5f4914dfd6e3ef43241'/>
<id>urn:sha1:d5935537c8256fc63c77d5f4914dfd6e3ef43241</id>
<content type='text'>
This enlarges the bits availiable for stack randomisation on RV64 from
the default of 8MiB to 1GiB, to match arm64 and x86.

Also, update the documentation to reflect our support for stack
randomisation.

Signed-off-by: Kefeng Wang &lt;wangkefeng.wang@huawei.com&gt;
[Palmer: commit text]
Signed-off-by: Palmer Dabbelt &lt;palmerdabbelt@google.com&gt;
</content>
</entry>
<entry>
<title>Documentation/features/vm: correct huge-vmap APIs</title>
<updated>2021-08-24T19:31:00+00:00</updated>
<author>
<name>Mark Rutland</name>
<email>mark.rutland@arm.com</email>
</author>
<published>2021-08-17T09:16:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d4477209c8fbc1bb0035ca44426e02238f68c5fd'/>
<id>urn:sha1:d4477209c8fbc1bb0035ca44426e02238f68c5fd</id>
<content type='text'>
In commit:

  bbc180a5adb05ee8 ("mm: HUGE_VMAP arch support cleanup")

We replaced:

  * ioremap_pud_enabled() with arch_vmap_pud_supported()
  * ioremap_pmd_enabled() with arch_vmap_pmd_supported()

Update the documentation accordingly.

Signed-off-by: Mark Rutland &lt;mark.rutland@arm.com&gt;
Cc: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Cc: Ingo Molnar &lt;mingo@kernel.org&gt;
Cc: Jonathan Corbet &lt;corbet@lwn.net&gt;
Cc: Nicholas Piggin &lt;npiggin@gmail.com&gt;
Cc: linux-doc@vger.kernel.org
Link: https://lore.kernel.org/r/20210817091621.16799-1-mark.rutland@arm.com
Signed-off-by: Jonathan Corbet &lt;corbet@lwn.net&gt;
</content>
</entry>
<entry>
<title>Documentation/features/vm: riscv supports THP now</title>
<updated>2021-08-12T14:54:33+00:00</updated>
<author>
<name>Jisheng Zhang</name>
<email>jszhang@kernel.org</email>
</author>
<published>2021-08-04T16:27:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=27f373cb5c9805d1e921ec9c5faf738ecf3fd989'/>
<id>urn:sha1:27f373cb5c9805d1e921ec9c5faf738ecf3fd989</id>
<content type='text'>
After commit e88b333142e4 ("riscv: mm: add THP support on 64-bit"),
riscv can support THP.

Signed-off-by: Jisheng Zhang &lt;jszhang@kernel.org&gt;
Link: https://lore.kernel.org/r/20210805002739.23f44d2d@xhacker
Signed-off-by: Jonathan Corbet &lt;corbet@lwn.net&gt;
</content>
</entry>
<entry>
<title>Documentation/features: mark BATCHED_UNMAP_TLB_FLUSH doesn't apply to ARM64</title>
<updated>2021-03-15T19:17:40+00:00</updated>
<author>
<name>Barry Song</name>
<email>song.bao.hua@hisilicon.com</email>
</author>
<published>2021-02-23T00:32:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6bfef171d0d74cb050112e0e49feb20bfddf7f42'/>
<id>urn:sha1:6bfef171d0d74cb050112e0e49feb20bfddf7f42</id>
<content type='text'>
BATCHED_UNMAP_TLB_FLUSH is used on x86 to do batched tlb shootdown by
sending one IPI to TLB flush all entries after unmapping pages rather
than sending an IPI to flush each individual entry.
On arm64, tlb shootdown is done by hardware. Flush instructions are
innershareable. The local flushes are limited to the boot (1 per CPU)
and when a task is getting a new ASID.
So marking this feature as "TODO" is not proper. ".." isn't good as
well. So this patch adds a "N/A" for this kind of features which are
not needed on some architectures.

Signed-off-by: Barry Song &lt;song.bao.hua@hisilicon.com&gt;
Acked-by: Will Deacon &lt;will@kernel.org&gt;
Cc: Mel Gorman &lt;mgorman@suse.de&gt;
Cc: Andy Lutomirski &lt;luto@kernel.org&gt;
Cc: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Cc: Will Deacon &lt;will@kernel.org&gt;
Link: https://lore.kernel.org/r/20210223003230.11976-1-song.bao.hua@hisilicon.com
Signed-off-by: Jonathan Corbet &lt;corbet@lwn.net&gt;
</content>
</entry>
</feed>
