[PATCH RFC 2/3] mm/treewide: rename CONFIG_HAVE_FAST_GUP to CONFIG_HAVE_GUP_FAST

Nowadays, we call it "GUP-fast", the external interface includes functions like "get_user_pages_fast()", and we renamed all internal functions to reflect that as well. Let's make the config option reflect that. Signed-off-by: David Hildenbrand --- arch/arm/Kconfig | 2 +-

[PATCH RFC 1/3] mm/gup: consistently name GUP-fast functions

Let's consistently call the "fast-only" part of GUP "GUP-fast" and rename all relevant internal functions to start with "gup_fast", to make it clearer that this is not ordinary GUP. The current mixture of "lockless", "gup" and "gup_fast" is confusing. Further, avoid the term "huge" when talking

[PATCH RFC 0/3] mm/gup: consistently call it GUP-fast

Some cleanups around function names, comments and the config option of "GUP-fast" -- GUP without "lock" safety belts on. With this cleanup it's easy to judge which functions are GUP-fast specific. We now consistently call it "GUP-fast", avoiding mixing it with "fast GUP", "lockless", or simply

FAILED: Patch "PCI/AER: Block runtime suspend when handling errors" failed to apply to 4.19-stable tree

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to . Thanks, Sasha -- original commit in Linus's tree -- >From

FAILED: Patch "powerpc: xor_vmx: Add '-mhard-float' to CFLAGS" failed to apply to 4.19-stable tree

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to . Thanks, Sasha -- original commit in Linus's tree -- >From

FAILED: Patch "powerpc/smp: Increase nr_cpu_ids to include the boot CPU" failed to apply to 4.19-stable tree

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to . Thanks, Sasha -- original commit in Linus's tree -- >From

FAILED: Patch "powerpc/smp: Adjust nr_cpu_ids to cover all threads of a core" failed to apply to 4.19-stable tree

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to . Thanks, Sasha -- original commit in Linus's tree -- >From

FAILED: Patch "PCI/AER: Block runtime suspend when handling errors" failed to apply to 5.4-stable tree

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to . Thanks, Sasha -- original commit in Linus's tree -- >From

FAILED: Patch "powerpc: xor_vmx: Add '-mhard-float' to CFLAGS" failed to apply to 5.4-stable tree

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to . Thanks, Sasha -- original commit in Linus's tree -- >From

FAILED: Patch "powerpc/smp: Increase nr_cpu_ids to include the boot CPU" failed to apply to 5.4-stable tree

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to . Thanks, Sasha -- original commit in Linus's tree -- >From

FAILED: Patch "powerpc/smp: Adjust nr_cpu_ids to cover all threads of a core" failed to apply to 5.4-stable tree

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to . Thanks, Sasha -- original commit in Linus's tree -- >From

FAILED: Patch "powerpc: xor_vmx: Add '-mhard-float' to CFLAGS" failed to apply to 5.10-stable tree

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to . Thanks, Sasha -- original commit in Linus's tree -- >From

FAILED: Patch "powerpc/smp: Increase nr_cpu_ids to include the boot CPU" failed to apply to 5.10-stable tree

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to . Thanks, Sasha -- original commit in Linus's tree -- >From

FAILED: Patch "powerpc/smp: Adjust nr_cpu_ids to cover all threads of a core" failed to apply to 5.10-stable tree

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to . Thanks, Sasha -- original commit in Linus's tree -- >From

FAILED: Patch "powerpc/smp: Increase nr_cpu_ids to include the boot CPU" failed to apply to 5.15-stable tree

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to . Thanks, Sasha -- original commit in Linus's tree -- >From

FAILED: Patch "powerpc/smp: Adjust nr_cpu_ids to cover all threads of a core" failed to apply to 5.15-stable tree

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to . Thanks, Sasha -- original commit in Linus's tree -- >From

Re: [RFC PATCH 1/8] mm: Provide pagesize to pmd_populate()

