[PATCH v9 14/21] ACPI / processor: Make it possible to get CPU hardware ID via GICC

[Hanjun Guo]

Introduce a new function map_gicc_mpidr() to allow MPIDRs to be obtained
from the GICC Structure introduced by ACPI 5.1.

The ARM architecture defines the MPIDR register as the CPU hardware
identifier. This patch adds the code infrastructure to retrieve the MPIDR
values from the ARM ACPI GICC structure in order to look-up the kernel CPU
hardware ids required by the ACPI core code to identify CPUs.

CC: Rafael J. Wysocki 
CC: Catalin Marinas 
CC: Will Deacon 
Tested-by: Suravee Suthikulpanit 
Tested-by: Yijing Wang 
Tested-by: Mark Langsdorf 
Tested-by: Jon Masters 
Tested-by: Timur Tabi 
Tested-by: Robert Richter 
Acked-by: Robert Richter 
Signed-off-by: Hanjun Guo 
---
 arch/arm64/include/asm/acpi.h | 12 
 drivers/acpi/processor_core.c | 30 ++
 2 files changed, 42 insertions(+)

diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index 9719921..9a23369 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -13,6 +13,8 @@
 #define _ASM_ACPI_H
 
 #include 
+#include 
+#include 
 
 /* Basic configuration for ACPI */
 #ifdef CONFIG_ACPI
@@ -27,6 +29,9 @@ static inline void __iomem 
*acpi_os_ioremap(acpi_physical_address phys,
 }
 #define acpi_os_ioremap acpi_os_ioremap
 
+typedef u64 phys_cpuid_t;
+#define CPU_PHYS_ID_INVALID INVALID_HWID
+
 #define acpi_strict 1  /* No out-of-spec workarounds on ARM64 */
 extern int acpi_disabled;
 extern int acpi_noirq;
@@ -59,6 +64,13 @@ static inline void enable_acpi(void)
 }
 
 /*
+ * The ACPI processor driver for ACPI core code needs this macro
+ * to find out this cpu was already mapped (mapping from CPU hardware
+ * ID to CPU logical ID) or not.
+ */
+#define cpu_physical_id(cpu) cpu_logical_map(cpu)
+
+/*
  * It's used from ACPI core in kdump to boot UP system with SMP kernel,
  * with this check the ACPI core will not override the CPU index
  * obtained from GICC with 0 and not print some error message as well.
diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
index a5547dc..8654adb 100644
--- a/drivers/acpi/processor_core.c
+++ b/drivers/acpi/processor_core.c
@@ -83,6 +83,31 @@ static int map_lsapic_id(struct acpi_subtable_header *entry,
return 0;
 }
 
+/*
+ * Retrieve the ARM CPU physical identifier (MPIDR)
+ */
+static int map_gicc_mpidr(struct acpi_subtable_header *entry,
+   int device_declaration, u32 acpi_id, phys_cpuid_t *mpidr)
+{
+   struct acpi_madt_generic_interrupt *gicc =
+   container_of(entry, struct acpi_madt_generic_interrupt, header);
+
+   if (!(gicc->flags & ACPI_MADT_ENABLED))
+   return -ENODEV;
+
+   /* device_declaration means Device object in DSDT, In the
+* GIC interrupt model, logical processors are required to
+* have a Processor Device object in the DSDT, so we should
+* check device_declaration here
+*/
+   if (device_declaration && (gicc->uid == acpi_id)) {
+   *mpidr = gicc->arm_mpidr;
+   return 0;
+   }
+
+   return -EINVAL;
+}
+
 static phys_cpuid_t map_madt_entry(int type, u32 acpi_id)
 {
unsigned long madt_end, entry;
@@ -111,6 +136,9 @@ static phys_cpuid_t map_madt_entry(int type, u32 acpi_id)
} else if (header->type == ACPI_MADT_TYPE_LOCAL_SAPIC) {
if (!map_lsapic_id(header, type, acpi_id, _id))
break;
+   } else if (header->type == ACPI_MADT_TYPE_GENERIC_INTERRUPT) {
+   if (!map_gicc_mpidr(header, type, acpi_id, _id))
+   break;
}
entry += header->length;
}
@@ -143,6 +171,8 @@ static phys_cpuid_t map_mat_entry(acpi_handle handle, int 
type, u32 acpi_id)
map_lsapic_id(header, type, acpi_id, _id);
else if (header->type == ACPI_MADT_TYPE_LOCAL_X2APIC)
map_x2apic_id(header, type, acpi_id, _id);
+   else if (header->type == ACPI_MADT_TYPE_GENERIC_INTERRUPT)
+   map_gicc_mpidr(header, type, acpi_id, _id);
 
 exit:
kfree(buffer.pointer);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v9 20/21] Documentation: ACPI for ARM64

[Hanjun Guo]

From: Graeme Gregory 

Add documentation for the guidelines of how to use ACPI
on ARM64.

Reviewed-by: Suravee Suthikulpanit 
Reviewed-by: Yi Li 
Reviewed-by: Mark Langsdorf 
Reviewed-by: Ashwin Chaugule 
Acked-by: Robert Richter 
Signed-off-by: Graeme Gregory 
Signed-off-by: Al Stone 
Signed-off-by: Hanjun Guo 
---
 Documentation/arm64/arm-acpi.txt | 506 +++
 1 file changed, 506 insertions(+)
 create mode 100644 Documentation/arm64/arm-acpi.txt

diff --git a/Documentation/arm64/arm-acpi.txt b/Documentation/arm64/arm-acpi.txt
new file mode 100644
index 000..24cf832
--- /dev/null
+++ b/Documentation/arm64/arm-acpi.txt
@@ -0,0 +1,506 @@
+ACPI on ARMv8 Servers
+-
+ACPI can be used for ARMv8 general purpose servers designed to follow
+the ARM SBSA (Server Base System Architecture) [0] and SBBR (Server
+Base Boot Requirements) [1] specifications.  Please note that the SBBR
+can be retrieved simply by visiting [1], but the SBSA is currently only
+available to those with an ARM login due to ARM IP licensing concerns.
+
+The ARMv8 kernel implements the reduced hardware model of ACPI version
+5.1 or later.  Links to the specification and all external documents
+it refers to are managed by the UEFI Forum.  The specification is
+available at http://www.uefi.org/specifications and documents referenced
+by the specification can be found via http://www.uefi.org/acpi.
+
+If an ARMv8 system does not meet the requirements of the SBSA and SBBR,
+or cannot be described using the mechanisms defined in the required ACPI
+specifications, then ACPI may not be a good fit for the hardware.
+
+While the documents mentioned above set out the requirements for building
+industry-standard ARMv8 servers, they also apply to more than one operating
+system.  The purpose of this document is to describe the interaction between
+ACPI and Linux only, on an ARMv8 system -- that is, what Linux expects of
+ACPI and what ACPI can expect of Linux.
+
+
+Why ACPI on ARM?
+
+Before examining the details of the interface between ACPI and Linux, it is
+useful to understand why ACPI is being used.  Several technologies already
+exist in Linux for describing non-enumerable hardware, after all.  In this
+section we summarize a blog post [2] from Grant Likely that outlines the
+reasoning behind ACPI on ARMv8 servers.  Actually, we snitch a good portion
+of the summary text almost directly, to be honest.
+
+The short form of the rationale for ACPI on ARM is:
+
+-- ACPI’s bytecode (AML) allows the platform to encode hardware behavior,
+   while DT explicitly does not support this.  For hardware vendors, being
+   able to encode behavior is a key tool used in supporting operating
+   system releases on new hardware.
+
+-- ACPI’s OSPM defines a power management model that constrains what the
+   platform is allowed to do into a specific model, while still providing
+   flexibility in hardware design.
+
+-- In the enterprise server environment, ACPI has established bindings (such
+   as for RAS) which are currently used in production systems.  DT does not.
+   Such bindings could be defined in DT at some point, but doing so means ARM
+   and x86 would end up using completely different code paths in both firmware
+   and the kernel.
+
+-- Choosing a single interface to describe the abstraction between a platform
+   and an OS is important.  Hardware vendors would not be required to implement
+   both DT and ACPI if they want to support multiple operating systems.  And,
+   agreeing on a single interface instead of being fragmented into per OS
+   interfaces makes for better interoperability overall.
+
+-- The new ACPI governance process works well and Linux is now at the same
+   table as hardware vendors and other OS vendors.  In fact, there is no
+   longer any reason to feel that ACPI is only belongs to Windows or that
+   Linux is in any way secondary to Microsoft in this arena.  The move of
+   ACPI governance into the UEFI forum has significantly opened up the
+   specification development process, and currently, a large portion of the
+   changes being made to ACPI is being driven by Linux.
+
+Key to the use of ACPI is the support model.  For servers in general, the
+responsibility for hardware behaviour cannot solely be the domain of the
+kernel, but rather must be split between the platform and the kernel, in
+order to allow for orderly change over time.  ACPI frees the OS from needing
+to understand all the minute details of the hardware so that the OS doesn’t
+need to be ported to each and every device individually.  It allows the
+hardware vendors to take responsibility for power management behaviour without
+depending on an OS release cycle which is not under their control.
+
+ACPI is also important because hardware and OS vendors have already worked
+out the mechanisms for supporting a general purpose computing ecosystem.  The
+infrastructure is in place, the bindings are 

[PATCH v9 18/21] ARM64 / ACPI: Select ACPI_REDUCED_HARDWARE_ONLY if ACPI is enabled on ARM64

[Hanjun Guo]

From: Al Stone 

ACPI reduced hardware mode is disabled by default, but ARM64
can only run properly in ACPI hardware reduced mode, so select
ACPI_REDUCED_HARDWARE_ONLY if ACPI is enabled on ARM64.

CC: Catalin Marinas 
CC: Will Deacon 
Reviewed-by: Grant Likely 
Tested-by: Suravee Suthikulpanit 
Tested-by: Yijing Wang 
Tested-by: Mark Langsdorf 
Tested-by: Jon Masters 
Tested-by: Timur Tabi 
Tested-by: Robert Richter 
Acked-by: Robert Richter 
Signed-off-by: Al Stone 
Signed-off-by: Hanjun Guo 
---
 arch/arm64/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 1b8e973..d00ab9a 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1,5 +1,6 @@
 config ARM64
def_bool y
+   select ACPI_REDUCED_HARDWARE_ONLY if ACPI
select ARCH_BINFMT_ELF_RANDOMIZE_PIE
select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select ARCH_HAS_GCOV_PROFILE_ALL
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v9 17/21] clocksource / arch_timer: Parse GTDT to initialize arch timer

[Hanjun Guo]

Using the information presented by GTDT (Generic Timer Description Table)
to initialize the arch timer (not memory-mapped).

CC: Daniel Lezcano 
CC: Thomas Gleixner 
Originally-by: Amit Daniel Kachhap 
Tested-by: Suravee Suthikulpanit 
Tested-by: Yijing Wang 
Tested-by: Mark Langsdorf 
Tested-by: Jon Masters 
Tested-by: Timur Tabi 
Tested-by: Robert Richter 
Acked-by: Robert Richter 
Signed-off-by: Hanjun Guo 
---
 arch/arm64/kernel/time.c |   7 ++
 drivers/clocksource/arm_arch_timer.c | 132 ---
 include/linux/clocksource.h  |   6 ++
 3 files changed, 118 insertions(+), 27 deletions(-)

diff --git a/arch/arm64/kernel/time.c b/arch/arm64/kernel/time.c
index 1a7125c..42f9195 100644
--- a/arch/arm64/kernel/time.c
+++ b/arch/arm64/kernel/time.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -72,6 +73,12 @@ void __init time_init(void)
 
tick_setup_hrtimer_broadcast();
 
+   /*
+* Since ACPI or FDT will only one be available in the system,
+* we can use acpi_generic_timer_init() here safely
+*/
+   acpi_generic_timer_init();
+
arch_timer_rate = arch_timer_get_rate();
if (!arch_timer_rate)
panic("Unable to initialise architected timer.\n");
diff --git a/drivers/clocksource/arm_arch_timer.c 
b/drivers/clocksource/arm_arch_timer.c
index a3025e7..ea62fc7 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -371,8 +372,12 @@ arch_timer_detect_rate(void __iomem *cntbase, struct 
device_node *np)
if (arch_timer_rate)
return;
 
-   /* Try to determine the frequency from the device tree or CNTFRQ */
-   if (of_property_read_u32(np, "clock-frequency", _timer_rate)) {
+   /*
+* Try to determine the frequency from the device tree or CNTFRQ,
+* if ACPI is enabled, get the frequency from CNTFRQ ONLY.
+*/
+   if (!acpi_disabled ||
+   of_property_read_u32(np, "clock-frequency", _timer_rate)) {
if (cntbase)
arch_timer_rate = readl_relaxed(cntbase + CNTFRQ);
else
@@ -691,28 +696,8 @@ static void __init arch_timer_common_init(void)
arch_timer_arch_init();
 }
 
-static void __init arch_timer_init(struct device_node *np)
+static void __init arch_timer_init(void)
 {
-   int i;
-
-   if (arch_timers_present & ARCH_CP15_TIMER) {
-   pr_warn("arch_timer: multiple nodes in dt, skipping\n");
-   return;
-   }
-
-   arch_timers_present |= ARCH_CP15_TIMER;
-   for (i = PHYS_SECURE_PPI; i < MAX_TIMER_PPI; i++)
-   arch_timer_ppi[i] = irq_of_parse_and_map(np, i);
-   arch_timer_detect_rate(NULL, np);
-
-   /*
-* If we cannot rely on firmware initializing the timer registers then
-* we should use the physical timers instead.
-*/
-   if (IS_ENABLED(CONFIG_ARM) &&
-   of_property_read_bool(np, "arm,cpu-registers-not-fw-configured"))
-   arch_timer_use_virtual = false;
-
/*
 * If HYP mode is available, we know that the physical timer
 * has been configured to be accessible from PL1. Use it, so
@@ -731,13 +716,39 @@ static void __init arch_timer_init(struct device_node *np)
}
}
 
-   arch_timer_c3stop = !of_property_read_bool(np, "always-on");
-
arch_timer_register();
arch_timer_common_init();
 }
-CLOCKSOURCE_OF_DECLARE(armv7_arch_timer, "arm,armv7-timer", arch_timer_init);
-CLOCKSOURCE_OF_DECLARE(armv8_arch_timer, "arm,armv8-timer", arch_timer_init);
+
+static void __init arch_timer_of_init(struct device_node *np)
+{
+   int i;
+
+   if (arch_timers_present & ARCH_CP15_TIMER) {
+   pr_warn("arch_timer: multiple nodes in dt, skipping\n");
+   return;
+   }
+
+   arch_timers_present |= ARCH_CP15_TIMER;
+   for (i = PHYS_SECURE_PPI; i < MAX_TIMER_PPI; i++)
+   arch_timer_ppi[i] = irq_of_parse_and_map(np, i);
+
+   arch_timer_detect_rate(NULL, np);
+
+   arch_timer_c3stop = !of_property_read_bool(np, "always-on");
+
+   /*
+* If we cannot rely on firmware initializing the timer registers then
+* we should use the physical timers instead.
+*/
+   if (IS_ENABLED(CONFIG_ARM) &&
+   of_property_read_bool(np, "arm,cpu-registers-not-fw-configured"))
+   arch_timer_use_virtual = false;
+
+   arch_timer_init();
+}
+CLOCKSOURCE_OF_DECLARE(armv7_arch_timer, "arm,armv7-timer", 
arch_timer_of_init);
+CLOCKSOURCE_OF_DECLARE(armv8_arch_timer, "arm,armv8-timer", 
arch_timer_of_init);
 
 static void __init arch_timer_mem_init(struct device_node *np)
 {
@@ -804,3 +815,70 @@ static void __init arch_timer_mem_init(struct device_node 
*np)
 }
 

[PATCH v9 19/21] ARM64 / ACPI: Enable ARM64 in Kconfig

[Hanjun Guo]

From: Graeme Gregory 

Add Kconfigs to build ACPI on ARM64, and make ACPI available on ARM64.

acpi_idle driver is x86/IA64 dependent now, so make CONFIG_ACPI_PROCESSOR
depend on X86 || IA64, and implement it on ARM64 in the future.

CC: Rafael J. Wysocki 
CC: Catalin Marinas 
CC: Will Deacon 
Reviewed-by: Grant Likely 
Tested-by: Suravee Suthikulpanit 
Tested-by: Yijing Wang 
Tested-by: Mark Langsdorf 
Tested-by: Jon Masters 
Tested-by: Timur Tabi 
Tested-by: Robert Richter 
Acked-by: Robert Richter 
Signed-off-by: Graeme Gregory 
Signed-off-by: Al Stone 
Signed-off-by: Hanjun Guo 
---
 arch/arm64/Kconfig   | 2 ++
 drivers/acpi/Kconfig | 3 ++-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index d00ab9a..e5aa081 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -713,6 +713,8 @@ source "drivers/Kconfig"
 
 source "drivers/firmware/Kconfig"
 
+source "drivers/acpi/Kconfig"
+
 source "fs/Kconfig"
 
 source "arch/arm64/kvm/Kconfig"
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index e6c3ddd..7aa3288 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -5,7 +5,7 @@
 menuconfig ACPI
bool "ACPI (Advanced Configuration and Power Interface) Support"
depends on !IA64_HP_SIM
-   depends on IA64 || X86
+   depends on IA64 || X86 || (ARM64 && EXPERT)
depends on PCI
select PNP
default y
@@ -163,6 +163,7 @@ config ACPI_PROCESSOR
tristate "Processor"
select THERMAL
select CPU_IDLE
+   depends on X86 || IA64
default y
help
  This driver installs ACPI as the idle handler for Linux and uses
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v9 21/21] ARM64 / ACPI: additions of ACPI documentation for arm64

[Hanjun Guo]

From: Al Stone 

Two more documentation files are also being added:
(1) A verbatim copy of the "Why ACPI on ARM?" blog posting by Grant Likely,
which is also summarized in arm-acpi.txt, and

(2) A section by section review of the ACPI spec (acpi_object_usage.txt)
to note recommendations and prohibitions on the use of the numerous
ACPI tables and objects.  This sets out the current expectations of
the firmware by Linux very explicitly (or as explicitly as I can, for
now).

CC: Suravee Suthikulpanit 
CC: Yi Li 
CC: Mark Langsdorf 
CC: Ashwin Chaugule 
Acked-by: Robert Richter 
Signed-off-by: Al Stone 
Signed-off-by: Hanjun Guo 
---
 Documentation/arm64/acpi_object_usage.txt | 594 ++
 Documentation/arm64/why_use_acpi.txt  | 231 
 2 files changed, 825 insertions(+)
 create mode 100644 Documentation/arm64/acpi_object_usage.txt
 create mode 100644 Documentation/arm64/why_use_acpi.txt

diff --git a/Documentation/arm64/acpi_object_usage.txt 
b/Documentation/arm64/acpi_object_usage.txt
new file mode 100644
index 000..b49b288
--- /dev/null
+++ b/Documentation/arm64/acpi_object_usage.txt
@@ -0,0 +1,594 @@
+ACPI Tables
+---
+The expectations of individual ACPI tables are discussed in the list that
+follows.
+
+If a section number is used, it refers to a section number in the ACPI
+specification where the object is defined.  If "Signature Reserved" is used,
+the table signature (the first four bytes of the table) is the only portion
+of the table recognized by the specification, and the actual table is defined
+outside of the UEFI Forum (see Section 5.2.6 of the specification).
+
+For ACPI on arm64, tables also fall into the following categories:
+
+   -- Required: DSDT, FADT, GTDT, MADT, MCFG, RSDP, SPCR, XSDT
+
+   -- Recommended: BERT, EINJ, ERST, HEST, SSDT
+
+   -- Optional: BGRT, CPEP, CSRT, DRTM, ECDT, FACS, FPDT, MCHI, MPST,
+  MSCT, RASF, SBST, SLIT, SPMI, SRAT, TCPA, TPM2, UEFI
+
+   -- Not supported: BOOT, DBG2, DBGP, DMAR, ETDT, HPET, IBFT, IVRS,
+  LPIT, MSDM, RSDT, SLIC, WAET, WDAT, WDRT, WPBT
+
+
+Table  Usage for ARMv8 Linux
+-  
+BERT   Section 18.3 (signature == "BERT")
+   == Boot Error Record Table ==
+   Must be supplied if RAS support is provided by the platform.  It
+   is recommended this table be supplied.
+
+BOOT   Signature Reserved (signature == "BOOT")
+   == simple BOOT flag table ==
+   Microsoft only table, will not be supported.
+
+BGRT   Section 5.2.22 (signature == "BGRT")
+   == Boot Graphics Resource Table ==
+   Optional, not currently supported, with no real use-case for an
+   ARM server.
+
+CPEP   Section 5.2.18 (signature == "CPEP")
+   == Corrected Platform Error Polling table ==
+   Optional, not currently supported, and not recommended until such
+   time as ARM-compatible hardware is available, and the specification
+   suitably modified.
+
+CSRT   Signature Reserved (signature == "CSRT")
+   == Core System Resources Table ==
+   Optional, not currently supported.
+
+DBG2   Signature Reserved (signature == "DBG2")
+   == DeBuG port table 2 ==
+   Microsoft only table, will not be supported.
+
+DBGP   Signature Reserved (signature == "DBGP")
+   == DeBuG Port table ==
+   Microsoft only table, will not be supported.
+
+DSDT   Section 5.2.11.1 (signature == "DSDT")
+   == Differentiated System Description Table ==
+   A DSDT is required; see also SSDT.
+
+   ACPI tables contain only one DSDT but can contain one or more SSDTs,
+   which are optional.  Each SSDT can only add to the ACPI namespace,
+   but cannot modify or replace anything in the DSDT.
+
+DMAR   Signature Reserved (signature == "DMAR")
+   == DMA Remapping table ==
+   x86 only table, will not be supported.
+
+DRTM   Signature Reserved (signature == "DRTM")
+   == Dynamic Root of Trust for Measurement table ==
+   Optional, not currently supported.
+
+ECDT   Section 5.2.16 (signature == "ECDT")
+   == Embedded Controller Description Table ==
+   Optional, not currently supported, but could be used on ARM if and
+   only if one uses the GPE_BIT field to represent an IRQ number, since
+   there are no GPE blocks defined in hardware reduced mode.  This would
+   need to be modified in the ACPI specification.
+
+EINJ   Section 18.6 (signature == "EINJ")
+   == Error Injection table ==
+   This table is very useful for testing platform response to error
+   conditions; it allows one to inject an error into the system as
+   if it had actually occurred.  However, this table should not be
+   shipped with a production system; it should be dynamically loaded
+   and executed with the ACPICA tools only during testing.
+
+ERST   Section 18.5 (signature == "ERST")
+   == Error Record 

[PATCH v9 07/21] ACPI / sleep: Introduce arm64 specific acpi_sleep.c

[Hanjun Guo]

From: Graeme Gregory 

ACPI 5.1 does not currently support S states for ARM64 hardware but
ACPI code will call acpi_target_system_state() for device power
management, so introduce acpi_sleep.c to allow other drivers to function
until S states are defined.

Since it is arm64 specific stub holder, so let acpi_sleep.c to ARM64
specific.

TODO: merge this with drivers/acpi/sleep.c once we fix the specification.

CC: Rafael J. Wysocki 
Tested-by: Suravee Suthikulpanit 
Tested-by: Yijing Wang 
Tested-by: Mark Langsdorf 
Tested-by: Jon Masters 
Tested-by: Timur Tabi 
Tested-by: Robert Richter 
Acked-by: Robert Richter 
Signed-off-by: Graeme Gregory 
Signed-off-by: Tomasz Nowicki 
Signed-off-by: Hanjun Guo 
---
 arch/arm64/kernel/Makefile |  2 +-
 arch/arm64/kernel/acpi_sleep.c | 28 
 drivers/acpi/Makefile  |  2 ++
 3 files changed, 31 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/kernel/acpi_sleep.c

diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 218eb7e..4435943 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -34,7 +34,7 @@ arm64-obj-$(CONFIG_KGDB)  += kgdb.o
 arm64-obj-$(CONFIG_EFI)+= efi.o efi-stub.o efi-entry.o
 arm64-obj-$(CONFIG_PCI)+= pci.o
 arm64-obj-$(CONFIG_ARMV8_DEPRECATED)   += armv8_deprecated.o
-arm64-obj-$(CONFIG_ACPI)   += acpi.o
+arm64-obj-$(CONFIG_ACPI)   += acpi.o acpi_sleep.o
 
 obj-y  += $(arm64-obj-y) vdso/
 obj-m  += $(arm64-obj-m)
diff --git a/arch/arm64/kernel/acpi_sleep.c b/arch/arm64/kernel/acpi_sleep.c
new file mode 100644
index 000..54578ef
--- /dev/null
+++ b/arch/arm64/kernel/acpi_sleep.c
@@ -0,0 +1,28 @@
+/*
+ *  ARM64 Specific Sleep Functionality
+ *
+ *  Copyright (C) 2013-2014, Linaro Ltd.
+ *  Author: Graeme Gregory 
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ */
+
+#include 
+
+/*
+ * Currently the ACPI 5.1 standard does not define S states in a
+ * manner which is usable for ARM64. These two stubs are sufficient
+ * that system initialises and device PM works.
+ */
+u32 acpi_target_system_state(void)
+{
+   return ACPI_STATE_S0;
+}
+EXPORT_SYMBOL_GPL(acpi_target_system_state);
+
+int __init acpi_sleep_init(void)
+{
+   return -ENOSYS;
+}
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 623b117..c32edf5 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -23,7 +23,9 @@ acpi-y+= nvs.o
 
 # Power management related files
 acpi-y += wakeup.o
+ifneq (,$(findstring $(ARCH),x86 ia64))
 acpi-y += sleep.o
+endif
 acpi-y += device_pm.o
 acpi-$(CONFIG_ACPI_SLEEP)  += proc.o
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] ARM: exynos_defconfig: Enable CPU idle

[Krzysztof Kozlowski]

Current Exynos CPU idle driver supports entering AFTR (Arm Off, Top
Running) mode on Exynos 4210 (coupled), Exynos 4x12 and Exynos 5250.
Enable it in default configuration to reduce energy consumption.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/configs/exynos_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/exynos_defconfig 
b/arch/arm/configs/exynos_defconfig
index 70e5d0bdb4e4..7e0622a36da9 100644
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -26,6 +26,8 @@ CONFIG_ZBOOT_ROM_BSS=0x0
 CONFIG_ARM_APPENDED_DTB=y
 CONFIG_ARM_ATAG_DTB_COMPAT=y
 CONFIG_CMDLINE="root=/dev/ram0 rw ramdisk=8192 initrd=0x4100,8M 
console=ttySAC1,115200 init=/linuxrc mem=256M"
+CONFIG_CPU_IDLE=y
+CONFIG_ARM_EXYNOS_CPUIDLE=y
 CONFIG_VFP=y
 CONFIG_NEON=y
 CONFIG_PM=y
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] ARM: multi_v7_defconfig: Enable CPU idle for Exynos

[Krzysztof Kozlowski]

Current Exynos CPU idle driver supports entering AFTR (Arm Off, Top
Running) mode on Exynos 4210 (coupled), Exynos 4x12 and Exynos 5250.
Enable it in default configuration to reduce energy consumption.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/configs/multi_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index e1f9a79651ca..7708bb82b0d0 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -96,6 +96,7 @@ CONFIG_CPU_FREQ=y
 CONFIG_CPU_FREQ_STAT_DETAILS=y
 CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
 CONFIG_CPU_IDLE=y
+CONFIG_ARM_EXYNOS_CPUIDLE=y
 CONFIG_NEON=y
 CONFIG_ARM_ZYNQ_CPUIDLE=y
 CONFIG_NET=y
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] OMAPDSS: restore "name" sysfs entry.

[Tomi Valkeinen]

Hi,

On 24/02/15 22:31, NeilBrown wrote:
> On Tue, 24 Feb 2015 12:40:32 +0200 Tomi Valkeinen 
> wrote:
> 
>> Hi,
>>
>> On 24/02/15 11:37, NeilBrown wrote:
>>>
>>>
>>> commit 303e4697e762dc92a40405f4e4b8aac02cd0d70b
>>> OMAPDSS: rename display-sysfs 'name' entry
>>>
>>> broke the xorg X server on my device as it couldn't find the display
>>> any more.  It needs the 'name' file and now there isn't one.
>>>
>>> That commit claims that 'name' is not compatible with i2c or spi.
>>> i2c does register it own 'name' file, but spi does not, hence my
>>> problem - I have an spi display.
>>>
>>> So create a special case for i2c: add the name attribute for non-i2c
>>> devices.

How about this patch instead. It separates the underlying device's sysfs 
directory 
from the "displayX" directory, and allows us to have name & display_name. So it
should work for any device type.


From 8e411fa684d42fca35628b41837c6d72e87aaff0 Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen 
Date: Wed, 25 Feb 2015 10:23:58 +0200
Subject: [PATCH] OMAPDSS: fix regression with display sysfs files

omapdss's sysfs directories for displays used to have 'name' file,
giving the name for the display. This file was later renamed to
'display_name' to avoid conflicts with i2c sysfs 'name' file. Looks like
at least xserver-xorg-video-omap3 requires the 'name' file to be
present.

To fix the regression, this patch creates new kobjects for each display,
allowing us to create sysfs directories for the displays. This way we
have the whole directory for omapdss, and there will be no sysfs file
clashes with the underlying display device's sysfs files.

We can thus add the 'name' sysfs file back.

Signed-off-by: Tomi Valkeinen 
---
 drivers/video/fbdev/omap2/dss/display-sysfs.c | 179 ++
 include/video/omapdss.h   |   1 +
 2 files changed, 96 insertions(+), 84 deletions(-)

diff --git a/drivers/video/fbdev/omap2/dss/display-sysfs.c 
b/drivers/video/fbdev/omap2/dss/display-sysfs.c
index 5a2095a98ed8..12186557a9d4 100644
--- a/drivers/video/fbdev/omap2/dss/display-sysfs.c
+++ b/drivers/video/fbdev/omap2/dss/display-sysfs.c
@@ -28,44 +28,22 @@
 #include 
 #include "dss.h"
 
-static struct omap_dss_device *to_dss_device_sysfs(struct device *dev)
+static ssize_t display_name_show(struct omap_dss_device *dssdev, char *buf)
 {
-   struct omap_dss_device *dssdev = NULL;
-
-   for_each_dss_dev(dssdev) {
-   if (dssdev->dev == dev) {
-   omap_dss_put_device(dssdev);
-   return dssdev;
-   }
-   }
-
-   return NULL;
-}
-
-static ssize_t display_name_show(struct device *dev,
-   struct device_attribute *attr, char *buf)
-{
-   struct omap_dss_device *dssdev = to_dss_device_sysfs(dev);
-
return snprintf(buf, PAGE_SIZE, "%s\n",
dssdev->name ?
dssdev->name : "");
 }
 
