Re: [PATCH 08/11] ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel

On Thu, Dec 8, 2016 at 2:11 AM, Dan Williams wrote: > On Tue, Nov 29, 2016 at 11:21 PM, Lv Zheng wrote: >> ACPICA commit cac6790954d4d752a083e610b8a22febcd07 >> >> This patch back ports Linux acpi_get_table_with_size() and >>

Re: [PATCH 08/11] ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel

_os_unmap_memory() from Linux kernel >> >> On Thu, Dec 8, 2016 at 5:18 AM, Rafael J. Wysocki <raf...@kernel.org> wrote: >> > On Thu, Dec 8, 2016 at 2:11 AM, Dan Williams <dan.j.willi...@intel.com> >> > wrote: >> >> O

Re: [RFC v2 1/5] acpi: add missing include in acpi_numa.h

UMNODES" is not defined > [-Wundef] > #if MAX_NUMNODES > 256 > ^~~~ > > Signed-off-by: Ross Zwisler <ross.zwis...@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com> > --- > include/acpi/acpi_numa.h | 1 + > 1 file

Re: [RFC v2 2/5] acpi: HMAT support in acpi_parse_entries_array()

On Thu, Jul 6, 2017 at 11:52 PM, Ross Zwisler wrote: > The current implementation of acpi_parse_entries_array() assumes that each > subtable has a standard ACPI subtable entry of type struct > acpi_sutbable_header. This standard subtable header has a one byte length

Re: [PATCH 5/6] acpi: change memory allocations to GFP_NOIO

On Friday, July 14, 2017 10:26:42 PM Dan Williams wrote: > [ adding Bob ] > > On Fri, Jul 14, 2017 at 3:11 PM, Vishal Verma > wrote: > > With the ACPI NFIT 'DSM' methods, acpi can be called from IO paths. > > Specifically, the DSM to clear media errors is called during

Re: [resend RFC 1/6] ACPICA: add HMAT table definitions

On Mon, Jun 5, 2017 at 9:50 PM, Ross Zwisler wrote: > Import HMAT table definitions from the ACPICA codebase. > > This kernel patch was generated using an ACPICA patch from "Zheng, Lv" > . The actual upstream patch that adds these table >

Re: [PATCH v3 1/3] acpi: HMAT support in acpi_parse_entries_array()

On Sat, Dec 16, 2017 at 2:57 AM, Dan Williams <dan.j.willi...@intel.com> wrote: > On Fri, Dec 15, 2017 at 5:53 PM, Rafael J. Wysocki <r...@rjwysocki.net> wrote: >> On Friday, December 15, 2017 2:10:17 AM CET Dan Williams wrote: >>> On Wed, Dec 13, 2017 at 6:10 P

Re: [PATCH v3 1/3] acpi: HMAT support in acpi_parse_entries_array()

On Friday, December 15, 2017 2:10:17 AM CET Dan Williams wrote: > On Wed, Dec 13, 2017 at 6:10 PM, Ross Zwisler > wrote: > > The current implementation of acpi_parse_entries_array() assumes that each > > subtable has a standard ACPI subtable entry of type struct > >

Re: [PATCH v3 1/3] acpi: HMAT support in acpi_parse_entries_array()

On Thu, Dec 14, 2017 at 3:10 AM, Ross Zwisler wrote: > The current implementation of acpi_parse_entries_array() assumes that each > subtable has a standard ACPI subtable entry of type struct > acpi_subtable_header. This standard subtable header has a one byte length

Re: [PATCH v3 2/3] hmat: add heterogeneous memory sysfs support

On Thu, Dec 14, 2017 at 3:10 AM, Ross Zwisler wrote: > Add a new sysfs subsystem, /sys/devices/system/hmat, which surfaces > information about memory initiators and memory targets to the user. These > initiators and targets are described by the ACPI SRAT and HMAT

Re: [PATCH v3 0/3] create sysfs representation of ACPI HMAT

On Sat, Dec 23, 2017 at 12:57 AM, Dan Williams wrote: > On Fri, Dec 22, 2017 at 3:22 PM, Ross Zwisler > wrote: >> On Fri, Dec 22, 2017 at 02:53:42PM -0800, Dan Williams wrote: >>> On Thu, Dec 21, 2017 at 12:31 PM, Brice Goglin

Re: [PATCH] acpi: add NFIT and HMAT to the initrd override list