Le 26/03/2024 à 16:01, Jason Gunthorpe a écrit : > On Mon, Mar 25, 2024 at 07:05:01PM +, Christophe Leroy wrote: > >> Not looked into details yet, but I guess so. >> >> By the way there is a wiki dedicated to huge pages on powerpc, you can >> have a look at it here : >>

Re: [PATCH 8/9] ALSA: aoa: avoid false-positive format truncation warning

On Tue, 26 Mar 2024 23:38:07 +0100, Arnd Bergmann wrote: > > From: Arnd Bergmann > > clang warns about what it interprets as a truncated snprintf: > > sound/aoa/soundbus/i2sbus/core.c:171:6: error: 'snprintf' will always be > truncated; specified size is 6, but format string expands to at

Re: [PATCH v12 8/8] PCI: endpoint: Remove "core_init_notifier" flag

On Wed, Mar 27, 2024 at 02:43:37PM +0530, Manivannan Sadhasivam wrote: > "core_init_notifier" flag is set by the glue drivers requiring refclk from > the host to complete the DWC core initialization. Also, those drivers will > send a notification to the EPF drivers once the initialization is fully

[PATCH v12 8/8] PCI: endpoint: Remove "core_init_notifier" flag

"core_init_notifier" flag is set by the glue drivers requiring refclk from the host to complete the DWC core initialization. Also, those drivers will send a notification to the EPF drivers once the initialization is fully completed using the pci_epc_init_notify() API. Only then, the EPF drivers

[PATCH v12 7/8] PCI: dwc: ep: Call dw_pcie_ep_init_registers() API directly from all glue drivers

Currently, dw_pcie_ep_init_registers() API is directly called by the glue drivers requiring active refclk from host. But for the other drivers, it is getting called implicitly by dw_pcie_ep_init(). This is due to the fact that this API initializes DWC EP specific registers and that requires an

[PATCH v12 6/8] PCI: dwc: ep: Rename dw_pcie_ep_init_complete() to dw_pcie_ep_init_registers()

The goal of the dw_pcie_ep_init_complete() API is to initialize the DWC specific registers post registering the controller with the EP framework. But the naming doesn't reflect its functionality and causes confusion. So, let's rename it to dw_pcie_ep_init_registers() to make it clear that it

[PATCH v12 5/8] PCI: dwc: ep: Introduce dw_pcie_ep_cleanup() API for drivers supporting PERST#

For DWC glue drivers supporting PERST# (currently Qcom and Tegra194), some of the DWC resources like eDMA should be cleaned up during the PERST# assert time. So let's introduce a dw_pcie_ep_cleanup() API that could be called by these drivers to cleanup the DWC specific resources. Currently, it

[PATCH v12 4/8] PCI: dwc: ep: Rename dw_pcie_ep_exit() to dw_pcie_ep_deinit()

dw_pcie_ep_exit() API is undoing what the dw_pcie_ep_init() API has done already (at least partly). But the API name dw_pcie_ep_exit() is not quite reflecting that. So let's rename it to dw_pcie_ep_deinit() to make the purpose of this API clear. This also aligns with the DWC host driver.

[PATCH v12 3/8] PCI: dwc: ep: Remove deinit() callback from struct dw_pcie_ep_ops

deinit() callback was solely introduced for the pcie-rcar-gen4 driver where it is used to do platform specific resource deallocation. And this callback is called right at the end of the dw_pcie_ep_exit() API. So it doesn't matter whether it is called within or outside of dw_pcie_ep_exit() API. So

[PATCH v12 2/8] PCI: dwc: ep: Add Kernel-doc comments for APIs

All of the APIs are missing the Kernel-doc comments. Hence, add them. Reviewed-by: Frank Li Reviewed-by: Niklas Cassel Signed-off-by: Manivannan Sadhasivam --- drivers/pci/controller/dwc/pcie-designware-ep.c | 77 + 1 file changed, 77 insertions(+) diff --git