-static ssize_t display_enabled_show(struct device *dev,
-   struct device_attribute *attr, char *buf)
+static ssize_t display_enabled_show(struct omap_dss_device *dssdev, char *buf)
 {
-   struct omap_dss_device *dssdev = to_dss_device_sysfs(dev);
-
return snprintf(buf, PAGE_SIZE, "%d\n",
omapdss_device_is_enabled(dssdev));
 }
 
-static ssize_t display_enabled_store(struct device *dev,
-   struct device_attribute *attr,
+static ssize_t display_enabled_store(struct omap_dss_device *dssdev,
const char *buf, size_t size)
 {
-   struct omap_dss_device *dssdev = to_dss_device_sysfs(dev);
int r;
bool enable;
 
@@ -90,19 +68,16 @@ static ssize_t display_enabled_store(struct device *dev,
return size;
 }
 
-static ssize_t display_tear_show(struct device *dev,
-   struct device_attribute *attr, char *buf)
+static ssize_t display_tear_show(struct omap_dss_device *dssdev, char *buf)
 {
-   struct omap_dss_device *dssdev = to_dss_device_sysfs(dev);
return snprintf(buf, PAGE_SIZE, "%d\n",
dssdev->driver->get_te ?
dssdev->driver->get_te(dssdev) : 0);
 }
 
-static ssize_t display_tear_store(struct device *dev,
-   struct device_attribute *attr, const char *buf, size_t size)
+static ssize_t display_tear_store(struct omap_dss_device *dssdev,
+   const char *buf, size_t size)
 {
-   struct omap_dss_device *dssdev = to_dss_device_sysfs(dev);
int r;
bool te;
 
@@ -120,10 +95,8 @@ static ssize_t display_tear_store(struct device *dev,
return size;
 }
 
-static ssize_t display_timings_show(struct device *dev,
-   struct device_attribute *attr, char *buf)
+static ssize_t display_timings_show(struct omap_dss_device *dssdev, char *buf)
 {
-   struct omap_dss_device *dssdev = to_dss_device_sysfs(dev);
struct omap_video_timings t;
 
if (!dssdev->driver->get_timings)
@@ -137,10 +110,9 @@ static 

[PATCH] mma8450: add parent device

[Stefan Sauer]

Add the parent device so that udev can show the full hierarchy. This avoids the
device showing up under /devices/virtual/input instead of the i2c bus it is
actually attached to.

Signed-off-by: Stefan Sauer 
---
 drivers/input/misc/mma8450.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/input/misc/mma8450.c b/drivers/input/misc/mma8450.c
index 59d4dcd..9822877 100644
--- a/drivers/input/misc/mma8450.c
+++ b/drivers/input/misc/mma8450.c
@@ -187,6 +187,7 @@ static int mma8450_probe(struct i2c_client *c,
idev->private   = m;
idev->input->name   = MMA8450_DRV_NAME;
idev->input->id.bustype = BUS_I2C;
+   idev->input->dev.parent = >dev;
idev->poll  = mma8450_poll;
idev->poll_interval = POLL_INTERVAL;
idev->poll_interval_max = POLL_INTERVAL_MAX;
-- 
2.2.0.rc0.207.ga3a616c

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/4] x86: get rid of KERNEL_STACK_OFFSET

[Ingo Molnar]

* Denys Vlasenko  wrote:

> PER_CPU_VAR(kernel_stack) was set up in a way where it 
> points five stack slots below the top of stack.
> 
> Presumably, it was done to avoid one "sub $5*8,%rsp" in 
> syscall/sysenter code paths, where iret frame needs to be 
> created by hand.
> 
> Ironically, none of them benefit from this optimization, 
> since all of them need to allocate additional data on 
> stack (struct pt_regs), so they still have to perform 
> subtraction.

Well, the original idea of percpu::kernel_stack was that of 
an optimization of the 64-bit system_call() path: to set up 
RSP as it has to be before we call into system calls.

This optimization has bitrotted away: because these days 
the first SAVE_ARGS in the 64-bit entry path modifies RSP 
as well, undoing the optimization.

But the fix should be to not touch RSP in SAVE_ARGS, to 
keep percpu::kernel_stack as an optimized entry point - 
with KERNEL_STACK_OFFSET pointing to.

So NAK - this should be fixed for real.

> And ia32_sysenter_target even needs to *undo* this 
> optimization: it constructs iret stack with pushes 
> instead of movs, so it needs to start right at the top.

Lets keep it in mind that in any case the micro-costs of 
the 32-bit entry path are almost always irrelevant: we 
optimize the 64-bit entry path, if that helps the 32-bit 
side as well then that's a happy coincidence, nothing more. 

If the 32-bit entry path can be optimized without affecting 
the 64-bit path then that's good, but we don't ever hurt 
the 64-bit path to make things easier or simpler for the 
32-bit path.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] ACPI / EC: Remove non-standard log emphasis

[Zheng, Lv]

Hi,

> From: Zheng, Lv
> Sent: Wednesday, February 25, 2015 4:42 PM
> 
> Hi,
> 
> > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> > Sent: Wednesday, February 18, 2015 2:19 PM
> > To: Scot Doyle
> > Cc: Zheng, Lv; linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH] ACPI / EC: Remove non-standard log emphasis
> >
> > On Sunday, February 15, 2015 07:43:08 PM Scot Doyle wrote:
> > > Remove unusual pr_info() visual emphasis introduced in ad479e7f47ca
> > > "ACPI / EC: Introduce STARTED/STOPPED flags to replace BLOCKED flag".
> > >
> > > Signed-off-by: Scot Doyle 
> >
> > Applied, thanks!
> >
> > > ---
> > >  drivers/acpi/ec.c | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
> > > index 982b67f..857175e 100644
> > > --- a/drivers/acpi/ec.c
> > > +++ b/drivers/acpi/ec.c
> > > @@ -680,7 +680,7 @@ static void acpi_ec_start(struct acpi_ec *ec, bool 
> > > resuming)
> > >   /* Enable GPE for event processing (SCI_EVT=1) */
> > >   if (!resuming)
> > >   acpi_ec_submit_request(ec);
> > > - pr_info("+ EC started +\n");
> > > + pr_info("EC started\n");
> > >   }
> > >   spin_unlock_irqrestore(>lock, flags);
> > >  }
> > > @@ -712,7 +712,7 @@ static void acpi_ec_stop(struct acpi_ec *ec, bool 
> > > suspending)
> > >   acpi_ec_complete_request(ec);
> > >   clear_bit(EC_FLAGS_STARTED, >flags);
> > >   clear_bit(EC_FLAGS_STOPPED, >flags);
> > > - pr_info("+ EC stopped +\n");
> > > + pr_info("EC stopped\n");
> > >   }
> > >   spin_unlock_irqrestore(>lock, flags);
> > >  }
> > >
> 
> I was using "+"/"#"/"*" to filter different EC log entries which 
> makes debugging easier.
> And, if we changed this from pr_info into pr_debug, then we will have nothing 
> in the suspend/resume logs for the EC device.
> While there are plenty of such log entries for each of other devices.
> So I really doubt what's the meaning of such a change.
> Could it improve anything or just make debugging more difficult for 
> developers?

IMO, it's better to introduce such kind of code in the head of ec.c:

#ifdef DEBUG_FILTER
#define EC_LOG_DEV "+"
#define EC_LOG_CMD "*"
#define EC_LOG_EVT "#"
...
#else
#define EC_LOG_DEV
#define EC_LOG_CMD
#define EC_LOG_EVT
#endif

And wrap the pr_info, pr_debug using filter enabled new macros - ec_info, 
ec_debug so that we won't see the filters in the normal dmesg output and the 
filters are still available for the developers.

Thanks and best regards
-Lv

> 
> Thanks and best regards
> -Lv
> 
> 
> >
> > --
> > I speak only for myself.
> > Rafael J. Wysocki, Intel Open Source Technology Center.
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Re: [PATCH 1/2] thermal: exynos: Fix wrong control of power down detection mode for Exynos7

[Lukasz Majewski]

Hi Abhilash,

> This patch fixes the wrong control of PD_DET_EN (power down detection
> mode) for Exynos7 because exynos7_tmu_control() always enables the
> power down detection mode regardless 'on' parameter.
> 
> Cc: Zhang Rui 
> Cc: Eduardo Valentin 
> Signed-off-by: Chanwoo Choi 
> ---
>  drivers/thermal/samsung/exynos_tmu.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> b/drivers/thermal/samsung/exynos_tmu.c index 933cd80..a60f527 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -682,6 +682,7 @@ static void exynos7_tmu_control(struct
> platform_device *pdev, bool on) 
>   if (on) {
>   con |= (1 << EXYNOS_TMU_CORE_EN_SHIFT);
> + con |= (1 << EXYNOS7_PD_DET_EN_SHIFT);
>   interrupt_en =
>   (of_thermal_is_trip_valid(tz, 7)
>   << EXYNOS7_TMU_INTEN_RISE7_SHIFT) |
> @@ -704,9 +705,9 @@ static void exynos7_tmu_control(struct
> platform_device *pdev, bool on) interrupt_en <<
> EXYNOS_TMU_INTEN_FALL0_SHIFT; } else {
>   con &= ~(1 << EXYNOS_TMU_CORE_EN_SHIFT);
> + con &= ~(1 << EXYNOS7_PD_DET_EN_SHIFT);
>   interrupt_en = 0; /* Disable all interrupts */
>   }
> - con |= 1 << EXYNOS7_PD_DET_EN_SHIFT;
>  
>   writel(interrupt_en, data->base + EXYNOS7_TMU_REG_INTEN);
>   writel(con, data->base + EXYNOS_TMU_REG_CONTROL);

Could you test this patch if it isn't introducing any regression on your
HW?

-- 
Best regards,

Lukasz Majewski

Samsung R Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: "advanced" LED controllers

[Alexandre Courbot]

On Wed, Feb 25, 2015 at 5:25 PM, Geert Uytterhoeven
 wrote:
> CC linux-gpio, as this looks like the LED equivalent of bulk gpio?

Indeed. The LED core could implement something similar to
gpiod_set_array() to allow several LEDs to be set in one call. If the
controller supports it, it would then set all the LEDs at once,
otherwise the core would apply the values serially.

In leds-gpio.c, this multiple LED setting could be implemented by a
single call to gpiod_set_array() and the right thing would happen.

>
> On Thu, Feb 19, 2015 at 10:14 PM, Felipe Balbi  wrote:
>> Do we have support for LED controllers which can handle patterns of
>> different kinds ? I mean, currently, if we have an LED controller such
>> as TPIC2810 [1] which can control 8 different leds and each LED
>> corresponds to one bit on register 0x44, we could control leds by just
>> "playing" a wave file on the controller and create easy patterns with
>> that.
>>
>> AFAICT, in linux today we would have to register each of the 8 LEDs as a
>> different LED and have driver magic to write the proper bits on register
>> 0x44, that seems a bit overkill, specially when we want to make
>> patterns: instead of writing 0xff we would have to write 0x80, 0x40,
>> 0x20, 0x10, 0x08, 0x04, 0x02, 0x01 separately and have the driver cache
>> the previous results so we don't end up switching off other LEDs.
>>
>> IOW, what could be handled with a single write, currently needs 8.
>>
>> I wonder if there's any work happening to support these slightly more
>> inteligent LED engines.
>>
>> regards
>>
>> [1] http://www.ti.com/product/tpic2810
>>
>> ps: tpic2810 is probably the simplest example, lp551, lp5523 and others
>> have even more advanced pattern engines which can even handle RGB leds.
>>
>> Currently the driver loads patterns as if it was a firmware blob and
>> registers each of R, G and B components as separate LEDs. Each component
>> also has its own brightness controls (something tpic2810 doesn't have,
>> it's either on or off).
> --
> To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] arm64: mediatek: Add config option for mt8173.

[Yingjoe Chen]

On Tue, 2015-01-27 at 15:13 +0800, Hongzhou Yang wrote:
> From: Hongzhou Yang 
> 
> The upcoming MTK pinctrl driver have a big pin table for each SoC,
> and we don't want to bloat the kernel binary if we don't need it.
> Add config options so we can build for one SoC only.
> 
> Signed-off-by: Hongzhou Yang 
> ---
>  arch/arm64/Kconfig | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index e627ead..6213dac 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -151,9 +151,15 @@ menu "Platform selection"
>  config ARCH_MEDIATEK
>   bool "Mediatek MT65xx & MT81xx ARMv8 SoC"
>   select ARM_GIC
> + select PINCTRL
>   help
> Support for Mediatek MT65xx & MT81xx ARMv8 SoCs
>  
> +config MACH_MT8173
> + bool "Mediatek 8173 Soc Supprt"
> + depends on ARCH_MEDIATEK
> + default y
> +
>  config ARCH_SEATTLE
>   bool "AMD Seattle SoC Family"
>   help

Hi Arnd/Matthias,

Any comments on this patch?

Joe.C



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] HID: rmi: disable palm detect gesture when present

[Gabriele Mazzotta]

On Tuesday 24 February 2015 17:36:50 Andrew Duggan wrote:
> A touchpad may have firmware based palm detection code enabled which
> suppresses 2D data from being reported when the firmware believes a palm is
> on the touchpad. This functionality is meant to be used in mouse mode without
> a driver. When a driver is present, the driver can do a better job of
> determining if a contact is a palm. If this gesture is enabled on a touchpad
> operating in rmi mode then the firmware will not properly clear the palm 
> detect
> interrupt, causing the touchpad to interrupt indefinately. This patch disables
> the palm detect gesture when the touchpad is operating in rmi mode.
> 
> Signed-off-by: Andrew Duggan 
> ---
> Hi Gabriele,
> 
> Can you test this patch on your system to confirm that it fixes your issue?
> I was able to test the  other two patches so I can confirm that the write
> fuction works. But, I don't have a touchpad with the palm detect gesture
> enabled so it would be good to double check that I have the right address and
> mask.
> 
> Andrew

I tested it and confirm that it's working. Thanks.

Gabriele
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] rcu: Remove reduplicate check of cpu_online

[Yao Dongdong]

The calling function invoke_rcu_core will check it.

Signed-off-by: Yao Dongdong 
---
 kernel/rcu/tree.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 48d640c..e5f9b7e 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -2741,7 +2741,7 @@ static void __call_rcu_core(struct rcu_state *rsp, struct 
rcu_data *rdp,
 * If called from an extended quiescent state, invoke the RCU
 * core in order to force a re-evaluation of RCU's idleness.
 */
-   if (!rcu_is_watching() && cpu_online(smp_processor_id()))
+   if (!rcu_is_watching())
invoke_rcu_core();
 
/* If interrupts were disabled or CPU offline, don't invoke RCU core. */
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/4] x86: entry.S: tidy up several suboptimal insns

[Ingo Molnar]

* H. Peter Anvin  wrote:

> On 02/24/2015 02:25 PM, Andy Lutomirski wrote:
> > On Tue, Feb 24, 2015 at 10:51 AM, Denys Vlasenko  
> > wrote:
> >>
> >> In all three 32-bit entry points, %eax is 
> >> zero-extended to %rax. It is safe to do 32-bit compare 
> >> when checking that syscall# is not too large.
> > 
> > Applied.  Thanks!
> > 
> 
> NAK NAK NAK NAK NAK
> 
> We have already had this turn into a security issue not 
> just once but TWICE, because someone decided to 
> "optimize" the path by taking out the zero extend.
> 
> The use of a 64-bit compare here is an intentional "belts 
> and suspenders" safety issue.

I think the fundamental fragility is that we allow the high 
32 bits to be nonzero.

So could we just zap the high 32 bits of RAX early in the 
entry code, and then from that point on we could both use 
32-bit ops and won't have to remember the possibility 
either?

That's arguably one more (cheap) instruction in the 32-bit 
entry paths but then we could use the shorter 32-bit 
instructions for compares and other uses and could always 
be certain that we get what we want.


But, if we do that, we can do even better, and also do an 
optimization of the 64-bit entry path as well: we could 
simply mask RAX with 0x3ff and not do a compare. Pad the 
syscall table up to 0x400 (1024) entries and fill in the 
table with sys_ni syscall entries.

This is valid on 64-bit and 32-bit kernels as well, and it 
allows the removal of a compare from the syscall entry 
path, at the cost of a couple of kilobytes of unused 
syscall table.

The downside would be that if we ever grow past 1024 
syscall entries we'll be in trouble if new userspace calls 
syscall 513 on an old kernel and gets syscall 1.

I doubt we'll ever get so many syscalls, and user-space 
will be able to be smart in any case, so it's not a 
showstopper.

This is the safest and quickest implementation as well.

Thoughts?

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] OMAPDSS: restore "name" sysfs entry.

[NeilBrown]

On Wed, 25 Feb 2015 10:49:58 +0200 Tomi Valkeinen 
wrote:

> Hi,
> 
> On 24/02/15 22:31, NeilBrown wrote:
> > On Tue, 24 Feb 2015 12:40:32 +0200 Tomi Valkeinen 
> > wrote:
> > 
> >> Hi,
> >>
> >> On 24/02/15 11:37, NeilBrown wrote:
> >>>
> >>>
> >>> commit 303e4697e762dc92a40405f4e4b8aac02cd0d70b
> >>> OMAPDSS: rename display-sysfs 'name' entry
> >>>
> >>> broke the xorg X server on my device as it couldn't find the display
> >>> any more.  It needs the 'name' file and now there isn't one.
> >>>
> >>> That commit claims that 'name' is not compatible with i2c or spi.
> >>> i2c does register it own 'name' file, but spi does not, hence my
> >>> problem - I have an spi display.
> >>>
> >>> So create a special case for i2c: add the name attribute for non-i2c
> >>> devices.
> 
> How about this patch instead. It separates the underlying device's sysfs 
> directory 
> from the "displayX" directory, and allows us to have name & display_name. So 
> it
> should work for any device type.
> 
> 
> From 8e411fa684d42fca35628b41837c6d72e87aaff0 Mon Sep 17 00:00:00 2001
> From: Tomi Valkeinen 
> Date: Wed, 25 Feb 2015 10:23:58 +0200
> Subject: [PATCH] OMAPDSS: fix regression with display sysfs files
> 
> omapdss's sysfs directories for displays used to have 'name' file,
> giving the name for the display. This file was later renamed to
> 'display_name' to avoid conflicts with i2c sysfs 'name' file. Looks like
> at least xserver-xorg-video-omap3 requires the 'name' file to be
> present.
> 
> To fix the regression, this patch creates new kobjects for each display,
> allowing us to create sysfs directories for the displays. This way we
> have the whole directory for omapdss, and there will be no sysfs file
> clashes with the underlying display device's sysfs files.
> 
> We can thus add the 'name' sysfs file back.
> 
> Signed-off-by: Tomi Valkeinen 
> ---
>  drivers/video/fbdev/omap2/dss/display-sysfs.c | 179 
> ++
>  include/video/omapdss.h   |   1 +
>  2 files changed, 96 insertions(+), 84 deletions(-)
> 
> diff --git a/drivers/video/fbdev/omap2/dss/display-sysfs.c 
> b/drivers/video/fbdev/omap2/dss/display-sysfs.c
> index 5a2095a98ed8..12186557a9d4 100644
> --- a/drivers/video/fbdev/omap2/dss/display-sysfs.c
> +++ b/drivers/video/fbdev/omap2/dss/display-sysfs.c
> @@ -28,44 +28,22 @@
>  #include 
>  #include "dss.h"
>  
> -static struct omap_dss_device *to_dss_device_sysfs(struct device *dev)
> +static ssize_t display_name_show(struct omap_dss_device *dssdev, char *buf)
>  {
> - struct omap_dss_device *dssdev = NULL;
> -
> - for_each_dss_dev(dssdev) {
> - if (dssdev->dev == dev) {
> - omap_dss_put_device(dssdev);
> - return dssdev;
> - }
> - }
> -
> - return NULL;
> -}
> -
> -static ssize_t display_name_show(struct device *dev,
> - struct device_attribute *attr, char *buf)
> -{
> - struct omap_dss_device *dssdev = to_dss_device_sysfs(dev);
> -
>   return snprintf(buf, PAGE_SIZE, "%s\n",
>   dssdev->name ?
>   dssdev->name : "");
>  }
>  
> -static ssize_t display_enabled_show(struct device *dev,
> - struct device_attribute *attr, char *buf)
> +static ssize_t display_enabled_show(struct omap_dss_device *dssdev, char 
> *buf)
>  {
> - struct omap_dss_device *dssdev = to_dss_device_sysfs(dev);
> -
>   return snprintf(buf, PAGE_SIZE, "%d\n",
>   omapdss_device_is_enabled(dssdev));
>  }
>  
> -static ssize_t display_enabled_store(struct device *dev,
> - struct device_attribute *attr,
> +static ssize_t display_enabled_store(struct omap_dss_device *dssdev,
>   const char *buf, size_t size)
>  {
> - struct omap_dss_device *dssdev = to_dss_device_sysfs(dev);
>   int r;
>   bool enable;
>  
> @@ -90,19 +68,16 @@ static ssize_t display_enabled_store(struct device *dev,
>   return size;
>  }
>  
> -static ssize_t display_tear_show(struct device *dev,
> - struct device_attribute *attr, char *buf)
> +static ssize_t display_tear_show(struct omap_dss_device *dssdev, char *buf)
>  {
> - struct omap_dss_device *dssdev = to_dss_device_sysfs(dev);
>   return snprintf(buf, PAGE_SIZE, "%d\n",
>   dssdev->driver->get_te ?
>   dssdev->driver->get_te(dssdev) : 0);
>  }
>  
> -static ssize_t display_tear_store(struct device *dev,
> - struct device_attribute *attr, const char *buf, size_t size)
> +static ssize_t display_tear_store(struct omap_dss_device *dssdev,
> + const char *buf, size_t size)
>  {
> - struct omap_dss_device *dssdev = to_dss_device_sysfs(dev);
>   int r;
>   bool te;
>  
> @@ -120,10 +95,8 @@ static ssize_t display_tear_store(struct device *dev,
>   return size;
>  }
>  
> -static ssize_t display_timings_show(struct device *dev,
> - struct device_attribute *attr, char 

Re: [PATCH] dcssblk.c : Array index 'i' is used before limits check.

[Heiko Carstens]

On Tue, Feb 24, 2015 at 06:41:50PM +0200, Ameen Ali wrote:
> avoid out-of-bounds-read by checking count before indexing.
> 
> Signed-off-by : Ameen Ali 
> ---
>  drivers/s390/block/dcssblk.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/s390/block/dcssblk.c b/drivers/s390/block/dcssblk.c
> index 96128cb..da21281 100644
> --- a/drivers/s390/block/dcssblk.c
> +++ b/drivers/s390/block/dcssblk.c
> @@ -547,7 +547,7 @@ dcssblk_add_store(struct device *dev, struct 
> device_attribute *attr, const char
>* parse input
>*/
>   num_of_segments = 0;
> - for (i = 0; ((buf[i] != '\0') && (buf[i] != '\n') && i < count); i++) {
> + for (i = 0; (i < count && (buf[i] != '\0') && (buf[i] != '\n')); i++) {

Applied, thanks!

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V4 0/7] x86/intel_rdt: Intel Cache Allocation Technology

[Peter Zijlstra]

On Tue, Feb 24, 2015 at 03:16:37PM -0800, Vikas Shivappa wrote:
> This patch adds a new cgroup subsystem to support the new Cache Allocation 
> Technology (CAT) feature found in future Intel Xeon Intel processors. CAT is 
> part of Resource Director Technology(RDT) or Platform Shared resource control 
> which provides support to control Platform shared resources like cache.

Totally insane naming all of that. Note that if you google for "intel
rdt" it suggests you search for "intel rst" and this patch is the only
link it finds that's somewhat close.

The CAT thing was annoying already, but at least one can find that in
the SDM, this RDT thing, not a single mention.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fwd: w1/slaves/w1_therm: null-ptr access of sl->family_data

[Thorsten Bschorr]

David,

I can try to prepare a patch fixing the null-ptr access.

Thanks for the hint with the search_count, I'll try it.


2015-02-24 2:37 GMT+01:00 David Fries :
> Thorsten,
> Are you planning on submitting a patch?
>
> FYI, I load the one wire module with
> wire search_count=1
> in
> /etc/modules
> which tells it to search the bus once only.  That works for me as
> devices don't come and go on my bus, and it isn't scanning the bus
> every few seconds just to find out nothing changed.  If you are
> finding devices vanish even when they aren't maybe it will be useful
> to you as well, though the bigger problem might be why they are
> vanishing in the first place.
>
> On Mon, Feb 23, 2015 at 06:09:16PM +0100, Thorsten Bschorr wrote:
>> Hi,
>>
>> I have observed a null-pointer access in w1/slaves/w1_therm on my Raspberry
>> Pi running 3.18.5 with several DS18S20 temperature sensors. I have already
>> discussed the problem with Evgeniy.
>>
>> @Evgeniy & David: sorry for re-sending my message, my email
>> accidentally contained a HTML part.
>>
>>
>>
>> w1_therm: w1_slave_show checks if the sensor uses external power. If this
>> is the case, the mutex on dev->bus_mutex is unlocked while waiting 750 ms
>> for the sensor to convert the temperature. Before reading the temperature,
>> the mutex is again locked.
>>
>> During this sleep-time, the sensor could get detached, for example by w1.c:
>> w1_search_process_cb not finding the sensor (*):
>>  !test_bit(W1_SLAVE_ACTIVE, >flags) ==true.
>> This triggers w1_slave_detach, and hence w1_therm_remove_slave frees and
>> nulls sl->family_data.
>>
>> w1_slave_show does not check if familiy_data is null after re-acquiring the
>> bus_mutex resulting in a null-ptr access when storing data.
>>
>> After I've added checks for family_data!=0, I did not observe any more
>> crashes; the other data of struct w1_slave seem to be valid as long as any
>> thread executes w1_slave_show.
>>
>>
>> I have added debug-output to w1.c and w1_therm.c, here's a log of a
>> potential crash:
>>
>> [184199.510227] w1_master_driver w1_bus_master2: w1_search_process_cb,
>> !W1_SLAVE_ACTIVE, calling w1_slave_detach
>> [184199.510276] w1_slave_driver 10-000802d9c9e4: w1_slave_detach
>> destroy_now 1
>> [184199.510297] w1_slave_driver 10-000802d9c9e4: w1_unref_slave refcnt 0
>> [184199.510321] w1_slave_driver 10-000802d9c9e4: w1_unref_slave: detaching
>> 10-000802d9c9e4 [d5fb8800].
>> [184199.510347] w1_slave_driver 10-000802d9c9e4: w1_unref_slave ->
>> w1_family_notify
>> [184199.510365] w1_slave_driver 10-000802d9c9e4: w1_family_notify calling
>> remove_slave
>> [184199.510382] w1_slave_driver 10-000802d9c9e4: w1_therm_remove_slave
>> [184199.510400] w1_slave_driver 10-000802d9c9e4: w1_therm_remove_slave
>> refcnt -1
>> [184200.049745] w1_slave_driver 10-000802d9c9e4: w1_slave_show (after
>> sleep), family_data==0
>> [184200.137133] w1_slave_driver 10-000802d9c9e4: w1_slave_show (before
>> sleep), family_data==0
>> [184200.889551] w1_slave_driver 10-000802d9c9e4: w1_slave_show (after
>> sleep), family_data==0
>> [184200.930866] w1_slave_driver 10-000802d9c9e4: w1_slave_show (after
>> sleep), family_data==0
>> [184200.930907] w1_slave_driver 10-000802d9c9e4: Read failed CRC check
>> [184200.931002] w1_slave_driver 10-000802d9c9e4: w1_unref_slave ->
>> device_unregister
>> [184200.931169] w1 w1_unref_slave -> kfree
>>
>> Note: When this crash happened, multiple threads were reading the sensor.
>>
>>
>> I could trigger the problem several times, and each time device_unregister
>> in w1_unref_slave was executed  *after*  w1_slave_show. In one case, the
>> logged time-difference between the first family_data==0 message and
>> device_unregister was about 8 seconds!
>> I have not observed a w1_slave_show call after w1_unref_slave (as long as
>> the device was not re-attached again).
>>
>> >From my observation, the w1_slave data seem to be valid as long as
>> w1_slave_show is executed.
>> My guess is that the call of sysfs_remove_groups in w1_family_notify hits a
>> mutex (I did not add debug output here).
>>
>>
>> (*) On my tiny raspberry, this happens from time to time with high CPU and
>> external disc load (timing and/or electrical issues); it seems that the
>> sensor does not respond in time to the (periodic) search.
>>
>>
>> Please email me if you need further information.
>>
>>
>>
>> Best regards,
>> Thorsten Bschorr
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>
> --
> David Fries PGP pub CB1EE8F0
> http://fries.net/~david/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/4] x86: entry.S: tidy up several suboptimal insns

[H. Peter Anvin]

On 02/25/2015 01:20 AM, Ingo Molnar wrote:


I think the fundamental fragility is that we allow the high
32 bits to be nonzero.

So could we just zap the high 32 bits of RAX early in the
entry code, and then from that point on we could both use
32-bit ops and won't have to remember the possibility
either?



We do that, but people keep "optimizing" the zero extend away.  We have 
had this cause a wide-open security hole twice already.  So the extra 
REX prefix is a cheap cost to avoid this happen again.


-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] OMAPDSS: restore "name" sysfs entry.

[Tomi Valkeinen]

On 25/02/15 11:20, NeilBrown wrote:

> Tested-by: NeilBrown 
> 
> Before the patch:
> 
> # ls -l /sys/devices/platform/omapdss/display0 
> lrwxrwxrwx 1 root root 0 Feb  8 12:57 /sys/devices/platform/omapdss/display0 
> -> ../spi_lcd/spi_master/spi32766/spi32766.0
> 
> After the patch:
> 
> # ls -l /sys/devices/platform/omapdss/display0 
> total 0
> -r--r--r-- 1 root root 4096 Feb  8 13:37 display_name
> -rw-r--r-- 1 root root 4096 Feb  8 13:37 enabled
> -rw-r--r-- 1 root root 4096 Feb  8 13:37 mirror
> -r--r--r-- 1 root root 4096 Feb  8 13:37 name
> -rw-r--r-- 1 root root 4096 Feb  8 13:37 rotate
> -rw-r--r-- 1 root root 4096 Feb  8 13:37 tear_elim
> -rw-r--r-- 1 root root 4096 Feb  8 13:37 timings
> -rw-r--r-- 1 root root 4096 Feb  8 13:37 wss
> 
> 
> So as you say it creates a directory just for the display0 device, and that
> has the 'name' that we want.

I think this was something similar than how the sysfs files were set up
originally for omapdss. If I remember right, we didn't have proper
devices for the displays then. Things have evolved quite a bit since then.

There's a small chance of this patch breaking things, of course... If
someone accessed those display sysfs files via the display device
(../spi_lcd/spi_master/spi32766/spi32766.0), the files are now gone.

But I think (hope...) they are always accessed via the omapdss's
displayX directories.

> This works for me, and it seems to me to be a better fit to the general
> structure of /sys/devices - symlinks within /sys/devices are a substantial
> minority, other than 'subsystem', 'device', 'driver' and 'bdi' which have
> very generic meanings.
> 
> I guess I'm a little surprised that there doesn't seem to be any linkage from
> the display0 to the spi device.  Maybe that isn't important.

Yep, I don't think so. In any case, all this is to be deprecated, and as
soon as omapdrm driver works reliably that should be the driver to use.

So of course we need to keep omapfb working for the years to come, but
I'd rather not add any new sysfs files for a soon deprecated driver.

 Tomi




signature.asc
Description: OpenPGP digital signature

[PATCH] OMAP: DSS: DPI: disable vt-switch on suspend/resume.

[NeilBrown]

These devices do not need to return to non-graphic console
for suspend, so disable that option.
This means there is less work to do in the suspend/resume cycle,
making it smoother and cheaper.


Signed-off-by: NeilBrown 

--
Hi Tomi,
 I wonder if you would consider this patch too.  It works for me and
removes pointless vt switching.  I assume no-one would need or want that
switching on suspend/resume but I guess I cannot be certain.

Maybe a module-parameter could be used if there was any uncertainty.

thanks,
NeilBrown


diff --git a/drivers/video/fbdev/omap2/dss/dpi.c 
b/drivers/video/fbdev/omap2/dss/dpi.c
index f83e7b030249..4a29bab4ade3 100644
--- a/drivers/video/fbdev/omap2/dss/dpi.c
+++ b/drivers/video/fbdev/omap2/dss/dpi.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -798,6 +799,8 @@ static int omap_dpi_probe(struct platform_device *pdev)
mutex_init(>lock);
 
dpi_init_output(pdev);
+   /* No need to vt_switch in suspend/resume */
+   pm_set_vt_switch(0);
 
return 0;
 }


pgpioYrNYMzbb.pgp
Description: OpenPGP digital signature

Re: [PATCH 13/13] x86/microcode/intel: Fix printing of microcode blobs in show_saved_mc()

[Quentin Casasnovas]

On Tue, Feb 24, 2015 at 05:48:17PM +0100, Borislav Petkov wrote:
> 
> Thanks for the review, very good points. I had spotted some of them
> myself but had to restrain myself not to do them now for the very
> simple reason: we want this code first cleaned up nicely, in small and
> self-contained pieces so that no regressions get introduced from more
> involved patches (debugging early microcode loader issues is nasty).
> 
> Then we can start improving it, once enough rust is shaken off.

Yup that's how I understood your patchset :)  If I may though, I think the
issue I raised on your patch 8 is serious enough to get a fix before you
merge this patchset - it should just be a matter of adding some parentheses
at the correct place, and should be a good candidate for -stable.

> 
> Now, I have limited time so, if, in case you wanted to do small and
> clean patchsets cleaning up this more or improving some aspects of it
> and tested them and sent them to me, I'll gladly give them a good look
> and test them here too. :-)
> 
> But you don't have to, this is just a suggestion anyway - I just get the
> feeling that you like looking at it and wanted to mention that in case
> you'd like to help out cleaning it up, you're welcome to do so.
> 

I have also very limited time to allocate for this, but I can surely help
with reviewing.  If I manage to get some spare time, I'll make sure to try
to contribute as well, no guarantee for now though!

Quentin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/4] x86: entry.S: tidy up several suboptimal insns

[Ingo Molnar]

* H. Peter Anvin  wrote:

> > So could we just zap the high 32 bits of RAX early in 
> > the entry code, and then from that point on we could 
> > both use 32-bit ops and won't have to remember the 
> > possibility either?
> 
> We do that, [...]

Ok, indeed, so in ia32_sysenter_target() we have:

movl%eax, %eax

> [...] but people keep "optimizing" the zero extend away. 
> [...]

Possibly because there's not a single comment near that 
code explaining the importance of that line. But nobody 
will get a change past me with such a warning next to the 
line.

> [...]  We have had this cause a wide-open security hole 
> twice already.  So the extra REX prefix is a cheap cost 
> to avoid this happen again.

But since we already zap the high bits, there's no point in 
doing 64-bit compares...

Just make sure the high zero bit clearing is there and is 
never removed.

So in that sense the changes are correct, even in the 
security robustness sense.

Furthermore, with the masking suggestion I made in the 
previous mail it's moot as we can solve both problems: 
64-bit uses of RAX will become correct as well, and it
will be a bit faster as well.

Hm?

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/4] x86: get rid of KERNEL_STACK_OFFSET

[Ingo Molnar]

* Andy Lutomirski  wrote:

> -   BUG_ON(((current_stack_pointer() ^ this_cpu_read_stable(kernel_stack))
> +   BUG_ON(((current_stack_pointer() ^
> +(this_cpu_read_stable(kernel_stack) - 1))
> & ~(THREAD_SIZE - 1)) != 0);
> 
> preempt_count_sub(HARDIRQ_OFFSET);
> 
> I added that in and applied this patch.

So this is not just slightly buggy, it's fundamentally 
wrong as well as it removes the possibility of an RSP value 
optimization from the 64-bit path, see my previous mail.

The right solution would be to make SAVE_ARGS recognize 
when KERNEL_STACK_OFFSET == args-offset and omit the RSP 
fixup in that case, or to simply use a __SAVE_ARGS for the 
64-bit path, knowing that RSP has the right value already.

Please also add comments that explain the relationship 
between percpu::kernel_stack, KERNEL_STACK_OFFSET and the 
64-bit system call entry code.

Also, guys, please slow down a bit and be more careful. 
Andy, could you please send me all currently pending entry 
bits pending in your tree, because all the in-flight 
changes make it hard for me to review patches? Please 
(re-)send all patches as well as part of the submission.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 2/2] fbcon: expose cursor blink interval via sysfs

[Pavel Machek]

On Mon 2015-01-26 20:41:53, Scot Doyle wrote:
> The fbcon cursor, when set to blink, is hardcoded to toggle display state
> five times per second. Expose this setting via
> /sys/class/graphics/fbcon/cursor_blink_ms
> 
> Values written to the interface set the approximate time interval in
> milliseconds between cursor toggles, from 1 to 32767. Since the interval
> is stored internally as a number of jiffies, the millisecond value read
> from the interface may not exactly match the entered value.
> 
> An outstanding blink timer is reset after a new value is entered.
> 
> If the cursor blink is disabled, either via the 'cursor_blink' boolean
> setting or some other mechanism, the 'cursor_blink_ms' setting may still
> be modified. The new value will be used if the blink is reactivated.
> 
> Signed-off-by: Scot Doyle 

Normally, this would be set by ansi escape sequences, no? We can hide
cursor using them, set its appearance.. makes sense to change timing
value there, too
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Nokia N900: omap aes is broken

[Pavel Machek]

On Tue 2015-02-24 09:37:34, Tony Lindgren wrote:
> * Pali Rohár  [150224 09:42]:
> > On Tuesday 24 February 2015 18:25:12 Tony Lindgren wrote:
> > > * Pali Rohár  [150218 16:03]:
> > > > --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> > > > +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> > > > @@ -3938,8 +3938,9 @@ int __init omap3xxx_hwmod_init(void)
> > > > 
> > > > if (r < 0)
> > > > 
> > > > return r;
> > > > 
> > > > -   /* Register GP-only hwmod links. */
> > > > -   if (h_gp && omap_type() == OMAP2_DEVICE_TYPE_GP) {
> > > > +// /* Register GP-only hwmod links. */
> > > > +// if (h_gp && omap_type() == OMAP2_DEVICE_TYPE_GP) {
> > > > +   if (h_gp) {
> > > > 
> > > > r = omap_hwmod_register_links(h_gp);
> > > > if (r < 0)
> > > > 
> > > > return r;
> > > > 
> > > > aes hwmod is defined in GP-only hwmod...
> > > 
> > > Doesn't this depend on the bootloader version of n900 to work?
> > > 
> > > Regards,
> > > 
> > > Tony
> > 
> > Ok, it looks like second patch (omap_hwmod_3xxx_data.c) needs 
> > that aes-enabled bootloader.
> 
> OK we need some runtime detection somehow for what's enabled..
>  
> > But first patch (omap3.dtsi) is needed for proper definitions. 
> > Otherwise omap-aes driver will never work on DT systems.
> 
> Yeah that one makes sense to me, I guess you'll do a proper
> fix for that one.

If this depends on bootloader... would command line parameter be right
solution here?
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/3] net: Linn Ethernet Packet Sniffer driver

[Richard Cochran]

On Mon, Feb 23, 2015 at 09:37:24AM +, Stathis Voukelatos wrote:
> Hi Richard,
> 
> On 18/02/15 21:08, Richard Cochran wrote:
> >On Tue, Feb 17, 2015 at 02:03:30PM +, Stathis Voukelatos wrote:
> >>The command string for packet matching is stored in module RAM
> >>and consists of a sequence of 16-bit entries. Each entry includes
> >>an 8-bit command code and and 8-bit data value. Valid command
> >>codes are:
> >>0 - Don't care
> >>1 - Match: packet data must match command string byte
> >>2 - Copy: packet data will be copied to FIFO
> >>3 - Match/Stamp: if packet data matches string byte, a timestamp
> >>  is copied into the FIFO
> >>4 - Copy/Done: packet data will be copied into the FIFO.
> >>This command terminates the command string.
> >
> >Why do you need to expose this interface to user space at all?  Why
> >not just time stamp every frame?
> 
> To put this into context with an example, the use case this H/W
> module was originally developed for was to allow multiple audio
> receivers to synchronize with a single transmitter, eg. multi-room
> synchronised audio.

The Linux kernel already fully supports this kind of application via
the SIOCSHWTSTAMP, SO_TIMESTAMPING, and PHC mechanisms.  We certainly
don't need another another interface just for someone's warped
hardware design.

I suggest that you find a way to make your HW work within the existing
frame work.

> The interface needs to be public so that a user-space application
> can program a command string that will match packets that belong to
> the audio stream of interest, for this example.

Let the user program simply use a BPF for that.

> In addition returning just a timestamp would not be enough in many
> cases. In the audio streaming use case mentioned above some
> additional
> bytes from the packet payload need to be returned (with Copy
> commands) in order to associate the timestamp with a certain point
> in the audio stream.

The time stamp is *already* associated with a particular frame.

Just tell your driver to program the hardware to:

1. time stamp every frame
2. deliver every frame

Thats all you need.

> >How does the "Match" command work?  The frame must have one particular
> >byte?  That can't be right.  Please explain.
> 
> Actually, that is how the H/W works. Each Match command is followed by
> a data value which must match the packet data byte at the corresponding
> location. If there is no match processing of the packet stops.

And just what is the "corresponding location"?

Thanks,
Richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH_V2 1/3] dt-bindings: dma: Add binding for jz4780-dma

[Zubair Lutfullah Kakakhel]

On 24/02/15 18:08, Zubair Lutfullah Kakakhel wrote:
> From: Alex Smith 
> 
> Add device tree bindings for the DMA controller on JZ4780 SoCs, used by
> the dma-jz4780 driver.
> 
> Signed-off-by: Alex Smith 
> Signed-off-by: Zubair Lutfullah Kakakhel 
> 
> ---
> V1 -> V2 None
> ---
>  .../devicetree/bindings/dma/jz4780-dma.txt | 61 
> ++
>  1 file changed, 61 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/dma/jz4780-dma.txt
> 
> diff --git a/Documentation/devicetree/bindings/dma/jz4780-dma.txt 
> b/Documentation/devicetree/bindings/dma/jz4780-dma.txt
> new file mode 100644
> index 000..ce90011
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/jz4780-dma.txt
> @@ -0,0 +1,61 @@
> +* Ingenic JZ4780 DMA Controller
> +
> +Required properties:
> +
> +- compatible: Should be "ingenic,jz4780-dma"
> +- reg: Should contain the DMA controller registers location and length.
> +- interrupts: Should contain the interrupt specifier of the DMA controller.
> +- interrupt-parent: Should be the phandle of the interrupt controller that
> +- clocks: Should contain a clock specifier for the JZ4780 PDMA clock.
> +- #dma-cells: Must be <3>. Number of integer cells in the dmas property of
> +  DMA clients (see below).
> +
> +Optional properties:
> +
> +- ingenic,reserved-channels: Bitmask of channels to reserve for devices that
> +  need a specific channel. These channels will only be assigned when 
> explicitly
> +  requested by a client. The primary use for this is channels 0 and 1, which
> +  can be configured to have special behaviour for NAND/BCH when using
> +  programmable firmware.
> +
> +Example:
> +
> +dma: dma@1342 {
> + compatible = "ingenic,jz4780-dma";
> + reg = <0x1342 0x1>;
> +
> + interrupt-parent = <>;
> + interrupts = <10>;
> +
> + clocks = < JZ4780_CLK_PDMA>;
> +
> + #dma-cells = <3>;
> +
> + ingenic,reserved-channels = <0x3>;
> +};
> +
> +DMA clients must use the format described in dma.txt, giving a phandle to the
> +DMA controller plus the following 3 integer cells:
> +
> +1. Transmit request type: The DMA request type for transfers to the device on
> +   the allocated channel, as defined in the SoC documentation. If set to 0,
> +   transfers to the device will not be allowed on the channel.
> +
> +2. Receive request type: The DMA request type for transfers from the device 
> on
> +   the allocated channel, as defined in the SoC documentation. If set to 0,
> +   transfers from the device will not be allowed on the channel.
> +
> +3. Channel: If set to 0x, any available channel will be allocated for
> +   the client. Otherwise, the exact channel specified will be used. The 
> channel
> +   should be reserved on the DMA controller using the 
> ingenic,reserved-channels
> +   property.

Update. 
I'm taking a look at these bindings again and see if Transmit/Receive request 
types 'need' to be separate.
mmc driver is the only one using it like that.

Sorry for the spam.

Regards,
ZubairLK

> +
> +Example:
> +
> +uart0: serial@1003 {
> + ...
> + dmas = < 0x14 0 0x
> +  0 0x15 0x>;
> + dma-names = "tx", "rx";
> + ...
> +};
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 1/3] mmc: dw_mmc: update clock after host reach a stable voltage

[Jaehoon Chung]

Hi,

On 02/25/2015 04:52 PM, Alim Akhtar wrote:
> Hi Doug,
> 
> 
> On Fri, Feb 20, 2015 at 5:19 AM, Doug Anderson  wrote:
>> Alim and Addy,
>>
>> On Sun, Feb 15, 2015 at 3:28 PM, Alim Akhtar  wrote:
>>> Hi Addy,
>>>
>>> On Sat, Feb 14, 2015 at 11:47 AM, Addy Ke  wrote:
 As show in mmc_power_up(), in MMC_POWER_UP state, the voltage isn't
 stable and we may get 'data busy' which can't be cleaned by resetting
 all blocks. So we should not send command to update clock in this state.

 Signed-off-by: Addy Ke 
 ---
  drivers/mmc/host/dw_mmc.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
 index 4d2e3c2..3472f9b 100644
 --- a/drivers/mmc/host/dw_mmc.c
 +++ b/drivers/mmc/host/dw_mmc.c
 @@ -1102,7 +1102,8 @@ static void dw_mci_set_ios(struct mmc_host *mmc, 
 struct mmc_ios *ios)
 drv_data->set_ios(slot->host, ios);

 /* Slot specific timing and width adjustment */
 -   dw_mci_setup_bus(slot, false);
 +   if (ios->power_mode != MMC_POWER_UP)
 +   dw_mci_setup_bus(slot, false);

>>> This looks a HACK to me.
>>> If stabilizing host voltage regulator is the problem, can you try out
>>> below patch, and see if this resolve your issue?
>>
>> Actually, IMHO Alim's patch is more of a hack than Addy's.  There's
>> already a 10ms delay between "power up" and "power on" in the MMC core
>> in mmc_power_up() state.  That delay is commented as:
>>
> Well, my suggestion (adding 5ms in switch_volatge) was based on DW_MMC
> databook (V2.41a) section "7.4.1.2 Voltage switch Normal Scenario"
> step #7 which says:" After the 5ms timer expires, the host voltage
> regulator is stable".

if you want to stable power, How about using SDMMC_CMD_INIT flag?

It waits for 80-clock before sending command.(To stable power)
- You can refer to CMD register description.

Best Regards,
Jaehoon Chung

> 
> PS: I have limited to no access of my mails and workstation until
> March 9th, so replies will be slow.
> 
>>   /*
>>* This delay should be sufficient to allow the power supply
>>* to reach the minimum voltage.
>>*/
>>   mmc_delay(10);
>>
>> That means that assuming that the voltage is stable in MMC_POWER_UP is
>> not valid anyway.
>>
>>
>> Addy's patch certainly needs more comments.  In another context Olof 
>> suggested:
>>
>> /*
>>  * Skip bus setup while voltage is still stabilizing. Instead,
>>  * bus setup will be done at MMC_POWER_ON.
>>  */
>>
>>
>> ...thinking about this more, though: really the voltage should be
>> stabilized when the regulator call returns (see my comments below).
>> In actuality the "right" fix might be to just rearrange this function
>> a little not to turn the clock on _before_ we even try to turn the
>> voltage on.
>>
>> I've got that coded up but I'm still testing it...  If you want to try
>> it too, you can find it at
>> .
>>
>> Note that without my patch I find that I _really_ need Addy's patch to
>> make sure that the card isn't busy in setup_bus.  With my patch Addy's
>> code catches the card busy less often.  I'm still trying to see if
>> there's a way to totally remove the need for his setup_bus and still
>> trying to grok all the patches flying around...
>>
>>
>>> ===
>>> [PATCH] mmc: dw_mmc: Wait for host voltage regulator to be stable
>>>
>>> Signed-off-by: Alim Akhtar 
>>> ---
>>>  drivers/mmc/host/dw_mmc.c | 3 +++
>>>  1 file changed, 3 insertions(+)
>>>
>>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>>> index 4d2e3c2..dc10fbb 100644
>>> --- a/drivers/mmc/host/dw_mmc.c
>>> +++ b/drivers/mmc/host/dw_mmc.c
>>> @@ -1202,6 +1202,9 @@ static int dw_mci_switch_voltage(struct mmc_host
>>> *mmc, struct mmc_ios *ios)
>>>   }
>>>   mci_writel(host, UHS_REG, uhs);
>>>
>>> + /* wait for 5ms so that host voltage regulator is stable */
>>> + usleep_range(5000, 5500);
>>> +
>>
>> Alim: if you have some other instance where you actually need VQMMC to
>> stabilize it should probably be done in a different way.  If I
>> understand correctly it is the regulator core's job to make sure that
>> voltage is stable before returning.  If you have a gpio-regulator you
>> may be able to use "startup-delay-us" to specify how long the
>> regulator takes to come up.  You could also look at
>> 'regulator-enable-ramp-delay'
>>
>> -Doug
> 
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 linux-next] iommu: Enable LPAE pagetable on ARM and ARM64 only

[Will Deacon]

On Tue, Feb 24, 2015 at 12:23:48AM +, Laurent Pinchart wrote:
> On Tuesday 24 February 2015 01:20:21 Vincent Stehlé wrote:
> > LPAE iommu page table makes sense only for ARM and ARM64 architectures. Add
> > the corresponding dependency in Kconfig (and enable for COMPILE_TEST, too,
> > as per Laurent's suggestion).
> > 
> > Signed-off-by: Vincent Stehlé 
> > Suggested-by: Laurent Pinchart 
> > Cc: Will Deacon 
> 
> Now,
> 
> Acked-by: Laurent Pinchart 

Sorry guys, I've been away from email for the past couple of days, but I
already have an exact copy of this patch queued from somebody else!

  http://www.spinics.net/lists/arm-kernel/msg400030.html

Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH linux-next] iommu: Enable LPAE pagetable on ARM only

[Will Deacon]

On Tue, Feb 24, 2015 at 10:33:02AM +, Geert Uytterhoeven wrote:
> On Mon, Feb 23, 2015 at 5:52 PM, Laurent Pinchart
>  wrote:
> > On Sunday 22 February 2015 17:09:06 Vincent Stehlé wrote:
> >> LPAE iommu page table makes sense only for ARM architecture. Add the
> >> corresponding dependency in Kconfig.
> >>
> >> This fixes the following runtime warnings on PA-RISC architecture:
> >
> > I suppose this is caused by the selftest code ?
> >
> >>   WARNING: at drivers/iommu/io-pgtable-arm.c:413
> >>   Modules linked in:
> >>   CPU: 0 PID: 1 Comm: swapper/0 Not tainted
> >> 3.19.0-next-20150222-2-gc420256 #2 task: 17ca ti: 17ca8000 task.ti:
> >> 17ca8000
> >>
> >>YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
> >>   PSW: 0100 Not tainted
> >>   r00-03  0004ff0f 001b 104871b0 17ca83c0
> >>   r04-07  1000   
> >>   r08-11   40001000 1013b36c 17ca8248
> >>   r12-15  0080 17e712c0  17c5e100
> >>   r16-19  000c 105d8eb0 40001000 
> >>   r20-23   00800020 1048717c 
> >>   r24-27  1000  0009 10774ce0
> >>   r28-31   0027 17ca8480 10486d44
> >>   sr00-03     
> >>   sr04-07     
> >>
> >>   IASQ:   IAOQ: 10486df4 10486df8
> >>IIR: 03ffe01fISR:   IOR: 17c86e54
> >>CPU:0   CR30: 17ca8000 CR31: 0002
> >>ORIG_R28: 0001
> >>IAOQ[0]: __arm_lpae_unmap+0x144/0x4cc
> >>IAOQ[1]: __arm_lpae_unmap+0x148/0x4cc
> >>RP(r2): arm_lpae_unmap+0x34/0x6c
> >>   Backtrace:
> >>[<104871b0>] arm_lpae_unmap+0x34/0x6c
> >>[<10127944>] 0x10127944
> >>[<10168ee0>] do_one_initcall+0x128/0x1dc
> >>[<101028fc>] 0x101028fc
> >>[<10161b48>] kernel_init+0x1c/0x118
> >>[<1015d01c>] end_fault_vector+0x1c/0x24
> >>[<101762ec>] save_stack_trace+0x28/0x60
> >>
> >> Signed-off-by: Vincent Stehlé 
> >> Cc: Laurent Pinchart 
> >> Cc: Will Deacon 
> >> ---
> >>
> >>
> >> Hi,
> >>
> >> This can be seen with e.g. Linux next-20150222 on parisc with allmodconfig.
> >>
> >> Best regards,
> >>
> >> V.
> >>
> >>
> >>  drivers/iommu/Kconfig | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> >> index baa0d97..c73fd72 100644
> >> --- a/drivers/iommu/Kconfig
> >> +++ b/drivers/iommu/Kconfig
> >> @@ -22,6 +22,7 @@ config IOMMU_IO_PGTABLE
> >>
> >>  config IOMMU_IO_PGTABLE_LPAE
> >>   bool "ARMv7/v8 Long Descriptor Format"
> >> + depends on ARM
> >
> > How about ARM || COMPILE_TEST ? It can still be useful to compile the module
> > on other architectures.
> 
> COMPILE_TEST is meant for test-compiling drivers or subsystems that are not
> useful on all platforms. IMHO COMPILE_TEST kernels are still supposed to boot
> without ill effects.
> 
> Now, I understand the issue on PA-RISC is with the selftest, not with the 
> actual
> IOMMU_IO_PGTABLE_LPAE module? Then IOMMU_IO_PGTABLE_LPAE
> can depend on ARM || COMPILE_TEST (|| ARM64, cfr. Laurent's later email).
> 
> But the selftest should protect itself against running on non-ARM, either
> by making IOMMU_IO_PGTABLE_LPAE_SELFTEST depend on ARM(64)
> (without "|| COMPILE_TEST"), or by adding a check to arm_lpae_do_selftests(),
> to please all compile-testers.

Perhaps, but actually the issues reported by the self-test are *real* bugs
that I've now got fixes for. They just don't show up on arm platforms
because of different right shift behaviour.

Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] net: macb: Add big endian CPU support

[Michal Simek]

On 02/24/2015 08:39 AM, Arun Chandran wrote:
> This patch converts all __raw_readl and __raw_writel function calls
> to their corresponding readl_relaxed and writel_relaxed variants.
> 
> It also tells the driver to set ahb_endian_swp_mgmt_en bit in dma_cfg
> when the cpu is configured in big endian mode.
> 
> Signed-off-by: Arun Chandran 
> ---
>   This patch is tested on xilinx ZC702 evaluation board with
>   CONFIG_CPU_BIG_ENDIAN=y and booting NFS rootfs
>   Added on the fly IP endianness detection according to
>   comments from Michal Simek.
> ---
> ---
>  drivers/net/ethernet/cadence/macb.c | 33 +++--
>  drivers/net/ethernet/cadence/macb.h | 15 ---
>  2 files changed, 35 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/net/ethernet/cadence/macb.c 
> b/drivers/net/ethernet/cadence/macb.c
> index ad76b8e..1642911 100644
> --- a/drivers/net/ethernet/cadence/macb.c
> +++ b/drivers/net/ethernet/cadence/macb.c
> @@ -449,7 +449,7 @@ static void macb_update_stats(struct macb *bp)
>   WARN_ON((unsigned long)(end - p - 1) != (MACB_TPF - MACB_PFR) / 4);
>  
>   for(; p < end; p++, reg++)
> - *p += __raw_readl(reg);
> + *p += readl_relaxed(reg);
>  }
>  
>  static int macb_halt_tx(struct macb *bp)
> @@ -1578,6 +1578,7 @@ static u32 macb_dbw(struct macb *bp)
>  static void macb_configure_dma(struct macb *bp)
>  {
>   u32 dmacfg;
> + u32 tmp, ncr;
>  
>   if (macb_is_gem(bp)) {
>   dmacfg = gem_readl(bp, DMACFG) & ~GEM_BF(RXBS, -1L);
> @@ -1585,7 +1586,25 @@ static void macb_configure_dma(struct macb *bp)
>   if (bp->dma_burst_length)
>   dmacfg = GEM_BFINS(FBLDO, bp->dma_burst_length, dmacfg);
>   dmacfg |= GEM_BIT(TXPBMS) | GEM_BF(RXBMS, -1L);
> - dmacfg &= ~GEM_BIT(ENDIA);
> + dmacfg &= ~GEM_BIT(ENDIA_PKT);
> +
> + /* Here we use the loopback bit of net_ctrl register to detect
> +  * endianness on IP. save it first. Program swaped mode for
> +  * management descriptor accesses if writing to loop back bit
> +  * and reading it back brings no change in bit value.
> +  */
> + ncr = macb_readl(bp, NCR);
> + __raw_writel(MACB_BIT(LLB), bp->regs + MACB_NCR);
> + tmp =  __raw_readl(bp->regs + MACB_NCR);


I have tested this patch on zc702 le and be and it is working.
The comment is not fully accurate. Sorry I thought that you are using a little 
bit different
configuration than Zynq. The case I had in mind is that CPU and also IP can 
have different endianness.

The code above is not checking endianness on IP itself but CPU endianness 
because IP is in little
endian mode all the time. But the logic for detecting this on CPU is correct 
and this is what
you need to do on Zynq. You are writing big endian value to little endian 
register and read it back
to see if it was correctly written or not.

Can you please fix that comment to reflect this?

Thanks,
Michal
-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform




signature.asc
Description: OpenPGP digital signature

Re: [PATCH] OMAP: DSS: DPI: disable vt-switch on suspend/resume.

[Tomi Valkeinen]

On 25/02/15 11:37, NeilBrown wrote:
> 
> These devices do not need to return to non-graphic console
> for suspend, so disable that option.
> This means there is less work to do in the suspend/resume cycle,
> making it smoother and cheaper.
> 
> 
> Signed-off-by: NeilBrown 
> 
> --
> Hi Tomi,
>  I wonder if you would consider this patch too.  It works for me and
> removes pointless vt switching.  I assume no-one would need or want that
> switching on suspend/resume but I guess I cannot be certain.
> 
> Maybe a module-parameter could be used if there was any uncertainty.

I was just yesterday picking patches from TI's kernel on top of
mainline, and there's a similar one for omapfb and for omapdrm. Here's
for omapfb:

http://git.ti.com/android-sdk/kernel-video/commit/5915d8744c927307987b12b14bc6aa37b3bac05c?format=patch

The patch in TI's kernel claims it's needed to make resume work. You're
saying it just optimizes suspend/resume. I hadn't picked this up
earlier, because I didn't understand why pm_set_vt_switch() would be
needed to make resume work. And never had time to study it, so I still
don't know what it's about...

Looking at the drivers/tty/vt/vt_ioctl.c, it sounds to me that we should
always do pm_set_vt_switch(0), as omapdss restores everything just fine
on resume. Although it makes me wonder how it works if there are two
display controllers, one needing the switch and the other not...

Your patch does the call in a bit odd place, so I'll be queuing the
patches for omapfb and omapdrm. Or actually, maybe the call could be
done in one place in omapdss driver, as you do, but in omap_dsshw_probe().

 Tomi




signature.asc
Description: OpenPGP digital signature

Re: [PATCH v2] mmc: dw_mmc: Don't start commands while busy

[Javier Martinez Canillas]

Hello Doug,

On 02/25/2015 06:43 AM, Doug Anderson wrote:
> 
> OK, so looking through things I _think_ I found another difference
> that _might_ matter...
>

Yes it does! when adding the "sd1_bus1" the slot pinctrl I do have
the WiFi module working, thanks a lot for your help!
 
> Upstream (arch/arm/boot/dts/exynos5420-pinctrl.dtsi):
> sd1_bus1: sd1-bus-width1 {
> samsung,pins = "gpc1-3";
> ...
> };
> 
> sd1_bus4: sd1-bus-width4 {
> samsung,pins = "gpc1-4", "gpc1-5", "gpc1-6";
> ...
>};
> 
> sd1_bus8: sd1-bus-width8 {
> samsung,pins = "gpd1-4", "gpd1-5", "gpd1-6", "gpd1-7";
> ...
>};
> 
> Upsttream (arch/arm/boot/dts/exynos5420-peach-pit.dts) -- your patch:
>pinctrl-0 = <_clk>, <_cmd>, <_int>, <_bus4>,
><_bus8>, <_en>, <_rst>;
> 
> Downstream (arch/arm/boot/dts/exynos542x-pinctrl.dtsi):
> sd1_bus1: sd1-bus-width1 {
> samsung,pins = "gpc1-3";
> ...
>};
> 
> sd1_bus4: sd1-bus-width4 {
> samsung,pins = "gpc1-3", "gpc1-4", "gpc1-5", "gpc1-6";
> ...
>};
> 
> sd1_bus8: sd1-bus-width8 {
> samsung,pins = "gpd1-4", "gpd1-5", "gpd1-6", "gpd1-7";
> ...
>};
> 
> Downstream (arch/arm/boot/dts/exynos542x-peach.dtsi):
> pinctrl-0 = <_clk _cmd _int _bus4 _bus8>;
> 
> 
> Notice the difference?  You need to add "sd1_bus1" to the pinctrl for
> upstream.  The upstream DTS makes more sense.  I think I remember
> discussing this in the past (finding the conversation on the lists is
> left as an exercise to the reader) and you can in fact see that the
> upstream 5250 pinctrl file is like the downstream 5420 pinctrl...
>

Yeah, I didn't notice that there was an inconsistency in the pinctrl
defines in mainline around the different SoCs. So for 5250 you need:

* only sd1_bus1 for bus-width = <1>
* only sd1_bus4 for bus-width = <4>
* sd1_bus4 + sd1_bus8 for bus-width = <8>

and for 5440 you need:

* only sd1_bus1 for bus-width = <1>
* only sd1_bus1 + sd1_bus4 for bus-width = <4>
* sd1_bus1 + sd1_bus4 + sd1_bus8 for bus-width = <8>

Is true that 5440 is at least more consistent in the sense that you
have to add all the pins but IMHO this approach is very error prone.

I would preferred if sd1_busN included all pins needed for width N
so you only had to define a single pinctrl group but for now I'll
include "sd1_bus1" to fix the SDIO WiFi issue.

> I think the same bug is present in eMMC and SD but possibly the
> bootloader inits the pinctrl properly there?
>

Correct, I'll fix those too so the kernel does not rely on the boot
loader to setup those pins.

> 
> Crossing my fingers that's your bug, but I can't say for sure why
> adding a tons of resets would somehow make it better?
>

It is, thanks a lot again for finding this issue. I feel very dumb for
not realizing there was a difference in the included pinctrl definition.

> -Doug
>

Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH for stable] x86/spinlocks/paravirt: Fix memory corruption on unlock

[Ingo Molnar]

* Greg KH  wrote:

> > >It's:
> > >
> > >  d6abfdb20223 x86/spinlocks/paravirt: Fix memory corruption on unlock
> > 
> > Yes, This is the original patch. Please note I have taken out the
> > READ_ONCE changes from the original patch to avoid build warnings
> > mentioned below.
> > (Those READ_ONCE changes were cosmetic and was not present in the
> > previous versions)
> > 
> > >
> > >You'll also need this fix from Linus to avoid (harmless)
> > >build warnings:
> > >
> > >  dd36929720f4 kernel: make READ_ONCE() valid on const arguments
> > 
> > So this may not be absolutely necessary with the current patch.
> 
> I'd prefer to be as close as possible to the upstream 
> patch.  So if applying both of these patches will work, 
> I'd much rather do that. Changing patches when 
> backporting them to stable for no good reason than to 
> clean things up, just confuses everyone involved.
> 
> Let's keep our messy history :)

By all means!

You'll first need to cherry-pick these commits:

 927609d622a3 kernel: tighten rules for ACCESS ONCE
 c5b19946eb76 kernel: Fix sparse warning for ACCESS_ONCE
 dd36929720f4 kernel: make READ_ONCE() valid on const arguments

That's the minimum set you will need for backporting, due 
to overlapping changes to the ACCESS_ONCE() definition.

and then apply this commit:

 d6abfdb20223 x86/spinlocks/paravirt: Fix memory corruption on unlock

I've double checked that these commits will cherry-pick 
fine on top of v3.19, in that order, and that an x86-64 
defconfig+kvmconfig+PARAVIRT_SPINLOCK=y kernel builds fine 
without warnings.

I've not boot tested the changes, so if anything breaks 
it's all your fault - while if it works just fine then
I'll be glad to take credit for that.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] clk: samsung: Add CLKOUT driver support for Exynos3250 SoC.

[Inha Song]

Hi, Tomasz,

Thanks for you comment :)