On Thu, Feb 22, 2018 at 10:12 PM, Ross Zwisler wrote: > On Mon, Dec 18, 2017 at 12:54:05PM -0700, Ross Zwisler wrote: >> On Fri, Dec 08, 2017 at 08:29:25AM -0800, Dan Williams wrote: >> > These tables, NFIT and HMAT, are essential for describing >> > next-generation

Re: [PATCH v2 5/7] ACPICA: Integrate package handling with module-level code

Linux ACPI <linux-a...@vger.kernel.org>; Rafael J. Wysocki > > <r...@rjwysocki.net>; Moore, Robert <robert.mo...@intel.com>; linux-nvdimm > > <linux-nvdimm@lists.01.org> > > Subject: Re: [PATCH v2 5/7] ACPICA: Integrate package handling with module- &

Re: [driver-core PATCH v9 2/9] device core: Consolidate locking and unlocking of parent and device

t; > This patch should produce no functional changes, it is meant to be a code > clean-up/consolidation only. > > Reviewed-by: Luis Chamberlain > Reviewed-by: Bart Van Assche > Reviewed-by: Dan Williams > Reviewed-by: Rafael J. Wysocki > Signed-off-by: Alexander Duyck > --- >

Re: [driver-core PATCH v9 1/9] driver core: Establish order of operations for device_add and device_del via bitflag

_attach, had already taken the > device_lock() and checked for dev->driver. Instead of testing for this > twice in this path it makes more sense to just consolidate the dev->dead > and dev->driver checks together into one set of checks. > > Reviewed-by: Dan Williams > Si

Re: [PATCH 2/2] vsprintf: Remove support for %pF and %pf in favour of %pS and %ps

On Fri, Mar 22, 2019 at 2:21 PM Sakari Ailus wrote: > > %pS and %ps are now the preferred conversion specifiers to print function > %names. The functionality is equivalent; remove the old, deprecated %pF > %and %pf support. Are %pF and %pf really not used any more in the kernel? If that is not

Re: [PATCH 1/2] treewide: Switch printk users from %pf and %pF to %ps and %pS, respectively

following command: > > git grep -l '%p[fF]' | grep -v '^\(tools\|Documentation\)/' | \ > while read i; do perl -i -pe 's/%pf/%ps/g; s/%pF/%pS/g;' $i; done > > And verifying the result. > > Signed-off-by: Sakari Ailus Acked-by: Rafael J. Wysocki > --- >

Re: [PATCH 2/2] vsprintf: Remove support for %pF and %pf in favour of %pS and %ps

On Mon, Mar 25, 2019 at 10:30 AM Rafael J. Wysocki wrote: > > On Fri, Mar 22, 2019 at 2:21 PM Sakari Ailus > wrote: > > > > %pS and %ps are now the preferred conversion specifiers to print function > > %names. The functionality is equivalent; remove the old, deprecat

Re: [driver-core PATCH v10 6/9] driver core: Attach devices on CPU local to device node

like this where we will see the biggest improvement. > > Reviewed-by: Dan Williams > Reviewed-by: Bart Van Assche > Signed-off-by: Alexander Duyck Reviewed-by: Rafael J. Wysocki > --- > drivers/base/dd.c |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > &

Re: [driver-core PATCH v10 3/9] driver core: Probe devices asynchronously instead of the driver

on the > deferred probe call. > > Reviewed-by: Bart Van Assche > Reviewed-by: Dan Williams > Signed-off-by: Alexander Duyck Reviewed-by: Rafael J. Wysocki > --- > drivers/base/base.h |2 ++ > drivers/base/bus.c | 23 +++ > drivers/base/

Re: [PATCH v2 1/8] acpi: Drop drivers/acpi/hmat/ directory

On Friday, May 31, 2019 12:59:27 AM CEST Dan Williams wrote: > As a single source file object there is no need for the hmat enabling to > have its own directory. Well, I asked Keith to add that directory as the code in hmat.c is more related to mm than to the rest of the ACPI subsystem. Is

Re: [PATCH v4 10/10] acpi/numa/hmat: Register "specific purpose" memory as an "hmem" device

