Yun Wu | 30 Jan 08:46 2015

[PATCH 0/5] enhance configuring an ITS

This patch series makes some enhancement to ITS configuration in the
following three aspects:

o allocation of the ITS tables
o replacing magic numbers with sensible macros
o supporting ITS power down

This patch series is based on linux 3.19-rc6, and tested on Hisilion
ARM64 board with GICv3 ITS hardware.

Yun Wu (5):
  irqchip: gicv3-its: allocate proper size for DT
  irqchip: gicv3-its: zero itt before handling to hardware
  irqchip: gicv3-its: use 64KB page as default granule
  irqchip: gicv3-its: define macros for GITS_CTLR fields
  irqchip: gicv3-its: add support for power down

 drivers/irqchip/irq-gic-v3-its.c   | 90 ++++++++++++++++++++++++++++++++++----
 include/linux/irqchip/arm-gic-v3.h |  3 ++
 2 files changed, 85 insertions(+), 8 deletions(-)

--
1.8.0

Stephen Rothwell | 30 Jan 08:02 2015
Picon
Picon

linux-next: Tree for Jan 30

Hi all,

Changes since 20150129:

The arm-soc gained conflicts against the arm-current and arm trees.

The spi tree gained a build failure for which I reverted a commit.

Non-merge commits (relative to Linus' tree): 6300
 6348 files changed, 255117 insertions(+), 131620 deletions(-)

----------------------------------------------------------------------------

I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a
multi_v7_defconfig for arm. After the final fixups (if any), it is also
built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and
allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm
defconfig.

(Continue reading)

Wang, Yalin | 30 Jan 07:14 2015

[RFC] mm:change /proc/smaps caculation behavior

This patch change smaps pagetable walk behavior, to make
sure not skip VM_PFNMAP pagetables,
so that we can calculate COW pages of VM_PFNMAP as normal pages.

Signed-off-by: Yalin Wang <yalin.wang <at> sonymobile.com>
---
 fs/proc/task_mmu.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index c7267e9..00a5b73 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
 <at>  <at>  -503,6 +503,15  <at>  <at>  static void smaps_pte_entry(pte_t *pte, unsigned long addr,
 	smaps_account(mss, page, PAGE_SIZE, pte_young(*pte), pte_dirty(*pte));
 }

+static int smaps_test_walk(unsigned long addr, unsigned long next,
+		struct mm_walk *walk)
+{
+	/*
+	 * don't skip VM_PFNMAP, so that we can caculate some COW pages.
+	 */
+	return 0;
+}
+
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
 static void smaps_pmd_entry(pmd_t *pmd, unsigned long addr,
 		struct mm_walk *walk)
 <at>  <at>  -616,6 +625,7  <at>  <at>  static int show_smap(struct seq_file *m, void *v, int is_pid)
(Continue reading)

Peter Hung | 30 Jan 07:13 2015
Picon

[PATCH v4 1/7] usb: serial: modify bulk-in/out size for F81232

The F81232 real bulk-in/out ep buffer size is 64Bytes

Signed-off-by: Peter Hung <hpeter+linux_kernel <at> gmail.com>
---
 drivers/usb/serial/f81232.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index c5dc233..4f42e9d 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
 <at>  <at>  -304,8 +304,8  <at>  <at>  static struct usb_serial_driver f81232_device = {
 	},
 	.id_table =		id_table,
 	.num_ports =		1,
-	.bulk_in_size =		256,
-	.bulk_out_size =	256,
+	.bulk_in_size =		64,
+	.bulk_out_size =	64,
 	.open =			f81232_open,
 	.close =		f81232_close,
 	.dtr_rts = 		f81232_dtr_rts,
--

-- 
1.9.1

Lee, Chun-Yi | 30 Jan 04:58 2015
Picon

[PATCH] x86/mm, hibernate: Fix misjudgment of register setup_data page to nosave region

The reserve setup_data action break usable regions to not align to
page size. As following case:

BIOS-e820: [mem 0x0000000000088000-0x00000000000bffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x0000000094caffff] usable
...
e820: update [mem 0x93c5f018-0x93c6f057] usable ==> usable	/* reserve setup_data */
e820: update [mem 0x93c4f018-0x93c5e057] usable ==> usable	/* reserve setup_data */
...
reserve setup_data: [mem0x0000000000088000-0x00000000000bffff] reserved
reserve setup_data: [mem0x0000000000100000-0x0000000093c4f017] usable /* not align */
reserve setup_data: [mem0x0000000093c4f018-0x0000000093c5e057] usable /* not align */
reserve setup_data: [mem0x0000000093c5e058-0x0000000093c5f017] usable /* not align */
reserve setup_data: [mem0x0000000093c5f018-0x0000000093c6f057] usable /* not align */
reserve setup_data: [mem0x0000000093c6f058-0x0000000094caffff] usable

The codes in e820_mark_nosave_regions() check pfn of each e820
entry to find out the hole between two entries then register it to
nosave region. This logic misjudges the non-align but continuous usable
region, then register one page in usable region to nosave. As following:

PM: Registered nosave memory: [mem 0x000c0000-0x000fffff]
PM: Registered nosave memory: [mem 0x93c4f000-0x93c4ffff] /* misjudgment */
PM: Registered nosave memory: [mem 0x93c5e000-0x93c5efff] /* misjudgment */
PM: Registered nosave memory: [mem 0x93c5f000-0x93c5ffff] /* misjudgment */
PM: Registered nosave memory: [mem 0x93c6f000-0x93c6ffff] /* misjudgment */
PM: Registered nosave memory: [mem 0x94cb0000-0x960affff]

The issue causes some usable pages didn't collect to hibernate snapshot image.
And, it also misjudges a usable page in nosave regions then hibernate resuming
(Continue reading)

Guenter Roeck | 30 Jan 04:15 2015
Picon

[PATCH] arc: mm: Fix build failure

Fix misspelled define.

Fixes: 33692f27597f ("vm: add VM_FAULT_SIGSEGV handling support")
Cc: Linus Torvalds <torvalds <at> linux-foundation.org>
Signed-off-by: Guenter Roeck <linux <at> roeck-us.net>
---
 arch/arc/mm/fault.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arc/mm/fault.c b/arch/arc/mm/fault.c
index 0f8df3b..563cb27 100644
--- a/arch/arc/mm/fault.c
+++ b/arch/arc/mm/fault.c
 <at>  <at>  -161,7 +161,7  <at>  <at>  good_area:

 	if (fault & VM_FAULT_OOM)
 		goto out_of_memory;
-	else if (fault & VM_FAULT_SIGSEV)
+	else if (fault & VM_FAULT_SIGSEGV)
 		goto bad_area;
 	else if (fault & VM_FAULT_SIGBUS)
 		goto do_sigbus;
--

-- 
2.1.0

Bryan O'Donoghue | 30 Jan 04:05 2015
Picon

[PATCH v7 0/2] x86: Add IMR support to Quark/Galileo

This patchset adds support for Isolated Memory Regions to the kernel.

Quark SoC X1000 contains a set of registers called Isolated Memory Regions.
IMRs provide fine grained memory access control to various system agents
within the SoC such as CPU SMM/non-SMM mode, PCIe virtual channels, CPU
snoop cycles, eSRAM flush cycles and the RMU. In simple terms, IMRs provide
a mechanism to protect memory regions from unwarranted access by system
agents that should not have access to that memory.

IMRs support a lock bit. Once a lock bit is set for an individual IMR it is
not possible to tear down that IMR without performing a cold boot of the
system. IMRs support reporting of violations. The SoC system can be
configured to reboot immediately when an IMR violation has taken place.
Immediate reboot of the system on IMR violation is recommended and is
currently how Quark BIOS configures the system.

An example of IMRs in use is given with Arduino compatiable Galileo boards
which ship with an IMR around the ACPI runtime services memory. If a DMA
read/write cycle were to occur to this region of memory this would trigger
the IMR violation mechansim.

As part of the IMR init code all unlocked IMRs are removed to ensure the
EFI memory map and IMR memory map are consistent. This is necessary since at
various stages during the boot of Quark systems firmware and second stage
bootloader will place unlocked IMRs around various assets in memory, with
the expectation that subsequent phases of boot will tear-down unlocked/stale
IMRs before proceeding. The kernel needs to tear-down unlocked IMRs placed
around the boot params structure and compressed kernel in memory. Without
doing so DMA addresses given out by the kernel to DMA capable hardware runs
the risk of triggering an IMR fault when DMA happens to those addresses.
(Continue reading)

Namhyung Kim | 30 Jan 03:33 2015

[PATCH 1/3] perf test: Fix dso cache testcase

The current dso cache permits to keep dso->data.fd is open under a
half of open file limit.  But test__dso_data_cache() sets dso_cnt to
limit / 2 + 1 so it'll reach the limit in the loop even though the
loop count is one less than the dso_cnt and it makes the final
dso__data_fd() after the loop meaningless.

I guess the intention was dsos[0]->data.fd is open before the last
open and gets closed after it.  So add an assert before the last open.

Signed-off-by: Namhyung Kim <namhyung <at> kernel.org>
---
 tools/perf/tests/dso-data.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/tools/perf/tests/dso-data.c b/tools/perf/tests/dso-data.c
index caaf37f079b1..22a8c428283a 100644
--- a/tools/perf/tests/dso-data.c
+++ b/tools/perf/tests/dso-data.c
 <at>  <at>  -243,8 +243,8  <at>  <at>  int test__dso_data_cache(void)
 	limit = nr * 4;
 	TEST_ASSERT_VAL("failed to set file limit", !set_fd_limit(limit));

-	/* and this is now our dso open FDs limit + 1 extra */
-	dso_cnt = limit / 2 + 1;
+	/* and this is now our dso open FDs limit */
+	dso_cnt = limit / 2;
 	TEST_ASSERT_VAL("failed to create dsos\n",
 		!dsos__create(dso_cnt, TEST_FILE_SIZE));

 <at>  <at>  -268,7 +268,10  <at>  <at>  int test__dso_data_cache(void)
(Continue reading)

Greg KH | 30 Jan 02:54 2015

Linux 3.10.67

I'm announcing the release of the 3.10.67 kernel.

All users of the 3.10 kernel series must upgrade.

The updated 3.10.y git tree can be found at:
	git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.10.y
and can be browsed at the normal kernel.org git web browser:
	http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h

------------

 Makefile                                   |    2 
 arch/arm/boot/dts/imx25.dtsi               |    8 +-
 arch/arm/crypto/aes_glue.c                 |    4 -
 arch/arm/crypto/sha1_glue.c                |    2 
 arch/powerpc/crypto/sha1.c                 |    3 
 arch/s390/crypto/aes_s390.c                |    2 
 arch/s390/crypto/des_s390.c                |    4 -
 arch/s390/crypto/ghash_s390.c              |    2 
 arch/s390/crypto/sha1_s390.c               |    2 
 arch/s390/crypto/sha256_s390.c             |    4 -
 arch/s390/crypto/sha512_s390.c             |    4 -
 arch/sparc/crypto/aes_glue.c               |    2 
 arch/sparc/crypto/camellia_glue.c          |    2 
 arch/sparc/crypto/crc32c_glue.c            |    2 
 arch/sparc/crypto/des_glue.c               |    2 
(Continue reading)

Bjorn Andersson | 30 Jan 02:51 2015

[PATCH] mfd: devicetree: bindings: Add Qualcomm RPM regulator subnodes

Add the regulator subnodes to the Qualcomm RPM MFD device tree bindings.

Signed-off-by: Bjorn Andersson <bjorn.andersson <at> sonymobile.com>
---
After discussing this back and forth we've concluded that we should be
future compatible with these bindings, so let's make an attempt to make
it possible to use the Qualcomm family A regulators.

 Documentation/devicetree/bindings/mfd/qcom-rpm.txt | 184 +++++++++++++++++++++
 1 file changed, 184 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/qcom-rpm.txt b/Documentation/devicetree/bindings/mfd/qcom-rpm.txt
index 85e3198..816acda 100644
--- a/Documentation/devicetree/bindings/mfd/qcom-rpm.txt
+++ b/Documentation/devicetree/bindings/mfd/qcom-rpm.txt
 <at>  <at>  -52,6 +52,177  <at>  <at>  frequencies.
 		    - u32 representing the ipc bit within the register

 
+= SUBDEVICES
+
+The RPM exposes resources to its subnodes. The below bindings specify the set
+of valid subnodes that can operate on these resources.
+
+== Switch-mode Power Supply regulator
+
+- compatible:
+	Usage: required
+	Value type: <string>
+	Definition: must be one of:
(Continue reading)

kbuild test robot | 30 Jan 01:43 2015
Picon

[rcu:rcu/dev 35/36] kernel/sched/idle.c:184:1: sparse: symbol '__pcpu_scope_cpu_dead_idle' was not declared. Should it be static?

tree:   git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git rcu/dev
head:   c0d4bae9db364cdb6e1cabad45a045a04d99cf51
commit: 86166c3e1e073e5e037d97bc51c66ef3fe1e90a4 [35/36] cpu: Make CPU-offline idle-loop
transition point more precise
reproduce:
  # apt-get install sparse
  git checkout 86166c3e1e073e5e037d97bc51c66ef3fe1e90a4
  make ARCH=x86_64 allmodconfig
  make C=1 CF=-D__CHECK_ENDIAN__

sparse warnings: (new ones prefixed by >>)

>> kernel/sched/idle.c:184:1: sparse: symbol '__pcpu_scope_cpu_dead_idle' was not declared. Should
it be static?

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructure                Open Source Technology Center
http://lists.01.org/mailman/listinfo/kbuild                 Intel Corporation

Gmane