On Wed, 25 Feb 2015 09:54:02 +0900
Tomasz Figa  wrote:

> Hi Inha,
> 
> Thanks for the patch. Please see my comments inline.
> 
> 2015-02-24 18:22 GMT+09:00 Inha Song :
> > This patch add CLKOUT driver support for Exynos3250 SoC.
> 
> Could you please add a little more information? I know that it might
> be pretty obvious to people familiar with this driver and/or hardware,
> but it might be a good idea to explicitly say that the CLKOUT
> controller is compatible with Exynos4, so only a new compatible string
> is added.
> 
> On the other hand, do you really need to add a new compatible string
> if an existing one can be reused? The reason why the DT property is
> called "compatible" is to be able to use the same compatible strings
> on different devices, because they are compatible, even though the
> string might have its name after only one of them. If there is some
> additional reason to add a new compatible string, please write this in
> commit message.

In in PMU document(Document/devicetree/bindgins/arm/samsung/pmu.txt),
"samsung,exynos3250-pmu" compatible string had been added.

So I add this compatible in driver.

> 
> >
> > Signed-off-by: Inha Song 
> > ---
> >  drivers/clk/samsung/clk-exynos-clkout.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/clk/samsung/clk-exynos-clkout.c 
> > b/drivers/clk/samsung/clk-exynos-clkout.c
> > index 3a7cb25..1c02e73 100644
> > --- a/drivers/clk/samsung/clk-exynos-clkout.c
> > +++ b/drivers/clk/samsung/clk-exynos-clkout.c
> > @@ -142,6 +142,8 @@ CLK_OF_DECLARE(exynos4212_clkout, 
> > "samsung,exynos4212-pmu",
> > exynos4_clkout_init);
> >  CLK_OF_DECLARE(exynos4412_clkout, "samsung,exynos4412-pmu",
> > exynos4_clkout_init);
> > +CLK_OF_DECLARE(exynos3250_clkout, "samsung,exynos3250-pmu",
> > +   exynos4_clkout_init);
> 
> Are you sure that the PMU DEBUG register on Exynos3250 is indeed
> compatible with Exynos4 and not with newer SoCs? AFAIR, the only
> difference was the number of bits (4 on Exynos4 and 5 on Exynos5?) of
> the main mux.

Exynos3250 PMU_DEBUG register is same with Exynos4. So I just use 
exynos4_clkout_init function.
But, on second thought, It looks good to add exynos3_clkout_init function for 
Exynos3 SoC even though it's the same with exynos4_clkout_init.

what is your opinion?

Best Regards,
Inha Song.

> 
> Best regards,
> Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH for stable] x86/spinlocks/paravirt: Fix memory corruption on unlock

[Christian Borntraeger]

Am 25.02.2015 um 11:08 schrieb Ingo Molnar:
> 
> * Greg KH  wrote:
> 
 It's:

  d6abfdb20223 x86/spinlocks/paravirt: Fix memory corruption on unlock
>>>
>>> Yes, This is the original patch. Please note I have taken out the
>>> READ_ONCE changes from the original patch to avoid build warnings
>>> mentioned below.
>>> (Those READ_ONCE changes were cosmetic and was not present in the
>>> previous versions)
>>>

 You'll also need this fix from Linus to avoid (harmless)
 build warnings:

  dd36929720f4 kernel: make READ_ONCE() valid on const arguments
>>>
>>> So this may not be absolutely necessary with the current patch.
>>
>> I'd prefer to be as close as possible to the upstream 
>> patch.  So if applying both of these patches will work, 
>> I'd much rather do that. Changing patches when 
>> backporting them to stable for no good reason than to 
>> clean things up, just confuses everyone involved.
>>
>> Let's keep our messy history :)
> 
> By all means!
> 
> You'll first need to cherry-pick these commits:
> 


>  927609d622a3 kernel: tighten rules for ACCESS ONCE
>  c5b19946eb76 kernel: Fix sparse warning for ACCESS_ONCE
>  dd36929720f4 kernel: make READ_ONCE() valid on const arguments

If you go before 3.19, you will also need

   230fa253df63 kernel: Provide READ_ONCE and ASSIGN_ONCE
   43239cbe79fc kernel: Change ASSIGN_ONCE(val, x) to WRITE_ONCE(x, val)


> 
> That's the minimum set you will need for backporting, due 
> to overlapping changes to the ACCESS_ONCE() definition.
> 
> and then apply this commit:
> 
>  d6abfdb20223 x86/spinlocks/paravirt: Fix memory corruption on unlock

the alternative might be to replace READ_ONCE with ACCESS_ONCE when
doing the backport.
This depends on how important you consider backporting the ACCESS_ONCE fixes.

Christian


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3 v5] kernel/fork.c: new function for max_threads

[Ingo Molnar]

* David Rientjes  wrote:

> The problem is with the structure of your patchset.  You 
> want three patches.  There's one bugfix patch, a 
> preparation patch, and a feature patch.  The bugfix patch 
> should come first so that it can be applied, possibly, to 
> stable kernels and doesn't depend on unnecessary 
> preparation patches for features.
> 
> 1/3: change the implementation of fork_init(), with 
> commentary, to avoid the divide by zero on certain 
> arches, enforce the limits, and deal with variable types 
> to prevent overflow.  This is the most urgent patch and 
> fixes a bug.
> 
> 2/3: simply extract the fixed fork_init() implementation 
> into a new set_max_threads() in preparation to use it for 
> threads-max, (hint: UINT_MAX and ignored arguments should 
> not appear in this patch),
> 
> 3/3: use the new set_max_threads() implementation for 
> threads-max with an update to the documentation.

I disagree strongly: it's better to first do low-risk 
cleanups, then do any fix and other changes.

This approach has four advantages:

  - it makes the bug fix more apparent, in the context of 
an already cleaned up code.

  - it strengthens the basic principle that 'substantial 
work should be done on clean code'.

  - on the off chance that the bugfix introduces problems 
_upstream_, it's much easier to revert in a late -rc 
kernel, than to first revert the cleanups. This 
happens in practice occasionally, so it's not a
theoretical concern.

  - the _backport_ to the -stable kernel will be more 
robust as well, because under your proposed structure, 
what gets tested upstream is the fix+cleanup, while the
backport will only be the fix, which does not get 
tested by upstream in isolation. If there's any 
(unintended) side effect of the cleanup that happens to
be an improvement, then we'll break -stable!

It is true that this makes backports a tiny bit more 
involved (2 cherry-picks instead of just one), but -stable 
kernels can backport preparatory patches just fine, and 
it's actually an advantage to have -stable kernel code 
match the upstream version as much as possible.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Nokia N900: omap aes is broken

[Pali Rohár]

On Wednesday 25 February 2015 10:50:00 Pavel Machek wrote:
> On Tue 2015-02-24 09:37:34, Tony Lindgren wrote:
> > * Pali Rohár  [150224 09:42]:
> > > On Tuesday 24 February 2015 18:25:12 Tony Lindgren wrote:
> > > > * Pali Rohár  [150218 16:03]:
> > > > > --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> > > > > +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> > > > > @@ -3938,8 +3938,9 @@ int __init
> > > > > omap3xxx_hwmod_init(void)
> > > > > 
> > > > >   if (r < 0)
> > > > >   
> > > > >   return r;
> > > > > 
> > > > > - /* Register GP-only hwmod links. */
> > > > > - if (h_gp && omap_type() == OMAP2_DEVICE_TYPE_GP) {
> > > > > +//   /* Register GP-only hwmod links. */
> > > > > +//   if (h_gp && omap_type() == OMAP2_DEVICE_TYPE_GP) {
> > > > > + if (h_gp) {
> > > > > 
> > > > >   r = omap_hwmod_register_links(h_gp);
> > > > >   if (r < 0)
> > > > >   
> > > > >   return r;
> > > > > 
> > > > > aes hwmod is defined in GP-only hwmod...
> > > > 
> > > > Doesn't this depend on the bootloader version of n900 to
> > > > work?
> > > > 
> > > > Regards,
> > > > 
> > > > Tony
> > > 
> > > Ok, it looks like second patch (omap_hwmod_3xxx_data.c)
> > > needs that aes-enabled bootloader.
> > 
> > OK we need some runtime detection somehow for what's
> > enabled..
> > 
> > > But first patch (omap3.dtsi) is needed for proper
> > > definitions. Otherwise omap-aes driver will never work on
> > > DT systems.
> > 
> > Yeah that one makes sense to me, I guess you'll do a proper
> > fix for that one.
> 
> If this depends on bootloader... would command line parameter
> be right solution here?
>   Pavel

Problem is that we need to disable AES in:

* DT file
* hwmod source code
* ... and maybe on other places too ...

So I think it make sense to check if AES is disabled in DT and 
add this check to other parts of kernel source code where needed.

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH 2/4] arm-cci: Get rid of secure transactions for PMU driver

[Suzuki K. Poulose]

On 24/02/15 21:53, Nicolas Pitre wrote:

On Tue, 24 Feb 2015, Suzuki K. Poulose wrote:


From: "Suzuki K. Poulose" 

Avoid secure transactions while probing the CCI PMU. The
existing code makes use of the Peripheral ID2 (PID2) register
to determine the revision of the CCI400, which requires a
secure transaction. This puts a limitation on the usage of the
driver on systems running non-secure Linux(e.g, ARM64).

Updated the device-tree binding for cci pmu node to add the explicit
revision number for the compatible field.

The supported strings are :
   arm,cci-400-pmu,r0
   arm,cci-400-pmu,r1
   arm,cci-400-pmu - DEPRECATED. See NOTE below

NOTE: If the revision is not mentioned, we need to probe the cci revision,
which could be fatal on a platform running non-secure. We need a reliable way
to know if we can poke the CCI registers at runtime on ARM32. We depend on
'mcpm_is_available()' when it is available. mcpm_is_available() returns true
only when there is a registered driver for mcpm. Otherwise, we assume that we
don't have secure access, and skips probing the revision number(ARM64 case).

The MCPM should figure out if it is safe to access the CCI. Unfortunately
there isn't a reliable way to indicate the same via dtb. This patch doesn't
address/change the current situation. It only deals with the CCI-PMU, leaving
the assumptions about the secure access as it has been, prior to this patch.


This is an extensive commit log about secure access issues which is nice
and appreciated.  However the patch does quite some more code reorg not
mentioned here.  Could you please move this code reorg to a separate
patch and then have a patch on top introducing these probing changes?
This should make the implication of what is said above clearer.


Sure, I will do that in the next revision. What I missed in the commit
follows (which will be added in the next version):

"This patch abstracts the representation of the CCI400 chipset
 PMU specific definitions, so that we can avoid probing the
 revision for any details. The new device-tree bindings helps to
 get the revision, without poking the CCI, and initialises the pmu with
 specific model details."

Thanks
Suzuki




Cc: devicet...@vger.kernel.org
Cc: Punit Agrawal 
Signed-off-by: Suzuki K. Poulose 
---
  Documentation/devicetree/bindings/arm/cci.txt |7 +-
  arch/arm/include/asm/arm-cci.h|   42 
  arch/arm64/include/asm/arm-cci.h  |   27 +
  drivers/bus/arm-cci.c |  138 -
  include/linux/arm-cci.h   |2 +
  5 files changed, 166 insertions(+), 50 deletions(-)
  create mode 100644 arch/arm/include/asm/arm-cci.h
  create mode 100644 arch/arm64/include/asm/arm-cci.h

diff --git a/Documentation/devicetree/bindings/arm/cci.txt 
b/Documentation/devicetree/bindings/arm/cci.txt
index f28d82b..0e4b6a7 100644
--- a/Documentation/devicetree/bindings/arm/cci.txt
+++ b/Documentation/devicetree/bindings/arm/cci.txt
@@ -94,8 +94,11 @@ specific to ARM.
   - compatible
   Usage: required
   Value type: 
- Definition: must be "arm,cci-400-pmu"
-
+ Definition: Supported strings are :
+  "arm,cci-400-pmu,r0"
+  "arm,cci-400-pmu,r1"
+  "arm,cci-400-pmu"  - DEPRECATED, permitted only 
where OS has
+   secure acces to CCI 
registers
   - reg:
   Usage: required
   Value type: Integer cells. A register entry, expressed
diff --git a/arch/arm/include/asm/arm-cci.h b/arch/arm/include/asm/arm-cci.h
new file mode 100644
index 000..b828d7a
--- /dev/null
+++ b/arch/arm/include/asm/arm-cci.h
@@ -0,0 +1,42 @@
+/*
+ * arch/arm/include/asm/arm-cci.h
+ *
+ * Copyright (C) 2015 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#ifndef __ASM_ARM_CCI_H
+#define __ASM_ARM_CCI_H
+
+#ifdef CONFIG_MCPM
+#include 
+
+/*
+ * We don't have a reliable way of detecting, whether
+ * we have access to secure-only registers, unless
+ * mcpm is registered.
+ */
+static inline int platform_has_secure_cci_access(void)
+{
+ return mcpm_is_available();
+}
+
+#else
+static inline int platform_has_secure_cci_access(void)
+{
+ return 0;
+}
+#endif
+
+#endif
diff 

Re: [PATCH] mmc: pwrseq: simplify alloc/free hooks

[Alexandre Courbot]

Chris, Ulf, gentle ping?

On Thu, Feb 12, 2015 at 1:36 PM, Alexandre Courbot  wrote:
> The alloc() and free() hooks required each pwrseq implementation to set
> host->pwrseq themselves. This is error-prone and could be done at a
> higher level if alloc() was changed to return a pointer to a struct
> mmc_pwrseq instead of an error code.
>
> This patch performs this change and moves the burden of maintaining
> host->pwrseq from the power sequence hooks to the pwrseq code.
>
> Signed-off-by: Alexandre Courbot 
> ---
> It occured to me that after this change, none of the alloc()
> implementations ever uses the host parameter. I have kept it in case
> it could be useful for other purposes, but can remove it in a v2 if
> this is deemed better by the MMC maintainers.
>
>  drivers/mmc/core/pwrseq.c| 16 
>  drivers/mmc/core/pwrseq.h|  6 --
>  drivers/mmc/core/pwrseq_emmc.c   | 11 +--
>  drivers/mmc/core/pwrseq_simple.c | 11 +--
>  4 files changed, 26 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/mmc/core/pwrseq.c b/drivers/mmc/core/pwrseq.c
> index 862356123d78..ab2129781161 100644
> --- a/drivers/mmc/core/pwrseq.c
> +++ b/drivers/mmc/core/pwrseq.c
> @@ -19,7 +19,7 @@
>
>  struct mmc_pwrseq_match {
> const char *compatible;
> -   int (*alloc)(struct mmc_host *host, struct device *dev);
> +   struct mmc_pwrseq *(*alloc)(struct mmc_host *host, struct device 
> *dev);
>  };
>
>  static struct mmc_pwrseq_match pwrseq_match[] = {
> @@ -52,6 +52,7 @@ int mmc_pwrseq_alloc(struct mmc_host *host)
> struct platform_device *pdev;
> struct device_node *np;
> struct mmc_pwrseq_match *match;
> +   struct mmc_pwrseq *pwrseq;
> int ret = 0;
>
> np = of_parse_phandle(host->parent->of_node, "mmc-pwrseq", 0);
> @@ -70,9 +71,14 @@ int mmc_pwrseq_alloc(struct mmc_host *host)
> goto err;
> }
>
> -   ret = match->alloc(host, >dev);
> -   if (!ret)
> -   dev_info(host->parent, "allocated mmc-pwrseq\n");
> +   pwrseq = match->alloc(host, >dev);
> +   if (IS_ERR(pwrseq)) {
> +   ret = PTR_ERR(host->pwrseq);
> +   goto err;
> +   }
> +
> +   host->pwrseq = pwrseq;
> +   dev_info(host->parent, "allocated mmc-pwrseq\n");
>
>  err:
> of_node_put(np);
> @@ -109,4 +115,6 @@ void mmc_pwrseq_free(struct mmc_host *host)
>
> if (pwrseq && pwrseq->ops && pwrseq->ops->free)
> pwrseq->ops->free(host);
> +
> +   host->pwrseq = NULL;
>  }
> diff --git a/drivers/mmc/core/pwrseq.h b/drivers/mmc/core/pwrseq.h
> index aba3409e8d6e..096da48c6a7e 100644
> --- a/drivers/mmc/core/pwrseq.h
> +++ b/drivers/mmc/core/pwrseq.h
> @@ -27,8 +27,10 @@ void mmc_pwrseq_post_power_on(struct mmc_host *host);
>  void mmc_pwrseq_power_off(struct mmc_host *host);
>  void mmc_pwrseq_free(struct mmc_host *host);
>
> -int mmc_pwrseq_simple_alloc(struct mmc_host *host, struct device *dev);
> -int mmc_pwrseq_emmc_alloc(struct mmc_host *host, struct device *dev);
> +struct mmc_pwrseq *mmc_pwrseq_simple_alloc(struct mmc_host *host,
> +  struct device *dev);
> +struct mmc_pwrseq *mmc_pwrseq_emmc_alloc(struct mmc_host *host,
> +struct device *dev);
>
>  #else
>
> diff --git a/drivers/mmc/core/pwrseq_emmc.c b/drivers/mmc/core/pwrseq_emmc.c
> index a2d545904fbf..9d6d2fb21796 100644
> --- a/drivers/mmc/core/pwrseq_emmc.c
> +++ b/drivers/mmc/core/pwrseq_emmc.c
> @@ -49,7 +49,6 @@ static void mmc_pwrseq_emmc_free(struct mmc_host *host)
> unregister_restart_handler(>reset_nb);
> gpiod_put(pwrseq->reset_gpio);
> kfree(pwrseq);
> -   host->pwrseq = NULL;
>  }
>
>  static struct mmc_pwrseq_ops mmc_pwrseq_emmc_ops = {
> @@ -67,14 +66,15 @@ static int mmc_pwrseq_emmc_reset_nb(struct notifier_block 
> *this,
> return NOTIFY_DONE;
>  }
>
> -int mmc_pwrseq_emmc_alloc(struct mmc_host *host, struct device *dev)
> +struct mmc_pwrseq *mmc_pwrseq_emmc_alloc(struct mmc_host *host,
> +struct device *dev)
>  {
> struct mmc_pwrseq_emmc *pwrseq;
> int ret = 0;
>
> pwrseq = kzalloc(sizeof(struct mmc_pwrseq_emmc), GFP_KERNEL);
> if (!pwrseq)
> -   return -ENOMEM;
> +   return ERR_PTR(-ENOMEM);
>
> pwrseq->reset_gpio = gpiod_get_index(dev, "reset", 0, GPIOD_OUT_LOW);
> if (IS_ERR(pwrseq->reset_gpio)) {
> @@ -92,10 +92,9 @@ int mmc_pwrseq_emmc_alloc(struct mmc_host *host, struct 
> device *dev)
> register_restart_handler(>reset_nb);
>
> pwrseq->pwrseq.ops = _pwrseq_emmc_ops;
> -   host->pwrseq = >pwrseq;
>
> -   return 0;
> +   return >pwrseq;
>  free:
> kfree(pwrseq);
> -   return ret;
> +   return ERR_PTR(ret);
>  }
> diff --git a/drivers/mmc/core/pwrseq_simple.c 
> b/drivers/mmc/core/pwrseq_simple.c
> 

Re: [PATCH 0/3 v2] e820: Fix handling of NvDIMM chips

[Ingo Molnar]

* Boaz Harrosh  wrote:

> List of patches:
>  [PATCH 1/3] e820: Don't let unknown DIMM type come out BUSY
>   The main fix
> 
>  [PATCH 2/3] resource: Add new flag IORESOURCE_WARN (64bit)
>   Warn in request_resource
> 
>  [PATCH 3A/3] e820: Add the unknown-12 Memory type (DDR3-NvDIMM)
>   Please accept this simple patch
> 
>  [PATCH 3B/3] e820: dynamic unknown-xxx names (for DDR3-NvDIMM)
>   Else we need this crap

Please also include your nvdimm driver in your next 
submission (even if that is not part of the submission 
yet), so that we can see how the driver makes use of the 
new facility.

There's quite a bit of confusion about what means what, 
people are not of one opinion, and it's easier to see and 
check the fine code instead of making assumptions.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging: android: ion: fix wrong init of dma_buf_export_info

[Dan Carpenter]

Reviewed-by: Dan Carpenter 

regards,
dan carpenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/4] arm-cci: Split the code for PMU vs driver support

[Suzuki K. Poulose]

On 24/02/15 22:17, Nicolas Pitre wrote:

On Tue, 24 Feb 2015, Suzuki K. Poulose wrote:


From: "Suzuki K. Poulose" 

This patch separates the PMU driver code from the low level
CCI driver code, and enables the CCI400-PMU for ARM64.

Introduces config options for both.

  - ARM_CCI400_MCPM - controls the low level MCPM driver code for CCI
  - ARM_CCI400_PMU  - controls the PMU driver code
  - ARM_CCI400_COMMON   - CCI400 specific details shared by MCPM
  and PMU
Changes:
  - ARM_CCI - common code for probing the CCI devices

Cc: Bartlomiej Zolnierkiewicz 
Cc: Kukjin Kim 
Cc: Abhilash Kesavan 
Cc: Liviu Dudau 
Cc: Lorenzo Pieralisi 
Cc: Sudeep Holla 
Signed-off-by: Suzuki K. Poulose 


Comments inline.


---
  arch/arm/mach-exynos/Kconfig   |2 +-
  arch/arm/mach-vexpress/Kconfig |4 ++--
  drivers/bus/Kconfig|   28 +++-
  drivers/bus/arm-cci.c  |   25 +
  include/linux/arm-cci.h|7 ++-
  5 files changed, 53 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 603820e..9bc8b4d 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -123,7 +123,7 @@ config SOC_EXYNOS5800
  config EXYNOS5420_MCPM
bool "Exynos5420 Multi-Cluster PM support"
depends on MCPM && SOC_EXYNOS5420
-   select ARM_CCI
+   select ARM_CCI400_MCPM
select ARM_CPU_SUSPEND
help
  This is needed to provide CPU and cluster power management
diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
index d6b16d9..097912f 100644
--- a/arch/arm/mach-vexpress/Kconfig
+++ b/arch/arm/mach-vexpress/Kconfig
@@ -53,7 +53,7 @@ config ARCH_VEXPRESS_CORTEX_A5_A9_ERRATA
  config ARCH_VEXPRESS_DCSCB
bool "Dual Cluster System Control Block (DCSCB) support"
depends on MCPM
-   select ARM_CCI
+   select ARM_CCI400_MCPM
help
  Support for the Dual Cluster System Configuration Block (DCSCB).
  This is needed to provide CPU and cluster power management
@@ -71,7 +71,7 @@ config ARCH_VEXPRESS_SPC
  config ARCH_VEXPRESS_TC2_PM
bool "Versatile Express TC2 power management"
depends on MCPM
-   select ARM_CCI
+   select ARM_CCI400_MCPM
select ARCH_VEXPRESS_SPC
help
  Support for CPU and cluster power management on Versatile Express
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index b99729e..91dd013 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -43,12 +43,30 @@ config OMAP_INTERCONNECT
help
  Driver to enable OMAP interconnect error handling driver.

-config ARM_CCI
-   bool "ARM CCI driver support"
-   depends on ARM && OF && CPU_V7
+config ARM_CCI400_MCPM
+   bool
+   depends on ARM && OF && CPU_V7 && MCPM


MCPM is not an actual dependency and therefore should probably not be
added here.

OK, will remove that.


You removed the prompt string therefore this will only be
selectable explicitly as needed.

This was intentional, I missed mentioning about it. Do you think we
need to change it back ?


Also, shouldn't it select ARM_CCI400_COMMON ?

Thanks for that, yes it should.



+   help
+ Low level power management driver for CCI400 cache coherent
+ interconnect for ARM platforms.
+
+config ARM_CCI400_PMU
+   bool "ARM CCI400 PMU support"
+   depends on ARM || ARM64
+   depends on HW_PERF_EVENTS
+   select ARM_CCI400_COMMON
help
- Driver supporting the CCI cache coherent interconnect for ARM
- platforms.
+ Support for PMU events monitoring on the ARM CCI cache coherent
+ interconnect.
+
+ If unsure, say N
+
+config ARM_CCI400_COMMON
+   bool
+   select ARM_CCI
+
+config ARM_CCI
+   bool


Surely you could do with only one of ARM_CCI or ARM_CCI400_COMMON?
Personally I'd go with the later as it is more precise.


The ARM_CCI now stands for CCI version agnostic code. This can be used
for adding support for the newer versions, e.g CCI-500, which I am
planning to post, after this series gets sorted out.





  config ARM_CCN
bool "ARM CCN driver support"
diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
index fe9fa46..7e330fe 100644
--- a/drivers/bus/arm-cci.c
+++ b/drivers/bus/arm-cci.c
@@ -32,6 +32,7 @@
  static void __iomem *cci_ctrl_base;
  static unsigned long cci_ctrl_phys;

+#ifdef CONFIG_ARM_CCI400_MCPM
  struct cci_nb_ports {
unsigned int nb_ace;
unsigned int nb_ace_lite;
@@ -42,12 +43,19 @@ static const struct cci_nb_ports cci400_ports = {
.nb_ace_lite = 3
  };

+#define CCI400_MCPM_PORTS_DATA (_ports)


I'm a bit uneasy with the conflation of MCPM in here.  Sure (most) MCPM
backends are the only users of this code, but that doesn't mean MCPM has
to have exclusive access.  Having "MCPM" entranched into 

Re: [PATCH for stable] x86/spinlocks/paravirt: Fix memory corruption on unlock

[Ingo Molnar]

* Christian Borntraeger  wrote:

> > By all means!
> > 
> > You'll first need to cherry-pick these commits:
> 
> >  927609d622a3 kernel: tighten rules for ACCESS ONCE
> >  c5b19946eb76 kernel: Fix sparse warning for ACCESS_ONCE
> >  dd36929720f4 kernel: make READ_ONCE() valid on const arguments
> 
> If you go before 3.19, you will also need
> 
>230fa253df63 kernel: Provide READ_ONCE and ASSIGN_ONCE
>43239cbe79fc kernel: Change ASSIGN_ONCE(val, x) to WRITE_ONCE(x, val)

The affected spinlock code went over several iterations 
post v3.18, which I think makes the spinlock change too 
risky and complex to backport so far back. So it's not 
necessay to backport these READ_ONCE() changes.

> > That's the minimum set you will need for backporting, 
> > due to overlapping changes to the ACCESS_ONCE() 
> > definition.
> > 
> > and then apply this commit:
> > 
> >  d6abfdb20223 x86/spinlocks/paravirt: Fix memory corruption on unlock
> 
> the alternative might be to replace READ_ONCE with 
> ACCESS_ONCE when doing the backport.

Doing changes to patches when doing a backport is a big 
no-no IMHO. Either there is a clean sequence of upstream 
commit IDs to cherry-pick, or it should not be backported 
in most cases.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] x86, boot: Allow 64bit EFI kernel to be loaded above 4G

[Ingo Molnar]

* Matt Fleming  wrote:

> On Sun, 22 Feb, at 07:43:48PM, Yinghai Lu wrote:
> > Index: linux-2.6/arch/x86/boot/header.S
> > ===
> > --- linux-2.6.orig/arch/x86/boot/header.S
> > +++ linux-2.6/arch/x86/boot/header.S
> > @@ -301,7 +301,7 @@ _start:
> > # Part 2 of the header, from the old setup.S
> >  
> > .ascii  "HdrS"  # header signature
> > -   .word   0x020d  # header version number (>= 0x0105)
> > +   .word   0x020e  # header version number (>= 0x0105)
> > # or else old loadlin-1.5 will fail)
> > .globl realmode_swtch
> >  realmode_swtch:.word   0, 0# default_switch, SETUPSEG
> > @@ -449,6 +449,7 @@ pref_address:   .quad LOAD_PHYSICAL_ADDR
> >  #endif
> >  init_size: .long INIT_SIZE # kernel initialization size
> >  handover_offset:   .long 0 # Filled in by build.c
> > +ext_code32_start:  .long 0 # werid one!
>   
> How about a comment like, "# Upper 32-bits of code32_start" ?

Also, in the Linux kernel we should not go about inventing 
new English words like 'werid', right?

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/3] clocksource: pxa: Fix section mismatch

