Eric,
> This series moves the contents of arch/$(ARCH)/lib/crypto/ into
> lib/crypto/$(ARCH)/.
LGTM.
Reviewed-by: Martin K. Petersen
--
Martin K. Petersen
On Thu, Jun 19, 2025 at 09:49:03AM +0100, Lorenzo Stoakes wrote:
> On Thu, Jun 19, 2025 at 10:42:14AM +0200, Christian Brauner wrote:
> > If you change vm_flags_t to u64 you probably want to compile with some
> > of these integer truncation options when you're doing the conversion.
> > Because othe
On Wed, Jun 18, 2025 at 08:42:53PM +0100, Lorenzo Stoakes wrote:
> The core kernel code is currently very inconsistent in its use of
> vm_flags_t vs. unsigned long. This prevents us from changing the type of
> vm_flags_t in the future and is simply not correct, so correct this.
>
> While this resu
On Wed, Jun 18, 2025 at 08:42:54PM +0100, Lorenzo Stoakes wrote:
> In future we intend to change the vm_flags_t type, so it isn't correct for
> architecture and driver code to assume it is unsigned long. Correct this
> assumption across the board.
>
> Overall, this patch does not introduce any fun
On Wed, Jun 18, 2025 at 08:42:52PM +0100, Lorenzo Stoakes wrote:
> We abstract the type of the VMA flags to vm_flags_t, however in may places
> it is simply assumed this is unsigned long, which is simply incorrect.
>
> At the moment this is simply an incongruity, however in future we plan to
> cha
On 6/19/2025 12:18 PM, Eric Biggers wrote:
> Eric Biggers (9):
> lib/crypto: arm: move arch/arm/lib/crypto/ into lib/crypto/
> lib/crypto: arm64: move arch/arm64/lib/crypto/ into lib/crypto/
> lib/crypto: mips: move arch/mips/lib/crypto/ into lib/crypto/
> lib/crypto: powerpc: move arch/po
On Thu, 19 Jun 2025 at 21:22, Eric Biggers wrote:
>
> This series applies on top of
> https://lore.kernel.org/r/20250616014019.415791-1-ebigg...@kernel.org/
> and is also available in git at:
>
> git fetch
> https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git
> arch-to-lib-cry
On Thu, Jun 19, 2025 at 12:18:59PM -0700, Eric Biggers wrote:
> This series applies on top of
> https://lore.kernel.org/r/20250616014019.415791-1-ebigg...@kernel.org/
> and is also available in git at:
>
> git fetch
> https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git
> arch-
On 18 Jun 2025, at 13:40, David Hildenbrand wrote:
> ... instead, look them up statically based on the page type. Maybe in the
> future we want a registration interface? At least for now, it can be
> easily handled using the two page types that actually support page
> migration.
>
> The remaining
On 18 Jun 2025, at 13:40, David Hildenbrand wrote:
> Convert to page_has_movable_ops(). While at it, cleanup relevant code
> a bit.
>
> The data_race() in migrate_folio_unmap() is questionable: we already
> hold a page reference, and concurrent modifications can no longer
> happen (iow: __ClearPag
On 18 Jun 2025, at 13:40, David Hildenbrand wrote:
> Currently, we only support migration of individual non-folio pages, so
> we can not run into that.
>
> Signed-off-by: David Hildenbrand
> ---
> mm/page_isolation.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Reviewed-by: Zi Yan
On 18 Jun 2025, at 13:39, David Hildenbrand wrote:
> Let's make it clearer that we are talking about movable_ops pages.
>
> Signed-off-by: David Hildenbrand
> ---
> include/linux/migrate.h| 2 +-
> include/linux/page-flags.h | 2 +-
> mm/compaction.c| 7 ++-
> mm/memory-fa
On 18 Jun 2025, at 13:39, David Hildenbrand wrote:
> As __ClearPageMovable() is gone that would have only made
> PageMovable()==false but still __PageMovable()==true, now
> PageMovable() == __PageMovable().
>
> So we can replace PageMovable() checks by __PageMovable(). In fact,
> __PageMovable() c
On 18 Jun 2025, at 13:39, David Hildenbrand wrote:
> Unused, let's remove it.
>
> The Chinese docs in Documentation/translations/zh_CN/mm/page_migration.rst
> still mention it, but that whole docs is destined to get outdated and
> updated by somebody that actually speaks that language.
>
> Signed-
On 18 Jun 2025, at 13:39, David Hildenbrand wrote:
> Let's move that handling directly into migrate_folio_move(), so we can
> simplify move_to_new_folio(). While at it, fixup the documentation a
> bit.
>
> Note that unmap_and_move_huge_page() does not care, because it only
> deals with actual foli
On 18 Jun 2025, at 13:39, David Hildenbrand wrote:
> Folios will have nothing to do with movable_ops page migration. These
> functions are now unused, so let's remove them.
>
> Signed-off-by: David Hildenbrand
> ---
> include/linux/migrate.h | 14 --
> 1 file changed, 14 deletions(-)
On 18 Jun 2025, at 13:39, David Hildenbrand wrote:
> Let's factor it out, simplifying the calling code.
>
> The assumption is that flush_dcache_page() is not required for
> movable_ops pages: as documented for flush_dcache_folio(), it really
> only applies when the kernel wrote to pagecache pages
From: Stefano Garzarella
Some devices do not support interrupts and provide a single synchronous
operation to send the command and receive the response on the same buffer.
Currently, these types of drivers must use an internal buffer where they
temporarily store the response between .send() and
The content of this version is the same of v5, but rebased on current
linux-tpmdd/next (`git range-diff` on v5 is empty) after the merge
window since tpm-svsm patches were merged with another tree, so we
agreed on postpone this series, see
https://lore.kernel.org/linux-integrity/adcb-wkhgolq-...@
Replace scnprintf() with sysfs_emit() in sysfs show functions.
These helpers are preferred in sysfs callbacks because they automatically
handle buffer size and improve safety and readability.
Signed-off-by: Ankit Chauhan
---
drivers/misc/ocxl/sysfs.c | 12 ++--
1 file changed, 6 insertio
- Original Message -
> From: "Lukas Wunner"
> To: "Timothy Pearson"
> Cc: "Bjorn Helgaas" , "linuxppc-dev"
> , "linux-kernel"
> , "linux-pci" ,
> "Madhavan Srinivasan" ,
> "Michael Ellerman" , "christophe leroy"
> , "Naveen N Rao"
> , "Bjorn Helgaas" , "Shawn Anastasio"
>
> Sent:
From: Stefano Garzarella
This driver does not support interrupts, and receiving the response is
synchronous with sending the command.
Enable synchronous send() with TPM_CHIP_FLAG_SYNC, which implies that
->send() already fills the provided buffer with a response, and ->recv()
is not implemented.
From: Stefano Garzarella
This driver does not support interrupts, and receiving the response is
synchronous with sending the command.
Enable synchronous send() with TPM_CHIP_FLAG_SYNC, which implies that
->send() already fills the provided buffer with a response, and ->recv()
is not implemented.
From: Stefano Garzarella
Add a new `bufsiz` parameter to the `.send` callback in `tpm_class_ops`.
This parameter will allow drivers to differentiate between the actual
command length to send and the total buffer size. Currently `bufsiz` is
not used, but it will be used to implement devices with s
Le 20/06/2025 à 09:55, Thomas Fourier a écrit :
[Vous ne recevez pas souvent de courriers de fourier.tho...@gmail.com.
Découvrez pourquoi ceci est important à
https://aka.ms/LearnAboutSenderIdentification ]
The DMA map functions can fail and should be tested for errors.
Signed-off-by: Thom
Shawn, Timothy:
Thanks for posting the series of patch. Few things I wanted to do better
understand Raptor problem -
1. Last time my two patches solved all the hotunplug operation and Kernel crash
issue except nvme case. It did not work with
NVME since dpc support was not there. I was not
On Fri, 2025-06-20 at 08:17 +0530, Ankit Chauhan wrote:
> Replace scnprintf() with sysfs_emit() in sysfs show functions.
> These helpers are preferred in sysfs callbacks because they
> automatically
> handle buffer size and improve safety and readability.
>
> Signed-off-by: Ankit Chauhan
Thanks
On Thu, Jun 19, 2025 at 02:29:33PM -0500, Timothy Pearson wrote:
> To be perfectly frank the existing code quality in this driver
> (and the associated EEH driver) is not the best, and it's been
> a frustrating experience trying to hack it into semi-stable
> operation.
>
> I would vastly prefer to
Le 20/06/2025 à 09:55, Thomas Fourier a écrit :
> [Vous ne recevez pas souvent de courriers de fourier.tho...@gmail.com.
> Découvrez pourquoi ceci est important à
> https://aka.ms/LearnAboutSenderIdentification ]
>
> The DMA map functions can fail and should be tested for errors.
>
> Signed-o
The DMA map functions can fail and should be tested for errors.
Signed-off-by: Thomas Fourier
---
arch/powerpc/include/asm/floppy.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/floppy.h
b/arch/powerpc/include/asm/floppy.h
index f8ce178b43b7..3
Hi Thomas,
Le 19/06/2025 à 13:07, Thomas Fourier a écrit :
[Vous ne recevez pas souvent de courriers de fourier.tho...@gmail.com.
Découvrez pourquoi ceci est important à
https://aka.ms/LearnAboutSenderIdentification ]
The DMA map functions can fail and should be tested for errors.
Signed-off
31 matches
Mail list logo
