Hanjun Guo | 3 Jul 09:29 2015

[PATCH v2] ARM64 / SMP: Switch pr_err() to pr_debug() for disabled GICC entry

It is normal that firmware presents GICC entry or entries (processors)
with disabled flag in ACPI MADT, taking a system of 16 cpus for example,
ACPI firmware may present 8 ebabled first with another 8 cpus disabled
in MADT, the disabled cpus can be hot-added later.

Firmware may also present more cpus than the hardware actually has, but
disabled the unused ones, and easily enable it when the hardware has such
cpus to make the firmware code scalable.

So that's not an error for disabled cpus in MADT, we can switch pr_err()
to pr_debug() to make the boot a little quieter by default.

Since hwid for disabled cpus often are invalid, and we check invalid hwid
fisrt in the code, for use case that hot add cpus later will be filtered
out and will not be counted in possible cups, so move this check before
the hwid one to prepare the code to count for disabeld cpus when cpu
hot-plug is introduced.

Signed-off-by: Hanjun Guo <hanjun.guo <at> linaro.org>
---
 arch/arm64/kernel/smp.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 4b2121b..49d00da 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
 <at>  <at>  -396,13 +396,13  <at>  <at>  acpi_map_gic_cpu_interface(struct acpi_madt_generic_interrupt *processor)
 {
 	u64 hwid = processor->arm_mpidr;
(Continue reading)

Al Stone | 3 Jul 01:48 2015

[PATCH v3 0/3] Correct for ACPI 5.1->6.0 spec changes in MADT GICC entries

In the ACPI 5.1 version of the spec, the struct for the GICC subtable
(struct acpi_madt_generic_interrupt) of the MADT is 76 bytes long; in
ACPI 6.0, the struct is 80 bytes long.  But, there is only one definition
in ACPICA for this struct -- and that is the 6.0 version.  Hence, when
BAD_MADT_ENTRY() compares the struct size to the length in the GICC
subtable, it fails if 5.1 structs are in use, and there are systems in
the wild that have them.

Note that this was found in linux-next and these patches apply against
that tree and the arm64 kernel tree; 4.1-rc8 does not appear to have this
problem since it still has the 5.1 struct definition.

Even though there is precendent in ia64 code for ignoring the changes in
size, this patch set instead tries to verify correctness.  The first patch
in the set adds macros for easily using the ACPI spec version.  The second
patch adds the BAD_MADT_GICC_ENTRY() macro that uses the version macros to
check the GICC subtable only, accounting for the difference in specification
versions that are possible.  The final patch replaces BAD_MADT_ENTRY usage
with the BAD_MADT_GICC_ENTRY macro in arm64 code, which is currently the
only architecture affected.  The BAD_MADT_ENTRY() will continue to work as
is for all other MADT subtables.

I have tested these patches on an APM Mustang with version 1.15 firmware,
where the problem was found, and they fix the problem.

Changes for v3:
  -- Modified the macros for using spec version numbers in order
     to make them clearer (Rafael, Hanjun)
  -- Moved the definition of the BAD_MADT_GICC_ENTRY macro to an
     arm64-specific header file since only this architecture uses
(Continue reading)

Rafael J. Wysocki | 3 Jul 01:31 2015

[GIT PULL] Additional ACPICA material for v4.2-rc1

Hi Linus,

Please pull from

 git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
 acpica-4.2-rc1

to receive additional ACPICA material for v4.2-rc1 with
top-most commit ea7d521569a70418aa9f6309a1d1916709818b62

 Revert 'Revert "ACPICA: Permanently set _REV to the value '2'."'

on top of commit f3b6ced236259a87829b829e8e542ff53bfb9a4f

 ACPICA: Fix for ill-formed GUID strings for NFIT tables.

merged earlier during the current merge window.

This will update the ACPICA code in the kernel to upstream revision
20150619 (a bug-fix release mostly including stable-candidate fixes)
and restore an earlier ACPICA commit that had to be reverted due to
a regression introduced by it (the regression is addressed by
blacklisting the only known system affected by it to date).

The only new feature added by this update is the support for
overriding objects in the ACPI namespace and a new ACPI table
that can be used for that called the Override System Definition
Table (OSDT).  That should allow us to "patch" the ACPI namespace
built from incomplete or incorrect ACPI System Definition tables
(DSDT, SSDT) during system startup without the need to provide
(Continue reading)

xiaofeng.yan | 2 Jul 05:05 2015

[PATCH] ACPI, Repair of outdated variable

variable "value" in struct acpi_pnp_device_id has been changed
to "string".

Signed-off-by: xiaofeng.yan <yanxiaofeng <at> inspur.com>
---
 drivers/acpi/acpica/nsdumpdv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/acpi/acpica/nsdumpdv.c b/drivers/acpi/acpica/nsdumpdv.c
index 7dc367e..1af1af7 100644
--- a/drivers/acpi/acpica/nsdumpdv.c
+++ b/drivers/acpi/acpica/nsdumpdv.c
 <at>  <at>  -89,7 +89,7  <at>  <at>  acpi_ns_dump_one_device(acpi_handle obj_handle,

 		ACPI_DEBUG_PRINT_RAW((ACPI_DB_TABLES,
 				      "    HID: %s, ADR: %8.8X%8.8X, Status: %X\n",
-				      info->hardware_id.value,
+				      info->hardware_id.string,
 				      ACPI_FORMAT_UINT64(info->address),
 				      info->current_status));
 		ACPI_FREE(info);
--

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(Continue reading)

Hanjun Guo | 1 Jul 15:37 2015

[PATCH] ARM64 / SMP: Switch pr_err() to pr_debug() for disabled GICC entry

It is normal that firmware presents GICC entry or entries (processors)
with disabled flag in ACPI MADT, taking a system of 16 cpus for example,
ACPI firmware may present 8 enabled first with another 8 cpus disabled
in MADT, the disabled cpus can be hot-added later.

Firmware may also present more cpus than the hardware actually has, but
disabled the unused ones, and easily enable it when the hardware has such
cpus to make the firmware code scalable.

So that's not an error for disabled cpus in MADT, we can switch
pr_err() to pr_debug() instead.

Signed-off-by: Hanjun Guo <hanjun.guo <at> linaro.org>
---
 arch/arm64/kernel/smp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 4b2121b..5caf04a 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
 <at>  <at>  -402,7 +402,7  <at>  <at>  acpi_map_gic_cpu_interface(struct acpi_madt_generic_interrupt *processor)
 	}

 	if (!(processor->flags & ACPI_MADT_ENABLED)) {
-		pr_err("skipping disabled CPU entry with 0x%llx MPIDR\n", hwid);
+		pr_debug("skipping disabled CPU entry with 0x%llx MPIDR\n", hwid);
 		return;
 	}

(Continue reading)

Sasnett_Karen | 1 Jul 13:53 2015

(unknown)


Haben Sie einen Investor brauchen?

Haben Sie geschäftliche oder persönliche Darlehen benötigen?

Wir geben Darlehen an eine natürliche Person und Unternehmen bei 3% Zinsen jährlich. Weitere
Informationen Kontaktieren Sie uns per E-Mail: omfcreditspa <at> hotmail.com<mailto:omfcreditspa <at> hotmail.com>

HINWEIS: Leiten Sie Ihre Antwort nur an diese E-Mail: omfcreditspa <at> hotmail.com<mailto:omfcreditspa <at> hotmail.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Sudarshan N Ramachandra | 1 Jul 11:11 2015
Picon

[PATCH] Fix crash during platform suspend when CPUs are related to each other

When CPUs are related to each other, The policy structure is shared among all
related CPUs. Similarly we need to take care of sharing/initializing/freeing
of data in acpi-cpufreq.c This patch addresses the same.

When acpi-cpufreq.c initializes CPUs specifying that they are related to each
other (CPUFREQ_SHARED_TYPE_ALL), we will encounter a crash during suspend exit
when acpi_processor_register_performance() is called. This is because
acpi_processor_unregister_performance() would not have been called for that
CPU during suspend entry

When CPU 0, CPU1 are related and CPU2, CPU3 are related, During suspend
exit, CPU2 fails to initialize since acpi_processor_register_performance()
returns error.  Finally when CPU3 is added, below crash is seen:

[ 92.712008] BUG: unable to handle kernel paging request at 0000000677ac20e8
[ 92.712035] IP:
[ 92.712036] [<ffffffff8177da22>] cpufreq_frequency_table_update_policy_cpu+0x42/0x90
[ 92.712049] PGD 58fed067 PUD 0
[ 92.712067] Oops: 0000 1 PREEMPT SMP
[ 92.712149] CPU: 0 PID: 2945 Comm: system_server Tainted: G WC O
3.14.37-x86_64-L1-R443-g9a60c52-dirty #18
[ 92.712166] task: ffff8800594003d0 ti: ffff880059402000 task.ti: ffff880059402000
[ 92.712184] RIP: 0010:[<ffffffff8177da22>]
[ 92.712184] [<ffffffff8177da22>] cpufreq_frequency_table_update_policy_cpu+0x42/0x90
[ 92.712191] RSP: 0018:ffff880059403b28 EFLAGS: 00010282
[ 92.712196] RAX: 00000000dead4ead RBX: ffff8800729e9c00 RCX: 000000000000c3c2
[ 92.712202] RDX: 0000000000000001 RSI: 0000000000000096 RDI: ffffffff81fc77e3
[ 92.712207] RBP: ffff880059403b38 R08: 00000000000142d8 R09: 0000000000000000
[ 92.712211] R10: 0000000000000000 R11: 0000000000040000 R12: 000000000000eae0
[ 92.712217] R13: ffff8800729e9d18 R14: ffffffff82385818 R15: 0000000000000003
(Continue reading)

Tomeu Vizoso | 1 Jul 08:47 2015

[PATCH v1 0/10] Fixes and API additions for firmware nodes

Hi,

this series makes it possible to extract device dependencies from firmware data
with fwnode, thus not depending on the particular format of that data.

The first patches are about making sure that we can reach the fwnode
handle of the firmware data associated with a given device, and the rest
add API that makes dependency extraction possible.

Thanks,

Tomeu

Tomeu Vizoso (10):
  of/platform: Set fwnode field for new devices
  i2c: core: Have clients point to their firmware nodes
  mfd: Have child devices point to their firmware nodes
  device property: add fwnode_get_parent()
  device property: add fwnode_get_name()
  ACPI / scan: Add acpi_dev_get_next_child()
  device property: Add fwnode_get_next_child_node()
  device property: add fwnode_is_compatible()
  device: property: add fwnode_driver_match_device()
  core: platform: use fwnode_driver_match_device()

 drivers/acpi/scan.c      |  5 +--
 drivers/base/platform.c  |  8 +---
 drivers/base/property.c  | 95 ++++++++++++++++++++++++++++++++++++++++++++----
 drivers/i2c/i2c-core.c   |  1 +
 drivers/mfd/mfd-core.c   |  1 +
(Continue reading)

Tang Chen | 1 Jul 06:45 2015

[PATCH 0/5] Make cpuid <-> nodeid mapping persistent.

[Problem]

cpuid <-> nodeid mapping is firstly established at boot time. And workqueue caches
the mapping in wq_numa_possible_cpumask in wq_numa_init() at boot time.

When doing node online/offline, cpuid <-> nodeid mapping is established/destroyed,
which means, cpuid <-> nodeid mapping will change if node hotplug happens. But
workqueue does not update wq_numa_possible_cpumask.

So here is the problem:

Assume we have the following cpuid <-> nodeid in the beginning:

  Node | CPU
------------------------
node 0 |  0-14, 60-74
node 1 | 15-29, 75-89
node 2 | 30-44, 90-104
node 3 | 45-59, 105-119

and we hot-remove node2 and node3, it becomes:

  Node | CPU
------------------------
node 0 |  0-14, 60-74
node 1 | 15-29, 75-89

and we hot-add node4 and node5, it becomes:

  Node | CPU
(Continue reading)

Dan Carpenter | 30 Jun 19:42 2015
Picon

re: libnvdimm, nfit, nd_blk: driver for BLK-mode access persistent memory

Hello Ross Zwisler,

This is a semi-automatic email about new static checker warnings.

The patch 047fc8a1f9a6: "libnvdimm, nfit, nd_blk: driver for BLK-mode 
access persistent memory" from Jun 25, 2015, leads to the following 
Smatch complaint:

drivers/acpi/nfit.c:1224 acpi_nfit_blk_region_enable()
	 error: we previously assumed 'nfit_mem' could be null (see line 1223)

drivers/acpi/nfit.c
  1222		nfit_mem = nvdimm_provider_data(nvdimm);
  1223		if (!nfit_mem || !nfit_mem->dcr || !nfit_mem->bdw) {
                     ^^^^^^^^
Check.

  1224			dev_dbg(dev, "%s: missing%s%s%s\n", __func__,
  1225					nfit_mem ? "" : " nfit_mem",
  1226					nfit_mem->dcr ? "" : " dcr",
                                        ^^^^^^^^^^^^^
Unchecked dereference.

regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(Continue reading)

Rafael J. Wysocki | 30 Jun 18:09 2015

[GIT PULL] Power management and ACPI fixes for v4.2-rc1

Hi Linus,

Please pull from

 git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
 pm+acpi-4.2-rc1-2

to receive power management and ACPI fixes for v4.2-rc1 with
top-most commit 132c242d95063f0c362597e74ee6759403a3f700

 Merge branches 'acpi-video', 'device-properties', 'pm-sleep' and 'pm-cpuidle'

on top of commit 43c9fad942b5afb9e03801c0721d83160fa5b0dd

 Merge tag 'pm+acpi-4.2-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm

These are fixes that didn't make it to the previous PM+ACPI pull
request or are fixing issues introduced by it.

Specifics:

 - Fix a recently added memory leak in an error path in the ACPI
   resources management code (Dan Carpenter).

 - Fix a build warning triggered by an ACPI video header function
   that should be static inline (Borislav Petkov).

 - Change names of helper function converting struct fwnode_handle
   pointers to either struct device_node or struct acpi_device
(Continue reading)


Gmane