[Daniel Lezcano]

From: Robert Jarzmik 

As pxa_timer_common_init() is only called in init context, mark it as
such, and quiesce the compiler warnings :
WARNING: vmlinux.o(.text.unlikely+0x45d4): Section mismatch in reference
from the function pxa_timer_common_init() to the function
.init.text:sched_clock_register()

WARNING: vmlinux.o(.text.unlikely+0x4610): Section mismatch in reference
from the function pxa_timer_common_init() to the function
.init.text:clocksource_mmio_init()

Signed-off-by: Robert Jarzmik 
Signed-off-by: Daniel Lezcano 
---
 drivers/clocksource/pxa_timer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clocksource/pxa_timer.c b/drivers/clocksource/pxa_timer.c
index 941f3f3..d9438af 100644
--- a/drivers/clocksource/pxa_timer.c
+++ b/drivers/clocksource/pxa_timer.c
@@ -163,7 +163,7 @@ static struct irqaction pxa_ost0_irq = {
.dev_id = _pxa_osmr0,
 };
 
-static void pxa_timer_common_init(int irq, unsigned long clock_tick_rate)
+static void __init pxa_timer_common_init(int irq, unsigned long 
clock_tick_rate)
 {
timer_writel(0, OIER);
timer_writel(OSSR_M0 | OSSR_M1 | OSSR_M2 | OSSR_M3, OSSR);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3] clocksource: mtk: Fix race conditions in probe code

[Daniel Lezcano]

From: Matthias Brugger 

We have two race conditions in the probe code which could lead to a null
pointer dereference in the interrupt handler.

The interrupt handler accesses the clockevent device, which may not yet be
registered.

First race condition happens when the interrupt handler gets registered before
the interrupts get disabled. The second race condition happens when the
interrupts get enabled, but the clockevent device is not yet registered.

Fix that by disabling the interrupts before we register the interrupt and enable
the interrupts after the clockevent device got registered.

Reported-by: Gongbae Park 
Signed-off-by: Matthias Brugger 
Cc: sta...@vger.kernel.org
Signed-off-by: Daniel Lezcano 
---
 drivers/clocksource/mtk_timer.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/clocksource/mtk_timer.c b/drivers/clocksource/mtk_timer.c
index 32a3d25..68ab423 100644
--- a/drivers/clocksource/mtk_timer.c
+++ b/drivers/clocksource/mtk_timer.c
@@ -224,6 +224,8 @@ static void __init mtk_timer_init(struct device_node *node)
}
rate = clk_get_rate(clk);
 
+   mtk_timer_global_reset(evt);
+
if (request_irq(evt->dev.irq, mtk_timer_interrupt,
IRQF_TIMER | IRQF_IRQPOLL, "mtk_timer", evt)) {
pr_warn("failed to setup irq %d\n", evt->dev.irq);
@@ -232,8 +234,6 @@ static void __init mtk_timer_init(struct device_node *node)
 
evt->ticks_per_jiffy = DIV_ROUND_UP(rate, HZ);
 
-   mtk_timer_global_reset(evt);
-
/* Configure clock source */
mtk_timer_setup(evt, GPT_CLK_SRC, TIMER_CTRL_OP_FREERUN);
clocksource_mmio_init(evt->gpt_base + TIMER_CNT_REG(GPT_CLK_SRC),
@@ -241,10 +241,11 @@ static void __init mtk_timer_init(struct device_node 
*node)
 
/* Configure clock event */
mtk_timer_setup(evt, GPT_CLK_EVT, TIMER_CTRL_OP_REPEAT);
-   mtk_timer_enable_irq(evt, GPT_CLK_EVT);
-
clockevents_config_and_register(>dev, rate, 0x3,
0x);
+
+   mtk_timer_enable_irq(evt, GPT_CLK_EVT);
+
return;
 
 err_clk_disable:
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] clockevents: asm9260: Fix compilation error with sparc/sparc64 allyesconfig

[Daniel Lezcano]

The Kconfig options for the asm9260 timer is wrong as it can be selected by
another platform with allyes config and thus leading to a compilation failure
as some non arch related code is pulled by the compilation.

Fix this by having the platform Kconfig to select the timer as it is done for
the others drivers.

Signed-off-by: Daniel Lezcano 
Acked-by: Guenter Roeck 
Acked-by: Oleksij Rempel 

Conflicts:
drivers/clocksource/Kconfig
---
 arch/arm/mach-asm9260/Kconfig |  2 ++
 drivers/clocksource/Kconfig   | 16 +---
 2 files changed, 7 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-asm9260/Kconfig b/arch/arm/mach-asm9260/Kconfig
index 8423be7..5224120 100644
--- a/arch/arm/mach-asm9260/Kconfig
+++ b/arch/arm/mach-asm9260/Kconfig
@@ -2,5 +2,7 @@ config MACH_ASM9260
bool "Alphascale ASM9260"
depends on ARCH_MULTI_V5
select CPU_ARM926T
+   select ASM9260_TIMER
+   select GENERIC_CLOCKEVENTS
help
  Support for Alphascale ASM9260 based platform.
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 1c2506f..68161f7 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -63,6 +63,11 @@ config VT8500_TIMER
 config CADENCE_TTC_TIMER
bool
 
+config ASM9260_TIMER
+   bool
+   select CLKSRC_MMIO
+   select CLKSRC_OF
+
 config CLKSRC_NOMADIK_MTU
bool
depends on (ARCH_NOMADIK || ARCH_U8500)
@@ -245,15 +250,4 @@ config CLKSRC_PXA
help
  This enables OST0 support available on PXA and SA-11x0
  platforms.
-
-config ASM9260_TIMER
-   bool "Alphascale ASM9260 timer driver"
-   depends on GENERIC_CLOCKEVENTS
-   select CLKSRC_MMIO
-   select CLKSRC_OF
-   default y if MACH_ASM9260
-   help
- This enables build of a clocksource and clockevent driver for
- the 32-bit System Timer hardware available on a Alphascale ASM9260.
-
 endmenu
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] mmc: dw_mmc: Make sure we only adjust the clock when power is on

[Jaehoon Chung]

Hi, Doug.

It makes sense. Looks good to me. Thanks!

Acked-by: Jaehoon Chung 

Best Regards,
Jaehoon Chung

On 02/21/2015 03:57 AM, Doug Anderson wrote:
> It appears that we can confuse things if we try to turn on the MMC
> clock when the power is off.  Adjust is so that we turn the clock on
> (using dw_mci_setup_bus) after power is all the way on and we turn the
> clock off before the power goes off.
> 
> Signed-off-by: Doug Anderson 
> ---
>  drivers/mmc/host/dw_mmc.c | 16 ++--
>  1 file changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index 4d2e3c2..43fcae1 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -1101,12 +1101,6 @@ static void dw_mci_set_ios(struct mmc_host *mmc, 
> struct mmc_ios *ios)
>   if (drv_data && drv_data->set_ios)
>   drv_data->set_ios(slot->host, ios);
>  
> - /* Slot specific timing and width adjustment */
> - dw_mci_setup_bus(slot, false);
> -
> - if (slot->host->state == STATE_WAITING_CMD11_DONE && ios->clock != 0)
> - slot->host->state = STATE_IDLE;
> -
>   switch (ios->power_mode) {
>   case MMC_POWER_UP:
>   if (!IS_ERR(mmc->supply.vmmc)) {
> @@ -1133,8 +1127,15 @@ static void dw_mci_set_ios(struct mmc_host *mmc, 
> struct mmc_ios *ios)
>   else
>   slot->host->vqmmc_enabled = true;
>   }
> +
> + /* Adjust clock / bus width after power is up */
> + dw_mci_setup_bus(slot, false);
> +
>   break;
>   case MMC_POWER_OFF:
> + /* Turn clock off before power goes down */
> + dw_mci_setup_bus(slot, false);
> +
>   if (!IS_ERR(mmc->supply.vmmc))
>   mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, 0);
>  
> @@ -1150,6 +1151,9 @@ static void dw_mci_set_ios(struct mmc_host *mmc, struct 
> mmc_ios *ios)
>   default:
>   break;
>   }
> +
> + if (slot->host->state == STATE_WAITING_CMD11_DONE && ios->clock != 0)
> + slot->host->state = STATE_IDLE;
>  }
>  
>  static int dw_mci_card_busy(struct mmc_host *mmc)
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] mmc: dw_mmc: Give a good reset after we give power

[Jaehoon Chung]

Dear, Doug.

Looks good to me. Thanks!

Acked-by: Jaehoon Chung 

Best Regards,
Jaehoon Chung

On 02/21/2015 03:57 AM, Doug Anderson wrote:
> We should give dw_mmc a good reset after we apply power.  On some
> boards vqmmc may actually be connected to the IP block in the SoC so
> it's good to reset after power comes in.
> 
> Without this we sometimes see failures enumerating cards on rk3288.
> 
> Signed-off-by: Doug Anderson 
> ---
>  drivers/mmc/host/dw_mmc.c | 27 ++-
>  1 file changed, 18 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index 43fcae1..6a712ae 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -1119,13 +1119,23 @@ static void dw_mci_set_ios(struct mmc_host *mmc, 
> struct mmc_ios *ios)
>   mci_writel(slot->host, PWREN, regs);
>   break;
>   case MMC_POWER_ON:
> - if (!IS_ERR(mmc->supply.vqmmc) && !slot->host->vqmmc_enabled) {
> - ret = regulator_enable(mmc->supply.vqmmc);
> - if (ret < 0)
> - dev_err(slot->host->dev,
> - "failed to enable vqmmc regulator\n");
> - else
> + if (!slot->host->vqmmc_enabled) {
> + if (!IS_ERR(mmc->supply.vqmmc)) {
> + ret = regulator_enable(mmc->supply.vqmmc);
> + if (ret < 0)
> + dev_err(slot->host->dev,
> + "failed to enable vqmmc\n");
> + else
> + slot->host->vqmmc_enabled = true;
> +
> + } else {
> + /* Keep track so we don't reset again */
>   slot->host->vqmmc_enabled = true;
> + }
> +
> + /* Reset our state machine after powering on */
> + dw_mci_ctrl_reset(slot->host,
> +   SDMMC_CTRL_ALL_RESET_FLAGS);
>   }
>  
>   /* Adjust clock / bus width after power is up */
> @@ -1139,10 +1149,9 @@ static void dw_mci_set_ios(struct mmc_host *mmc, 
> struct mmc_ios *ios)
>   if (!IS_ERR(mmc->supply.vmmc))
>   mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, 0);
>  
> - if (!IS_ERR(mmc->supply.vqmmc) && slot->host->vqmmc_enabled) {
> + if (!IS_ERR(mmc->supply.vqmmc) && slot->host->vqmmc_enabled)
>   regulator_disable(mmc->supply.vqmmc);
> - slot->host->vqmmc_enabled = false;
> - }
> + slot->host->vqmmc_enabled = false;
>  
>   regs = mci_readl(slot->host, PWREN);
>   regs &= ~(1 << slot->id);
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH v2] sched/rt: Use IPI to trigger RT task push migration instead of pulling

[Peter Zijlstra]

On Tue, Feb 24, 2015 at 01:39:46PM -0500, Steven Rostedt wrote:
> Index: linux-rt.git/kernel/sched/rt.c
> ===
> --- linux-rt.git.orig/kernel/sched/rt.c   2015-02-24 10:44:08.798785452 
> -0500
> +++ linux-rt.git/kernel/sched/rt.c2015-02-24 13:07:20.154735448 -0500