[PATCH v12 1/8] PCI: dwc: ep: Fix DBI access failure for drivers requiring refclk from host

The DWC glue drivers requiring an active reference clock from the PCIe host for initializing their PCIe EP core, set a flag called 'core_init_notifier' to let DWC driver know that these drivers need a special attention during initialization. In these drivers, access to the hw registers (like DBI)

[PATCH v12 0/8] PCI: dwc: ep: Fix DBI access failure for drivers requiring refclk from host

...@nvidia.com/ [2] https://lore.kernel.org/linux-pci/20231120084014.108274-1-manivannan.sadhasi...@linaro.org/ Changes in v12: - Fixed the init_notify() API used in non-dwc drivers (thanks Niklas) - Dropped Gustavo from CC since his email is bouncing - Link to v11: https://lore.kernel.org/r/20240327

Re: [PATCH v11 8/8] PCI: endpoint: Remove "core_init_notifier" flag

On Wed, Mar 27, 2024 at 09:24:05AM +0100, Niklas Cassel wrote: > Hello Mani, > > On Wed, Mar 27, 2024 at 12:05:54PM +0530, Manivannan Sadhasivam wrote: > > "core_init_notifier" flag is set by the glue drivers requiring refclk from > > the host to complete the DWC core initialization. Also, those

[PATCH v7 6/6] docs: trusted-encrypted: add DCP as new trust source

Update the documentation for trusted and encrypted KEYS with DCP as new trust source: - Describe security properties of DCP trust source - Describe key usage - Document blob format Co-developed-by: Richard Weinberger Signed-off-by: Richard Weinberger Co-developed-by: David Oberhollenzer

[PATCH v7 5/6] docs: document DCP-backed trusted keys kernel params

Document the kernel parameters trusted.dcp_use_otp_key and trusted.dcp_skip_zk_test for DCP-backed trusted keys. Co-developed-by: Richard Weinberger Signed-off-by: Richard Weinberger Co-developed-by: David Oberhollenzer Signed-off-by: David Oberhollenzer Signed-off-by: David Gstir ---

[PATCH v7 4/6] MAINTAINERS: add entry for DCP-based trusted keys

This covers trusted keys backed by NXP's DCP (Data Co-Processor) chip found in smaller i.MX SoCs. Signed-off-by: David Gstir Acked-by: Jarkko Sakkinen --- MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 976a5cea1577..ca7f42ca9338 100644

[PATCH v7 3/6] KEYS: trusted: Introduce NXP DCP-backed trusted keys

DCP (Data Co-Processor) is the little brother of NXP's CAAM IP. Beside of accelerated crypto operations, it also offers support for hardware-bound keys. Using this feature it is possible to implement a blob mechanism similar to what CAAM offers. Unlike on CAAM, constructing and parsing the blob

[PATCH v7 2/6] KEYS: trusted: improve scalability of trust source config

Enabling trusted keys requires at least one trust source implementation (currently TPM, TEE or CAAM) to be enabled. Currently, this is done by checking each trust source's config option individually. This does not scale when more trust sources like the one for DCP are added, because the condition

[PATCH v7 1/6] crypto: mxs-dcp: Add support for hardware-bound keys

DCP (Data Co-Processor) is able to derive private keys for a fused random seed, which can be referenced by handle but not accessed by the CPU. Similarly, DCP is able to store arbitrary keys in four dedicated key slots located in its secure memory area (internal SRAM). These keys can be used to

[PATCH v7 0/6] DCP as trusted keys backend

This is a revival of the previous patch set submitted by Richard Weinberger: https://lore.kernel.org/linux-integrity/20210614201620.30451-1-rich...@nod.at/ After having been thoroughly reviewed by Jarkko, it would be great if this could go into 6.10. :-) v6 is here (please ignore the incorrect

