Fabian Frederick | 24 Jul 10:18 2014

[PATCH 00/10 linux-next] drivers/usb: remove unnecessary break after goto/return

Small patchset addressing break redundancy on drivers/usb branch
(suggested by Joe Perches).

Fabian Frederick (10):
  USB: iowarrior: remove unnecessary break after goto
  USB: usblcd: remove unnecessary break after return
  usb: dcw3: remove unnecessary break after return
  usb: gadget: remove unnecessary break after return
  usb: gadget: remove unnecessary break after goto
  xhci: remove unnecessary break after return
  usb: storage: remove unnecessary break after return
  USB: serial: remove unnecessary break after return
  USB: ftdi_sio: remove unnecessary break after return
  USB: microtek: remove unnecessary break after goto

 drivers/usb/dwc3/ep0.c                     | 2 --
 drivers/usb/gadget/function/f_hid.c        | 8 --------
 drivers/usb/gadget/legacy/tcm_usb_gadget.c | 2 --
 drivers/usb/host/xhci-mem.c                | 1 -
 drivers/usb/image/microtek.c               | 1 -
 drivers/usb/misc/iowarrior.c               | 3 ---
 drivers/usb/misc/usblcd.c                  | 1 -
 drivers/usb/serial/ftdi_sio.c              | 1 -
 drivers/usb/serial/iuu_phoenix.c           | 2 --
 drivers/usb/storage/freecom.c              | 1 -
 10 files changed, 22 deletions(-)



(Continue reading)

Sukadev Bhattiprolu | 24 Jul 09:46 2014

[RFC PATCH 0/2] powerpc/perf: Implement get_cpu_str()

These two patches implement get_cpu_str() for powerpc.

get_cpu_str() will allow users to cache their perf event JSON files
and skip having to specify the --events-file with each perf invocation.

These patches are based on the commit

	commit 4a5e890
	Author: Andi Kleen <ak <at> linux.intel.com>
	Date:   Fri Jun 13 15:14:14 2014 -0700

	    perf, tools: Add a --no-desc flag to perf list

in Andi Kleen's tree


At this point, I am mostly looking for feedback on the changes around
cache_cpu_str() and the get_cpu_str().

Zhang Zhen | 24 Jul 09:41 2014

[PATCH] memory-hotplug: add sysfs zone_index attribute

Currently memory-hotplug has two limits:
1. If the memory block is in ZONE_NORMAL, you can change it to
ZONE_MOVABLE, but this memory block must be adjacent to ZONE_MOVABLE.
2. If the memory block is in ZONE_MOVABLE, you can change it to
ZONE_NORMAL, but this memory block must be adjacent to ZONE_NORMAL.

Without this patch, we don't know which zone a memory block is in.
So we don't know which memory block is adjacent to ZONE_MOVABLE or