> @@ -1760,11 +1771,171 @@ static void push_rt_tasks(struct rq *rq)
>   ;
>  }
>  
> +static void tell_cpu_to_push(int cpu, struct rq *rq, int prio)
> +{
> + /* We should never be here if the IPI is already out. */
> + BUG_ON(rq->rt.push_csd_pending);
> +
> + rq->rt.push_csd_pending = 1;
> + rq->rt.push_csd_cpu = cpu;
> + /* Save the prio that we used to find this CPU */
> + rq->rt.push_csd_prio = prio;
> +
> + /* Make sure csd_cpu is visible before we send the ipi */
> + smp_mb();

We've architecturally defined the raising of interrupts vs the execution
of the handler to be a serializing event, therefore this full barrier is
not required.

I think we documented it in places, but I never can find it.

> +
> + smp_call_function_single_async(cpu, >rt.push_csd);

I'm confused why are you mixing smp_call_function_single_async() and
irq_work_queue_on() in the same logic?

Pick one and stick to it.

Also: 
lkml.kernel.org/r/ca+55afz492bzlfhdbkn-hygjcreup7cjmeyk3ntsfrwjppz...@mail.gmail.com

Now I would suggest you use irq_wok_queue_on() for this, consistently,
because irq_works are ran after the smp function calls complete and
therefore minimize the latency for people waiting on the (sync) smp
function calls.

> +}
> +
> +static void try_to_push_tasks(void *arg)
> +{
> + struct rt_rq *rt_rq = arg;
> + struct rq *rq, *next_rq;
> + int next_cpu = -1;
> + int next_prio = MAX_PRIO + 1;
> + int this_prio;
> + int src_prio;
> + int prio;
> + int this_cpu;
> + int success;
> + int cpu;
> +
> + /* Make sure we can see csd_cpu */
> + smp_rmb();

As per the above, interrupt are serializing, this is not needed.

> +
> + this_cpu = rt_rq->push_csd_cpu;
> +
> + /* Paranoid check */
> + BUG_ON(this_cpu != smp_processor_id());
> +
> + rq = cpu_rq(this_cpu);
> +
> + /*
> +  * If there's nothing to push here, then see if another queue
> +  * can push instead.
> +  */
> + if (!has_pushable_tasks(rq))
> + goto pass_the_ipi;
> +
> + raw_spin_lock(>lock);
> + success = push_rt_task(rq);
> + raw_spin_unlock(>lock);
> +
> + if (success)
> + goto done;
> +
> + /* Nothing was pushed, try another queue */
> +pass_the_ipi:
> +
> + /*
> +  * We use the priority that determined to send to this CPU
> +  * even if the priority for this CPU changed. This is used
> +  * to determine what other CPUs to send to, to keep from
> +  * doing a ping pong from each CPU.
> +  */
> + this_prio = rt_rq->push_csd_prio;
> + src_prio = rt_rq->highest_prio.curr;

Should we, at this point, not check if the condition that triggered the
pull request is still valid on our src cpu? No point in continuing our
IPI chain if the CPU we're looking for work for is no longer interested
in it.

> + for_each_cpu(cpu, rq->rd->rto_mask) {
> + if (this_cpu == cpu)
> + continue;
> +
> + /*
> +  * This function was called because some rq lowered its
> +  * priority. It then searched for the highest priority
> +  * rq that had overloaded tasks and sent an smp function
> +  * call to that cpu to call this function to push its
> +  * tasks. But when it got here, the task was either
> +  * already pushed, or due to affinity, could not move
> +  * the overloaded task.
> +  *
> +  * Now we need to see if there's another overloaded rq that
> +  * has an RT task that can migrate to that CPU.
> +  *
> +  * We need to be careful, we do not want to cause a ping
> +  * pong between this CPU and another CPU that has an RT task
> +  * that can migrate, but not to the CPU that lowered its
> +  * priority. Since the lowering priority CPU finds the highest
> +  * priority rq to send to, we will ignore any rq that is of 
> higher
> +  * priority than this current one. 

Maybe start a new paragraph here?

   That is, if a rq scheduled a
> +  * task of higher priority, the schedule itself would do the
> +  * push or pull then. We can safely ignore higher priority rqs.
> +  * And if there's one that is the same priority, since the CPUS
> +  * are searched in order we will ignore CPUS of the same 
> priority
> +  * unless the CPU number is greater than this CPU's number.
> +  */

I would s/CPUS/CPUs/ the plural is not part of the 

Re: [PATCH 3/3] clocksource: pxa: Fix section mismatch

[Ingo Molnar]

* Daniel Lezcano  wrote:

> From: Robert Jarzmik 
> 
> As pxa_timer_common_init() is only called in init context, mark it as
> such, and quiesce the compiler warnings :
> WARNING: vmlinux.o(.text.unlikely+0x45d4): Section mismatch in reference
> from the function pxa_timer_common_init() to the function
> .init.text:sched_clock_register()
> 
> WARNING: vmlinux.o(.text.unlikely+0x4610): Section mismatch in reference
> from the function pxa_timer_common_init() to the function
> .init.text:clocksource_mmio_init()
> 
> Signed-off-by: Robert Jarzmik 
> Signed-off-by: Daniel Lezcano 
> ---
>  drivers/clocksource/pxa_timer.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/clocksource/pxa_timer.c b/drivers/clocksource/pxa_timer.c
> index 941f3f3..d9438af 100644
> --- a/drivers/clocksource/pxa_timer.c
> +++ b/drivers/clocksource/pxa_timer.c
> @@ -163,7 +163,7 @@ static struct irqaction pxa_ost0_irq = {
>   .dev_id = _pxa_osmr0,
>  };
>  
> -static void pxa_timer_common_init(int irq, unsigned long clock_tick_rate)
> +static void __init pxa_timer_common_init(int irq, unsigned long 
> clock_tick_rate)
>  {
>   timer_writel(0, OIER);
>   timer_writel(OSSR_M0 | OSSR_M1 | OSSR_M2 | OSSR_M3, OSSR);

So this is then used indirectly by:

CLOCKSOURCE_OF_DECLARE(pxa_timer, "marvell,pxa-timer", pxa_timer_dt_init);

which should probably be marked __initdata?

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] mmc: dw_mmc: rockchip: add support MMC_CAP_RUNTIME_RESUME capability

[Jaehoon Chung]

Hi, Addy.

Acked-by: Jaehoon Chung 

Thanks!

Best Regards,
Jaehoon Chung

On 02/20/2015 11:37 AM, Addy Ke wrote:
> To support HS200 and UHS mode, mmc core will call init_card() to
> execute tuning:
> - sdio: init_card can be executed at runtime resume.
> - sd and mmc: init_card can be executed at resume or runtime resume,
>   which depends on MMC_CAP_RUNTIME_RESUME capability.
> 
> On rk3288 SoC, host will get DRTO interrupt when host send command
> to read tuning data. This will spend more than 111ms:
> drto_ms = drto_clks * 1000 / bus_hz = 111ms.
> 
> And the total tuning time will be more than 400ms.
> 
> So we should add MMC_CAP_RUNTIME_RESUME capability to execute tuning
> at runtime resume. Only if we do so, can we pass resume test.
> 
> Reviewed-by: Doug Anderson 
> Signed-off-by: Addy Ke 
> ---
> Changes in v2:
> - add this capability for all 4 slots, suggested by Doug Anderson.
> 
>  drivers/mmc/host/dw_mmc-rockchip.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/mmc/host/dw_mmc-rockchip.c 
> b/drivers/mmc/host/dw_mmc-rockchip.c
> index e2a726a..dbf166f 100644
> --- a/drivers/mmc/host/dw_mmc-rockchip.c
> +++ b/drivers/mmc/host/dw_mmc-rockchip.c
> @@ -76,12 +76,20 @@ static int dw_mci_rockchip_init(struct dw_mci *host)
>   return 0;
>  }
>  
> +/* Common capabilities of RK3288 SoC */
> +static unsigned long dw_mci_rk3288_dwmmc_caps[4] = {
> + MMC_CAP_RUNTIME_RESUME, /* emmc */
> + MMC_CAP_RUNTIME_RESUME, /* sdmmc */
> + MMC_CAP_RUNTIME_RESUME, /* sdio0 */
> + MMC_CAP_RUNTIME_RESUME, /* sdio1 */
> +};
>  static const struct dw_mci_drv_data rk2928_drv_data = {
>   .prepare_command= dw_mci_rockchip_prepare_command,
>   .init   = dw_mci_rockchip_init,
>  };
>  
>  static const struct dw_mci_drv_data rk3288_drv_data = {
> + .caps   = dw_mci_rk3288_dwmmc_caps,
>   .prepare_command= dw_mci_rockchip_prepare_command,
>   .set_ios= dw_mci_rk3288_set_ios,
>   .setup_clock= dw_mci_rk3288_setup_clock,
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH] x86, fpu: Use eagerfpu by default on all CPUs

[Borislav Petkov]

On Tue, Feb 24, 2015 at 04:07:07PM -0800, Andy Lutomirski wrote:
> I'd prefer a different partial solution: encourage everyone to clear
> the xstate before making syscalls (using e.g. vzeroall).  In fact,
> maybe user code should aggressively clear newly-unused xstate.

We don't trust userspace.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 9/8 v2] ARM OMAP2+ GPMC: fix programming/showing reserved timing parameters

[Roger Quadros]

Robert,

On 24/02/15 22:05, Robert ABEL wrote:
> GPMC_CONFIG1_i parameters CLKACTIVATIONTIME and WAITMONITORINGTIME
> have reserved values.
> Raise an error if calculated timings try to program reserved values.
> 
> GPMC_CONFIG1_i ATTCHEDDEVICEPAGELENGTH and DEVICESIZE were already checked

typo ATTCHEDDEVICEPAGELENGTH->ATTACHEDDEVICEPAGELENGTH

> when parsing the DT.
> 
> Explicitly comment invalid values on gpmc_cs_show_timings for
> -CLKACTIVATIONTIME
> -WAITMONITORINGTIME
> -DEVICESIZE
> -ATTACHEDDEVICEPAGELENGTH
> 
> Signed-off-by: Robert ABEL 
> ---
>  drivers/memory/omap-gpmc.c | 69 
> ++
>  1 file changed, 46 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
> index 6591991..cc2e6d0 100644
> --- a/drivers/memory/omap-gpmc.c
> +++ b/drivers/memory/omap-gpmc.c
> @@ -135,6 +135,8 @@
>  #define GPMC_CONFIG1_WRITETYPE_ASYNC(0 << 27)
>  #define GPMC_CONFIG1_WRITETYPE_SYNC (1 << 27)
>  #define GPMC_CONFIG1_CLKACTIVATIONTIME(val) ((val & 3) << 25)
> +/** CLKACTIVATIONTIME Max Ticks */
> +#define GPMC_CONFIG1_CLKACTIVATIONTIME_MAX 2
>  #define GPMC_CONFIG1_PAGE_LEN(val)  ((val & 3) << 23)
>  #define GPMC_CONFIG1_WAIT_READ_MON  (1 << 22)
>  #define GPMC_CONFIG1_WAIT_WRITE_MON (1 << 21)
> @@ -144,6 +146,8 @@
>  #define GPMC_CONFIG1_WAIT_PIN_SEL(val)  ((val & 3) << 16)
>  #define GPMC_CONFIG1_DEVICESIZE(val)((val & 3) << 12)
>  #define GPMC_CONFIG1_DEVICESIZE_16  GPMC_CONFIG1_DEVICESIZE(1)
> +/** DEVICESIZE Max Value */
> +#define GPMC_CONFIG1_DEVICESIZE_MAX GPMC_CONFIG1_DEVICESIZE_16

Shouldn't this be 1 instead? I'm hoping max value is without the shift
based on GPMC_CONFIG1_CLKACTIVATIONTIME_MAX.

>  #define GPMC_CONFIG1_DEVICETYPE(val)((val & 3) << 10)
>  #define GPMC_CONFIG1_DEVICETYPE_NOR GPMC_CONFIG1_DEVICETYPE(0)
>  #define GPMC_CONFIG1_MUXTYPE(val)   ((val & 3) << 8)
> @@ -394,18 +398,21 @@ static void gpmc_cs_bool_timings(int cs, const struct 
> gpmc_bool_timings *p)
>   * @reg GPMC_CS_CONFIGn register offset.
>   * @st_bit  Start Bit
>   * @end_bit End Bit. Must be >= @st_bit.
> + * @max Maximum parameter value (after optional @shift).

max should be absolute value, without the shift.

> + *  If 0, maximum is as high as @st_bit and @end_bit allow.
>   * @nameDTS node name, w/o "gpmc,"
>   * @cd  Clock Domain of timing parameter.
>   * @shift   Parameter value left shifts @shift, which is then printed 
> instead of value.
>   * @raw Raw Format Option.
>   *  raw format:  gpmc,name = 
>   *  tick format: gpmc,name =  /* x ticks */
> + *  When @max is exceeded, "invalid" is printed inside comment.
>   * @noval   Parameter values equal to 0 are not printed.
>   *
>   */
>  static int get_gpmc_timing_reg(
>   /* timing specifiers */
> - int cs, int reg, int st_bit, int end_bit,
> + int cs, int reg, int st_bit, int end_bit, int max,
>   const char *name, const enum gpmc_clk_domain cd,
>   /* value transform */
>   int shift,
> @@ -415,11 +422,15 @@ static int get_gpmc_timing_reg(
>   u32 l;
>   int nr_bits;
>   int mask;
> + bool invalid;
>  
>   l = gpmc_cs_read_reg(cs, reg);
>   nr_bits = end_bit - st_bit + 1;
>   mask = (1 << nr_bits) - 1;;
>   l = (l >> st_bit) & mask;
> + if (!max)
> + max = mask;
> + invalid = l > max;
>   if (shift)
>   l = (shift << l);
>   if (noval && (l == 0))
> @@ -429,11 +440,11 @@ static int get_gpmc_timing_reg(
>   unsigned int time_ns;
>  
>   time_ns = gpmc_clk_ticks_to_ns(l, cs, cd);
> - pr_info("gpmc,%s = <%u> /* %i ticks */\n",
> - name, time_ns, l);
> + pr_info("gpmc,%s = <%u> /* %i ticks %s*/\n",
> + name, time_ns, l, invalid ? "; invalid " : "");
>   } else {
>   /* raw format */
> - pr_info("gpmc,%s = <%u>\n", name, l);
> + pr_info("gpmc,%s = <%u>%s\n", name, l, invalid ? " /* invalid 
> */" : "");
>   }
>  
>   return l;
> @@ -443,15 +454,19 @@ static int get_gpmc_timing_reg(
>   pr_info("cs%i %s: 0x%08x\n", cs, #config, \
>   gpmc_cs_read_reg(cs, config))
>  #define GPMC_GET_RAW(reg, st, end, field) \
> - get_gpmc_timing_reg(cs, (reg), (st), (end), field, GPMC_CD_FCLK, 0, 1, 
> 0)
> + get_gpmc_timing_reg(cs, (reg), (st), (end), 0, field, GPMC_CD_FCLK, 0, 
> 1, 0)
> +#define GPMC_GET_RAW_MAX(reg, st, end, max, field) \
> + get_gpmc_timing_reg(cs, (reg), (st), (end), (max), field, GPMC_CD_FCLK, 
> 0, 1, 0)
>  #define GPMC_GET_RAW_BOOL(reg, st, end, field) \
> - get_gpmc_timing_reg(cs, (reg), (st), (end), field, GPMC_CD_FCLK, 0, 1, 
> 1)
> -#define GPMC_GET_RAW_SHIFT(reg, st, end, shift, field) \
> - get_gpmc_timing_reg(cs, (reg), (st), (end), field, GPMC_CD_FCLK, 
> (shift), 1, 1)
> + 

Re: [PATCH 3/3] clocksource: pxa: Fix section mismatch

[Daniel Lezcano]

On 02/25/2015 11:35 AM, Ingo Molnar wrote:


* Daniel Lezcano  wrote:


From: Robert Jarzmik 

As pxa_timer_common_init() is only called in init context, mark it as
such, and quiesce the compiler warnings :
WARNING: vmlinux.o(.text.unlikely+0x45d4): Section mismatch in reference
from the function pxa_timer_common_init() to the function
.init.text:sched_clock_register()

WARNING: vmlinux.o(.text.unlikely+0x4610): Section mismatch in reference
from the function pxa_timer_common_init() to the function
.init.text:clocksource_mmio_init()

Signed-off-by: Robert Jarzmik 
Signed-off-by: Daniel Lezcano 
---
  drivers/clocksource/pxa_timer.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clocksource/pxa_timer.c b/drivers/clocksource/pxa_timer.c
index 941f3f3..d9438af 100644
--- a/drivers/clocksource/pxa_timer.c
+++ b/drivers/clocksource/pxa_timer.c
@@ -163,7 +163,7 @@ static struct irqaction pxa_ost0_irq = {
.dev_id = _pxa_osmr0,
  };

-static void pxa_timer_common_init(int irq, unsigned long clock_tick_rate)
+static void __init pxa_timer_common_init(int irq, unsigned long 
clock_tick_rate)
  {
timer_writel(0, OIER);
timer_writel(OSSR_M0 | OSSR_M1 | OSSR_M2 | OSSR_M3, OSSR);


So this is then used indirectly by:

CLOCKSOURCE_OF_DECLARE(pxa_timer, "marvell,pxa-timer", pxa_timer_dt_init);

which should probably be marked __initdata?



Sorry, I miss the point. What should be marked __initdata ?


--
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH] x86, fpu: Use eagerfpu by default on all CPUs

[Ingo Molnar]

* Andy Lutomirski  wrote:

> > I'm a big fan of simplifying things, but.
> >
> > SIMD registers were growing in x86, and they are going 
> > to grow again, this time four-fold in Intel MIC: from 
> > sixteen 256-bit registers to thirty two 512-bit 
> > registers.
> >
> > That's 2 kbytes of data. Just moving this data out 
> > to/from memory will take some time.
> >
> > And some people talk about 1024-bit registers 
> > already...
> >
> > Let's not completely remove lazy FPU saving code just 
> > yet. Maybe we'll be forced to reinstate it.
> 
> I'd prefer a different partial solution: encourage 
> everyone to clear the xstate before making syscalls 
> (using e.g. vzeroall).  In fact, maybe user code should 
> aggressively clear newly-unused xstate.

Also, xstate has various compaction features and could grow 
new ones in the future as well, should the xsave area 
become overly sparse: see xstate_comp_*[] et al in 
arch/x86/kernel/xsave.c.

This is the better, hardware driven, synchronous 
alternative to lazy, async register state save/restore, as 
it gets us similar benefits of not saving/restoring unused 
space, but avoids any async trap overhead.

Also ... with more and wider vector CPU registers context 
switches between different sets of registers are going to 
be inevitably more expensive, no matter what.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] clocksource: pxa: Fix section mismatch

[Ingo Molnar]

* Daniel Lezcano  wrote:

> On 02/25/2015 11:35 AM, Ingo Molnar wrote:
> >
> >* Daniel Lezcano  wrote:
> >
> >>From: Robert Jarzmik 
> >>
> >>As pxa_timer_common_init() is only called in init context, mark it as
> >>such, and quiesce the compiler warnings :
> >>WARNING: vmlinux.o(.text.unlikely+0x45d4): Section mismatch in reference
> >>from the function pxa_timer_common_init() to the function
> >>.init.text:sched_clock_register()
> >>
> >>WARNING: vmlinux.o(.text.unlikely+0x4610): Section mismatch in reference
> >>from the function pxa_timer_common_init() to the function
> >>.init.text:clocksource_mmio_init()
> >>
> >>Signed-off-by: Robert Jarzmik 
> >>Signed-off-by: Daniel Lezcano 
> >>---
> >>  drivers/clocksource/pxa_timer.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >>diff --git a/drivers/clocksource/pxa_timer.c 
> >>b/drivers/clocksource/pxa_timer.c
> >>index 941f3f3..d9438af 100644
> >>--- a/drivers/clocksource/pxa_timer.c
> >>+++ b/drivers/clocksource/pxa_timer.c
> >>@@ -163,7 +163,7 @@ static struct irqaction pxa_ost0_irq = {
> >>.dev_id = _pxa_osmr0,
> >>  };
> >>
> >>-static void pxa_timer_common_init(int irq, unsigned long clock_tick_rate)
> >>+static void __init pxa_timer_common_init(int irq, unsigned long 
> >>clock_tick_rate)
> >>  {
> >>timer_writel(0, OIER);
> >>timer_writel(OSSR_M0 | OSSR_M1 | OSSR_M2 | OSSR_M3, OSSR);
> >
> >So this is then used indirectly by:
> >
> >CLOCKSOURCE_OF_DECLARE(pxa_timer, "marvell,pxa-timer", pxa_timer_dt_init);
> >
> >which should probably be marked __initdata?
> 
> 
> Sorry, I miss the point. What should be marked __initdata ?

so CLOCKSOURCE_OF_DECLARE() defines 'struct of_device_id' 
entries, right? Those, if they are only used during 
initialization, should be marked __initdata.

Or are they mixed use?

Thnks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH] x86, fpu: Use eagerfpu by default on all CPUs

[Ingo Molnar]

* Borislav Petkov  wrote:

> On Tue, Feb 24, 2015 at 04:07:07PM -0800, Andy Lutomirski wrote:
>
> > I'd prefer a different partial solution: encourage 
> > everyone to clear the xstate before making syscalls 
> > (using e.g. vzeroall).  In fact, maybe user code should 
> > aggressively clear newly-unused xstate.
> 
> We don't trust userspace.

We certainly don't, but in this case it's a performance 
optimization detail: if user-space clears unused xstate in 
a way that the CPU recognizes it (for example VZEROALL) 
then it might get faster context switches.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch v2 for-4.0] mm, thp: really limit transparent hugepage allocation to local node

[Vlastimil Babka]

On 02/25/2015 12:24 AM, David Rientjes wrote:

From: Greg Thelen 

Commit 077fcf116c8c ("mm/thp: allocate transparent hugepages on local
node") restructured alloc_hugepage_vma() with the intent of only
allocating transparent hugepages locally when there was not an effective
interleave mempolicy.

alloc_pages_exact_node() does not limit the allocation to the single
node, however, but rather prefers it.  This is because __GFP_THISNODE is
not set which would cause the node-local nodemask to be passed.  Without
it, only a nodemask that prefers the local node is passed.


Oops, good catch.
But I believe we have the same problem with khugepaged_alloc_page(), 
rendering the recent node determination and zone_reclaim strictness 
patches partially useless.


Then I start to wonder about other alloc_pages_exact_node() users. Some 
do pass __GFP_THISNODE, others not - are they also mistaken? I guess the 
function is a misnomer - when I see "exact_node", I expect the 
__GFP_THISNODE behavior.


I think to avoid such hidden catches, we should create 
alloc_pages_preferred_node() variant, change the exact_node() variant to 
pass __GFP_THISNODE, and audit and adjust all callers accordingly.


Also, you pass __GFP_NOWARN but that should be covered by GFP_TRANSHUGE 
already. Of course, nothing guarantees that hugepage == true implies 
that gfp == GFP_TRANSHUGE... but current in-tree callers conform to that.



Fix this by passing __GFP_THISNODE and falling back to small pages when
the allocation fails.

Fixes: 077fcf116c8c ("mm/thp: allocate transparent hugepages on local node")
Signed-off-by: Greg Thelen 
Signed-off-by: David Rientjes 
---
  v2: GFP_THISNODE actually defers compaction and reclaim entirely based on
  the combination of gfp flags.  We want to try compaction and reclaim,
  so only set __GFP_THISNODE.  We still set __GFP_NOWARN to suppress
  oom warnings in the kernel log when we can simply fallback to small
  pages.

  mm/mempolicy.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/mm/mempolicy.c b/mm/mempolicy.c
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -1985,7 +1985,10 @@ retry_cpuset:
nmask = policy_nodemask(gfp, pol);
if (!nmask || node_isset(node, *nmask)) {
mpol_cond_put(pol);
-   page = alloc_pages_exact_node(node, gfp, order);
+   page = alloc_pages_exact_node(node, gfp |
+   __GFP_THISNODE |
+   __GFP_NOWARN,
+ order);
goto out;
}
}



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 03/24] mm: use __SetPageSwapBacked and don't ClearPageSwapBacked

[Mel Gorman]

On Fri, Feb 20, 2015 at 07:56:15PM -0800, Hugh Dickins wrote:
> Commit 07a427884348 ("mm: shmem: avoid atomic operation during
> shmem_getpage_gfp") rightly replaced one instance of SetPageSwapBacked
> by __SetPageSwapBacked, pointing out that the newly allocated page is
> not yet visible to other users (except speculative get_page_unless_zero-
> ers, who may not update page flags before their further checks).
> 
> That was part of a series in which Mel was focused on tmpfs profiles:
> but almost all SetPageSwapBacked uses can be so optimized, with the
> same justification.  And remove the ClearPageSwapBacked from
> read_swap_cache_async()'s and zswap_get_swap_cache_page()'s error
> paths: it's not an error to free a page with PG_swapbacked set.
> 
> (There's probably scope for further __SetPageFlags in other places,
> but SwapBacked is the one I'm interested in at the moment.)
> 
> Signed-off-by: Hugh Dickins 
> ---
>  mm/migrate.c|6 +++---
>  mm/rmap.c   |2 +-
>  mm/shmem.c  |4 ++--
>  mm/swap_state.c |3 +--
>  mm/zswap.c  |3 +--
>  5 files changed, 8 insertions(+), 10 deletions(-)
> 
> 
> --- thpfs.orig/mm/shmem.c 2015-02-08 18:54:22.0 -0800
> +++ thpfs/mm/shmem.c  2015-02-20 19:33:35.676074594 -0800
> @@ -987,8 +987,8 @@ static int shmem_replace_page(struct pag
>   flush_dcache_page(newpage);
>  
>   __set_page_locked(newpage);
> + __SetPageSwapBacked(newpage);
>   SetPageUptodate(newpage);
> - SetPageSwapBacked(newpage);
>   set_page_private(newpage, swap_index);
>   SetPageSwapCache(newpage);
>  

It's clear why you did this but ...

> @@ -1177,8 +1177,8 @@ repeat:
>   goto decused;
>   }
>  
> - __SetPageSwapBacked(page);
>   __set_page_locked(page);
> + __SetPageSwapBacked(page);
>   if (sgp == SGP_WRITE)
>   __SetPageReferenced(page);
>  

It's less clear why this was necessary. I don't think it causes any
problems though so

Reviewed-by: Mel Gorman 

-- 
Mel Gorman
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] arm64: mediatek: Add config option for mt8173.

[Arnd Bergmann]

On Wednesday 25 February 2015 17:07:22 Yingjoe Chen wrote:
> On Tue, 2015-01-27 at 15:13 +0800, Hongzhou Yang wrote:
> > From: Hongzhou Yang 
> > 
> > The upcoming MTK pinctrl driver have a big pin table for each SoC,
> > and we don't want to bloat the kernel binary if we don't need it.
> > Add config options so we can build for one SoC only.
> > 
> > Signed-off-by: Hongzhou Yang 
> > ---
> >  arch/arm64/Kconfig | 6 ++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index e627ead..6213dac 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -151,9 +151,15 @@ menu "Platform selection"
> >  config ARCH_MEDIATEK
> >   bool "Mediatek MT65xx & MT81xx ARMv8 SoC"
> >   select ARM_GIC
> > + select PINCTRL
> >   help
> > Support for Mediatek MT65xx & MT81xx ARMv8 SoCs
> >  
> > +config MACH_MT8173
> > + bool "Mediatek 8173 Soc Supprt"
> > + depends on ARCH_MEDIATEK
> > + default y
> > +
> >  config ARCH_SEATTLE
> >   bool "AMD Seattle SoC Family"
> >   help
> 
> Hi Arnd/Matthias,
> 
> Any comments on this patch?

Hi Joe,

Actually I just commented on a similar patch from Samsung the other
day, and I think we should make a more general decision about these:

I would rather see only one Kconfig option per SoC family and use
ARCH_MEDIATEK without any MACH_* options. We can have other options
for e.g. networking chips from Mediatek that are not closely related
but I would group all the phone and tablet chips under one option
here. Same for the other vendors of course.

Any other opinions?

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/3] net: Linn Ethernet Packet Sniffer driver

[Stathis Voukelatos]

Hi Richard,

On 25/02/15 09:50, Richard Cochran wrote:


The Linux kernel already fully supports this kind of application via
the SIOCSHWTSTAMP, SO_TIMESTAMPING, and PHC mechanisms.  We certainly
don't need another another interface just for someone's warped
hardware design.

I suggest that you find a way to make your HW work within the existing
frame work.


The driver already uses that framework for returning timestamps to user 
space. It does not introduce any new interface.





The interface needs to be public so that a user-space application
can program a command string that will match packets that belong to
the audio stream of interest, for this example.


Let the user program simply use a BPF for that.


In addition returning just a timestamp would not be enough in many
cases. In the audio streaming use case mentioned above some
additional
bytes from the packet payload need to be returned (with Copy
commands) in order to associate the timestamp with a certain point
in the audio stream.


The time stamp is *already* associated with a particular frame.

Just tell your driver to program the hardware to:

1. time stamp every frame
2. deliver every frame

Thats all you need.



The H/W could not support that:
We have a "Match/Stamp" command, so the packet byte needs to match the 
value following the command, in order for a timestamp to be generated, 
otherwise the packet is dropped.
In addition, due to FIFO size limitations up to 128 bytes (including the 
timestamp) can be returned (through Copy commands) from each packet.


The module was designed to be able to configure it to sniff packets 
belonging to a certain application level stream and from each matching 
packet return a timestamp and some bytes (from eg. the application layer 
protocol header) that would be useful to the application.


BPF could accomplish that too, but timestamps will not be as accurate
without H/W support.

I understand that the device needs to be configured with a proprietary
command stream, but all interfacing with user-space is done using 
existing frameworks (AF_PACKET, SIOCSHWTSTAMP, cmsg)



Actually, that is how the H/W works. Each Match command is followed by
a data value which must match the packet data byte at the corresponding
location. If there is no match processing of the packet stops.


And just what is the "corresponding location"?


The command string is made up of a sequence of  pairs. Take 
this for example: {0x00, 0x00, 0x01, 0x55, 0x02, 0x00, 0x04, 0x00}.
First command is Don't Care (0x00), ie 1st byte of Ethernet frame is 
just skipped.
Second command is Match (0x01), ie if the 2nd byte of the Ethernet frame 
is 0x55 processing continues otherwise packet is dropped.
Third command is Copy (0x02), ie 3rd byte of the packet is copied to the 
H/W FIFO to be returned to the user
Fourth command is Copy/Done (0x04), ie 4th packet byte is also copied to 
the FIFO and processing stops.

Then an IRQ is generated, data (2 bytes) are read from the FIFO and
delivered through an AF_PACKET socket.

In v4 of the patch I tried to improve the documentation of some of these 
points.


Thanks,
Richard



Thanks,
Stathis

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] clocksource: pxa: Fix section mismatch

[Daniel Lezcano]

On 02/25/2015 11:48 AM, Ingo Molnar wrote:


* Daniel Lezcano  wrote:


On 02/25/2015 11:35 AM, Ingo Molnar wrote:


* Daniel Lezcano  wrote:


From: Robert Jarzmik 

As pxa_timer_common_init() is only called in init context, mark it as
such, and quiesce the compiler warnings :
WARNING: vmlinux.o(.text.unlikely+0x45d4): Section mismatch in reference

>from the function pxa_timer_common_init() to the function

.init.text:sched_clock_register()

WARNING: vmlinux.o(.text.unlikely+0x4610): Section mismatch in reference

>from the function pxa_timer_common_init() to the function

.init.text:clocksource_mmio_init()

Signed-off-by: Robert Jarzmik 
Signed-off-by: Daniel Lezcano 
---
  drivers/clocksource/pxa_timer.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clocksource/pxa_timer.c b/drivers/clocksource/pxa_timer.c
index 941f3f3..d9438af 100644
--- a/drivers/clocksource/pxa_timer.c
+++ b/drivers/clocksource/pxa_timer.c
@@ -163,7 +163,7 @@ static struct irqaction pxa_ost0_irq = {
.dev_id = _pxa_osmr0,
  };

-static void pxa_timer_common_init(int irq, unsigned long clock_tick_rate)
+static void __init pxa_timer_common_init(int irq, unsigned long 
clock_tick_rate)
  {
timer_writel(0, OIER);
timer_writel(OSSR_M0 | OSSR_M1 | OSSR_M2 | OSSR_M3, OSSR);


So this is then used indirectly by:

CLOCKSOURCE_OF_DECLARE(pxa_timer, "marvell,pxa-timer", pxa_timer_dt_init);

which should probably be marked __initdata?



Sorry, I miss the point. What should be marked __initdata ?


so CLOCKSOURCE_OF_DECLARE() defines 'struct of_device_id'
entries, right? Those, if they are only used during
initialization, should be marked __initdata.

Or are they mixed use?


Ah, ok. Thanks for the clarification. I thought there was an issue with 
the patch and I was hanging the PR.


Let me look in details.


--
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] net: macb: Add big endian CPU support

[Arun Chandran]

On Wed, Feb 25, 2015 at 3:32 PM, Michal Simek  wrote:
> On 02/24/2015 08:39 AM, Arun Chandran wrote:
>> This patch converts all __raw_readl and __raw_writel function calls
>> to their corresponding readl_relaxed and writel_relaxed variants.
>>
>> It also tells the driver to set ahb_endian_swp_mgmt_en bit in dma_cfg
>> when the cpu is configured in big endian mode.
>>
>> Signed-off-by: Arun Chandran 
>> ---
>>   This patch is tested on xilinx ZC702 evaluation board with
>>   CONFIG_CPU_BIG_ENDIAN=y and booting NFS rootfs
>>   Added on the fly IP endianness detection according to
>>   comments from Michal Simek.
>> ---
>> ---
>>  drivers/net/ethernet/cadence/macb.c | 33 +++--
>>  drivers/net/ethernet/cadence/macb.h | 15 ---
>>  2 files changed, 35 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/cadence/macb.c 
>> b/drivers/net/ethernet/cadence/macb.c
>> index ad76b8e..1642911 100644
>> --- a/drivers/net/ethernet/cadence/macb.c
>> +++ b/drivers/net/ethernet/cadence/macb.c
>> @@ -449,7 +449,7 @@ static void macb_update_stats(struct macb *bp)
>>   WARN_ON((unsigned long)(end - p - 1) != (MACB_TPF - MACB_PFR) / 4);
>>
>>   for(; p < end; p++, reg++)
>> - *p += __raw_readl(reg);
>> + *p += readl_relaxed(reg);
>>  }
>>
>>  static int macb_halt_tx(struct macb *bp)
>> @@ -1578,6 +1578,7 @@ static u32 macb_dbw(struct macb *bp)
>>  static void macb_configure_dma(struct macb *bp)
>>  {
>>   u32 dmacfg;
>> + u32 tmp, ncr;
>>
>>   if (macb_is_gem(bp)) {
>>   dmacfg = gem_readl(bp, DMACFG) & ~GEM_BF(RXBS, -1L);
>> @@ -1585,7 +1586,25 @@ static void macb_configure_dma(struct macb *bp)
>>   if (bp->dma_burst_length)
>>   dmacfg = GEM_BFINS(FBLDO, bp->dma_burst_length, 
>> dmacfg);
>>   dmacfg |= GEM_BIT(TXPBMS) | GEM_BF(RXBMS, -1L);
>> - dmacfg &= ~GEM_BIT(ENDIA);
>> + dmacfg &= ~GEM_BIT(ENDIA_PKT);
>> +
>> + /* Here we use the loopback bit of net_ctrl register to detect
>> +  * endianness on IP. save it first. Program swaped mode for
>> +  * management descriptor accesses if writing to loop back bit
>> +  * and reading it back brings no change in bit value.
>> +  */
>> + ncr = macb_readl(bp, NCR);
>> + __raw_writel(MACB_BIT(LLB), bp->regs + MACB_NCR);
>> + tmp =  __raw_readl(bp->regs + MACB_NCR);
>
>
> I have tested this patch on zc702 le and be and it is working.
> The comment is not fully accurate. Sorry I thought that you are using a 
> little bit different
> configuration than Zynq. The case I had in mind is that CPU and also IP can 
> have different endianness.
>
> The code above is not checking endianness on IP itself but CPU endianness 
> because IP is in little

Ok. I will change the comment.

> endian mode all the time. But the logic for detecting this on CPU is correct 
> and this is what
> you need to do on Zynq. You are writing big endian value to little endian 
> register and read it back
> to see if it was correctly written or not.

Just curious; will the same code work without change on a CPU with Big
endian IP?
(ie. If zynq hardware comes with only one change; IP configured in BE;
 will the driver be needing further changes?)

--Arun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] clocksource: pxa: Fix section mismatch

[Ingo Molnar]

* Daniel Lezcano  wrote:

> On 02/25/2015 11:48 AM, Ingo Molnar wrote:
> >
> >* Daniel Lezcano  wrote:
> >
> >>On 02/25/2015 11:35 AM, Ingo Molnar wrote:
> >>>
> >>>* Daniel Lezcano  wrote:
> >>>
> From: Robert Jarzmik 
> 
> As pxa_timer_common_init() is only called in init context, mark it as
> such, and quiesce the compiler warnings :
> WARNING: vmlinux.o(.text.unlikely+0x45d4): Section mismatch in reference
> from the function pxa_timer_common_init() to the function
> .init.text:sched_clock_register()
> 
> WARNING: vmlinux.o(.text.unlikely+0x4610): Section mismatch in reference
> from the function pxa_timer_common_init() to the function
> .init.text:clocksource_mmio_init()
> 
> Signed-off-by: Robert Jarzmik 
> Signed-off-by: Daniel Lezcano 
> ---
>   drivers/clocksource/pxa_timer.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/clocksource/pxa_timer.c 
> b/drivers/clocksource/pxa_timer.c
> index 941f3f3..d9438af 100644
> --- a/drivers/clocksource/pxa_timer.c
> +++ b/drivers/clocksource/pxa_timer.c
> @@ -163,7 +163,7 @@ static struct irqaction pxa_ost0_irq = {
>   .dev_id = _pxa_osmr0,
>   };
> 
> -static void pxa_timer_common_init(int irq, unsigned long clock_tick_rate)
> +static void __init pxa_timer_common_init(int irq, unsigned long 
> clock_tick_rate)
>   {
>   timer_writel(0, OIER);
>   timer_writel(OSSR_M0 | OSSR_M1 | OSSR_M2 | OSSR_M3, OSSR);
> >>>
> >>>So this is then used indirectly by:
> >>>
> >>>CLOCKSOURCE_OF_DECLARE(pxa_timer, "marvell,pxa-timer", pxa_timer_dt_init);
> >>>
> >>>which should probably be marked __initdata?
> >>
> >>
> >>Sorry, I miss the point. What should be marked __initdata ?
> >
> >so CLOCKSOURCE_OF_DECLARE() defines 'struct of_device_id'
> >entries, right? Those, if they are only used during
> >initialization, should be marked __initdata.
> >
> >Or are they mixed use?
> 
> Ah, ok. Thanks for the clarification. I thought there was 
> an issue with the patch and I was hanging the PR.

No, the patch is fine I think, I was just double checking 
it and noticed that nobody really marks 
CLOCKSOURCE_OF_DECLARE() as __initdata in practice.

> Let me look in details.

might not be worth doing, and it will quickly bitrot 
anyway, as new drivers might not pick it up.

Plus, should that structure ever get modularized, it will 
have to be removed again.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [lm-sensors] [PATCH 1/4] kernel.h: add find_closest() macro

[Bartosz Golaszewski]

2015-02-24 21:51 GMT+01:00 Guenter Roeck :
> I think the lm85 conversion actually introduces a bug with such an
> off-by-one mistake. And if it doesn't, there is still a unexplained
> and not easy to understand '-1' in one of the calls to find_closest().
>
> So the question is if the new code really improves the situation in that
> respect.

Yes, it's a mistake. I couldn't test this one and missed this '-1'.
Sorry for that.

As for the size comparisons - at first glance it seems as if it adds bloat:

ina2xx:
add/remove: 0/0 grow/shrink: 1/0 up/down: 24/0 (24)
function old new   delta
ina226_set_interval  296 320 +24

lm85:
add/remove: 0/0 grow/shrink: 3/0 up/down: 72/0 (72)
function old new   delta
set_temp_auto_temp_min   364 388 +24
set_temp_auto_temp_max   336 360 +24
set_pwm_freq 284 308 +24

w83795:
add/remove: 0/0 grow/shrink: 1/0 up/down: 16/0 (16)
function old new   delta
store_pwm496 512 +16

But this actually comes from DIV_ROUND_CLOSEST() since replacing it
with a simple '/ 2' gives different results:

ina2xx.ko:
add/remove: 0/0 grow/shrink: 1/0 up/down: 6/0 (6)
function old new   delta
__UNIQUE_ID_vermagic0 73  79  +6

lm85.ko:
add/remove: 0/0 grow/shrink: 1/0 up/down: 6/0 (6)
function old new   delta
__UNIQUE_ID_vermagic0 73  79  +6

w83795.ko:
add/remove: 0/0 grow/shrink: 2/0 up/down: 14/0 (14)
function old new   delta
store_pwm496 504  +8
__UNIQUE_ID_vermagic0 73  79  +6

The idea however was to remove duplicated operations from source files
and prevent off-by-one bugs (how ironic the lm85 patch...), not really
to reduce size.

Bart
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/8 v2] ARM OMAP2+ GPMC: don't undef DEBUG

[Roger Quadros]

On 24/02/15 22:05, Robert ABEL wrote:
> OMAP2+ GPMC driver undefines DEBUG, which makes it unnecessarily
> hard to turn DEBUG on. Remove the offending lines.
> 
> Signed-off-by: Robert ABEL 

Acked-by: Roger Quadros 

cheers,
-roger

> ---
>  drivers/memory/omap-gpmc.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
> index 24696f5..5cabac8 100644
> --- a/drivers/memory/omap-gpmc.c
> +++ b/drivers/memory/omap-gpmc.c
> @@ -12,8 +12,6 @@
>   * it under the terms of the GNU General Public License version 2 as
>   * published by the Free Software Foundation.
>   */
> -#undef DEBUG
> -
>  #include 
>  #include 
>  #include 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/3] Add MIPS CDMM bus support

[James Hogan]

Hi,

On 02/02/15 11:45, James Hogan wrote:
> This patchset adds basic support for the MIPS Common Device Memory Map
> Memory (CDMM) region in the form of a bus in the standard Linux device
> model.

It'd be great to get these patches upstream for v4.1 via the MIPS tree
along with my other two related patchsets (MIPS: Allow shared IRQ for
timer & perf counter, and Add MIPS EJTAG Fast Debug Channel TTY driver).

Greg: Since this is a new bus I suspect I need your Ack/Review first?

Btw, more info about CDMM can be found here:
http://www.linux-mips.org/wiki/CDMM

And a git branch containing the latest version of all 3 patchsets
(basically just rebased on v4.0-rc1 to resolve conflicts) can be found
here:
git://git.kernel.org/pub/scm/linux/kernel/git/jhogan/mips.git fdc

Thanks
James

> 
> Since the CDMM region is a feature of the MIPS architecture (since
> around MIPSr2) the first patch adds the necessary definitions and
> probing to arch/mips.
> 
> The second patch adds the actual bus driver (see that patch for lots
> more info). 
> 
> The final patch just enables CDMM to work on Malta.
> 
> Futher patches will follow soon to add TTY/Console/KGDB support for the
> EJTAG Fast Debug Channel (FDC) device which is found in the CDMM region.
> 
> Changes in v2:
> - Fix typo in definition of MIPS_CPU_CDMM, s/0ll/ull (Maciej).
> - Fix some checkpatch errors.
> - Correct CDMM name in various places. It is "Common Device Memory Map",
>   rather than "Common Device Mapped Memory" (which for some reason had
>   got stuck in my head).
> 
> Cc: Ralf Baechle 
> Cc: Greg Kroah-Hartman 
> Cc: linux-m...@linux-mips.org
> 
> James Hogan (3):
>   MIPS: Add arch CDMM definitions and probing
>   MIPS: Add CDMM bus support
>   MIPS: Malta: Implement mips_cdmm_phys_base()
> 
>  arch/mips/include/asm/cdmm.h |  87 +
>  arch/mips/include/asm/cpu-features.h |   4 +
>  arch/mips/include/asm/cpu.h  |   1 +
>  arch/mips/include/asm/mipsregs.h |  11 +
>  arch/mips/kernel/cpu-probe.c |   2 +
>  arch/mips/mti-malta/malta-memory.c   |   7 +
>  drivers/bus/Kconfig  |  13 +
>  drivers/bus/Makefile |   1 +
>  drivers/bus/mips_cdmm.c  | 711 
> +++
>  include/linux/mod_devicetable.h  |   8 +
>  scripts/mod/devicetable-offsets.c|   3 +
>  scripts/mod/file2alias.c |  16 +
>  12 files changed, 864 insertions(+)
>  create mode 100644 arch/mips/include/asm/cdmm.h
>  create mode 100644 drivers/bus/mips_cdmm.c
> 



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 0/9] Add MIPS EJTAG Fast Debug Channel TTY driver

[James Hogan]

Hi,

On 29/01/15 11:14, James Hogan wrote:
> This patchset adds a TTY, console, and KGDB driver for the MIPS Fast
> Debug Channel (FDC) hardware, for communicating with a debugger via an
> EJTAG probe. 16 TTY ports are created per FDC device, corresponding to
> the 16 FDC channels. Each VPE usually has its own FDC instance.

It'd be great to get these patches upstream for v4.1 via the MIPS tree
along with my other two patchsets it depends on ([v2] Add MIPS CDMM bus
support, and MIPS: Allow shared IRQ for timer & perf counter), so
Acks/Reviews from TTY maintainers in particular would be really
appreciated.

Btw, more info about the FDC can be found here:
http://www.linux-mips.org/wiki/FDC

And a git branch containing the latest version of all 3 patchsets
(basically just rebased on v4.0-rc1 to resolve conflicts) can be found
here:
git://git.kernel.org/pub/scm/linux/kernel/git/jhogan/mips.git fdc

Thanks
James

> 
> This patchset depends on my recent CDMM bus patchset (the FDC is in the
> per-CPU CDMM region), and my recent MIPS timer & perf counter IRQ
> sharing patchset (the FDC IRQ is a local CPU IRQ which may similarly
> share CPU IRQ lines with the other local IRQs).
> 
> Patches 1 to 6 add the necessary architecture bits for the FDC
> interrupt, and a workaround in the MIPS idle code to avoid the wait
> instruction on certain cores if FDC driver is enabled.
> 
> Finally patches 7-9 add the main TTY/console driver, wire up some early
> console code, and implement KGDB operations & magic sysrq.
> 
> Cc: Ralf Baechle 
> Cc: Andrew Bresticker 
> Cc: Thomas Gleixner 
> Cc: Jason Cooper 
> Cc: Greg Kroah-Hartman 
> Cc: Jiri Slaby 
> Cc: Jason Wessel 
> Cc: linux-m...@linux-mips.org
> Cc: kgdb-bugrep...@lists.sourceforge.net
> 
> James Hogan (9):
>   MIPS: Add architectural FDC IRQ fields
>   MIPS: Read CPU IRQ line that FDC to routed to
>   irqchip: mips-gic: Don't treat FDC IRQ as percpu devid
>   irqchip: mips-gic: Add function for retrieving FDC IRQ
>   MIPS: Malta: Implement get_c0_fdc_int()
>   MIPS: idle: Workaround wait + FDC problems
>   tty: Add MIPS EJTAG Fast Debug Channel TTY driver
>   MIPS, ttyFDC: Add early FDC console support
>   ttyFDC: Implement KGDB IO operations.
> 
>  arch/mips/include/asm/cdmm.h |   11 +
>  arch/mips/include/asm/irq.h  |3 +
>  arch/mips/include/asm/mipsregs.h |4 +
>  arch/mips/kernel/idle.c  |   13 +-
>  arch/mips/kernel/setup.c |2 +
>  arch/mips/kernel/traps.c |   11 +
>  arch/mips/mti-malta/malta-time.c |   16 +
>  drivers/irqchip/irq-mips-gic.c   |   38 +-
>  drivers/tty/Kconfig  |   47 ++
>  drivers/tty/Makefile |1 +
>  drivers/tty/mips_ejtag_fdc.c | 1303 
> ++
>  include/linux/irqchip/mips-gic.h |1 +
>  12 files changed, 1443 insertions(+), 7 deletions(-)
>  create mode 100644 drivers/tty/mips_ejtag_fdc.c
> 