Re: [PATCH v11 8/8] PCI: endpoint: Remove "core_init_notifier" flag

Hello Mani, On Wed, Mar 27, 2024 at 12:05:54PM +0530, Manivannan Sadhasivam wrote: > "core_init_notifier" flag is set by the glue drivers requiring refclk from > the host to complete the DWC core initialization. Also, those drivers will > send a notification to the EPF drivers once the

[PATCH v11 8/8] PCI: endpoint: Remove "core_init_notifier" flag

"core_init_notifier" flag is set by the glue drivers requiring refclk from the host to complete the DWC core initialization. Also, those drivers will send a notification to the EPF drivers once the initialization is fully completed using the pci_epc_init_notify() API. Only then, the EPF drivers

[PATCH v11 7/8] PCI: dwc: ep: Call dw_pcie_ep_init_registers() API directly from all glue drivers

Currently, dw_pcie_ep_init_registers() API is directly called by the glue drivers requiring active refclk from host. But for the other drivers, it is getting called implicitly by dw_pcie_ep_init(). This is due to the fact that this API initializes DWC EP specific registers and that requires an

[PATCH v11 6/8] PCI: dwc: ep: Rename dw_pcie_ep_init_complete() to dw_pcie_ep_init_registers()

The goal of the dw_pcie_ep_init_complete() API is to initialize the DWC specific registers post registering the controller with the EP framework. But the naming doesn't reflect its functionality and causes confusion. So, let's rename it to dw_pcie_ep_init_registers() to make it clear that it

[PATCH v11 5/8] PCI: dwc: ep: Introduce dw_pcie_ep_cleanup() API for drivers supporting PERST#

For DWC glue drivers supporting PERST# (currently Qcom and Tegra194), some of the DWC resources like eDMA should be cleaned up during the PERST# assert time. So let's introduce a dw_pcie_ep_cleanup() API that could be called by these drivers to cleanup the DWC specific resources. Currently, it

[PATCH v11 4/8] PCI: dwc: ep: Rename dw_pcie_ep_exit() to dw_pcie_ep_deinit()

dw_pcie_ep_exit() API is undoing what the dw_pcie_ep_init() API has done already (at least partly). But the API name dw_pcie_ep_exit() is not quite reflecting that. So let's rename it to dw_pcie_ep_deinit() to make the purpose of this API clear. This also aligns with the DWC host driver.

[PATCH v11 3/8] PCI: dwc: ep: Remove deinit() callback from struct dw_pcie_ep_ops

deinit() callback was solely introduced for the pcie-rcar-gen4 driver where it is used to do platform specific resource deallocation. And this callback is called right at the end of the dw_pcie_ep_exit() API. So it doesn't matter whether it is called within or outside of dw_pcie_ep_exit() API. So

[PATCH v11 2/8] PCI: dwc: ep: Add Kernel-doc comments for APIs

All of the APIs are missing the Kernel-doc comments. Hence, add them. Reviewed-by: Frank Li Reviewed-by: Niklas Cassel Signed-off-by: Manivannan Sadhasivam --- drivers/pci/controller/dwc/pcie-designware-ep.c | 77 + 1 file changed, 77 insertions(+) diff --git

[PATCH v11 1/8] PCI: dwc: ep: Fix DBI access failure for drivers requiring refclk from host

The DWC glue drivers requiring an active reference clock from the PCIe host for initializing their PCIe EP core, set a flag called 'core_init_notifier' to let DWC driver know that these drivers need a special attention during initialization. In these drivers, access to the hw registers (like DBI)

[PATCH v11 0/8] PCI: dwc: ep: Fix DBI access failure for drivers requiring refclk from host

Hello, This series is the continuation of previous work by Vidya Sagar [1] to fix the issues related to accessing DBI register space before completing the core initialization in some EP platforms like Tegra194/234 and Qcom EP. Since Vidya is busy, I took over the series based on his consent

<    1   2