On the other hand, with this patch, we can easy to know newly added
memory is added as ZONE_NORMAL (for powerpc, ZONE_DMA, for x86_32,

Updated the related Documentation.

Signed-off-by: Zhang Zhen <zhenzhang.zhang <at> huawei.com>
 Documentation/ABI/testing/sysfs-devices-memory |  9 +++++++++
 Documentation/memory-hotplug.txt               |  4 +++-
 drivers/base/memory.c                          | 15 ++++++++++++++-
 3 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-devices-memory b/Documentation/ABI/testing/sysfs-devices-memory
index 7405de2..39d3423 100644
--- a/Documentation/ABI/testing/sysfs-devices-memory
+++ b/Documentation/ABI/testing/sysfs-devices-memory
 <at>  <at>  -61,6 +61,15  <at>  <at>  Users:		hotplug memory remove tools

(Continue reading)

Alexander Stein | 24 Jul 09:05 2014

[PATCH] arm/mach-imx/iomux: Do not export symbol without public declaration

The iomux function declarations are in headers only accessible in this
directory. Thus those can't be used in any module. None of the
objects in this directory is tristate. Neither can the header be included
in out-of-tree modules.

Signed-off-by: Alexander Stein <alexander.stein <at> systec-electronic.com>
 arch/arm/mach-imx/iomux-imx31.c | 7 -------
 arch/arm/mach-imx/iomux-v1.c    | 2 --
 arch/arm/mach-imx/iomux-v3.c    | 2 --
 3 files changed, 11 deletions(-)

diff --git a/arch/arm/mach-imx/iomux-imx31.c b/arch/arm/mach-imx/iomux-imx31.c
index 7c66805d2cc0..1657fe64cd0f 100644
--- a/arch/arm/mach-imx/iomux-imx31.c
+++ b/arch/arm/mach-imx/iomux-imx31.c
 <at>  <at>  -64,7 +64,6  <at>  <at>  int mxc_iomux_mode(unsigned int pin_mode)

 	return ret;

  * This function configures the pad value for a IOMUX pin.
 <at>  <at>  -90,7 +89,6  <at>  <at>  void mxc_iomux_set_pad(enum iomux_pins pin, u32 config)


(Continue reading)

Sam Bobroff | 24 Jul 08:56 2014

Re: [PATCH V3 2/3] powerpc, ptrace: Enable support for transactional memory register sets

On 24/05/14 01:15, Anshuman Khandual wrote:
> This patch enables get and set of transactional memory related register
> sets through PTRACE_GETREGSET/PTRACE_SETREGSET interface by implementing
> four new powerpc specific register sets i.e REGSET_TM_SPR, REGSET_TM_CGPR,
> REGSET_TM_CFPR, REGSET_CVMX support corresponding to these following new
> ELF core note types added previously in this regard.
> 	(1) NT_PPC_TM_SPR
> Signed-off-by: Anshuman Khandual <khandual <at> linux.vnet.ibm.com>

Hi Anshuman,

I'm not Ben but I've reviewed your patch as well as I can and I have
some comments that might be useful to you.

First of all, I couldn't get this to compile without CONFIG_VSX and
CONFIG_PPC_TRANSACTIONAL_MEM defined: there are obvious typos ("esle"
instead of "else") and references to fields that aren't defined for
those cases. I haven't mentioned any of those issues below as the
compiler will do that but you should definitely test those configurations.

Also some of the code seems to assume that if CONFIG_VSX is defined then
CONFIG_PPC_TRANSACTIONAL_MEM must also be defined, but that isn't the
case (it's the other way round: CONFIG_PPC_TRANSACTIONAL_MEM implies

(Continue reading)

Sam Bobroff | 24 Jul 08:52 2014

Re: [PATCH V3 0/3] Add new PowerPC specific ELF core notes

On 24/05/14 01:15, Anshuman Khandual wrote:
> 	This patch series adds five new ELF core note sections which can be
> used with existing ptrace request PTRACE_GETREGSET/SETREGSET for accessing
> various transactional memory and miscellaneous register sets on PowerPC
> platform. Please find a test program exploiting these new ELF core note
> types on a POWER8 system.
> RFC: https://lkml.org/lkml/2014/4/1/292
> V1:  https://lkml.org/lkml/2014/4/2/43
> V2:  https://lkml.org/lkml/2014/5/5/88
> Changes in V3
> =============
> (1) Added two new error paths in every TM related get/set functions when regset
>     support is not present on the system (ENODEV) or when the process does not
>     have any transaction active (ENODATA) in the context
> (2) Installed the active hooks for all the newly added regset core note types
> Changes in V2
> =============
> (1) Removed all the power specific ptrace requests corresponding to new NT_PPC_*
>     elf core note types. Now all the register sets can be accessed from ptrace
>     through PTRACE_GETREGSET/PTRACE_SETREGSET using the individual NT_PPC* core
>     note type instead
> (2) Fixed couple of attribute values for REGSET_TM_CGPR register set
> (3) Renamed flush_tmreg_to_thread as flush_tmregs_to_thread
> (4) Fixed 32 bit checkpointed GPR support
> (5) Changed commit messages accordingly
(Continue reading)

Andy Lutomirski | 24 Jul 06:57 2014

[PATCH v5 0/5] random,x86,kvm: Rework arch RNG seeds and get some from kvm

This introduces and uses a very simple synchronous mechanism to get
/dev/urandom-style bits appropriate for initial KVM PV guest RNG

It also re-works the way that architectural random data is fed into
random.c's pools.  I added a new arch hook called arch_get_rng_seed.
The default implementation is more or less the same as the current
code, except that random_get_entropy is now called unconditionally.

x86 gets a custom arch_get_rng_seed.  It will use KVM_GET_RNG_SEED
if available, and, if it does anything, it will log the number of
bits collected from each available architectural source.  If more
paravirt seed sources show up, it will be a natural place to add

I sent the corresponding kvm-unit-tests and qemu changes separately.

Changes from v4:
 - Got rid of the RDRAND behavior change.  If this series is accepted,
   I may resend it separately, but I think it's an unrelated issue.
 - Fix up the changelog entries -- I misunderstood how the old code
 - Avoid lots of failed attempts to use KVM_GET_RNG_SEED if it's not

Changes from v3:
 - Other than KASLR, the guest pieces are completely rewritten.
   Patches 2-4 have essentially nothing in common with v2.

Changes from v2:
(Continue reading)

John Stultz | 24 Jul 06:03 2014

[PATCH] sched_clock: Avoid corrupting hrtimer tree during suspend

From: Stephen Boyd <sboyd <at> codeaurora.org>

During suspend we call sched_clock_poll() to update the epoch and
accumulated time and reprogram the sched_clock_timer to fire
before the next wrap-around time. Unfortunately,
sched_clock_poll() doesn't restart the timer, instead it relies
on the hrtimer layer to do that and during suspend we aren't
calling that function from the hrtimer layer. Instead, we're
reprogramming the expires time while the hrtimer is enqueued,
which can cause the hrtimer tree to be corrupted. Furthermore, we
restart the timer during suspend but we update the epoch during
resume which seems counter-intuitive.

Let's fix this by saving the accumulated state and canceling the
timer during suspend. On resume we can update the epoch and
restart the timer similar to what we would do if we were starting
the clock for the first time.

Cc: Thomas Gleixner <tglx <at> linutronix.de>
Cc: Ingo Molnar <mingo <at> kernel.org>
Cc: stable <stable <at> vger.kernel.org>
Fixes: a08ca5d1089d "sched_clock: Use an hrtimer instead of timer"
Signed-off-by: Stephen Boyd <sboyd <at> codeaurora.org>
Signed-off-by: John Stultz <john.stultz <at> linaro.org>

Ingo/Thomas: Here's a fix for tip/timers/urgent for 3.16 and -stable.
Let me know if you have any objections.

(Continue reading)

Nicholas Krause | 24 Jul 05:35 2014

[PATCH] staging: Join lines in IntefaceIdleMode.c

This joins two lines that need to be joined as this improves
the coding style and makes it much easier to read.

Signed-off-by: Nicholas Krause <xerofoify <at> gmail.com>
 drivers/staging/bcm/InterfaceIdleMode.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/bcm/InterfaceIdleMode.c b/drivers/staging/bcm/InterfaceIdleMode.c
index c84ee49..e075f0e 100644
--- a/drivers/staging/bcm/InterfaceIdleMode.c
+++ b/drivers/staging/bcm/InterfaceIdleMode.c
 <at>  <at>  -211,8 +211,7  <at>  <at>  static int InterfaceAbortIdlemode(struct bcm_mini_adapter *Adapter,
-				"Number of completed iteration to"
-				"read chip-id :%lu", itr);
+				"Number of completed iteration to read chip-id :%lu", itr);

 		status = wrmalt(Adapter, SW_ABORT_IDLEMODE_LOC,
 				&Pattern, sizeof(status));


bpqw | 24 Jul 03:00 2014

Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function

Do nand reset before write protect check
If we want to check the WP# low or high through STATUS READ and check bit 7,
we must reset the device, other operation (eg.erase/program a locked block) can
also clear the bit 7 of status register.

Signed-off-by: White Ding <bpqw <at> micron.com>
 drivers/mtd/nand/nand_base.c |   18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 41167e9..22dd3aa 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
 <at>  <at>  -965,6 +965,15  <at>  <at>  int nand_unlock(struct mtd_info *mtd, loff_t ofs, uint64_t len)

 	chip->select_chip(mtd, chipnr);

+	/*
+	 * Reset the chip.
+	 * If we want to check the WP through READ STATUS and check the bit 7
+	 * we must reset the chip
+	 * some operation can also clear the bit 7 of status register
+	 * eg. erase/program a locked block
+	 */
+	chip->cmdfunc(mtd, NAND_CMD_RESET, -1, -1);
 	/* Check, if it is write protected */
 	if (nand_check_wp(mtd)) {
 		pr_debug("%s: device is write protected!\n",
(Continue reading)

Ian Kumlien | 24 Jul 01:33 2014

[BUG?] 3.16-rc6 ... at drivers/gpu/drm/i915/intel_pm.c:5997 intel_display_power_put+0x12d/0x160()

Try four, now including CC lists for the intel driver...


Hi again,

Playing some more with the new kernel release i noticed this:
[ 9064.008821] WARNING: CPU: 3 PID: 22929 at drivers/gpu/drm/i915/intel_pm.c:5997 intel_display_power_put+0x12d/0x160()
[ 9064.008822] Modules linked in: uas bnep b43 mac80211 cfg80211 snd_hda_codec_hdmi btusb bluetooth
6lowpan_iphc rfkill snd_hda_codec_cirrus uvcvideo snd_hda_codec_generic videobuf2_vmalloc
videobuf2_memops videobuf2_core snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep
snd_pcm snd_timer sdhci_pci snd sdhci soundcore mmc_core bcma
[ 9064.008839] CPU: 3 PID: 22929 Comm: kworker/3:2 Tainted: G        W     3.16.0-rc6 #23
[ 9064.008840] Hardware name: Apple Inc. MacBookPro10,2/Mac-AFD8A9D944EA4843, BIOS
MBP102.88Z.0106.B03.1211161133 11/16/2012
[ 9064.008843] Workqueue: events edp_panel_vdd_work
[ 9064.008844]  0000000000000009 ffff88015ba77d28 ffffffff8198ea2d 0000000000000000
[ 9064.008846]  ffff88015ba77d60 ffffffff810cbac8 ffff8802610b002c 00000000000c7204
[ 9064.008848]  0000000000000001 ffff8802610b80f0 ffff8802610b0000 ffff88015ba77d70
[ 9064.008850] Call Trace:
[ 9064.008854]  [<ffffffff8198ea2d>] dump_stack+0x4e/0x7a
[ 9064.008857]  [<ffffffff810cbac8>] warn_slowpath_common+0x78/0xa0
[ 9064.008858]  [<ffffffff810cbba5>] warn_slowpath_null+0x15/0x20
[ 9064.008860]  [<ffffffff815bdb3d>] intel_display_power_put+0x12d/0x160
[ 9064.008862]  [<ffffffff8161e084>] edp_panel_vdd_off_sync+0xf4/0x1c0
[ 9064.008863]  [<ffffffff8161e17f>] edp_panel_vdd_work+0x2f/0x40
[ 9064.008866]  [<ffffffff810e63be>] process_one_work+0x16e/0x480
[ 9064.008868]  [<ffffffff810e6cbb>] worker_thread+0x11b/0x520
[ 9064.008870]  [<ffffffff810e6ba0>] ? create_and_start_worker+0x50/0x50
[ 9064.008872]  [<ffffffff810ecb24>] kthread+0xc4/0xe0
(Continue reading)