signature.asc
Description: OpenPGP digital signature

Re: [STLinux Kernel] [PATCH v3 7/8] rtc: st: add new driver for ST's LPC RTC

[Lee Jones]

On Mon, 23 Feb 2015, Peter Griffin wrote:
> On Wed, 18 Feb 2015, Lee Jones wrote:
> 
> > ST's Low Power Controller (LPC) controls two devices; watchdog and RTC.
> > Only one of the devices can be used at any one time.  This is enforced
> > by the correlating MFD driver.  This portion of the driver-set controls
> > the Real Time Clock.
> 
> 
> 
> > +{
> > +   unsigned long flags;
> > +
> > +   spin_lock_irqsave(>lock, flags);
> > +
> > +   writel(1, rtc->ioaddr + LPC_WDT_OFF);
> > +
> > +   writel(msb, rtc->ioaddr + LPC_LPA_MSB_OFF);
> > +   writel(lsb, rtc->ioaddr + LPC_LPA_LSB_OFF);
> > +   writel(1, rtc->ioaddr + LPC_LPA_START_OFF);
> > +
> > +   writel(0, rtc->ioaddr + LPC_WDT_OFF);
> 
> I think all the writel IO accessors in this driver can be replaced
> with the *_relaxed variant. This will avoid the overhead of taking a
> spinlock in the l2 outer cache part of writel.

Yes, there is no technical reason why we can't use the relaxed
variants.  Will fix.

> > +#ifdef CONFIG_PM_SLEEP
> > +static int st_rtc_suspend(struct device *dev)
> > +{
> > +   struct st_rtc *rtc = dev_get_drvdata(dev);
> > +
> > +   if (device_may_wakeup(dev))
> > +   return 0;
> > +
> > +   writel(1, rtc->ioaddr + LPC_WDT_OFF);
> > +   writel(0, rtc->ioaddr + LPC_LPA_START_OFF);
> > +   writel(0, rtc->ioaddr + LPC_WDT_OFF);
> 
> Is there a reason for not disabling the IP clock in suspend / resume 
> functions?

There is.  It will stop the alarm timer, which is undesirable.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] arm64: mm: remove unused functions and variable protoypes

[Will Deacon]

On Wed, Feb 25, 2015 at 02:47:45AM +, Yingjoe Chen wrote:
> The functions __cpu_flush_user_tlb_range and __cpu_flush_kern_tlb_range
> were removed in commit fa48e6f780 'arm64: mm: Optimise tlb flush logic
> where we have >4K granule'. Global variable cpu_tlb was never used in
> arm64.
> 
> Remove them.
> 
> Signed-off-by: Yingjoe Chen 
> ---
>  arch/arm64/include/asm/tlbflush.h | 5 -
>  1 file changed, 5 deletions(-)

Acked-by: Will Deacon 

Will

> diff --git a/arch/arm64/include/asm/tlbflush.h 
> b/arch/arm64/include/asm/tlbflush.h
> index 73f0ce5..4abe9b9 100644
> --- a/arch/arm64/include/asm/tlbflush.h
> +++ b/arch/arm64/include/asm/tlbflush.h
> @@ -24,11 +24,6 @@
>  #include 
>  #include 
>  
> -extern void __cpu_flush_user_tlb_range(unsigned long, unsigned long, struct 
> vm_area_struct *);
> -extern void __cpu_flush_kern_tlb_range(unsigned long, unsigned long);
> -
> -extern struct cpu_tlb_fns cpu_tlb;
> -
>  /*
>   *   TLB Management
>   *   ==
> -- 
> 1.8.1.1.dirty
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH v3 00/26] Early kprobe: enable kprobes at very early booting stage.

[Wang Nan]

On 2015/2/20 11:59, Masami Hiramatsu wrote:
> Hi,
> 
> Sorry for replying late.
> 
> (2015/02/13 14:39), Wang Nan wrote:
>> I fell very sorry for people who reviewed my v2 patch series yesterday
>> at https://lkml.org/lkml/2015/2/12/234 because I didn't provide enough
>> information in commit log. This v3 patch series add those missing
>> commit messages. There are also 2 small fix based on v2:
>>
>>  1. Fixes ftrace_sort_mcount_area. Original patch doesn't work for module.
>>  2. Wraps setting of kprobes_initialized in stop_machine() context.
> 
> From the viewpoint of the maintenance, it seems over-engineered and
> not general implementation. Please reconsider just initializing breakpoint
> handler in earlier stage. Since those exceptions may happen anywhere,
> those trap handlers setup very early stage. E.g. on x86, setup_arch()
> setup early_trap_init() at beginning. So we just need to initialize
> kprobes earlier.

I tried as your suggestion. For x86, int3 handler doesn't work correctly until
trap_init(). I don't have enough time to look into this problem today (and I 
don't
familiar with x86 architecture). Could you please have a look on it?

Thank you.

> I think this is almost enough for debugging, and very general because
> we don't need optprobe for porting to other arch.
> 
> And for ftrace-based kprobe, we can just put breakpoint on mcount call at
> beginning. ftrace will need to check and keep it when replacing mcount-call
> with nop. Afterward, we can cleanly update those kprobes with ftrace-based
> kprobe.
> 
> So, please start with smaller changes.
> 
> Thank you,
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL][resend] clockevents fixes for 4.0-rc1

[Daniel Lezcano]

Hi Thomas, Ingo,

this pull request provides the following fixes for 4.0-rc1:

- Fix the Kconfig to prevent the asm9260 timer to be compiled with 
allyesconfig with sparc/sparc64 (Daniel Lezcano)


 - Reorder the mtk driver init sequence in order to prevent a potential 
race when the clock is registered before the irq handler is set 
(Matthias Brugger)


 - Fix a section mismatch for the pxa driver (Robert Jarzmik)

Thanks !

  -- Daniel

The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539:

  Linux 4.0-rc1 (2015-02-22 18:21:14 -0800)

are available in the git repository at:

  http://git.linaro.org/people/daniel.lezcano/linux.git clockevents/4.0-rc1

for you to fetch changes up to 6f2116ebe24f9f0f0d90ad17e405ea181f2499eb:

  clocksource: pxa: Fix section mismatch (2015-02-25 10:28:55 +0100)


Daniel Lezcano (1):
  clockevents: asm9260: Fix compilation error with sparc/sparc64 
allyesconfig


Matthias Brugger (1):
  clocksource: mtk: Fix race conditions in probe code

Robert Jarzmik (1):
  clocksource: pxa: Fix section mismatch

 arch/arm/mach-asm9260/Kconfig   |  2 ++
 drivers/clocksource/Kconfig | 16 +---
 drivers/clocksource/mtk_timer.c |  9 +
 drivers/clocksource/pxa_timer.c |  2 +-
 4 files changed, 13 insertions(+), 16 deletions(-)


--
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/3] clocksource: pxa: Fix section mismatch

[Daniel Lezcano]

From: Robert Jarzmik 

As pxa_timer_common_init() is only called in init context, mark it as
such, and quiesce the compiler warnings :
WARNING: vmlinux.o(.text.unlikely+0x45d4): Section mismatch in reference
from the function pxa_timer_common_init() to the function
.init.text:sched_clock_register()

WARNING: vmlinux.o(.text.unlikely+0x4610): Section mismatch in reference
from the function pxa_timer_common_init() to the function
.init.text:clocksource_mmio_init()

Signed-off-by: Robert Jarzmik 
Signed-off-by: Daniel Lezcano 
---
 drivers/clocksource/pxa_timer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clocksource/pxa_timer.c b/drivers/clocksource/pxa_timer.c
index 941f3f3..d9438af 100644
--- a/drivers/clocksource/pxa_timer.c
+++ b/drivers/clocksource/pxa_timer.c
@@ -163,7 +163,7 @@ static struct irqaction pxa_ost0_irq = {
.dev_id = _pxa_osmr0,
 };
 
-static void pxa_timer_common_init(int irq, unsigned long clock_tick_rate)
+static void __init pxa_timer_common_init(int irq, unsigned long 
clock_tick_rate)
 {
timer_writel(0, OIER);
timer_writel(OSSR_M0 | OSSR_M1 | OSSR_M2 | OSSR_M3, OSSR);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [STLinux Kernel] [PATCH v3 7/8] rtc: st: add new driver for ST's LPC RTC

[Russell King - ARM Linux]

On Mon, Feb 23, 2015 at 10:12:23AM +, Peter Griffin wrote:
> I think all the writel IO accessors in this driver can be replaced
> with the *_relaxed variant. This will avoid the overhead of taking a
> spinlock in the l2 outer cache part of writel.

You're really operating on old information.  With much improved L2 cache
support code which went in a year or so ago, for the popular L2 cache
controllers, we don't take a spinlock anymore - we just write to the
register directly.

The spinlock is only present for L2C-220 controllers, which are rare.

Moreover, taking the spinlock is only expensive if you have things like
lockdep enabled, otherwise it should be inline and will be fast.

However, using the _relaxed variants where we can get away with weaker
ordering of the writes to the device is a good thing nevertheless.  I'm
just pointing out that your reasoning above is wrong.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3] clocksource: mtk: Fix race conditions in probe code

[Daniel Lezcano]

From: Matthias Brugger 

We have two race conditions in the probe code which could lead to a null
pointer dereference in the interrupt handler.

The interrupt handler accesses the clockevent device, which may not yet be
registered.

First race condition happens when the interrupt handler gets registered before
the interrupts get disabled. The second race condition happens when the
interrupts get enabled, but the clockevent device is not yet registered.

Fix that by disabling the interrupts before we register the interrupt and enable
the interrupts after the clockevent device got registered.

Reported-by: Gongbae Park 
Signed-off-by: Matthias Brugger 
Cc: sta...@vger.kernel.org
Signed-off-by: Daniel Lezcano 
---
 drivers/clocksource/mtk_timer.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/clocksource/mtk_timer.c b/drivers/clocksource/mtk_timer.c
index 32a3d25..68ab423 100644
--- a/drivers/clocksource/mtk_timer.c
+++ b/drivers/clocksource/mtk_timer.c
@@ -224,6 +224,8 @@ static void __init mtk_timer_init(struct device_node *node)
}
rate = clk_get_rate(clk);
 
+   mtk_timer_global_reset(evt);
+
if (request_irq(evt->dev.irq, mtk_timer_interrupt,
IRQF_TIMER | IRQF_IRQPOLL, "mtk_timer", evt)) {
pr_warn("failed to setup irq %d\n", evt->dev.irq);
@@ -232,8 +234,6 @@ static void __init mtk_timer_init(struct device_node *node)
 
evt->ticks_per_jiffy = DIV_ROUND_UP(rate, HZ);
 
-   mtk_timer_global_reset(evt);
-
/* Configure clock source */
mtk_timer_setup(evt, GPT_CLK_SRC, TIMER_CTRL_OP_FREERUN);
clocksource_mmio_init(evt->gpt_base + TIMER_CNT_REG(GPT_CLK_SRC),
@@ -241,10 +241,11 @@ static void __init mtk_timer_init(struct device_node 
*node)
 
/* Configure clock event */
mtk_timer_setup(evt, GPT_CLK_EVT, TIMER_CTRL_OP_REPEAT);
-   mtk_timer_enable_irq(evt, GPT_CLK_EVT);
-
clockevents_config_and_register(>dev, rate, 0x3,
0x);
+
+   mtk_timer_enable_irq(evt, GPT_CLK_EVT);
+
return;
 
 err_clk_disable:
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Kprobes: pre-handler with interrupts enabled - is it possible?

[Eugene Shatokhin]

> (2015/02/24 15:04), Eugene Shatokhin wrote:

24.02.2015 06:47, Masami Hiramatsu пишет:

No, that is not allowed. I mean, you can do anything you want to do
on your handler (enabling preemption/irq etc.) but the result may be
not safe (it can crash your kernel, but it's not a kprobes' bug).


Yes, that is why I am asking.


Actually, enable interrupts on kprobe handlers can cause reentering
kprobes (by kprobes on interrupt handlers), and currently kprobe skips
all those reentered kprobes.
Is it acceptable that some of your kprobe handlers are not fired when
hitting?


I think, yes. When a software breakpoint hits, my system decodes the
instruction, finds the address that is about to be accessed and tries to
place a hardware breakpoint on that memory area.

There are only 4 hardware breakpoints a CPU can use on x86, so if the
software breakpoint hits too often, the system will not be able to
process all hits anyway because all HW breakpoints may be already in use.


Would you mean sleep on your handler??


No, I use mdelay(). It is, in essence, a busy-wait loop as far as I
know. The delay intervals may vary, the default is 5 jiffies.


Hmm, here I couldn't understand. If mdelay() does busy-wait loop, why
would you like to enable irq??
Other code doesn't work on the core while waiting.


I'd like not to enable IRQ but rather to execute my handler with the
same (or similar) restrictions as the original instruction would. If the
insn executed with IRQ enabled, so would the handler, etc. So I am
looking for a way to avoid *additionally* disabling IRQ (and, perhaps,
preemption, although this might be harder).

The breakpoints and delays already incur a penalty on the system's
responsiveness.
However, if, say, I probe an insn executing in a process context with
IRQs enabled, the interrupts may be served on this CPU during the delay.
If, additionally, preemption is not disabled and the kernel is built
with CONFIG_PREEMPT=y then, I guess, mdelay() can be preempted allowing
some other task to run, which is good for overall responsiveness.

Usually, the longer delays I make, the more likely the races are
detected but the performance overhead increases too. I do not have the
exact numbers yet, but still.

So, while 5-10 jiffies are often enough, sometimes it could be
beneficial to wait longer. For example, when I used the system to
confirm a race between .probe() and .ndo_open() callbacks in e1000
driver a year ago, I used the delay of about one second or more (for
NetworkManager to start working with the device), which is too much if
the IRQs were disabled, I think. Both .probe() and .ndo_open() executed
in process context, by the way.

Well, I was actually thinking about something like the following (for
x86, at least).

If a Kprobe's pre_handler returns non-zero, single-step will not be
performed, right? As far as I can see in the code, Jprobes rely on that.
Preemption will still be disabled and Jprobe's handler enables it when
ready.

What if I place a Kprobe on an insn of interest and the pre_handler
changes regs->ip to the address of my function, say, "my_thunk_pre" (see
below) then returns non-zero. Handling of int3 then completes, the
context is restored, the interrupts are re-enabled (if they were enabled
before int3). Preemption remains off because the Kprobe's implementation
disabled it. Execution resumes in "my_thunk_pre" that is written in
assembly and may look like this on x86_64 (x86_32 is similar):

--
my_thunk_pre:
push %rax


call my_handler
// my_handler() is a C function, with the default
// calling convention/linkage.
// Returns the address of the copied insn in the
// Kprobe's insn slot in %rax.



// restore the orig value of %rax and push the address
// to jump to on the stack
xchg %rax, (%rsp)

// Jump to the copied insn (and fix %rsp at the same time):
ret
--

In this case, my_handler() seems to execute in the same context as the
original insn, except for disabled preemption.

It may use kprobe_running() to get the Kprobe, and, perhaps, some my
structure that contains that Kprobe. Then, I guess, it might call
preempt_enable_no_resched() like Jprobe's handler does (may be some
other actions are needed?). After that, my_handler can do the rest of
its job: arm the HW breakpoints, call mdelay(), etc.

my_handler will return the address of the copied insn in the Kprobe's
insn slot. The control will be passed there by my_thunk_pre().

For this to work, it is needed that the copied insn stored in the
Kprobe's insn slot was followed by a jump back to the original code, to
the next insn, I mean. Of course, this is not necessary for some
control-transfer insns. But my system mostly works with the insns that
access data rather than with these.

Looks like Kprobes already do something similar and place such jumps in
the insn 

[PATCH 1/3] clockevents: asm9260: Fix compilation error with sparc/sparc64 allyesconfig

[Daniel Lezcano]

The Kconfig options for the asm9260 timer is wrong as it can be selected by
another platform with allyes config and thus leading to a compilation failure
as some non arch related code is pulled by the compilation.

Fix this by having the platform Kconfig to select the timer as it is done for
the others drivers.

Signed-off-by: Daniel Lezcano 
Acked-by: Guenter Roeck 
Acked-by: Oleksij Rempel 

Conflicts:
drivers/clocksource/Kconfig
---
 arch/arm/mach-asm9260/Kconfig |  2 ++
 drivers/clocksource/Kconfig   | 16 +---
 2 files changed, 7 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-asm9260/Kconfig b/arch/arm/mach-asm9260/Kconfig
index 8423be7..5224120 100644
--- a/arch/arm/mach-asm9260/Kconfig
+++ b/arch/arm/mach-asm9260/Kconfig
@@ -2,5 +2,7 @@ config MACH_ASM9260
bool "Alphascale ASM9260"
depends on ARCH_MULTI_V5
select CPU_ARM926T
+   select ASM9260_TIMER
+   select GENERIC_CLOCKEVENTS
help
  Support for Alphascale ASM9260 based platform.
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 1c2506f..68161f7 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -63,6 +63,11 @@ config VT8500_TIMER
 config CADENCE_TTC_TIMER
bool
 
+config ASM9260_TIMER
+   bool
+   select CLKSRC_MMIO
+   select CLKSRC_OF
+
 config CLKSRC_NOMADIK_MTU
bool
depends on (ARCH_NOMADIK || ARCH_U8500)
@@ -245,15 +250,4 @@ config CLKSRC_PXA
help
  This enables OST0 support available on PXA and SA-11x0
  platforms.
-
-config ASM9260_TIMER
-   bool "Alphascale ASM9260 timer driver"
-   depends on GENERIC_CLOCKEVENTS
-   select CLKSRC_MMIO
-   select CLKSRC_OF
-   default y if MACH_ASM9260
-   help
- This enables build of a clocksource and clockevent driver for
- the 32-bit System Timer hardware available on a Alphascale ASM9260.
-
 endmenu
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/7] x86/intel_rdt: Intel Cache Allocation Technology detection

[Borislav Petkov]

On Tue, Feb 24, 2015 at 04:42:10PM -0800, Vikas Shivappa wrote:
> >>+
> >>+   pr_info("cbmlength:%u,Closs: %u\n", cbm_len, maxid);
> >
> >This text message needs to be much more user-friendly if it is going out
> >to the console unconditionally.
> >
> 
> bit mask lengh:  number of CLOSids: ? . it should print with the module name
> as well which should help understand what it is for.

Right, if I haven't read the SDM on RDT, I still don't understand what
those mean. What is the need for that message at all, what is it telling
me?

Can you show an example from a machine with RDT and explain what it is
good for?

> >>+config CGROUP_RDT
> >>+   bool "Resource Director Technology cgroup subsystem"
> >>+   depends on X86_64
> >
> >depends on X86_64 && CPU_SUP_INTEL
> >
> >Also, this should probably also depend on CGROUP-something or so
> >AFAICT...
> 
> This is with in the if CGROUPS

Right, but you still need the CPU_SUP_INTEL dependency as !Intel x86
doesn't need that code built.

Thanks.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] arm64: mediatek: Add config option for mt8173.

[Catalin Marinas]

On Wed, Feb 25, 2015 at 11:51:57AM +0100, Arnd Bergmann wrote:
> On Wednesday 25 February 2015 17:07:22 Yingjoe Chen wrote:
> > On Tue, 2015-01-27 at 15:13 +0800, Hongzhou Yang wrote:
> > > From: Hongzhou Yang 
> > > 
> > > The upcoming MTK pinctrl driver have a big pin table for each SoC,
> > > and we don't want to bloat the kernel binary if we don't need it.
> > > Add config options so we can build for one SoC only.
> > > 
> > > Signed-off-by: Hongzhou Yang 
> > > ---
> > >  arch/arm64/Kconfig | 6 ++
> > >  1 file changed, 6 insertions(+)
> > > 
> > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > > index e627ead..6213dac 100644
> > > --- a/arch/arm64/Kconfig
> > > +++ b/arch/arm64/Kconfig
> > > @@ -151,9 +151,15 @@ menu "Platform selection"
> > >  config ARCH_MEDIATEK
> > >   bool "Mediatek MT65xx & MT81xx ARMv8 SoC"
> > >   select ARM_GIC
> > > + select PINCTRL
> > >   help
> > > Support for Mediatek MT65xx & MT81xx ARMv8 SoCs
> > >  
> > > +config MACH_MT8173
> > > + bool "Mediatek 8173 Soc Supprt"
> > > + depends on ARCH_MEDIATEK
> > > + default y
> > > +
> > >  config ARCH_SEATTLE
> > >   bool "AMD Seattle SoC Family"
> > >   help
> > 
> > Hi Arnd/Matthias,
> > 
> > Any comments on this patch?
> 
> Hi Joe,
> 
> Actually I just commented on a similar patch from Samsung the other
> day, and I think we should make a more general decision about these:
> 
> I would rather see only one Kconfig option per SoC family and use
> ARCH_MEDIATEK without any MACH_* options. We can have other options
> for e.g. networking chips from Mediatek that are not closely related
> but I would group all the phone and tablet chips under one option
> here. Same for the other vendors of course.

I agree.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] compat: Fix endian issue in union sigval

[Catalin Marinas]

On Tue, Feb 24, 2015 at 04:54:17PM -0500, Chris Metcalf wrote:
> On 2/14/2015 6:22 AM, Catalin Marinas wrote:
> >1. user populates sival_int compat_sigevent and invokes
> >compat_sys_mq_notify()
> >2. kernel get_compat_sigevent() copies compat_sigevent into the native
> >sigevent. compat and native sival_int are the same, no problem so
> >far. The other half of 64-bit sival_ptr is zeroed by a memset in this
> >function (this other half can be top or bottom, depending on
> >endianness)
> >3. signal is about to be delivered to user via arch code. The
> >compat_ptr(from->si_ptr) conversion always takes the least
> >significant part of the native si_ptr. On big endian 64-bit, this is
> >zero because get_compat_sigevent() populated the top part of si_ptr
> >with si_int.
> >
> >So delivering such signals to compat user always sets si_int to 0.
> >Little endian is fine.
> 
> I looked at this again as I was getting ready to do a tile patch, and realized
> why tile and arm64 are different here: tile does a field-by-field copy in
> copy_siginfo_from_user32(), like parisc and s390.  As a result, we initialize
> the 64-bit kernel si_ptr value by cast from the 32-bit user si_ptr value, 
> rather
> than blindly writing into the lower-addressed half of the 64-bit sigval.

It's not about copy_siginfo_from_user32() but the generic
get_compat_sigevent() which always uses sival_int (called from e.g.
compat_sys_timer_create()).

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: nios2: is the ptrace ABI correct?

[Ezequiel Garcia]

On 02/24/2015 04:25 PM, Arnd Bergmann wrote:
> On Tuesday 24 February 2015 12:28:41 Ezequiel Garcia wrote:
>>
>> Gah, no, you are right. I got confused.
>>
>> So it would be OK to avoid remove pt_regs from the uapi headers?
>> How does this affect the signal handling nios2 implementation?
>>
> 
> We have a number of architectures that don't provide this structure:
> 
> $ git grep -L pt_regs arch/*/include/uapi/asm/ptrace.h
> arch/frv/include/uapi/asm/ptrace.h
> arch/metag/include/uapi/asm/ptrace.h
> arch/openrisc/include/uapi/asm/ptrace.h
> arch/s390/include/uapi/asm/ptrace.h
> 
> so I'd assume it's ok in general not to have it. However, on
> nios2, struct pt_regs is embedded inside of struct sigcontext.
> If I read the code in arch/nios2/kernel/signal.c correctly,
> this is actually a bug and you should use a different structure
> there too, because pt_regs does not match the layout of the
> stack either. This means that the (rare) user programs that
> would know about the architecture to modify signal stacks
> are currently broken.
> 

/me is more confused now

In arch/nios2/include/asm/ucontext.h

struct ucontext {
unsigned long uc_flags;
struct ucontext  *uc_link;
stack_t   uc_stack;
struct mcontext   uc_mcontext;
sigset_t  uc_sigmask;
};

And in include/uapi/asm-generic/ucontext.h:

struct ucontext {
unsigned long uc_flags;
struct ucontext  *uc_link;
stack_t   uc_stack;
struct sigcontext uc_mcontext;
sigset_t  uc_sigmask;
};

Which one is the one that userspace sees? And why does the kernel has
two different structures?

Given this oddities, I'm wondering how troublesome would be to just
re-do this and break the ptrace and signal ABI. For instance, just
pushing pt_regs in PTRACE_GETREGSET would make things much clearer.

I guess Linus would burn me for even suggesting to breaking users... but
do we have any users at all? This arch has just been mainlined. Altera's
out-of-tree is already ABI-incompatible with mainline so that's not an
issue.

The only one using this ABI is gdb, which is easily fixed.
-- 
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] doc:input : Fix typo in Documentations/input

[Masanari Iida]

This patch fix spelling typos in Documentations/input.

Signed-off-by: Masanari Iida 
---
 Documentation/input/alps.txt| 4 ++--
 Documentation/input/event-codes.txt | 2 +-
 Documentation/input/gpio-tilt.txt   | 2 +-
 Documentation/input/iforce-protocol.txt | 2 +-
 Documentation/input/walkera0701.txt | 2 +-
 Documentation/input/yealink.txt | 2 +-
 6 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/Documentation/input/alps.txt b/Documentation/input/alps.txt
index a63e5e0..b9ecf99 100644
--- a/Documentation/input/alps.txt
+++ b/Documentation/input/alps.txt
@@ -58,7 +58,7 @@ To exit command mode, PSMOUSE_CMD_SETSTREAM (EA) is sent to 
the touchpad.
 While in command mode, register addresses can be set by first sending a
 specific command, either EC for v3 devices or F5 for v4 devices. Then the
 address is sent one nibble at a time, where each nibble is encoded as a
-command with optional data. This enoding differs slightly between the v3 and
+command with optional data. This encoding differs slightly between the v3 and
 v4 protocols.
 
 Once an address has been set, the addressed register can be read by sending
@@ -131,7 +131,7 @@ ALPS Absolute Mode - Protocol Version 3
 ---
 
 ALPS protocol version 3 has three different packet formats. The first two are
-associated with touchpad events, and the third is associatd with trackstick
+associated with touchpad events, and the third is associated with trackstick
 events.
 
 The first type is the touchpad position packet.
diff --git a/Documentation/input/event-codes.txt 
b/Documentation/input/event-codes.txt
index c587a96..d92eae3 100644
--- a/Documentation/input/event-codes.txt
+++ b/Documentation/input/event-codes.txt
@@ -229,7 +229,7 @@ such device to feedback.
 EV_PWR:
 --
 EV_PWR events are a special type of event used specifically for power
-mangement. Its usage is not well defined. To be addressed later.
+management. Its usage is not well defined. To be addressed later.
 
 Device properties:
 =
diff --git a/Documentation/input/gpio-tilt.txt 
b/Documentation/input/gpio-tilt.txt
index 06d60c3..2cdfd9b 100644
--- a/Documentation/input/gpio-tilt.txt
+++ b/Documentation/input/gpio-tilt.txt
@@ -28,7 +28,7 @@ Example:
 
 
 Example configuration for a single TS1003 tilt switch that rotates around
-one axis in 4 steps and emitts the current tilt via two GPIOs.
+one axis in 4 steps and emits the current tilt via two GPIOs.
 
 static int sg060_tilt_enable(struct device *dev) {
/* code to enable the sensors */
diff --git a/Documentation/input/iforce-protocol.txt 
b/Documentation/input/iforce-protocol.txt
index 2d5fbfd..6628715 100644
--- a/Documentation/input/iforce-protocol.txt
+++ b/Documentation/input/iforce-protocol.txt
@@ -97,7 +97,7 @@ LEN= 0e
 *** Attack and fade ***
 OP=  02
 LEN= 08
-00-01 Address where to store the parameteres
+00-01 Address where to store the parameters
 02-03 Duration of attack (little endian encoding, in ms)
 04 Level at end of attack. Signed byte.
 05-06 Duration of fade.
diff --git a/Documentation/input/walkera0701.txt 
b/Documentation/input/walkera0701.txt
index 561385d..49e3ac6 100644
--- a/Documentation/input/walkera0701.txt
+++ b/Documentation/input/walkera0701.txt
@@ -91,7 +91,7 @@ absolute binary value. (10 bits per channel). Next nibble is 
checksum for
 first ten nibbles.
 
 Next nibbles 12 .. 21 represents four channels (not all channels can be
-directly controlled from TX). Binary representations ar the same as in first
+directly controlled from TX). Binary representations are the same as in first
 four channels. In nibbles 22 and 23 is a special magic number. Nibble 24 is
 checksum for nibbles 12..23.
 
diff --git a/Documentation/input/yealink.txt b/Documentation/input/yealink.txt
index 5360e43..8277b76 100644
--- a/Documentation/input/yealink.txt
+++ b/Documentation/input/yealink.txt
@@ -93,7 +93,7 @@ Format description:
   Format specifier
 '8' :  Generic 7 segment digit with individual addressable segments
 
-Reduced capability 7 segm digit, when segments are hard wired together.
+Reduced capability 7 segment digit, when segments are hard wired together.
 '1' : 2 segments digit only able to produce a 1.
 'e' : Most significant day of the month digit,
   able to produce at least 1 2 3.
-- 
2.3.0.149.gf3f4077

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 3/3] tomoyo: reduce mmap_sem hold for mm->exe_file

[Tetsuo Handa]

Davidlohr Bueso wrote:
> The mm->exe_file is currently serialized with mmap_sem (shared) in order
> to both safely (1) read the file and (2) compute the realpath by calling
> tomoyo_realpath_from_path, making it an absolute overkill. Good users will,
> on the other hand, make use of the more standard get_mm_exe_file(), requiring
> only holding the mmap_sem to read the value, and relying on reference
> 
> Signed-off-by: Davidlohr Bueso 

Acked-by: Tetsuo Handa 