{ > "chardev":"dax1.0", > "size":"4.00 GiB (4.29 GB)" > } > ] > }, > { > "path":"\/platform\/hmem.0", > "id":0, > "size":"4.00 GiB (4.29 GB)",

Re: [PATCH v4 01/10] acpi/numa: Establish a new drivers/acpi/numa/ directory

o srat.c and moved to drivers/acpi/numa/ along with > hmat.c. > > Cc: Len Brown > Cc: Keith Busch > Cc: "Rafael J. Wysocki" > Reviewed-by: Dave Hansen > Signed-off-by: Dan Williams Acked-by: Rafael J. Wysocki > --- > drivers/acpi/Kconfig |

Re: [PATCH v4 09/10] acpi/numa/hmat: Register HMAT at device_initcall level

ccur > after e820__reserve_resources_late() which is the point at which the > iomem resource tree is populated with "Application Reserved" > (IORES_DESC_APPLICATION_RESERVED). e820__reserve_resources_late() > happens at subsys_initcall time. > > Cc: "Rafael J. Wysocki" > Cc:

Re: [PATCH v4 02/10] acpi/numa/hmat: Skip publishing target info for nodes with no online memory

hen the node is not marked > online leading a spurious: > > "acpi/hmat: Ignoring HMAT: Invalid table" > > ...result for HMAT parsing. > > Reviewed-by: Dave Hansen > Signed-off-by: Dan Williams Acked-by: Rafael J. Wysocki > --- > drivers/acpi/numa/hmat.c

Re: [PATCH v8 00/12] EFI Specific Purpose Memory Support

On Thu, Nov 7, 2019 at 2:57 AM Dan Williams wrote: > > Changes since v7: > - This is mostly a resend to get it refreshed in Ingo's inbox for v5.5 > consideration. It picks up a Reviewed-by on patch4 from Ard, has a > minor cosmetic rebase on v5.4-rc6 with no other changes, it merges >

Re: [PATCH v8 00/12] EFI Specific Purpose Memory Support

On Thu, Nov 7, 2019 at 2:49 PM Thomas Gleixner wrote: > > On Thu, 7 Nov 2019, Rafael J. Wysocki wrote: > > On Thu, Nov 7, 2019 at 2:57 AM Dan Williams > > wrote: > > > > Indeed. > > > > I have waited for comments on x86 bits from Thomas, but since th

Re: [PATCH] acpi/nfit: unlock on error in scrub_show()

On Fri, Oct 18, 2019 at 2:38 PM Dan Carpenter wrote: > > We change the locking in this function and forgot to update this error > path so we are accidentally still holding the "dev->lockdep_mutex". > > Fixes: 87a30e1f05d7 ("driver-core, libnvdimm: Let device subsystems add local > lockdep

[GIT PULL] ACPI updates for v5.5-rc1

Hi Linus, Please pull from the tag git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ acpi-5.5-rc1 with top-most commit 782b59711e1561ee0da06bc478ca5e8249aa8d09 Merge branch 'acpi-mm' on top of commit 31f4f5b495a62c9a8b15b1c3581acd5efeb9af8c Linux 5.4-rc7 to receive

Re: [PATCH v2 14/18] acpi/numa: Up-level "map to online node" functionality

> represent were it to be onlined (target_node), up-level the core of > acpi_map_pxm_to_online_node() to a generic mm/numa helper. > > Cc: Michal Hocko > Cc: "Rafael J. Wysocki" > Signed-off-by: Dan Williams It looks like this is the only patch in the series nee

Re: [PATCH][next] acpi: nfit.h: Replace zero-length array with flexible-array member

On Thu, Mar 19, 2020 at 9:15 PM Gustavo A. R. Silva wrote: > > The current codebase makes use of the zero-length array language > extension to the C90 standard, but the preferred mechanism to declare > variable-length types such as these ones is a flexible array member[1][2], > introduced in C99:

Re: [PATCH v2 0/6] Manual definition of Soft Reserved memory devices

mat) to optionally disable > consideration of the HMAT and update efi_fake_mem= to behave like > memmap=nn!ss in terms of delimiting device boundaries. > > [2]: > https://lore.kernel.org/lkml/20200110190313.17144-1-joao.m.mart...@oracle.com/ > > With Ard's and Rafael's ack

Re: [ACPI] b13663bdf9: BUG:sleeping_function_called_from_invalid_context_at_kernel/locking/mutex.c

On 5/11/2020 11:00 AM, kernel test robot wrote: Greeting, FYI, we noticed the following commit (built with gcc-7): commit: b13663bdf9701c8896bebcc7ee998f8656c1ea37 ("[PATCH] ACPI: Drop rcu usage for MMIO mappings") url:

Re: [PATCH 1/5] ACPI: NUMA: Add 'nohmat' option

On Wed, Mar 18, 2020 at 6:39 PM Dan Williams wrote: > > On Wed, Mar 18, 2020 at 1:24 AM Rafael J. Wysocki wrote: > > > > On Wed, Mar 18, 2020 at 1:09 AM Dan Williams > > wrote: > > > > > > On Mon, Mar 2, 2020 at 2:36 PM Dan Williams > > >

Re: [PATCH 1/5] ACPI: NUMA: Add 'nohmat' option

n with this change to the numa= option? > > ...as I look at this I realize I failed to also update > Documentation/x86/x86_64/boot-options.rst, will fix. Thanks! Apart from this just a minor nit below. > > > > Cc: x...@kernel.org > > Cc: "Rafael J. Wysocki" &

Re: [PATCH] ACPI: Drop rcu usage for MMIO mappings

emory mapped I/O remappings") Cc: Len Brown Cc: Borislav Petkov Cc: Ira Weiny Cc: James Morse Cc: Erik Kaneda Cc: Myron Stowe Cc: "Rafael J. Wysocki" Cc: Andy Shevchenko Signed-off-by: Dan Williams linux-acpi is kind of relevant for this too, so please CC it. ---

Re: [PATCH] acpi/nfit: Use kobj_to_dev() instead

On Sat, Aug 15, 2020 at 12:52 AM Verma, Vishal L wrote: > > On Fri, 2020-08-14 at 17:28 +0200, Rafael J. Wysocki wrote: > > On Thu, Aug 13, 2020 at 4:54 AM Wang Qing wrote: > > > Use kobj_to_dev() instead of container_of() > > > > > > Signed-off-by: W

Re: [PATCH -next] ACPI: NFIT: Fix judgment of rc is '-ENXIO'

On Tue, Oct 27, 2020 at 2:38 PM Zhang Qilong wrote: > > Initial value of rc is '-ENXIO', and we should > use the initial value to check it. > > Signed-off-by: Zhang Qilong > --- > drivers/acpi/nfit/core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git

Re: [RFT][PATCH v3 0/4] ACPI: ACPICA / OSL: Avoid unmapping ACPI memory inside of the AML interpreter

On Mon, Jun 29, 2020 at 10:46 PM Dan Williams wrote: > > On Sun, Jun 28, 2020 at 10:09 AM Rafael J. Wysocki wrote: > > > > On Fri, Jun 26, 2020 at 8:41 PM Dan Williams > > wrote: > > > > > > On Fri, Jun 26, 2020 at 10:34 AM Rafael J. Wys

Re: [PATCH 00/12] ACPI/NVDIMM: Runtime Firmware Activation

On Tue, Jun 30, 2020 at 1:37 AM Dan Williams wrote: > > On Sun, Jun 28, 2020 at 10:23 AM Rafael J. Wysocki wrote: > > > > On Fri, Jun 26, 2020 at 8:43 PM Dan Williams > > wrote: > > > > > > On Fri, Jun 26, 2020 at 7:22 AM Rafael J. Wysocki > &g

Re: [PATCH v4 2/2] ACPICA: Preserve memory opregion mappings

On Mon, Jun 29, 2020 at 10:57 PM Al Stone wrote: > > On 29 Jun 2020 18:33, Rafael J. Wysocki wrote: > > From: "Rafael J. Wysocki" > > > > The ACPICA's strategy with respect to the handling of memory mappings > > associated with memory operation regions i

Re: [PATCH v4 2/2] ACPICA: Preserve memory opregion mappings

On Tue, Jun 30, 2020 at 5:31 PM Al Stone wrote: > > On 30 Jun 2020 13:44, Rafael J. Wysocki wrote: > > On Mon, Jun 29, 2020 at 10:57 PM Al Stone wrote: > > > > > > On 29 Jun 2020 18:33, Rafael J. Wysocki wrote: > > > > From: "Rafael J. Wysocki"

Re: [PATCH v2 11/12] PM, libnvdimm: Add 'mem-quiet' state and callback for firmware activation

On Thu, Jul 9, 2020 at 5:39 PM Jason Gunthorpe wrote: > > On Thu, Jul 09, 2020 at 04:00:51PM +0100, Christoph Hellwig wrote: > > On Mon, Jul 06, 2020 at 06:59:32PM -0700, Dan Williams wrote: > > > The runtime firmware activation capability of Intel NVDIMM devices > > > requires memory

Re: [PATCH v2 11/12] PM, libnvdimm: Add 'mem-quiet' state and callback for firmware activation

On Tuesday, July 7, 2020 3:59:32 AM CEST Dan Williams wrote: > The runtime firmware activation capability of Intel NVDIMM devices > requires memory transactions to be disabled for 100s of microseconds. > This timeout is large enough to cause in-flight DMA to fail and other > application detectable

Re: [PATCH v2 11/12] PM, libnvdimm: Add 'mem-quiet' state and callback for firmware activation

On Thursday, July 9, 2020 9:04:30 PM CEST Dan Williams wrote: > On Thu, Jul 9, 2020 at 7:57 AM Rafael J. Wysocki wrote: > > > > On Tuesday, July 7, 2020 3:59:32 AM CEST Dan Williams wrote: > > > The runtime firmware activation capability of Intel NVDIMM devices > >

[RFT][PATCH v3 1/4] ACPICA: Take deferred unmapping of memory into account

From: "Rafael J. Wysocki" The ACPI OS layer in Linux uses RCU to protect the walkers of the list of ACPI memory mappings from seeing an inconsistent state while it is being updated. Among other situations, that list can be walked in (NMI and non-NMI) interrupt context, so using a sle

[RFT][PATCH v3 4/4] ACPI: OSL: Implement acpi_os_map_memory_fast_path()

From: "Rafael J. Wysocki" Add acpi_os_map_memory_fast_path() and set ACPI_USE_FAST_PATH_MAPPING to allow acpi_ex_system_memory_space_handler() to avoid unnecessary memory mapping and unmapping overhead by retaining all memory mappings created by it until the memory opregions associated

[RFT][PATCH v3 3/4] ACPICA: Preserve memory opregion mappings if supported by OS

From: "Rafael J. Wysocki" The ACPICA's strategy with respect to the handling of memory mappings associated with memory operation regions is to avoid mapping the entire region at once which may be problematic at least in principle (for example, it may lead to conflicts with overlappin

[RFT][PATCH v3 0/4] ACPI: ACPICA / OSL: Avoid unmapping ACPI memory inside of the AML interpreter

Hi All, On Monday, June 22, 2020 3:50:42 PM CEST Rafael J. Wysocki wrote: > Hi All, > > This series is to address the problem with RCU synchronization occurring, > possibly relatively often, inside of acpi_ex_system_memory_space_handler(), > when the namespace and interpreter m

[RFT][PATCH v3 2/4] ACPI: OSL: Implement deferred unmapping of ACPI memory

From: "Rafael J. Wysocki" Rework acpi_os_unmap_memory() so that it does not release the memory mapping matching the given address range right away but queues it up for later removal, implement acpi_os_release_unused_mappings() that will remove the unused ACPI memory mappings and add i

Re: [RFT][PATCH v2 3/4] ACPICA: Preserve memory opregion mappings if supported by OS

On Sat, Jun 27, 2020 at 12:53 AM Kaneda, Erik wrote: > > > > > -Original Message- > > From: Rafael J. Wysocki > > Sent: Monday, June 22, 2020 7:02 AM > > To: Williams, Dan J ; Kaneda, Erik > > > > Cc: Wysocki, Rafael J ; Len Brown > &g

[PATCH v4 1/2] ACPI: OSL: Implement deferred unmapping of ACPI memory

From: "Rafael J. Wysocki" The ACPI OS layer in Linux uses RCU to protect the walkers of the list of ACPI memory mappings from seeing an inconsistent state while it is being updated. Among other situations, that list can be walked in (NMI and non-NMI) interrupt context, so using a sle

[PATCH v4 2/2] ACPICA: Preserve memory opregion mappings

From: "Rafael J. Wysocki" The ACPICA's strategy with respect to the handling of memory mappings associated with memory operation regions is to avoid mapping the entire region at once which may be problematic at least in principle (for example, it may lead to conflicts with overlappin

[PATCH v4 0/2] ACPI: ACPICA / OSL: Avoid unmapping ACPI memory inside of the AML interpreter

Hi All, On Friday, June 26, 2020 7:28:27 PM CEST Rafael J. Wysocki wrote: > Hi All, > > On Monday, June 22, 2020 3:50:42 PM CEST Rafael J. Wysocki wrote: > > Hi All, > > > > This series is to address the problem with RCU synchronization occurring, > >

[RFT][PATCH v2 3/4] ACPICA: Preserve memory opregion mappings if supported by OS

From: "Rafael J. Wysocki" The ACPICA's strategy with respect to the handling of memory mappings associated with memory operation regions is to avoid mapping the entire region at once which may be problematic at least in principle (for example, it may lead to conflicts with overlappin

[RFT][PATCH v2 0/4] ACPI: ACPICA / OSL: Avoid unmapping ACPI memory inside of the AML interpreter

Hi All, This series is to address the problem with RCU synchronization occurring, possibly relatively often, inside of acpi_ex_system_memory_space_handler(), when the namespace and interpreter mutexes are held. Like I said before, I had decided to change the approach used in the previous

[RFT][PATCH v2 1/4] ACPICA: Defer unmapping of opregion memory if supported by OS

From: "Rafael J. Wysocki" The ACPI OS layer in Linux uses RCU to protect the walkers of the list of ACPI memory mappings from seeing an inconsistent state while it is being updated. Among other situations, that list can be walked in (NMI and non-NMI) interrupt context, so using a sle

[RFT][PATCH v2 2/4] ACPI: OSL: Add support for deferred unmapping of ACPI memory

From: "Rafael J. Wysocki" Implement acpi_os_unmap_deferred() and acpi_os_release_unused_mappings() and set ACPI_USE_DEFERRED_UNMAPPING to allow ACPICA to use deferred unmapping of memory in acpi_ex_system_memory_space_handler() so as to avoid RCU-related performance issues with memory

[RFT][PATCH v2 4/4] ACPI: OSL: Implement acpi_os_map_memory_fast_path()

From: "Rafael J. Wysocki" Add acpi_os_map_memory_fast_path() and set ACPI_USE_FAST_PATH_MAPPING to allow acpi_ex_system_memory_space_handler() to avoid unnecessary memory mapping and unmapping overhead by retaining all memory mappings created by it until the memory opregions associated

Re: [RFT][PATCH v3 0/4] ACPI: ACPICA / OSL: Avoid unmapping ACPI memory inside of the AML interpreter

On Fri, Jun 26, 2020 at 8:41 PM Dan Williams wrote: > > On Fri, Jun 26, 2020 at 10:34 AM Rafael J. Wysocki wrote: > > > > Hi All, > > > > On Monday, June 22, 2020 3:50:42 PM CEST Rafael J. Wysocki wrote: > > > Hi All, > > > > > > This

Re: [PATCH 00/12] ACPI/NVDIMM: Runtime Firmware Activation

On Fri, Jun 26, 2020 at 8:43 PM Dan Williams wrote: > > On Fri, Jun 26, 2020 at 7:22 AM Rafael J. Wysocki wrote: > > > > On Fri, Jun 26, 2020 at 2:06 AM Dan Williams > > wrote: > > > > > > Quoting the documentation: > > > > > &g

Re: [PATCH 11/12] PM, libnvdimm: Add syscore_quiesced() callback for firmware activation

On Fri, Jun 26, 2020 at 2:07 AM Dan Williams wrote: > > The runtime firmware activation capability of Intel NVDIMM devices > requires memory transactions to be disabled for 100s of microseconds. > This timeout is large enough to cause in-flight DMA to fail and other > application detectable

Re: [PATCH 00/12] ACPI/NVDIMM: Runtime Firmware Activation

On Fri, Jun 26, 2020 at 2:06 AM Dan Williams wrote: > > Quoting the documentation: > > Some persistent memory devices run a firmware locally on the device / > "DIMM" to perform tasks like media management, capacity provisioning, > and health monitoring. The process of updating that

Re: [RFT][PATCH v2 2/4] ACPI: OSL: Add support for deferred unmapping of ACPI memory

On Mon, Jun 22, 2020 at 4:56 PM Andy Shevchenko wrote: > > On Mon, Jun 22, 2020 at 5:06 PM Rafael J. Wysocki wrote: > > > > From: "Rafael J. Wysocki" > > > > Implement acpi_os_unmap_deferred() and > > acpi_os_release_unused_mappings() and set A

[RFT][PATCH 1/3] ACPICA: Defer unmapping of memory used in memory opregions

From: "Rafael J. Wysocki" The ACPI OS layer in Linux uses RCU to protect the list of ACPI memory mappings from being walked while it is being updated. Among other situations, that list can be walked in (NMI and non-NMI) interrupt context, so using a sleeping lock to protect it is not

[RFT][PATCH 2/3] ACPICA: Remove unused memory mappings on interpreter exit

From: "Rafael J. Wysocki" For transient memory opregions that are created dynamically under the namespace and interpreter mutexes and go away quickly, there still is the problem that removing their memory mappings may take significant time and so doing that while holding the mute

[RFT][PATCH 3/3] ACPI: OSL: Define ACPI_OS_MAP_MEMORY_FAST_PATH()

From: "Rafael J. Wysocki" Define the ACPI_OS_MAP_MEMORY_FAST_PATH() macro to allow acpi_ex_system_memory_space_handler() to avoid memory unmapping overhead by deferring the unmap operations to the point when the AML interpreter is exited after removing the operation region that held

[RFT][PATCH 0/3] ACPI: ACPICA / OSL: Avoid unmapping ACPI memory inside of the AML interpreter

Hi All, This series is to address the problem with RCU synchronization occurring, possibly relatively often, inside of acpi_ex_system_memory_space_handler(), when the namespace and interpreter mutexes are held. The basic idea is to avoid the actual unmapping of memory in

Re: [RFT][PATCH] ACPI: OSL: Use rwlock instead of RCU for memory management

On Fri, Jun 5, 2020 at 9:40 PM Andy Shevchenko wrote: > > On Fri, Jun 5, 2020 at 5:11 PM Rafael J. Wysocki wrote: > > ... > > > + if (!refcount) { > > + write_lock_irq(_ioremaps_list_lock); > > + > > + list_del(>list);

Re: [RFT][PATCH] ACPI: OSL: Use rwlock instead of RCU for memory management

On Fri, Jun 5, 2020 at 7:09 PM Dan Williams wrote: > > On Fri, Jun 5, 2020 at 7:06 AM Rafael J. Wysocki wrote: > > > > From: Rafael J. Wysocki > > Subject: [PATCH] ACPI: OSL: Use rwlock instead of RCU for memory management > > > > The ACPI OS layer uses RC

Re: [PATCH v2] ACPI: Drop rcu usage for MMIO mappings

On Fri, Jun 5, 2020 at 6:18 PM Dan Williams wrote: > > On Fri, Jun 5, 2020 at 6:32 AM Rafael J. Wysocki wrote: > > > > On Fri, May 8, 2020 at 1:55 AM Dan Williams > > wrote: > > > > > > Recently a performance problem was reported for a proce

Re: [PATCH v2] ACPI: Drop rcu usage for MMIO mappings

On Fri, Jun 5, 2020 at 6:39 PM Dan Williams wrote: > > On Fri, Jun 5, 2020 at 9:22 AM Rafael J. Wysocki wrote: > [..] > > > The fix we are looking at now is to pre-map operation regions in a > > > similar manner as the way APEI resources are pre-mapped. The >

Re: [RFT][PATCH] ACPI: OSL: Use rwlock instead of RCU for memory management

On Saturday, June 6, 2020 8:56:26 AM CEST Rafael J. Wysocki wrote: > On Fri, Jun 5, 2020 at 7:09 PM Dan Williams wrote: > > > > On Fri, Jun 5, 2020 at 7:06 AM Rafael J. Wysocki wrote: > > > > > > From: Rafael J. Wysocki > > > Subject: [PATCH] ACPI:

[RFT][PATCH] ACPI: OSL: Use rwlock instead of RCU for memory management

From: Rafael J. Wysocki Subject: [PATCH] ACPI: OSL: Use rwlock instead of RCU for memory management The ACPI OS layer uses RCU to protect the list of ACPI memory mappings from being walked while it is updated. Among other situations, that list can be walked in non-NMI interrupt context, so

Re: [PATCH v2] ACPI: Drop rcu usage for MMIO mappings

On Fri, May 8, 2020 at 1:55 AM Dan Williams wrote: > > Recently a performance problem was reported for a process invoking a > non-trival ASL program. The method call in this case ends up > repetitively triggering a call path like: > > acpi_ex_store > acpi_ex_store_object_to_node >

Re: [RFT][PATCH 2/3] ACPICA: Remove unused memory mappings on interpreter exit

On Fri, Jun 12, 2020 at 2:12 AM Kaneda, Erik wrote: > > > > > -Original Message- > > From: Rafael J. Wysocki > > Sent: Wednesday, June 10, 2020 5:22 AM > > To: Williams, Dan J > > Cc: Kaneda, Erik ; Wysocki, Rafael J > > ; Len Brown ; B

Re: [RFT][PATCH 2/3] ACPICA: Remove unused memory mappings on interpreter exit

On Friday, June 12, 2020 2:05:01 PM CEST Rafael J. Wysocki wrote: > On Fri, Jun 12, 2020 at 2:12 AM Kaneda, Erik wrote: > > > > > > > > > -Original Message- > > > From: Rafael J. Wysocki > > > Sent: Wednesday, June 10, 2020 5:22 AM &

Re: [RFT][PATCH 0/3] ACPI: ACPICA / OSL: Avoid unmapping ACPI memory inside of the AML interpreter

On Wednesday, June 10, 2020 2:17:04 PM CEST Rafael J. Wysocki wrote: > Hi All, > > This series is to address the problem with RCU synchronization occurring, > possibly relatively often, inside of acpi_ex_system_memory_space_handler(), > when the namespace and interpreter m

Re: [PATCH v3 10/11] PM, libnvdimm: Add runtime firmware activation support

On Wed, Jul 29, 2020 at 3:35 AM Vishal Verma wrote: > > On Mon, 2020-07-27 at 14:37 +0200, Rafael J. Wysocki wrote: > > On Tue, Jul 21, 2020 at 12:24 AM Dan Williams > > wrote: > > > Abstract platform specific mechanics for nvdimm firmware activation > >

Re: [PATCH v3 10/11] PM, libnvdimm: Add runtime firmware activation support

y. The mechanism supports enumeration and > triggering of firmware activate, optionally in the > hibernate_quiet_exec() context. > > Cc: Pavel Machek > Cc: Ira Weiny > Cc: Len Brown > Cc: Jonathan Corbet > Cc: Dave Jiang > Cc: Vishal Verma > [rafael: hibernate_quiet_

Re: [PATCH v4 2/2] ACPICA: Preserve memory opregion mappings

On Thu, Jul 16, 2020 at 9:22 PM Verma, Vishal L wrote: > > On Mon, 2020-06-29 at 18:33 +0200, Rafael J. Wysocki wrote: > > From: "Rafael J. Wysocki" > > > > The ACPICA's strategy with respect to the handling of memory mappings > > associated with memo

Re: [PATCH] acpi/nfit: Use kobj_to_dev() instead

On Thu, Aug 13, 2020 at 4:54 AM Wang Qing wrote: > > Use kobj_to_dev() instead of container_of() > > Signed-off-by: Wang Qing LGTM Dan, any objections? > --- > drivers/acpi/nfit/core.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/acpi/nfit/core.c

Re: [PATCH v2] ACPI: Fix whitespace inconsistencies

On Thu, Nov 5, 2020 at 3:06 AM Maximilian Luz wrote: > > Replaces spaces with tabs where spaces have been (inconsistently) used > for indentation and removes trailing whitespaces. > > Signed-off-by: Maximilian Luz > --- > > Was previously: ACPI: Remove trailing whitespace > > Changes in v2: > -

Re: [PATCH] ACPI: NFIT: Fix support for variable 'SPA' structure size

; skx_register_mci+0x132/0x1c0 [skx_edac] > > Cc: Bob Moore > Cc: Erik Kaneda > Fixes: cf16b05c607b ("ACPICA: ACPI 6.4: NFIT: add Location Cookie field") Do you want me to apply this (as the commit being fixed went in through the ACPI tree)? If you'd rather take care of i

Re: [PATCH] ACPI: NFIT: Fix support for variable 'SPA' structure size

On Fri, May 7, 2021 at 4:12 PM Dan Williams wrote: > > On Fri, May 7, 2021 at 2:47 AM Rafael J. Wysocki wrote: > > > > Hi Dan, > > > > On Fri, May 7, 2021 at 9:33 AM Dan Williams > > wrote: > > > > > > ACPI 6.4 introduced the "SpaLoca