James, will you apply to linux-security.git#next ?
I'm not using publicly accessible git tree for sending pull requests.

> ---
> 
> Changes from v2: remove cleanups and cp initialization.
> 
>  security/tomoyo/util.c | 21 -
>  1 file changed, 12 insertions(+), 9 deletions(-)
> 
> diff --git a/security/tomoyo/util.c b/security/tomoyo/util.c
> index 2952ba5..29f3b65 100644
> --- a/security/tomoyo/util.c
> +++ b/security/tomoyo/util.c
> @@ -948,16 +948,19 @@ bool tomoyo_path_matches_pattern(const struct 
> tomoyo_path_info *filename,
>   */
>  const char *tomoyo_get_exe(void)
>  {
> - struct mm_struct *mm = current->mm;
> - const char *cp = NULL;
> +   struct file *exe_file;
> +   const char *cp;
> +   struct mm_struct *mm = current->mm;
>  
> - if (!mm)
> - return NULL;
> - down_read(>mmap_sem);
> - if (mm->exe_file)
> - cp = tomoyo_realpath_from_path(>exe_file->f_path);
> - up_read(>mmap_sem);
> - return cp;
> +   if (!mm)
> +return NULL;
> +   exe_file = get_mm_exe_file(mm);
> +   if (!exe_file)
> +return NULL;
> +
> +   cp = tomoyo_realpath_from_path(_file->f_path);
> +   fput(exe_file);
> +   return cp;
>  }
>  
>  /**
> -- 
> 2.1.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/7] soc: tegra: Move the fuse header to a separate directory

[Ezequiel Garcia]

As preparation work for the introduction of an eFuse subsystem,
this commit moves Tegra's fuse header and fixes the includes
where needed.

Cc: Thierry Reding 
Cc: Stephen Warren 
Cc: Alexandre Courbot 
Signed-off-by: Ezequiel Garcia 
---
 arch/arm/mach-tegra/cpuidle.c | 3 +--
 arch/arm/mach-tegra/flowctrl.c| 3 +--
 arch/arm/mach-tegra/hotplug.c | 2 +-
 arch/arm/mach-tegra/platsmp.c | 2 +-
 arch/arm/mach-tegra/pm.c  | 2 +-
 arch/arm/mach-tegra/reset-handler.S   | 3 +--
 arch/arm/mach-tegra/reset.c   | 3 +--
 arch/arm/mach-tegra/sleep-tegra30.S   | 3 +--
 arch/arm/mach-tegra/tegra.c   | 2 +-
 drivers/ata/ahci_tegra.c  | 2 +-
 drivers/clk/tegra/clk-periph-gate.c   | 3 +--
 drivers/clk/tegra/clk.c   | 3 +--
 drivers/gpu/drm/nouveau/nouveau_platform.c| 2 +-
 drivers/soc/tegra/fuse/fuse-tegra.c   | 2 +-
 drivers/soc/tegra/fuse/fuse-tegra20.c | 3 +--
 drivers/soc/tegra/fuse/fuse-tegra30.c | 3 +--
 drivers/soc/tegra/fuse/speedo-tegra114.c  | 3 +--
 drivers/soc/tegra/fuse/speedo-tegra124.c  | 3 +--
 drivers/soc/tegra/fuse/speedo-tegra20.c   | 3 +--
 drivers/soc/tegra/fuse/speedo-tegra30.c   | 3 +--
 drivers/soc/tegra/fuse/tegra-apbmisc.c| 3 +--
 drivers/soc/tegra/pmc.c   | 2 +-
 drivers/thermal/tegra_soctherm.c  | 3 +--
 include/{soc/tegra/fuse.h => linux/efuse/tegra.h} | 0
 24 files changed, 23 insertions(+), 38 deletions(-)
 rename include/{soc/tegra/fuse.h => linux/efuse/tegra.h} (100%)

diff --git a/arch/arm/mach-tegra/cpuidle.c b/arch/arm/mach-tegra/cpuidle.c
index 3165631..62b8086 100644
--- a/arch/arm/mach-tegra/cpuidle.c
+++ b/arch/arm/mach-tegra/cpuidle.c
@@ -21,11 +21,10 @@
  * more details.
  */
 
+#include 
 #include 
 #include 
 
-#include 
-
 #include "cpuidle.h"
 
 void __init tegra_cpuidle_init(void)
diff --git a/arch/arm/mach-tegra/flowctrl.c b/arch/arm/mach-tegra/flowctrl.c
index 475e783..623c820 100644
--- a/arch/arm/mach-tegra/flowctrl.c
+++ b/arch/arm/mach-tegra/flowctrl.c
@@ -19,14 +19,13 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 
-#include 
-
 #include "flowctrl.h"
 
 static u8 flowctrl_offset_halt_cpu[] = {
diff --git a/arch/arm/mach-tegra/hotplug.c b/arch/arm/mach-tegra/hotplug.c
index 6fc71f1..0d55820 100644
--- a/arch/arm/mach-tegra/hotplug.c
+++ b/arch/arm/mach-tegra/hotplug.c
@@ -9,11 +9,11 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 
 #include 
-#include 
 
 #include 
 
diff --git a/arch/arm/mach-tegra/platsmp.c b/arch/arm/mach-tegra/platsmp.c
index b450866..2c65404 100644
--- a/arch/arm/mach-tegra/platsmp.c
+++ b/arch/arm/mach-tegra/platsmp.c
@@ -15,13 +15,13 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 
-#include 
 #include 
 
 #include 
diff --git a/arch/arm/mach-tegra/pm.c b/arch/arm/mach-tegra/pm.c
index b0f48a3..7089444 100644
--- a/arch/arm/mach-tegra/pm.c
+++ b/arch/arm/mach-tegra/pm.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -27,7 +28,6 @@
 #include 
 #include 
 
-#include 
 #include 
 #include 
 
diff --git a/arch/arm/mach-tegra/reset-handler.S 
b/arch/arm/mach-tegra/reset-handler.S
index 71be4af..318fbcc 100644
--- a/arch/arm/mach-tegra/reset-handler.S
+++ b/arch/arm/mach-tegra/reset-handler.S
@@ -14,11 +14,10 @@
  * along with this program.  If not, see .
  */
 
+#include 
 #include 
 #include 
 
-#include 
-
 #include 
 #include 
 
diff --git a/arch/arm/mach-tegra/reset.c b/arch/arm/mach-tegra/reset.c
index 894c5c4..7fb3030 100644
--- a/arch/arm/mach-tegra/reset.c
+++ b/arch/arm/mach-tegra/reset.c
@@ -16,11 +16,10 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
-#include 
-
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-tegra/sleep-tegra30.S 
b/arch/arm/mach-tegra/sleep-tegra30.S
index 5d8d13a..e8c8946 100644
--- a/arch/arm/mach-tegra/sleep-tegra30.S
+++ b/arch/arm/mach-tegra/sleep-tegra30.S
@@ -14,10 +14,9 @@
  * along with this program.  If not, see .
  */
 
+#include 
 #include 
 
-#include 
-
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-tegra/tegra.c b/arch/arm/mach-tegra/tegra.c
index 914341b..b216403 100644
--- a/arch/arm/mach-tegra/tegra.c
+++ b/arch/arm/mach-tegra/tegra.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -35,7 +36,6 @@
 #include 
 #include 
 
-#include 
 #include 
 
 #include 
diff --git a/drivers/ata/ahci_tegra.c b/drivers/ata/ahci_tegra.c
index 3a62eb2..cbd4b43 100644
--- a/drivers/ata/ahci_tegra.c
+++ b/drivers/ata/ahci_tegra.c
@@ -19,6 +19,7 @@
 
 #include 
 #include 
+#include 

[PATCH 1/7] soc: tegra: Add missing include linux/types.h

[Ezequiel Garcia]

The soc/tegra/fuse.h header makes use of kernel-specific types (u32, u8) and
therefore it needs a linux/types.h include.

Cc: Thierry Reding 
Cc: Stephen Warren 
Cc: Alexandre Courbot 
Signed-off-by: Ezequiel Garcia 
---
 include/soc/tegra/fuse.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/soc/tegra/fuse.h b/include/soc/tegra/fuse.h
index b5f7b5f..8459008 100644
--- a/include/soc/tegra/fuse.h
+++ b/include/soc/tegra/fuse.h
@@ -28,6 +28,8 @@
 
 #ifndef __ASSEMBLY__
 
+#include 
+
 u32 tegra_read_chipid(void);
 u8 tegra_get_chip_id(void);
 
-- 
2.3.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/7] efuse: Move Tegra efuse driver

[Ezequiel Garcia]

Now that the efuse subsystem has been introduced, move the Tegra efuse driver
from drivers/soc/tegra/fuse/ to drivers/efuse/tegra. For now, there's no
generic efuse API. However, by having the drivers in a unified location it is
expected that such API will arise easier once support for more devices is added.

Cc: Stephen Warren 
Cc: Thierry Reding 
Cc: Alexandre Courbot 
Signed-off-by: Ezequiel Garcia 
---
 drivers/efuse/Kconfig | 7 +++
 drivers/efuse/Makefile| 1 +
 drivers/{soc/tegra/fuse => efuse/tegra}/Makefile  | 0
 drivers/{soc/tegra/fuse => efuse/tegra}/fuse-tegra.c  | 0
 drivers/{soc/tegra/fuse => efuse/tegra}/fuse-tegra20.c| 0
 drivers/{soc/tegra/fuse => efuse/tegra}/fuse-tegra30.c| 0
 drivers/{soc/tegra/fuse => efuse/tegra}/fuse.h| 0
 drivers/{soc/tegra/fuse => efuse/tegra}/speedo-tegra114.c | 0
 drivers/{soc/tegra/fuse => efuse/tegra}/speedo-tegra124.c | 0
 drivers/{soc/tegra/fuse => efuse/tegra}/speedo-tegra20.c  | 0
 drivers/{soc/tegra/fuse => efuse/tegra}/speedo-tegra30.c  | 0
 drivers/{soc/tegra/fuse => efuse/tegra}/tegra-apbmisc.c   | 0
 drivers/soc/tegra/Makefile| 2 --
 13 files changed, 8 insertions(+), 2 deletions(-)
 rename drivers/{soc/tegra/fuse => efuse/tegra}/Makefile (100%)
 rename drivers/{soc/tegra/fuse => efuse/tegra}/fuse-tegra.c (100%)
 rename drivers/{soc/tegra/fuse => efuse/tegra}/fuse-tegra20.c (100%)
 rename drivers/{soc/tegra/fuse => efuse/tegra}/fuse-tegra30.c (100%)
 rename drivers/{soc/tegra/fuse => efuse/tegra}/fuse.h (100%)
 rename drivers/{soc/tegra/fuse => efuse/tegra}/speedo-tegra114.c (100%)
 rename drivers/{soc/tegra/fuse => efuse/tegra}/speedo-tegra124.c (100%)
 rename drivers/{soc/tegra/fuse => efuse/tegra}/speedo-tegra20.c (100%)
 rename drivers/{soc/tegra/fuse => efuse/tegra}/speedo-tegra30.c (100%)
 rename drivers/{soc/tegra/fuse => efuse/tegra}/tegra-apbmisc.c (100%)

diff --git a/drivers/efuse/Kconfig b/drivers/efuse/Kconfig
index 617476f..b84e06b 100644
--- a/drivers/efuse/Kconfig
+++ b/drivers/efuse/Kconfig
@@ -1,3 +1,10 @@
 menu "eFuse drivers"
 
+config EFUSE_TEGRA
+   bool
+   depends on ARCH_TEGRA
+   help
+ Support for the eFuses available on Tegra SoCs
+
+
 endmenu
diff --git a/drivers/efuse/Makefile b/drivers/efuse/Makefile
index e69de29..b69a0d6 100644
--- a/drivers/efuse/Makefile
+++ b/drivers/efuse/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_EFUSE_TEGRA)  += tegra/
diff --git a/drivers/soc/tegra/fuse/Makefile b/drivers/efuse/tegra/Makefile
similarity index 100%
rename from drivers/soc/tegra/fuse/Makefile
rename to drivers/efuse/tegra/Makefile
diff --git a/drivers/soc/tegra/fuse/fuse-tegra.c 
b/drivers/efuse/tegra/fuse-tegra.c
similarity index 100%
rename from drivers/soc/tegra/fuse/fuse-tegra.c
rename to drivers/efuse/tegra/fuse-tegra.c
diff --git a/drivers/soc/tegra/fuse/fuse-tegra20.c 
b/drivers/efuse/tegra/fuse-tegra20.c
similarity index 100%
rename from drivers/soc/tegra/fuse/fuse-tegra20.c
rename to drivers/efuse/tegra/fuse-tegra20.c
diff --git a/drivers/soc/tegra/fuse/fuse-tegra30.c 
b/drivers/efuse/tegra/fuse-tegra30.c
similarity index 100%
rename from drivers/soc/tegra/fuse/fuse-tegra30.c
rename to drivers/efuse/tegra/fuse-tegra30.c
diff --git a/drivers/soc/tegra/fuse/fuse.h b/drivers/efuse/tegra/fuse.h
similarity index 100%
rename from drivers/soc/tegra/fuse/fuse.h
rename to drivers/efuse/tegra/fuse.h
diff --git a/drivers/soc/tegra/fuse/speedo-tegra114.c 
b/drivers/efuse/tegra/speedo-tegra114.c
similarity index 100%
rename from drivers/soc/tegra/fuse/speedo-tegra114.c
rename to drivers/efuse/tegra/speedo-tegra114.c
diff --git a/drivers/soc/tegra/fuse/speedo-tegra124.c 
b/drivers/efuse/tegra/speedo-tegra124.c
similarity index 100%
rename from drivers/soc/tegra/fuse/speedo-tegra124.c
rename to drivers/efuse/tegra/speedo-tegra124.c
diff --git a/drivers/soc/tegra/fuse/speedo-tegra20.c 
b/drivers/efuse/tegra/speedo-tegra20.c
similarity index 100%
rename from drivers/soc/tegra/fuse/speedo-tegra20.c
rename to drivers/efuse/tegra/speedo-tegra20.c
diff --git a/drivers/soc/tegra/fuse/speedo-tegra30.c 
b/drivers/efuse/tegra/speedo-tegra30.c
similarity index 100%
rename from drivers/soc/tegra/fuse/speedo-tegra30.c
rename to drivers/efuse/tegra/speedo-tegra30.c
diff --git a/drivers/soc/tegra/fuse/tegra-apbmisc.c 
b/drivers/efuse/tegra/tegra-apbmisc.c
similarity index 100%
rename from drivers/soc/tegra/fuse/tegra-apbmisc.c
rename to drivers/efuse/tegra/tegra-apbmisc.c
diff --git a/drivers/soc/tegra/Makefile b/drivers/soc/tegra/Makefile
index cdaad9d..23a0f64 100644
--- a/drivers/soc/tegra/Makefile
+++ b/drivers/soc/tegra/Makefile
@@ -1,4 +1,2 @@
-obj-$(CONFIG_ARCH_TEGRA) += fuse/
-
 obj-$(CONFIG_ARCH_TEGRA) += common.o
 obj-$(CONFIG_ARCH_TEGRA) += pmc.o
-- 
2.3.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org

[PATCH 0/7] New eFuse subsystem

[Ezequiel Garcia]

This patchset introduces a new driver subsystem, meant to support eFuse
(alias OTP, one-time-programmable) devices.

The motivation behind this work is to have a common place for drivers
that are currently more or less scattered: the tegra efuses are in
drivers/soc/ and the sunxi efuses in drivers/misc/eeprom.

For now, there's no proposal for a generic efuse API. Instead, we simply
group the drivers together.

This patchset is the result of the initial submission for IMG Pistachio
eFuse support [1]. Our first proposal was to follow the Tegra efuse, and
put the Pistachio efuse in drivers/soc. After some discussion we finally
agreed [2] to first create an efuse directoy, and then put all efuse drivers
in it.

As always, all comments are welcome!

[1] http://www.spinics.net/lists/devicetree/msg59246.html
[2] http://www.spinics.net/lists/arm-kernel/msg389325.html

Ezequiel Garcia (7):
  soc: tegra: Add missing include linux/types.h
  soc: tegra: Move the fuse header to a separate directory
  drivers: Introduce new eFuse subsystem stub
  efuse: Move Tegra efuse driver
  ARM: tegra: Make sure efuse is always selected
  efuse: Move Sunxi fuse driver
  ARM: sunxi: Rename EFUSE_SUNXI option in defconfigs

 arch/arm/configs/multi_v7_defconfig|  2 +-
 arch/arm/configs/sunxi_defconfig   |  2 +-
 arch/arm/mach-tegra/Kconfig|  1 +
 arch/arm/mach-tegra/cpuidle.c  |  3 +--
 arch/arm/mach-tegra/flowctrl.c |  3 +--
 arch/arm/mach-tegra/hotplug.c  |  2 +-
 arch/arm/mach-tegra/platsmp.c  |  2 +-
 arch/arm/mach-tegra/pm.c   |  2 +-
 arch/arm/mach-tegra/reset-handler.S|  3 +--
 arch/arm/mach-tegra/reset.c|  3 +--
 arch/arm/mach-tegra/sleep-tegra30.S|  3 +--
 arch/arm/mach-tegra/tegra.c|  2 +-
 drivers/Kconfig|  2 ++
 drivers/Makefile   |  1 +
 drivers/ata/ahci_tegra.c   |  2 +-
 drivers/clk/tegra/clk-periph-gate.c|  3 +--
 drivers/clk/tegra/clk.c|  3 +--
 drivers/efuse/Kconfig  | 22 ++
 drivers/efuse/Makefile |  2 ++
 drivers/{misc/eeprom => efuse}/sunxi_sid.c |  0
 drivers/{soc/tegra/fuse => efuse/tegra}/Makefile   |  0
 .../{soc/tegra/fuse => efuse/tegra}/fuse-tegra.c   |  2 +-
 .../{soc/tegra/fuse => efuse/tegra}/fuse-tegra20.c |  3 +--
 .../{soc/tegra/fuse => efuse/tegra}/fuse-tegra30.c |  3 +--
 drivers/{soc/tegra/fuse => efuse/tegra}/fuse.h |  0
 .../tegra/fuse => efuse/tegra}/speedo-tegra114.c   |  3 +--
 .../tegra/fuse => efuse/tegra}/speedo-tegra124.c   |  3 +--
 .../tegra/fuse => efuse/tegra}/speedo-tegra20.c|  3 +--
 .../tegra/fuse => efuse/tegra}/speedo-tegra30.c|  3 +--
 .../tegra/fuse => efuse/tegra}/tegra-apbmisc.c |  3 +--
 drivers/gpu/drm/nouveau/nouveau_platform.c |  2 +-
 drivers/misc/eeprom/Kconfig| 13 -
 drivers/misc/eeprom/Makefile   |  1 -
 drivers/soc/tegra/Makefile |  2 --
 drivers/soc/tegra/pmc.c|  2 +-
 drivers/thermal/tegra_soctherm.c   |  3 +--
 include/{soc/tegra/fuse.h => linux/efuse/tegra.h}  |  2 ++
 37 files changed, 55 insertions(+), 56 deletions(-)
 create mode 100644 drivers/efuse/Kconfig
 create mode 100644 drivers/efuse/Makefile
 rename drivers/{misc/eeprom => efuse}/sunxi_sid.c (100%)
 rename drivers/{soc/tegra/fuse => efuse/tegra}/Makefile (100%)
 rename drivers/{soc/tegra/fuse => efuse/tegra}/fuse-tegra.c (99%)
 rename drivers/{soc/tegra/fuse => efuse/tegra}/fuse-tegra20.c (99%)
 rename drivers/{soc/tegra/fuse => efuse/tegra}/fuse-tegra30.c (99%)
 rename drivers/{soc/tegra/fuse => efuse/tegra}/fuse.h (100%)
 rename drivers/{soc/tegra/fuse => efuse/tegra}/speedo-tegra114.c (98%)
 rename drivers/{soc/tegra/fuse => efuse/tegra}/speedo-tegra124.c (99%)
 rename drivers/{soc/tegra/fuse => efuse/tegra}/speedo-tegra20.c (99%)
 rename drivers/{soc/tegra/fuse => efuse/tegra}/speedo-tegra30.c (99%)
 rename drivers/{soc/tegra/fuse => efuse/tegra}/tegra-apbmisc.c (98%)
 rename include/{soc/tegra/fuse.h => linux/efuse/tegra.h} (98%)

-- 
2.3.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH v3 00/26] Early kprobe: enable kprobes at very early booting stage.

[Wang Nan]

On 2015/2/25 19:11, Wang Nan wrote:
> On 2015/2/20 11:59, Masami Hiramatsu wrote:
>> Hi,
>>
>> Sorry for replying late.
>>
>> (2015/02/13 14:39), Wang Nan wrote:
>>> I fell very sorry for people who reviewed my v2 patch series yesterday
>>> at https://lkml.org/lkml/2015/2/12/234 because I didn't provide enough
>>> information in commit log. This v3 patch series add those missing
>>> commit messages. There are also 2 small fix based on v2:
>>>
>>>  1. Fixes ftrace_sort_mcount_area. Original patch doesn't work for module.
>>>  2. Wraps setting of kprobes_initialized in stop_machine() context.
>>
>> From the viewpoint of the maintenance, it seems over-engineered and
>> not general implementation. Please reconsider just initializing breakpoint
>> handler in earlier stage. Since those exceptions may happen anywhere,
>> those trap handlers setup very early stage. E.g. on x86, setup_arch()
>> setup early_trap_init() at beginning. So we just need to initialize
>> kprobes earlier.
> 
> I tried as your suggestion. For x86, int3 handler doesn't work correctly until
> trap_init(). I don't have enough time to look into this problem today (and I 
> don't
> familiar with x86 architecture). Could you please have a look on it?
> 
> Thank you.
> 

Hi Masami,

Sorry for the noise. I have futher information may be useful.

I initialize kprobe and probed an instruction with int3 between setup_arch() and
trap_init(). It doesn't work at first. By dumping __log_buf[] I fount it 
reports NULL pointer panic.
With some random test I found following patch, which makes it works (looks 
like) correctly.

However I think there must be some reason to set dpl to '3' instead of '0' 
(set_mni_gate
use 0 as dpl). Do you have any suggestion on it?

Thank you.

- The patch ---
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 9d2073e..ac29277 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -925,9 +925,9 @@ dotraplinkage void do_iret_error(struct pt_regs *regs, long 
error_code)
 /* Set of traps needed for early debugging. */
 void __init early_trap_init(void)
 {
-   set_intr_gate_ist(X86_TRAP_DB, , DEBUG_STACK);
+   set_intr_gate_ist(X86_TRAP_DB, , 0);
/* int3 can be called from all */
-   set_system_intr_gate_ist(X86_TRAP_BP, , DEBUG_STACK);
+   set_intr_gate_ist(X86_TRAP_BP, , 0);
 #ifdef CONFIG_X86_32
set_intr_gate(X86_TRAP_PF, page_fault);
 #endif


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/7] drivers: Introduce new eFuse subsystem stub

[Ezequiel Garcia]

This commit introduces a new eFuse subsystem stub to hold all the eFuse-like
device drivers. This will be used to host the currently supported Tegra
eFuse driver, and will allow to add support for other platforms as well.

Cc: Thierry Reding 
Cc: Stephen Warren 
Cc: Maxime Ripard 
Cc: Arnd Bergmann 
Cc: Stefan Wahren 
Signed-off-by: Ezequiel Garcia 
---
 drivers/Kconfig| 2 ++
 drivers/Makefile   | 1 +
 drivers/efuse/Kconfig  | 3 +++
 drivers/efuse/Makefile | 0
 4 files changed, 6 insertions(+)
 create mode 100644 drivers/efuse/Kconfig
 create mode 100644 drivers/efuse/Makefile

diff --git a/drivers/Kconfig b/drivers/Kconfig
index c0cc96b..9c0d93d 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -146,6 +146,8 @@ source "drivers/remoteproc/Kconfig"
 
 source "drivers/rpmsg/Kconfig"
 
+source "drivers/efuse/Kconfig"
+
 source "drivers/soc/Kconfig"
 
 source "drivers/devfreq/Kconfig"
diff --git a/drivers/Makefile b/drivers/Makefile
index 527a6da..5572728 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -34,6 +34,7 @@ obj-y += amba/
 obj-$(CONFIG_DMADEVICES)   += dma/
 
 # SOC specific infrastructure drivers.
+obj-y  += efuse/
 obj-y  += soc/
 
 obj-$(CONFIG_VIRTIO)   += virtio/
diff --git a/drivers/efuse/Kconfig b/drivers/efuse/Kconfig
new file mode 100644
index 000..617476f
--- /dev/null
+++ b/drivers/efuse/Kconfig
@@ -0,0 +1,3 @@
+menu "eFuse drivers"
+
+endmenu
diff --git a/drivers/efuse/Makefile b/drivers/efuse/Makefile
new file mode 100644
index 000..e69de29
-- 
2.3.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Re: [PATCH v2 3/3] efi: Capsule update with user helper interface

[Borislav Petkov]

On Tue, Feb 24, 2015 at 12:49:09PM +, Kweh, Hock Leong wrote:
> So the process steps basically look like this:
> 1.) cat capsule_ticket===> acquire a number and lock mutex then
>  expose 
> firmware_class user helper
>  
> interface as well as start timer for timeout
>  counting
> 2.) repeat step 1 if obtained a "0" number
> 3.) echo 1 > loading
> 4.) cat bin > data
> 5.) echo 0 > loading===> stop the timeout counting  then unlock
>   mutex 
> at the end of callback routine 
> 6.) cat capsule_report   ===> grep the number acquired from beginning
>   for 
> checking succeeded/failed

So this sounds pretty overengineered for no reason, or maybe I'm missing
the reason.

If I had to give an example from the microcode loader, what we do there
is put the microcode in /lib/firmware/... and do

echo 1 > /sys/devices/system/cpu/microcode/reload

which goes and calls reload_store() in
arch/x86/kernel/cpu/microcode/core.c which grabs a mutex, disables CPU
hotplug, etc, etc...

And this mechanism is as simple as it can get. Maybe capsules can be
loaded like that too?

Error code can be propagated too, if needed, of course.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 5/7] ARM: tegra: Make sure efuse is always selected

[Ezequiel Garcia]

After the introduction of the efuse subsystem, platforms are now required
to select the efuse support explicitly.

Cc: Stephen Warren 
Cc: Thierry Reding 
Cc: Alexandre Courbot 
Signed-off-by: Ezequiel Garcia 
---
 arch/arm/mach-tegra/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index 5d1a318..114ea4e 100644
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@ -11,6 +11,7 @@ menuconfig ARCH_TEGRA
select ARCH_HAS_RESET_CONTROLLER
select RESET_CONTROLLER
select SOC_BUS
+   select EFUSE_TEGRA
select USB_ULPI if USB_PHY
select USB_ULPI_VIEWPORT if USB_PHY
help
-- 
2.3.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 6/7] efuse: Move Sunxi fuse driver

[Ezequiel Garcia]

The Sunxi SoC eFuse support is currently located under drivers/eeprom,
although the driver is not an eeprom. This commit just moves the driver
to drivers/efuse. There's no functionality change.

Cc: Maxime Ripard 
Signed-off-by: Ezequiel Garcia 
---
 drivers/efuse/Kconfig  | 12 
 drivers/efuse/Makefile |  1 +
 drivers/{misc/eeprom => efuse}/sunxi_sid.c |  0
 drivers/misc/eeprom/Kconfig| 13 -
 drivers/misc/eeprom/Makefile   |  1 -
 5 files changed, 13 insertions(+), 14 deletions(-)
 rename drivers/{misc/eeprom => efuse}/sunxi_sid.c (100%)

diff --git a/drivers/efuse/Kconfig b/drivers/efuse/Kconfig
index b84e06b..a91a16e 100644
--- a/drivers/efuse/Kconfig
+++ b/drivers/efuse/Kconfig
@@ -6,5 +6,17 @@ config EFUSE_TEGRA
help
  Support for the eFuses available on Tegra SoCs
 
+config EFUSE_SUNXI_SID
+   tristate "Allwinner sunxi security ID support"
+   depends on ARCH_SUNXI && SYSFS
+   help
+ This is a driver for the 'security ID' available on various Allwinner
+ devices.
+
+ Due to the potential risks involved with changing e-fuses,
+ this driver is read-only.
+
+ This driver can also be built as a module. If so, the module
+ will be called sunxi_sid.
 
 endmenu
diff --git a/drivers/efuse/Makefile b/drivers/efuse/Makefile
index b69a0d6..30f8d5e 100644
--- a/drivers/efuse/Makefile
+++ b/drivers/efuse/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_EFUSE_TEGRA)  += tegra/
+obj-$(CONFIG_EFUSE_SUNXI_SID)  += sunxi_sid.o
diff --git a/drivers/misc/eeprom/sunxi_sid.c b/drivers/efuse/sunxi_sid.c
similarity index 100%
rename from drivers/misc/eeprom/sunxi_sid.c
rename to drivers/efuse/sunxi_sid.c
diff --git a/drivers/misc/eeprom/Kconfig b/drivers/misc/eeprom/Kconfig
index 9536852f..04f2e1f 100644
--- a/drivers/misc/eeprom/Kconfig
+++ b/drivers/misc/eeprom/Kconfig
@@ -96,17 +96,4 @@ config EEPROM_DIGSY_MTC_CFG
 
  If unsure, say N.
 
-config EEPROM_SUNXI_SID
-   tristate "Allwinner sunxi security ID support"
-   depends on ARCH_SUNXI && SYSFS
-   help
- This is a driver for the 'security ID' available on various Allwinner
- devices.
-
- Due to the potential risks involved with changing e-fuses,
- this driver is read-only.
-
- This driver can also be built as a module. If so, the module
- will be called sunxi_sid.
-
 endmenu
diff --git a/drivers/misc/eeprom/Makefile b/drivers/misc/eeprom/Makefile
index 9507aec..fc1e81d 100644
--- a/drivers/misc/eeprom/Makefile
+++ b/drivers/misc/eeprom/Makefile
@@ -4,5 +4,4 @@ obj-$(CONFIG_EEPROM_LEGACY) += eeprom.o
 obj-$(CONFIG_EEPROM_MAX6875)   += max6875.o
 obj-$(CONFIG_EEPROM_93CX6) += eeprom_93cx6.o
 obj-$(CONFIG_EEPROM_93XX46)+= eeprom_93xx46.o
-obj-$(CONFIG_EEPROM_SUNXI_SID) += sunxi_sid.o
 obj-$(CONFIG_EEPROM_DIGSY_MTC_CFG) += digsy_mtc_eeprom.o
-- 
2.3.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/