Re: [PATCH 00/11] ARM: multi_v7_defconfig: Enable Zynq/Xilinx drivers

[Olof Johansson]

On Fri, Aug 22, 2014 at 08:54:25AM -0700, Soren Brinkmann wrote:
> Hi,
> 
> I went through the defconfig and searched for Zynq drivers. The result is
> this series of patches. The first few are all for Zynq and pretty much
> straight forward. The second half is mostly soft-IP, I think. That
> soft-IP works with Zynq devices, but I'm not sure whether those should
> go into the multi_v7 defconfig.

Thanks, S?ren! 

There's no need to split up into individual patches like this, but it was
convenient in case I wanted to only apply a few of them. I took them all
as one patch, and used your series description as commit message since
none of the individual patches had any. :)

As far as "unusual" drivers in the multiconfig; yeah, we need to deal
with that at some point due to kernel size. We're likely to switch ti
using modules first, but it'll make things slightly more complicated
since people will need to start dealing with initrds and at least I
don't have a good setup for that in my test farm yet. :-)


-Olof
--
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 v2] coccinelle: misc: semantic patch to delete overly complex return code processing

[Julia Lawall]

From: Julia Lawall 

This semantic patch simplifies cases where the effect of the processing of
a function call's return code is just to return the result of the function
directly.  It may also delete a local return flag variable, if this is no
longer used.

This was proposed by Uwe Kleine-K??nig.

Signed-off-by: Julia Lawall 

---
v2: wrong email address

 scripts/coccinelle/misc/simple_return.cocci |  180 
 1 file changed, 180 insertions(+)

diff --git a/scripts/coccinelle/misc/simple_return.cocci 
b/scripts/coccinelle/misc/simple_return.cocci
new file mode 100644
index 000..47f7084
--- /dev/null
+++ b/scripts/coccinelle/misc/simple_return.cocci
@@ -0,0 +1,180 @@
+/// Simplify a trivial if-return sequence.  Possibly combine with a
+/// preceding function call.
+//
+// Confidence: High
+// Copyright: (C) 2014 Julia Lawall, INRIA/LIP6.  GPLv2.
+// Copyright: (C) 2014 Gilles Muller, INRIA/LiP6.  GPLv2.
+// URL: http://coccinelle.lip6.fr/
+// Comments:
+// Options: --no-includes --include-headers
+
+virtual patch
+virtual context
+virtual org
+virtual report
+
+@r depends on patch@
+local idexpression e;
+identifier i,f,fn;
+@@
+
+fn(...) { <...
+- e@i =
++ return
+f(...);
+-if (i != 0) return i;
+-return 0;
+...> }
+
+@depends on patch@
+identifier r.i;
+type t;
+@@
+
+-t i;
+ ... when != i
+
+@depends on patch@
+expression e;
+@@
+
+-if (e != 0)
+   return e;
+-return 0;
+
+// ---
+
+@s1 depends on context || org || report@
+local idexpression e;
+identifier i,f,fn;
+position p,p1,p2;
+@@
+
+fn(...) { <...
+* e@i@p = f(...);
+  if (\(i@p1 != 0\|i@p2 < 0\))
+ return i;
+  return 0;
+...> }
+
+@s2 depends on context || org || report forall@
+identifier s1.i;
+type t;
+position q,s1.p;
+expression e,f;
+@@
+
+* t i@q;
+  ... when != i
+  e@p = f(...);
+
+@s3 depends on context || org || report@
+expression e;
+position p1!=s1.p1;
+position p2!=s1.p2;
+@@
+
+*if (\(e@p1 != 0\|e@p2 < 0\))
+   return e;
+ return 0;
+
+// ---
+
+@script:python depends on org@
+p << s1.p;
+p1 << s1.p1;
+q << s2.q;
+@@
+
+cocci.print_main("decl",q)
+cocci.print_secs("use",p)
+cocci.include_match(False)
+
+@script:python depends on org@
+p << s1.p;
+p2 << s1.p2;
+q << s2.q;
+@@
+
+cocci.print_main("decl",q)
+cocci.print_secs("use with questionable test",p)
+cocci.include_match(False)
+
+@script:python depends on org@
+p << s1.p;
+p1 << s1.p1;
+@@
+
+cocci.print_main("use",p)
+
+@script:python depends on org@
+p << s1.p;
+p2 << s1.p2;
+@@
+
+cocci.print_main("use with questionable test",p)
+
+@script:python depends on org@
+p << s3.p1;
+@@
+
+cocci.print_main("test",p)
+
+@script:python depends on org@
+p << s3.p2;
+@@
+
+cocci.print_main("questionable test",p)
+
+// ---
+
+@script:python depends on report@
+p << s1.p;
+p1 << s1.p1;
+q << s2.q;
+@@
+
+msg = "WARNING: end returns can be simpified and declaration on line %s can be 
dropped" % (q[0].line)
+coccilib.report.print_report(p[0],msg)
+cocci.include_match(False)
+
+@script:python depends on report@
+p << s1.p;
+p1 << s1.p1;
+q << s2.q
+;
+@@
+
+msg = "WARNING: end returns may be simpified if negative or 0 value and 
declaration on line %s can be dropped" % (q[0].line)
+coccilib.report.print_report(p[0],msg)
+cocci.include_match(False)
+
+@script:python depends on report@
+p << s1.p;
+p1 << s1.p1;
+@@
+
+msg = "WARNING: end returns can be simpified"
+coccilib.report.print_report(p[0],msg)
+
+@script:python depends on report@
+p << s1.p;
+p2 << s1.p2;
+@@
+
+msg = "WARNING: end returns can be simpified if negative or 0 value"
+coccilib.report.print_report(p[0],msg)
+
+@script:python depends on report@
+p << s3.p1;
+@@
+
+msg = "WARNING: end returns can be simpified"
+coccilib.report.print_report(p[0],msg)
+
+@script:python depends on report@
+p << s3.p2;
+@@
+
+msg = "WARNING: end returns can be simpified if tested value is negative or 0"
+coccilib.report.print_report(p[0],msg)

--
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] coccinelle: misc: semantic patch to delete overly complex return code processing

[Julia Lawall]

From: Julia Lawall 

This semantic patch simplifies cases where the effect of the processing of
a function call's return code is just to return the result of the function
directly.  It may also delete a local return flag variable, if this is no
longer used.

This was proposed by Uwe Kleine-K??nig.

Signed-off-by: Julia Lawall 

---
 scripts/coccinelle/misc/simple_return.cocci |  180 
 1 file changed, 180 insertions(+)

diff --git a/scripts/coccinelle/misc/simple_return.cocci 
b/scripts/coccinelle/misc/simple_return.cocci
new file mode 100644
index 000..47f7084
--- /dev/null
+++ b/scripts/coccinelle/misc/simple_return.cocci
@@ -0,0 +1,180 @@
+/// Simplify a trivial if-return sequence.  Possibly combine with a
+/// preceding function call.
+//
+// Confidence: High
+// Copyright: (C) 2014 Julia Lawall, INRIA/LIP6.  GPLv2.
+// Copyright: (C) 2014 Gilles Muller, INRIA/LiP6.  GPLv2.
+// URL: http://coccinelle.lip6.fr/
+// Comments:
+// Options: --no-includes --include-headers
+
+virtual patch
+virtual context
+virtual org
+virtual report
+
+@r depends on patch@
+local idexpression e;
+identifier i,f,fn;
+@@
+
+fn(...) { <...
+- e@i =
++ return
+f(...);
+-if (i != 0) return i;
+-return 0;
+...> }
+
+@depends on patch@
+identifier r.i;
+type t;
+@@
+
+-t i;
+ ... when != i
+
+@depends on patch@
+expression e;
+@@
+
+-if (e != 0)
+   return e;
+-return 0;
+
+// ---
+
+@s1 depends on context || org || report@
+local idexpression e;
+identifier i,f,fn;
+position p,p1,p2;
+@@
+
+fn(...) { <...
+* e@i@p = f(...);
+  if (\(i@p1 != 0\|i@p2 < 0\))
+ return i;
+  return 0;
+...> }
+
+@s2 depends on context || org || report forall@
+identifier s1.i;
+type t;
+position q,s1.p;
+expression e,f;
+@@
+
+* t i@q;
+  ... when != i
+  e@p = f(...);
+
+@s3 depends on context || org || report@
+expression e;
+position p1!=s1.p1;
+position p2!=s1.p2;
+@@
+
+*if (\(e@p1 != 0\|e@p2 < 0\))
+   return e;
+ return 0;
+
+// ---
+
+@script:python depends on org@
+p << s1.p;
+p1 << s1.p1;
+q << s2.q;
+@@
+
+cocci.print_main("decl",q)
+cocci.print_secs("use",p)
+cocci.include_match(False)
+
+@script:python depends on org@
+p << s1.p;
+p2 << s1.p2;
+q << s2.q;
+@@
+
+cocci.print_main("decl",q)
+cocci.print_secs("use with questionable test",p)
+cocci.include_match(False)
+
+@script:python depends on org@
+p << s1.p;
+p1 << s1.p1;
+@@
+
+cocci.print_main("use",p)
+
+@script:python depends on org@
+p << s1.p;
+p2 << s1.p2;
+@@
+
+cocci.print_main("use with questionable test",p)
+
+@script:python depends on org@
+p << s3.p1;
+@@
+
+cocci.print_main("test",p)
+
+@script:python depends on org@
+p << s3.p2;
+@@
+
+cocci.print_main("questionable test",p)
+
+// ---
+
+@script:python depends on report@
+p << s1.p;
+p1 << s1.p1;
+q << s2.q;
+@@
+
+msg = "WARNING: end returns can be simpified and declaration on line %s can be 
dropped" % (q[0].line)
+coccilib.report.print_report(p[0],msg)
+cocci.include_match(False)
+
+@script:python depends on report@
+p << s1.p;
+p1 << s1.p1;
+q << s2.q
+;
+@@
+
+msg = "WARNING: end returns may be simpified if negative or 0 value and 
declaration on line %s can be dropped" % (q[0].line)
+coccilib.report.print_report(p[0],msg)
+cocci.include_match(False)
+
+@script:python depends on report@
+p << s1.p;
+p1 << s1.p1;
+@@
+
+msg = "WARNING: end returns can be simpified"
+coccilib.report.print_report(p[0],msg)
+
+@script:python depends on report@
+p << s1.p;
+p2 << s1.p2;
+@@
+
+msg = "WARNING: end returns can be simpified if negative or 0 value"
+coccilib.report.print_report(p[0],msg)
+
+@script:python depends on report@
+p << s3.p1;
+@@
+
+msg = "WARNING: end returns can be simpified"
+coccilib.report.print_report(p[0],msg)
+
+@script:python depends on report@
+p << s3.p2;
+@@
+
+msg = "WARNING: end returns can be simpified if tested value is negative or 0"
+coccilib.report.print_report(p[0],msg)

--
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] early microcode: extend the ramdisk address to 64bit

[Yinghai Lu]

On Fri, Aug 22, 2014 at 6:59 AM,   wrote:
> From: Harald Hoyer 
>
> commit 4bf7111f50167133a71c23530ca852a41355e739 enabled loading of the
> initramfs above 4G addresses. So I was wondering, if the early microcode
> code might want to honor the upper 32bit of the 64bit address.
>

https://lkml.org/lkml/2014/6/11/27
--
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 2/4] drivers/bus: Freescale Management Complex (fsl-mc) bus driver

[German Rivera]

Hi Arnd,

I have posted respin v3 of this patch series to address your lastest  of 
comments. Please see below the resolutions.


Thanks,

German

On 08/21/2014 06:30 AM, Arnd Bergmann wrote:

On Tuesday 19 August 2014, German Rivera wrote:

+ * @dev_node: Node in the container's child list


Same here: just use the device model's list management instead if you can,
or explain why this is needed.


We still need to keep a per-bus list of child devices (devices contained
in a given DPRC object). Unless I'm missing something,
I think the device model's list management links together all the
devices of the same bus type. We are trying to follow a similar approach
to the pci_dev/pci_bus structs.


There are multiple lists in the device handling. device_for_each_child()
should iterate over the children of a particular device using the
klist_children member.

Removed per-bus list of children, and instead use 
device_for_each_child() as you suggested.



+/**
+ * struct fsl_mc_dprc - Data Path Resource Container (DPRC) object
+ * @magic: marker to verify identity of this structure
+ * @mc_dev: pointer to MC object device object for this DPRC
+ * @mutex: mutex to serialize access to the container.
+ * @child_device_count: have the count of devices in this DPRC
+ * @child_list: anchor node of list of child devices on this DPRC
+ */
+struct fsl_mc_dprc {
+#   define FSL_MC_DPRC_MAGIC   FSL_MC_MAGIC('D', 'P', 'R', 'C')
+uint32_t magic;
+struct fsl_mc_device *mc_dev;
+struct mutex mutex; /* serializes access to fields below */
+uint16_t child_device_count;/* Count of devices in this DPRC */
+struct list_head child_list;
+};


It's not clear what this represents to me. mc_dev presumably already
has a list of children, so why not just use a pointer to mc_dev
and remove this structure entirely?


This structure represents the per-bus (per DPRC object) information.
It is kind of the equivalent to 'struct pci_bus' in the PCI world.
I have renamed this struct to 'struct fsl_mc_bus'.


Ok, I'll look at the new version when I get back to Germany. I still think
that can remove all members of the current structure and just use the
same structure for fsl_mc_bus and fsl_mc_device. If you really need
a small number of extra members beyond what is in the device, you have
two other choices:

By removing the child list from the fsl_mc_bus structure as you 
suggested, the fsl_mc_bus structure does not need to exist for this 
patch series. As you rightfully suggested, we can use just one

structure (fsl_mc_device) to represent both regular devices (children)
and bus devices.


a) put the members into the device structure as well but not use them
for a device that is not a bus

b) embed the device structure within the bus structure like

struct fsl_mc_bus {
int something;
struct fsl_mc_device;
};

and then use container_of() to go from the device to the bus where needed
rather than having two objects that are allocated separately. This is
what a lot of other subsystems (not PCI) do. See for instance
platform_device, which often has child devices as well.


In other functionality to be delivered as a follow-on patch series
(after this patch series), we will need to track some per-bus 
information, and we will do so using your "b)" recommendation.



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/

[RFC PATCH 2/4 v3] drivers/bus: Freescale Management Complex (fsl-mc) bus driver

[J. German Rivera]

From: "J. German Rivera" 

Platform device driver that sets up the basic bus infrastructure
for the fsl-mc bus type, including support for adding/removing
fsl-mc devices, register/unregister of fsl-mc drivers, and bus
match support to bind devices to drivers.

Signed-off-by: J. German Rivera 
---
 drivers/bus/Kconfig |3 +
 drivers/bus/Makefile|3 +
 drivers/bus/fsl-mc/Kconfig  |   13 +
 drivers/bus/fsl-mc/Makefile |   14 +
 drivers/bus/fsl-mc/fsl_mc_bus.c |  601 +++
 include/linux/fsl_mc.h  |  130 +
 include/linux/fsl_mc_private.h  |   33 +++
 7 files changed, 797 insertions(+)
 create mode 100644 drivers/bus/fsl-mc/Kconfig
 create mode 100644 drivers/bus/fsl-mc/Makefile
 create mode 100644 drivers/bus/fsl-mc/fsl_mc_bus.c
 create mode 100644 include/linux/fsl_mc.h
 create mode 100644 include/linux/fsl_mc_private.h

diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index 603eb1b..2fbb1fd 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -67,4 +67,7 @@ config VEXPRESS_CONFIG
help
  Platform configuration infrastructure for the ARM Ltd.
  Versatile Express.
+
+source "drivers/bus/fsl-mc/Kconfig"
+
 endmenu
diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
index 2973c18..6abcab1 100644
--- a/drivers/bus/Makefile
+++ b/drivers/bus/Makefile
@@ -15,3 +15,6 @@ obj-$(CONFIG_ARM_CCI) += arm-cci.o
 obj-$(CONFIG_ARM_CCN)  += arm-ccn.o

 obj-$(CONFIG_VEXPRESS_CONFIG)  += vexpress-config.o
+
+# Freescale Management Complex (MC) bus drivers
+obj-$(CONFIG_FSL_MC_BUS)   += fsl-mc/
diff --git a/drivers/bus/fsl-mc/Kconfig b/drivers/bus/fsl-mc/Kconfig
new file mode 100644
index 000..e3226f9
--- /dev/null
+++ b/drivers/bus/fsl-mc/Kconfig
@@ -0,0 +1,13 @@
+#
+# Freescale Management Complex (MC) bus drivers
+#
+# Copyright (C) 2014 Freescale Semiconductor, Inc.
+#
+# This file is released under the GPLv2
+#
+
+config FSL_MC_BUS
+   tristate "Freescale Management Complex (MC) bus driver"
+   help
+ Driver to enable the bus infrastructure for the Freescale
+  QorIQ Management Complex.
diff --git a/drivers/bus/fsl-mc/Makefile b/drivers/bus/fsl-mc/Makefile
new file mode 100644
index 000..2981d70
--- /dev/null
+++ b/drivers/bus/fsl-mc/Makefile
@@ -0,0 +1,14 @@
+#
+# Freescale Management Complex (MC) bus drivers
+#
+# Copyright (C) 2014 Freescale Semiconductor, Inc.
+#
+# This file is released under the GPLv2
+#
+obj-$(CONFIG_FSL_MC_BUS) += fsl_mc_bus_driver.o
+
+fsl_mc_bus_driver-objs := fsl_mc_bus.o \
+ fsl_mc_sys.o \
+ dprc.o \
+ dpmng.o
+
diff --git a/drivers/bus/fsl-mc/fsl_mc_bus.c b/drivers/bus/fsl-mc/fsl_mc_bus.c
new file mode 100644
index 000..5cce52a
--- /dev/null
+++ b/drivers/bus/fsl-mc/fsl_mc_bus.c
@@ -0,0 +1,601 @@
+/*
+ * Freescale Management Complex (MC) bus driver
+ *
+ * Copyright (C) 2014 Freescale Semiconductor, Inc.
+ * Author: German Rivera 
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "fsl_dprc_cmd.h"
+
+static struct kmem_cache *mc_dev_cache;
+
+/**
+ * fsl_mc_bus_match - device to driver matching callback
+ * @dev: the MC object device structure to match against
+ * @drv: the device driver to search for matching MC object device id
+ * structures
+ *
+ * Returns 1 on success, 0 otherwise.
+ */
+static int fsl_mc_bus_match(struct device *dev, struct device_driver *drv)
+{
+   const struct fsl_mc_device_match_id *id;
+   struct fsl_mc_device *mc_dev = to_fsl_mc_device(dev);
+   struct fsl_mc_driver *mc_drv = to_fsl_mc_driver(drv);
+   bool found = false;
+
+   if (mc_drv->match_id_table == NULL)
+   goto out;
+
+   /*
+* If the object is not 'plugged' don't match.
+* Only exception is the root DPRC, which is a special case.
+*/
+   if ((mc_dev->obj_desc.state & DPRC_OBJ_STATE_PLUGGED) == 0 &&
+   _dev->dev != fsl_mc_bus_type.dev_root)
+   goto out;
+
+   /*
+* Traverse the match_id table of the given driver, trying to find
+* a matching for the given MC object device.
+*/
+   for (id = mc_drv->match_id_table; id->vendor != 0x0; id++) {
+   if (id->vendor == mc_dev->obj_desc.vendor &&
+   strcmp(id->obj_type, mc_dev->obj_desc.type) == 0 &&
+   id->ver_major == mc_dev->obj_desc.ver_major &&
+   id->ver_minor == mc_dev->obj_desc.ver_minor) {
+   found = true;
+   break;
+   }
+   }
+
+out:
+   pr_debug("%s: %s %s\n", __func__, dev_name(dev),
+

[RFC PATCH 0/4 v3] drivers/bus: Freescale Management Complex bus driver patch series

[J. German Rivera]

This patch series introduces Linux support for the Freescale
Management Complex (fsl-mc) hardware.

The fsl-mc is a hardware resource manager that manages specialized
hardware objects used in network-oriented packet processing
applications.  After the fsl-mc block is enabled, pools of hardware
resources are available, such as queues, buffer poools, I/O
interfaces.  These resources are building blocks that can be
used to create functional hardware objects such as network
interfaces, crypto accelerator instances, or L2 switches.

All the fsl-mc managed hardware resources/objects are represented in
a physical grouping mechanism called a 'container' or DPRC (data
path resource container).

>From the point of view of an OS, a DPRC functions similar to a plug
and play bus.  Using fsl-mc commands software can enumerate the
contents of the DPRC discovering the hardware objects present
and binding them to drivers.  Hardware objects can be created
and removed dynamically, providing hot pluggability of the hardware
objects.

Software contexts interact with the fsl-mc by sending commands through
a memory mapped hardware interface called an "MC portal". Every
fsl-mc object type has a command set to manage the objects. Key
DPRC commands include:
   -create/destroy a DPRC
   -enumerate objects and resource pools in the DPRC, including
identifying mappable regions and the number of IRQs an object
may have
   -IRQ configuration
   -move objects/resources between DPRCs
   -connecting objects (e.g. connecting a network interface to
an L2 switch port)
   -reset

Patch 1 contains a minimal set of low level functions to send an
d receive commands to the fsl-mc. It includes support for basic
management commands and commands to manipulate DPRC objects.

Patch 2 contains a platform device driver that sets up and registers
the basic bus infrastructure including support for adding/removing
devices, register/unregister of drivers, and bus match support
to bind devices to drivers.

Patch 3 contains an driver that manages DPRC objects (the
container that holds the hardware resources). This driver
functions as a bus controller and handles enumeration
of the objects in the container and hotplug events.

Patch 4 contains the update to the MAINTAINERS file.

--
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/

[RFC PATCH 3/4 v3] drivers/bus: Device driver for FSL-MC DPRC devices

[J. German Rivera]

From: "J. German Rivera" 

A DPRC (Data Path Resource Container) is an isolation device
that contains a set of DPAA networking devices to be
assigned to an isolation domain (e.g., a virtual machine).

Signed-off-by: J. German Rivera 
---
 drivers/bus/fsl-mc/Makefile  |3 +-
 drivers/bus/fsl-mc/fsl_mc_dprc.c |  395 ++
 include/linux/fsl_mc_private.h   |6 +
 3 files changed, 403 insertions(+), 1 deletion(-)
 create mode 100644 drivers/bus/fsl-mc/fsl_mc_dprc.c

diff --git a/drivers/bus/fsl-mc/Makefile b/drivers/bus/fsl-mc/Makefile
index 2981d70..499dc9b 100644
--- a/drivers/bus/fsl-mc/Makefile
+++ b/drivers/bus/fsl-mc/Makefile
@@ -5,7 +5,8 @@
 #
 # This file is released under the GPLv2
 #
-obj-$(CONFIG_FSL_MC_BUS) += fsl_mc_bus_driver.o
+obj-$(CONFIG_FSL_MC_BUS) += fsl_mc_bus_driver.o \
+   fsl_mc_dprc.o

 fsl_mc_bus_driver-objs := fsl_mc_bus.o \
  fsl_mc_sys.o \
diff --git a/drivers/bus/fsl-mc/fsl_mc_dprc.c b/drivers/bus/fsl-mc/fsl_mc_dprc.c
new file mode 100644
index 000..7372171
--- /dev/null
+++ b/drivers/bus/fsl-mc/fsl_mc_dprc.c
@@ -0,0 +1,395 @@
+/*
+ * Freescale daata path resource container (DPRC) driver
+ *
+ * Copyright (C) 2014 Freescale Semiconductor, Inc.
+ * Author: German Rivera 
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include "fsl_dprc_cmd.h"
+
+struct dprc_child_objs {
+   int child_count;
+   struct dprc_obj_desc *child_array;
+};
+
+static int __fsl_mc_device_remove_if_not_in_mc(struct device *dev, void *data)
+{
+   int i;
+   struct dprc_child_objs *objs;
+   struct fsl_mc_device *mc_dev;
+
+   WARN_ON(dev == NULL);
+   WARN_ON(data == NULL);
+   mc_dev = to_fsl_mc_device(dev);
+   objs = data;
+
+   for (i = 0; i < objs->child_count; i++) {
+   struct dprc_obj_desc *obj_desc = >child_array[i];
+
+   if (strlen(obj_desc->type) != 0 &&
+   FSL_MC_DEVICE_MATCH(mc_dev, obj_desc))
+   break;
+   }
+
+   if (i == objs->child_count)
+   fsl_mc_device_remove(mc_dev);
+
+   return 0;
+}
+
+static int __fsl_mc_device_remove(struct device *dev, void *data)
+{
+   WARN_ON(dev == NULL);
+   WARN_ON(data != NULL);
+   fsl_mc_device_remove(to_fsl_mc_device(dev));
+   return 0;
+}
+
+/**
+ * dprc_remove_devices - Removes devices for objects removed from a DPRC
+ *
+ * @mc_bus_dev: pointer to the fsl-mc device that represents a DPRC object
+ * @obj_desc_array: array of object descriptors for child objects currently
+ * present in the DPRC in the MC.
+ * @num_child_objects_in_mc: number of entries in obj_desc_array
+ *
+ * Synchronizes the state of the Linux bus driver with the actual state of
+ * the MC by removing devices that represent MC objects that have
+ * been dynamically removed in the physical DPRC.
+ */
+static void dprc_remove_devices(struct fsl_mc_device *mc_bus_dev,
+   struct dprc_obj_desc *obj_desc_array,
+   int num_child_objects_in_mc)
+{
+   if (num_child_objects_in_mc != 0) {
+   /*
+* Remove child objects that are in the DPRC in Linux,
+* but not in the MC:
+*/
+   struct dprc_child_objs objs;
+
+   objs.child_count = num_child_objects_in_mc;
+   objs.child_array = obj_desc_array;
+   device_for_each_child(_bus_dev->dev, ,
+ __fsl_mc_device_remove_if_not_in_mc);
+   } else {
+   /*
+* There are no child objects for this DPRC in the MC.
+* So, remove all the child devices from Linux:
+*/
+   device_for_each_child(_bus_dev->dev, NULL,
+ __fsl_mc_device_remove);
+   }
+}
+
+static int __fsl_mc_device_match(struct device *dev, void *data)
+{
+   struct dprc_obj_desc *obj_desc = data;
+   struct fsl_mc_device *mc_dev = to_fsl_mc_device(dev);
+
+   return FSL_MC_DEVICE_MATCH(mc_dev, obj_desc);
+}
+
+static struct fsl_mc_device *fsl_mc_device_lookup(struct dprc_obj_desc
+   *obj_desc,
+ struct fsl_mc_device
+   *mc_bus_dev)
+{
+   struct device *dev;
+
+   dev = device_find_child(mc_bus_dev, obj_desc, __fsl_mc_device_match);
+   return (dev != NULL) ? to_fsl_mc_device(dev) : NULL;
+}
+
+/**
+ * dprc_add_new_devices - Adds devices to the logical bus for a DPRC
+ *
+ * @mc_bus_dev: pointer to the fsl-mc device that represents a DPRC object
+ * 

[RFC PATCH 4/4 v3] Update MAINTAINERS file

[J. German Rivera]

From: "J. German Rivera" 

Signed-off-by: J. German Rivera 
---
 MAINTAINERS |8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7e2eb4c..eb8597d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3841,6 +3841,14 @@ S:   Maintained
 F: sound/soc/fsl/fsl*
 F: sound/soc/fsl/mpc8610_hpcd.c

+FREESCALE QORIQ MANAGEMENT COMPLEX DRIVER
+M: J. German Rivera 
+L: linux-kernel@vger.kernel.org
+S: Maintained
+F: include/linux/fsl_mc*
+F: include/linux/fsl_dp*
+F: drivers/bus/fsl-mc/*
+
 FREEVXFS FILESYSTEM
 M: Christoph Hellwig 
 W: ftp://ftp.openlinux.org/pub/people/hch/vxfs
--
1.7.9.7

--
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/

[RFC PATCH 1/4 v3] drivers/bus: Added Freescale Management Complex APIs

[J. German Rivera]

From: "J. German Rivera" 

APIs to access the Management Complex (MC) hardware
module of Freescale LS2 SoCs. This patch includes
APIs to check the MC firmware version and to manipulate
DPRC objects in the MC.

Signed-off-by: J. German Rivera 
---
 drivers/bus/fsl-mc/dpmng.c |   93 +
 drivers/bus/fsl-mc/dprc.c  |  504 +++
 drivers/bus/fsl-mc/fsl_dpmng_cmd.h |   83 
 drivers/bus/fsl-mc/fsl_dprc_cmd.h  |  545 +
 drivers/bus/fsl-mc/fsl_mc_sys.c|  237 +++
 include/linux/fsl_dpmng.h  |  120 ++
 include/linux/fsl_dprc.h   |  790 
 include/linux/fsl_mc_cmd.h |  182 +
 include/linux/fsl_mc_sys.h |   50 +++
 9 files changed, 2604 insertions(+)
 create mode 100644 drivers/bus/fsl-mc/dpmng.c
 create mode 100644 drivers/bus/fsl-mc/dprc.c
 create mode 100644 drivers/bus/fsl-mc/fsl_dpmng_cmd.h
 create mode 100644 drivers/bus/fsl-mc/fsl_dprc_cmd.h
 create mode 100644 drivers/bus/fsl-mc/fsl_mc_sys.c
 create mode 100644 include/linux/fsl_dpmng.h
 create mode 100644 include/linux/fsl_dprc.h
 create mode 100644 include/linux/fsl_mc_cmd.h
 create mode 100644 include/linux/fsl_mc_sys.h

diff --git a/drivers/bus/fsl-mc/dpmng.c b/drivers/bus/fsl-mc/dpmng.c
new file mode 100644
index 000..c6ed27c
--- /dev/null
+++ b/drivers/bus/fsl-mc/dpmng.c
@@ -0,0 +1,93 @@
+/* Copyright 2013-2014 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in the
+ *   documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ *   names of its contributors may be used to endorse or promote products
+ *   derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include 
+#include 
+#include 
+#include "fsl_dpmng_cmd.h"
+
+int mc_get_version(struct fsl_mc_io *mc_io, struct mc_version *mc_ver_info)
+{
+   struct mc_command cmd = { 0 };
+   int err;
+
+   cmd.header = mc_encode_cmd_header(DPMNG_CMDID_GET_VERSION,
+ DPMNG_CMDSZ_GET_VERSION,
+ MC_CMD_PRI_LOW, 0);
+
+   err = mc_send_command(mc_io, );
+   if (!err)
+   DPMNG_RSP_GET_VERSION(cmd, mc_ver_info);
+
+   return err;
+}
+
+int dpmng_reset_aiop(struct fsl_mc_io *mc_io, int aiop_tile_id)
+{
+   struct mc_command cmd = { 0 };
+
+   cmd.header = mc_encode_cmd_header(DPMNG_CMDID_RESET_AIOP,
+ DPMNG_CMDSZ_RESET_AIOP,
+ MC_CMD_PRI_LOW, 0);
+
+   DPMNG_CMD_RESET_AIOP(cmd, aiop_tile_id);
+
+   return mc_send_command(mc_io, );
+}
+
+int dpmng_load_aiop(struct fsl_mc_io *mc_io,
+   int aiop_tile_id, uint8_t *img_addr, int img_size)
+{
+   struct mc_command cmd = { 0 };
+   uint64_t img_paddr = virt_to_phys(img_addr);
+
+   cmd.header = mc_encode_cmd_header(DPMNG_CMDID_LOAD_AIOP,
+ DPMNG_CMDSZ_LOAD_AIOP,
+ MC_CMD_PRI_LOW, 0);
+
+   DPMNG_CMD_LOAD_AIOP(cmd, aiop_tile_id, img_size, img_paddr);
+
+   return mc_send_command(mc_io, );
+}
+
+int dpmng_run_aiop(struct fsl_mc_io *mc_io,
+  int aiop_tile_id, uint32_t cores_mask, uint64_t options)
+{
+   struct mc_command cmd = { 0 };
+
+   cmd.header = mc_encode_cmd_header(DPMNG_CMDID_RUN_AIOP,
+ 

Re: [PATCH] gpio: omap: Fix interrupt names

[Kevin Hilman]

Nishanth Menon  writes:

> When viewing the /proc/interrupts, there is no information about which
> GPIO bank a specific gpio interrupt is hooked on to. This is more than a
> bit irritating as such information can esily be provided back to the
> user and at times, can be crucial for debug.
>
> So, instead of displaying something like:
> 31:   0   0  GPIO   0  palmas
> 32:   0   0  GPIO  27  mmc0
>
> Display the following with appropriate device name:
> 31:   0   0  4ae1.gpio   0  palmas
> 32:   0   0  4805d000.gpio  27  mmc0
>
> This requires that we create irq_chip instance specific for each GPIO
> bank which is trivial to achieve.
>
> Signed-off-by: Nishanth Menon 

Acked-by: Kevin Hilman 
--
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/1] ARM: exynos_defconfig: Enable options for display panel support

[Kevin Hilman]

Javier Martinez Canillas  writes:

> Many Exynos devices have a display panel, most of them just have
> a simple panel while others have more complex configurations that
> requires an embedded DisplayPort (eDP) to LVDS display bridge.
>
> This patch enables the following features to support both setups:
>
> - Direct Rendering Manager (DRM)
> - DRM bridge registration and lookup framework
> - Parade ps8622/ps8625 eDP/LVDS bridge
> - NXP ptn3460 eDP/LVDS bridge
> - Exynos Fully Interactive Mobile Display controller (FIMD)
> - Panel registration and lookup framework
> - Simple panels
> - Backlight and LCD device support
>
> Signed-off-by: Javier Martinez Canillas 
> ---
>
> Some of the options enabled here (e.g: the eDP/LVDS bridges)
> are still not merged in mainline so this patch depends on
> the following posted patches that were still not merged:
>
> "drm/bridge: Modify drm_bridge core to support driver model" [0]
> "drm/bridge: Add i2c based driver for ptn3460 bridge" [1]
> "drm/bridge: Add i2c based driver for ps8622/ps8625 bridge" [2]
>
> But I wanted to post anyways to make easier for others to
> figure out what are the needed options to have the display
> working on their Exynos machines.

Great, thanks for this!  I spent/wasted quite a bit of time trying to
figure out which options I needed to enable to get basic display support
working.
>
> In order to test the display panel on the Peach machines,
> the following patches are also needed:
>
> "ARM: dts: Add DT changes for display on peach_pit" [3]
> "ARM: dts: Add DT changes for display on peach_pi" [4]

Tested-by: Kevin Hilman 

On v3.17-rc1 along with these DT patches abvoe on exynos5800/chromebook2
(peach-pi).

Thanks,

Kevin
--
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 0/7] i2c: Relax mandatory I2C ID table passing

[Wolfram Sang]

> > Sure thing, yet I won't make it for 3.17, sadly :( It has high priority
> > for 3.18, though.
> 
> Do you want me to re-send now the -rc1 had been released?

I think this version will do for an initial review.

Thanks,

   Wolfram



signature.asc
Description: Digital signature

[PATCH v3] staging: rtl8821ae: fix sparse warning for static declarations in rtl8821ae/stats.c

[Hoang Tran]

This patch fixes the following sparse warnings in rtl8821ae/stats.c

drivers/staging/rtl8821ae/stats.c:62:6: warning: symbol 'rtl_translate_todbm' 
was not declared. Should it be static?
drivers/staging/rtl8821ae/stats.c:101:6: warning: symbol 'rtl_process_ui_rssi' 
was not declared. Should it be static?

Signed-off-by: Hoang Tran 
---
 drivers/staging/rtl8821ae/stats.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8821ae/stats.c 
b/drivers/staging/rtl8821ae/stats.c
index 4d383d1..fdbde43 100644
--- a/drivers/staging/rtl8821ae/stats.c
+++ b/drivers/staging/rtl8821ae/stats.c
@@ -59,7 +59,7 @@ u8 rtl_evm_db_to_percentage(char value)
 }
 //EXPORT_SYMBOL(rtl_evm_db_to_percentage);
 
-long rtl_translate_todbm(struct ieee80211_hw *hw,
+static long rtl_translate_todbm(struct ieee80211_hw *hw,
 u8 signal_strength_index)
 {
long signal_power;
@@ -98,7 +98,8 @@ long rtl_signal_scale_mapping(struct ieee80211_hw *hw, long 
currsig)
 }
 //EXPORT_SYMBOL(rtl_signal_scale_mapping);
 
-void rtl_process_ui_rssi(struct ieee80211_hw *hw, struct rtl_stats *pstatus)
+static void rtl_process_ui_rssi(struct ieee80211_hw *hw,
+   struct rtl_stats *pstatus)
 {
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rtl_phy *rtlphy = &(rtlpriv->phy);
-- 
2.0.2

--
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-next 0/4] r8152: firmware support

[David Miller]

From: Hayes Wang 
Date: Wed, 20 Aug 2014 16:58:35 +0800

> Parsing, checking, and writing the firmware.

You haven't told us why you need to do this.

These are just programming registers in the chip, and I see no reason
to not keep these in the driver with real code.

I'm not applying this series, you haven't explained what is happening
here and the reason for doing so.  Ironically, that's exactly what you
are supposed to provide in this 0/4 header email.
--
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] arch: Kconfig: Let all little endian architectures define CPU_LITTLE_ENDIAN explicitly

[Chen Gang]

On 8/22/14 19:09, Michal Marek wrote:
> Dne 13.8.2014 10:03, Geert Uytterhoeven napsal(a):
>> CC kbuild
>>
>> On Wed, Aug 13, 2014 at 12:48 AM, Chen Gang  wrote:
>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>>> index c49a775..0510a5d 100644
>>> --- a/arch/arm/Kconfig
>>> +++ b/arch/arm/Kconfig
>>> @@ -199,6 +199,11 @@ config NEED_DMA_MAP_STATE
>>>  config ARCH_SUPPORTS_UPROBES
>>> def_bool y
>>>
>>> +config CPU_LITTLE_ENDIAN
>>> +   depends on !CPU_BIG_ENDIAN
>>> +   def_bool y
>>> +
>>> +
>>>  config ARCH_HAS_DMA_SET_COHERENT_MASK
>>> bool
>>
>> As this is a common symbol, and replicated for all affected architectures,
>> I'm wondering if we should have the "config CPU_LITTLE_ENDIAN" in
>> common Kconfig code instead, and make the individual architectures do a
>> "select CPU_LITTLE_ENDIAN"?
> 
> Yes!
> 
> 
>> Also we could have "config CPU_BIG_ENDIAN", too, and error out
>> if none or both are selected (can Kconfig error out?).
> 
> We can error out in the Makefile, if there is consensus that we should
> be doing so.
> 

OK, thanks. I have sent patch v3 for it, and did not check related error
in Kconfig files.

Please check the related patches (excuse me, I send the patch v3 only
according to "scripts/maintainers.pl", maybe not cc to you explicitly).


Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed
--
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 v5 2/3] mfd: qcom-rpm: Driver for the Qualcomm RPM

[Bjorn Andersson]

On Fri, Aug 22, 2014 at 12:50 AM, Lee Jones  wrote:
> On Thu, 21 Aug 2014, Bjorn Andersson wrote:
>> On Thu 21 Aug 06:22 PDT 2014, Lee Jones wrote:
>> > > +struct qcom_rpm *dev_get_qcom_rpm(struct device *dev)
>> > > +{
>> > > + return dev_get_drvdata(dev);
>> > > +}
>> > > +EXPORT_SYMBOL(dev_get_qcom_rpm);
>> >
>> > No need for this at all.  Use dev_get_drvdata() direct instead.
>> >
>>
>> I see that others have put this as static inline in the header file, so I 
>> will
>> follow that. I don't want to expose this directly in the implementation of 
>> the
>> clients.
>>
>> Let me know if you object.
>
> I do (unless you convince me otherwise).  Why is this a good idea and
> why 'exposing' this directly is a bad one?  At the moment this looks
> to me like abstraction for the sake of abstraction.
>

There's no other reason for it than to abstract because "it's nice",
so I'll change it.

>> > > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> > > + rpm->status_regs = devm_ioremap_resource(>dev, res);
>> > > + rpm->ctrl_regs = rpm->status_regs + 0x400;
>> > > + rpm->req_regs = rpm->status_regs + 0x600;
>> > > + if (IS_ERR(rpm->status_regs))
>> > > + return PTR_ERR(rpm->status_regs);
>> >
>> > You should probably do this _before_ using it above.
>>
>> There's no difference in behaviour, but it just feels cleaner than:
>>
>> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> rpm->status_regs = devm_ioremap_resource(>dev, res);
>> if (IS_ERR(rpm->status_regs))
>>   return PTR_ERR(rpm->status_regs);
>> rpm->ctrl_regs = rpm->status_regs + 0x400;
>> rpm->req_regs = rpm->status_regs + 0x600;
>>
>> If you don't like it, I'll change it.
>
> There is a difference.  In the current implementation you're doing math
> with a possible error code and assigning rubbish to rpm->ctrl_regs and
> rpm->req_regs.
>

Unfortunately, I still don't understand what practical drawback this
has, but I will of course change it per your request.

> [...]
>
>> > > +MODULE_DESCRIPTION("Qualcomm Resource Power Manager driver");
>> > > +MODULE_LICENSE("GPL v2");
>> >
>> > No one authored this driver?
>> >
>>
>> Thought that was optional, will update.
>
> It's also helpful.  Can you place an Author: line in the header(s) too.
>

Will do.

Regards,
Bjorn
--
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: [ANNOUNCE] (Resend) Tools to analyse PM and scheduling behaviour

[Sundar]

Hi Amit,

On Tue, Aug 19, 2014 at 11:11 AM, Amit Kucheria
 wrote:
>
> We’re soliciting early feedback from community on the direction of idlestat

Nice :)

> Idlestat Details
> 
> Idlestat uses FTRACE to capture traces related to C-state and P-state
> transitions of the CPU and wakeups (IRQ, IPI) on the system and then
> post-processes the data to print statistics. It is designed to be used
> non-interactively. Idlestat can deduce the idle time for a cluster as an
> intersection between the idle times of all the cpus belonging to the same
> cluster. This data is useful to analyse and optimise scheduling behaviour.
> The tool will also list how many times the menu governor mis-predicts
> target residency in a C-state.

We discussed this in the energy aware scheduling workshop this week @
the Kernel Summit. A few notes:

1. We need to really understand the co-relation of this tool w.r.t
actual hardware states.
It is usually likely that the software "thinks" it is in a low power
state, but the actual
hardware might not be. What is the coverage for these kind of cases here.

2. I understand that C/P states are a direct metric of how well the
workload behaved w.r.t power;
but I am not sure that relates to a direct measure of how the
scheduler performed. The C/P states
could be maintained whilst giving away performance or power at the
expense of additional components
on the SoC and platform like DDR IOs, fabric states etc.

Quick Summary of what I discussed with Daniel @ the workshop about idlestat:

1. There might be usually platform specific tools to get residencies
for P/C states.
PowerTop & Turbostat are two that first come to mind. Any specific
item apart from prediction logic
that idlestat differs from these two?

2. To me debugging performance or power, C/P states provide the
direction that something is wrong.
But they still dont tell me "what" is wrong "if" the issue is somehow
in the kernel as opposed to a more
easily fixable software code (traceable at hardware/software level for
best optimizations). How do I
conclude that my scheduler is the culprit apart from the points where
it took a decision to select the
right idle states based on predicted sleep times? In my opinion, that
would boil down to if the scheduler
was invoking too much load balancing calls, moving my threads across
cores too much, data being
thrashed across caches, cores too much etc.

I think a tool for scheduler metrics must be based on more inner
details like the above, finally culminating
into C/P states. as opposed to C/P states being the metric to be relied.

Let me know your thoughts.

Cheers!

-- these are my personal thoughts and do not represent my employers'
--
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] carl9170: Remove redundant protection check

[Christian Lamparter]

On Friday, August 22, 2014 04:23:19 PM Eric Dumazet wrote:
> On Fri, 2014-08-22 at 23:53 +0200, Christian Lamparter wrote:
> 
> > The sta_info->agg[tid] check is not needed (for reference, see [0]).
> > (There is already a check in mac80211 which prevents the leak of
> > sta_info->agg[tid] [1]).
> > 
> > Regards
> > Christian
> > 
> > [0] 
> > [1] 
> > 
> 
> Hmpfff... this code is quite confusing. 
That's true. Furthermore, parts of the logic are also embedded in
the mac80211-stack and above. So, it's very hard to see the whole
big picture, just by looking at the driver code.

> RCU is used both in tricky way (carl9170_ampdu_gc() is an example)
> and a talisman (the part you remove)
I know that game ;-). But fair enough: if you have concerns about
the complexity of the code in question: I'm willing to help you
and explain the quirks in detail if necessary. I think this is a
valuable addition, since "external consultants" are hard to come
by.

> Why is rcu_assign_pointer(sta_info->agg[tid], tid_info);
> done inside the spinlock protected region, I don't know.
The pointer in sta_info->agg[tid] is used exclusively by 
the tx.c code... It is queried only if an outgoing frame
has the IEEE80211_TX_CTL_AMPDU flag set. 

But for this flag to be set, the aggregation session has
to be operational. This requires two calls to ampdu_action [0].
(first with: IEEE80211_AMPDU_TX_START and later with:
IEEE80211_AMPDU_TX_OPERATIONAL).

=> If you want to make a patch to move this rcu_assign_pointer(...)
after the spin_unlock_bh() - Then: Yes, GO FOR IT!
 
> If this code relies on external protection, a comment would help its
> comprehension for sure.
> 
> For example, you could add a 
> BUG_ON(rcu_access_pointer(sta_info->agg[tid]));
> so that we are sure requirements are not changed
> in the callers one day.
Maybe, but then: Is a "specific driver" the right place for this?
Other drivers may also depend on ampdu_action not changing.
As for the logic: The AMPDU handshake itself is part of the 802.11
spec. If you are interested you can get 802.11-2012 [1] and look 
into Section 9.21 "Block Acknowledgment". It contains a message
sequence chart and details about the setup and tear down procedures
for aggregation session [which is at the heart of the ampdu_action
callback issue].

Note: mac80211 has a "software simulator" mac80211_hwsim [2].
It can be (and is) used to test most of the mac80211 functionality.
So what do you think?

Regards
Christian 

[0] 
[1] 
[2] 
--
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][SCSI] scsi-mq: fix requests that use a separate CDB buffer

[Douglas Gilbert]

On 14-08-22 08:52 PM, Douglas Gilbert wrote:

On 14-08-22 03:53 PM, Tony Battersby wrote:

This patch fixes code such as the following with scsi-mq enabled:

 rq = blk_get_request(...);
 blk_rq_set_block_pc(rq);

 rq->cmd = my_cmd_buffer; /* separate CDB buffer */

 blk_execute_rq_nowait(...);

Code like this appears in e.g. sg_start_req() in drivers/scsi/sg.c (for
large CDBs only).  Without this patch, scsi_mq_prep_fn() will set
rq->cmd back to rq->__cmd, causing the wrong CDB to be sent to the device.


Still looking at this one. 'sg_write_same --32' is my
tool of choice. The target is scsi_debug which needs
dif=2 (because mkp read the draft and only allows
WRITE SAME(32) when the protection_level=2). Turned
on command tracing and this is what I saw:

sd 7:0:0:0: scsi_debug: cmd 9e 10 00 00 00 00 00 00 00 00 00 00 00 20 00 00
sd 7:0:0:0: scsi_debug: cmd 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 08
24 6b d3 00 88 ff ff 20 00 c7 e8 00 00 00 00

So the WS(32) command did get through, it is the second
command that arrived on its tail that is a worry. So yes,
IMO it is broken.


Got that wrong, that is a READ CAPACITY(16) that got
through properly (issued by sg_write_same) followed
by a 32 byte command of random bytes instead of the
requested WS(32), the first 6 bytes of which will
cause it to be parsed as a TEST UNIT READY.


Now the >16 byte cdb length in the sg driver
introduced in lk 3.17-rc1 was copied directly
from the bsg driver which has had that capability
for some time. Since your patch touches two files
in drivers/block I'm wondering the bsg driver's
 >16 byte cdb length capability is broken in
lk 3.16 ?

Doug Gilbert



--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" 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 v2 0/3] x86: PER_CPU segment improvements

[Andy Lutomirski]

On Wed, Jul 30, 2014 at 3:07 PM, Andy Lutomirski  wrote:
> x86 sets up a per-cpu GDT entry so that vgetcpu can use LSL on it
> to determine the CPU number and node.

hpa, if/when you apply this, can you put it onto a fresh branch based
on something at least as new as 3.17-rc1?  It should apply cleanly
regardless, but the nine followup patches that I want to send also
depend on cleanup that isn't in tip/x86/vdso.

Thanks,
Andy

>
> This series, in little baby steps, cleans up that code and sets
> the accessed and 32-bit flags on the segment.
>
> The accessed bit prevents user code from setting the accessed bit
> on its own, and making the segment 32-bit prevents concerns about
> shenanigans involving CPU oddities with 16-bit data segments.
>
> The latter isn't a real problem -- if it were a 16-bit read/write
> segment, it could be used to bypass espfix64, but fortunately
> RO segments can't be loaded into SS.
>
> Changes from v1:
>  - Fix patch 2's changelog.
>  - Learn to spell "Not a system segment".
>
> Andy Lutomirski (3):
>   x86,vdso: Change the PER_CPU segment to use struct desc_struct
>   x86,vdso: Make the PER_CPU segment start out accessed
>   x86,vdso: Make the PER_CPU segment 32 bits
>
>  arch/x86/kernel/vsyscall_64.c | 19 ---
>  1 file changed, 12 insertions(+), 7 deletions(-)
>
> --
> 1.9.3
>



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
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][SCSI] scsi-mq: fix requests that use a separate CDB buffer

[Douglas Gilbert]

On 14-08-22 03:53 PM, Tony Battersby wrote:

This patch fixes code such as the following with scsi-mq enabled:

 rq = blk_get_request(...);
 blk_rq_set_block_pc(rq);

 rq->cmd = my_cmd_buffer; /* separate CDB buffer */

 blk_execute_rq_nowait(...);

Code like this appears in e.g. sg_start_req() in drivers/scsi/sg.c (for
large CDBs only).  Without this patch, scsi_mq_prep_fn() will set
rq->cmd back to rq->__cmd, causing the wrong CDB to be sent to the device.


Still looking at this one. 'sg_write_same --32' is my
tool of choice. The target is scsi_debug which needs
dif=2 (because mkp read the draft and only allows
WRITE SAME(32) when the protection_level=2). Turned
on command tracing and this is what I saw:

sd 7:0:0:0: scsi_debug: cmd 9e 10 00 00 00 00 00 00 00 00 00 00 00 20 00 00
sd 7:0:0:0: scsi_debug: cmd 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 08 
24 6b d3 00 88 ff ff 20 00 c7 e8 00 00 00 00


So the WS(32) command did get through, it is the second
command that arrived on its tail that is a worry. So yes,
IMO it is broken.


Now the >16 byte cdb length in the sg driver
introduced in lk 3.17-rc1 was copied directly
from the bsg driver which has had that capability
for some time. Since your patch touches two files
in drivers/block I'm wondering the bsg driver's
>16 byte cdb length capability is broken in
lk 3.16 ?

Doug Gilbert



--
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/2] pmbus: add regulator support

[atull]

On Fri, 22 Aug 2014, Mark Brown wrote:

> On Fri, Aug 22, 2014 at 04:11:33PM -0500, at...@opensource.altera.com wrote:
> 
> > +   if (pdata && pdata->reg_init_data) {
> > +   config.init_data = pdata->reg_init_data;
> > +   } else {
> > +   config.init_data = of_get_regulator_init_data(dev, np);
> > +   if (!config.init_data)
> > +   return -ENOMEM;
> > +   }
> 
> It should be fine to start with no init data - just let the regulator
> core worry about it.  This will allow users to read back the state even
> if they can't change anything which is useful for system bringup or
> general debugging.
> 

of_get_regulator_init_data() will only have an error if it cannot alloc 
the regulator_init_data struct.  That's why I did -ENOMEM.  If there
is no platform data and nothing about the regulator in the device tree, we 
should end up with a zeroed out regulator_init_data.

Thanks for the review.

Alan
--
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 2/3] usb: Add LED trigger for USB host activity

[Bryan Wu]

On Fri, Aug 22, 2014 at 5:08 PM, Michal Sojka  wrote:
> With this patch, USB host activity can be signaled by blinking a LED.
>
> This should work with all host controllers. Tested only with musb.
>
> Signed-off-by: Michal Sojka 
> ---
>  drivers/usb/core/Kconfig  |  9 +
>  drivers/usb/core/Makefile |  1 +
>  drivers/usb/core/hcd.c|  2 ++
>  drivers/usb/core/led.c| 38 ++
>  include/linux/usb/hcd.h   |  6 ++
>  5 files changed, 56 insertions(+)
>  create mode 100644 drivers/usb/core/led.c
>
> diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig
> index 1060657..8295f65 100644
> --- a/drivers/usb/core/Kconfig
> +++ b/drivers/usb/core/Kconfig
> @@ -90,3 +90,12 @@ config USB_OTG_FSM
>   Implements OTG Finite State Machine as specified in On-The-Go
>   and Embedded Host Supplement to the USB Revision 2.0 Specification.
>
> +config USB_HOST_LED
> +   bool "USB Host LED Trigger"
> +   depends on LEDS_CLASS
> +   select LEDS_TRIGGERS
> +   help
> + This option adds a LED trigger for USB host controllers.
> +
> + Say Y here if you are working on a system with led-class supported
> + LEDs and you want to use them as USB host activity indicators.
> diff --git a/drivers/usb/core/Makefile b/drivers/usb/core/Makefile
> index 2f6f932..324c8c9 100644
> --- a/drivers/usb/core/Makefile
> +++ b/drivers/usb/core/Makefile
> @@ -9,5 +9,6 @@ usbcore-y += port.o
>
>  usbcore-$(CONFIG_PCI)  += hcd-pci.o
>  usbcore-$(CONFIG_ACPI) += usb-acpi.o
> +usbcore-$(CONFIG_USB_HOST_LED) += led.o
>
>  obj-$(CONFIG_USB)  += usbcore.o
> diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
> index 487abcf..46d9f3a 100644
> --- a/drivers/usb/core/hcd.c
> +++ b/drivers/usb/core/hcd.c
> @@ -1664,6 +1664,8 @@ static void __usb_hcd_giveback_urb(struct urb *urb)
> usbmon_urb_complete(>self, urb, status);
> usb_anchor_suspend_wakeups(anchor);
> usb_unanchor_urb(urb);
> +   if (status == 0)
> +   usb_hcd_led_activity();
>
> /* pass ownership to the completion handler */
> urb->status = status;
> diff --git a/drivers/usb/core/led.c b/drivers/usb/core/led.c
> new file mode 100644
> index 000..49ff76c
> --- /dev/null
> +++ b/drivers/usb/core/led.c
> @@ -0,0 +1,38 @@
> +/*
> + * LED Trigger for USB Host Activity
> + *
> + * Copyright 2014 Michal Sojka 
> + *
> + * 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 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define BLINK_DELAY 30
> +
> +DEFINE_LED_TRIGGER(ledtrig_usb_hcd);

Add one more trigger named ledtrig_usb_gadget

> +static unsigned long usb_hcd_blink_delay = BLINK_DELAY;
> +
> +void usb_hcd_led_activity(void)

Give an input parameter like emum usb_led_event.
USB_LED_EVENT_HOST = 0
USB_LED_EVENT_GADGET = 1


> +{

Add case for USB_LED_EVENT_HOST:
> +   led_trigger_blink_oneshot(ledtrig_usb_hcd,
> + _hcd_blink_delay, _hcd_blink_delay, 
> 0);

Add case for USB_LED_EVENT_GADGET:
 led_trigger_blink_oneshot(ledtrig_usb_gadget,
 _gadget_blink_delay,
_gadget_blink_delay, 0);

> +}
> +
> +int __init ledtrig_usb_hcd_init(void)
> +{
> +   led_trigger_register_simple("usb-host", _usb_hcd);
register one more trigger for gadget.

> +   return 0;
> +}
> +
> +void __exit ledtrig_usb_hcd_exit(void)
> +{
> +   led_trigger_unregister_simple(ledtrig_usb_hcd);
unregister one more trigger for gadget.

> +}
> diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
> index b43f0fe..eb5fa0f 100644
> --- a/include/linux/usb/hcd.h
> +++ b/include/linux/usb/hcd.h
> @@ -700,6 +700,12 @@ extern struct rw_semaphore ehci_cf_port_reset_rwsem;
>  #define USB_EHCI_LOADED2
>  extern unsigned long usb_hcds_loaded;
>
> +#ifdef CONFIG_USB_HOST_LED
> +extern void usb_hcd_led_activity(void);

User can call usb_led_activity(USB_LED_EVENT_HOST);
or usb_led_activity(USB_LED_EVENT_GADGET);

> +#else
> +static inline void usb_hcd_led_activity(void) {}
> +#endif
> +
>  #endif /* __KERNEL__ */
>
>  #endif /* __USB_CORE_HCD_H */
> --
> 2.1.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: [PATCH][SCSI] fix regression in SCSI_IOCTL_SEND_COMMAND

[Christoph Hellwig]

On Fri, Aug 22, 2014 at 08:28:27PM -0400, Douglas Gilbert wrote:
> To test this ioctl one option is to get the sg3_utils
> package and build scsi_ioctl.c in the examples
> directory with 'make scsi_ioctl'.
>
> In lk 3.17-rc1, scsi_ioctl indicates that
> SCSI_IOCTL_SEND_COMMAND is not working. In my test applying
> this patch fixes the regression.

Is there any amount of chocolate or beer that could trick you into adding an
automated regression test suite to sg3_utils that could be used to
automatically check for regressions like this?

--
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][SCSI] fix regression in SCSI_IOCTL_SEND_COMMAND

[Douglas Gilbert]

On 14-08-22 03:53 PM, Tony Battersby wrote:

blk_rq_set_block_pc() memsets rq->cmd to 0, so it should come
immediately after blk_get_request() to avoid overwriting the
user-supplied CDB.  Also check for failure to allocate rq.

Fixes: f27b087b81b7 ("block: add blk_rq_set_block_pc()")
Cc:  # 3.16.x
Signed-off-by: Tony Battersby 


Tested-by: Douglas Gilbert 


For inclusion in 3.17 and 3.16.x.

Note: I don't have any programs that use this ioctl, so this patch is
compile-tested only.


To test this ioctl one option is to get the sg3_utils
package and build scsi_ioctl.c in the examples
directory with 'make scsi_ioctl'.

In lk 3.17-rc1, scsi_ioctl indicates that
SCSI_IOCTL_SEND_COMMAND is not working. In my test applying
this patch fixes the regression.


--- linux-3.17.0-rc1-a/block/scsi_ioctl.c   2014-08-16 12:40:26.0 
-0400
+++ linux-3.17.0-rc1-b/block/scsi_ioctl.c   2014-08-22 14:15:34.0 
-0400
@@ -448,6 +448,11 @@ int sg_scsi_ioctl(struct request_queue *
}

rq = blk_get_request(q, in_len ? WRITE : READ, __GFP_WAIT);
+   if (!rq) {
+   err = -ENOMEM;
+   goto error;
+   }
+   blk_rq_set_block_pc(rq);

cmdlen = COMMAND_SIZE(opcode);

@@ -501,7 +506,6 @@ int sg_scsi_ioctl(struct request_queue *
memset(sense, 0, sizeof(sense));
rq->sense = sense;
rq->sense_len = 0;
-   blk_rq_set_block_pc(rq);

blk_execute_rq(q, disk, rq, 0);

@@ -521,7 +525,8 @@ out:

  error:
kfree(buffer);
-   blk_put_request(rq);
+   if (rq)
+   blk_put_request(rq);
return err;
  }
  EXPORT_SYMBOL_GPL(sg_scsi_ioctl);

--


--
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 0/7] MIPS: Move device-tree files to a common location

[Andrew Bresticker]

On Fri, Aug 22, 2014 at 4:16 PM, Jonas Gorski  wrote:
> On Sat, Aug 23, 2014 at 12:10 AM, Andrew Bresticker
>  wrote:
>> On Fri, Aug 22, 2014 at 1:57 PM, David Daney  wrote:
>>> On 08/22/2014 01:42 PM, Florian Fainelli wrote:

 On Aug 21, 2014 3:05 PM, "Andrew Bresticker" >>> > wrote:
  >
  > To be consistent with other architectures and to avoid unnecessary
  > makefile duplication, move all MIPS device-trees to arch/mips/boot/dts
  > and build them with a common makefile.

 I recall reading that the ARM organization for DTS files was a bit
 unfortunate and should have been something like:

 arch/arm/boot/dts//

 Is this something we should do for the MIPS and update the other
 architectures to follow that scheme?
>>>
>>>
>>> If we choose not to intermingle .dts files from all the vendors in a single
>>> directory, why do anything at all?  Currently the .dts files for a vendor
>>> are nicely segregated with the rest of the vendors code under a single
>>> directory.
>>>
>>> Personally I think things are fine as they are.  Any common code remaining
>>> in the Makefiles could be moved to the scripts directory for a smaller
>>> change.
>>
>> Assuming we don't move them to a common location just to segregate
>> them again, it makes MIPS consistent with every other architecture
>> (not just ARM!) using DT.  It also makes it easier to introduce common
>> changes later on, like the 'dtbs' or 'dtbs_install' make targets.
>
> I think having dts files under a predictable location is a good idea,
> especially if it allows common code/targets as "dtbs".
>
> Maybe a totally insane idea, but how this for having the cake and eating it 
> too:
>
> arch/mips/boot/dts/*.dts => dts files to be built along side the kernel as 
> .dtbs
>
> arch/mips//*.dts => dts files built into the kernel
>
> (the ../*.dts isn't meant as they should be in the top directory, just
> somewhere in that sub tree)
>
> Because I can see a use case where you want both. For example octeon
> uses generic device tree boards to use as a basis if the bootloader
> did not provide one/is too old, but maybe also provide dts files for
> known boards, which shouldn't be included in the kernel binary itself.

I'm not sure I like having DTs in both the common and per-platform
directories, but this is a use case I've been think about as well.
What I'm thinking is: have "make dtbs" build all applicable DTBs for
the selected platform and, based on other config options, build some
subset of those DTBs in the kernel.  For example: if CONFIG_RALINK,
"make dtbs" builds all the {mt,rt}*_eval.dtb's and, when building the
kernel, one of those dtbs may be built into the kernel based on which
CONFIG_DTB_RT* option is selected (if any).  I'm not sure yet what the
cleanest way to do that is though.
--
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] LED triggers for USB host and device

[Bryan Wu]

On Fri, Aug 22, 2014 at 5:08 PM, Michal Sojka  wrote:
> This adds LED triggers for USB host and device.
>
> Changes from v1:
> - Moved from drivers/leds/ to drivers/usb/
> - Improved Kconfig help
> - Linked with other modules rather than being standalone modules
>
> Michal Sojka (3):
>   usb: Add missing #include
>   usb: Add LED trigger for USB host activity
>   usb: Add LED trigger for USB gadget activity
>
>  drivers/usb/core/Kconfig|  9 +
>  drivers/usb/core/Makefile   |  1 +
>  drivers/usb/core/hcd.c  |  2 ++
>  drivers/usb/core/led.c  | 38 ++

I suggest put host trigger and gadget trigger together in
drivers/usb/core/led.c.

>  drivers/usb/gadget/Kconfig  | 12 
>  drivers/usb/gadget/udc/Makefile |  5 -
>  drivers/usb/gadget/udc/led.c| 38 ++

We don't need a duplicated version for gadget.

>  drivers/usb/musb/musb_gadget.c  |  5 +++--
>  include/linux/usb/gadget.h  | 10 ++
>  include/linux/usb/hcd.h |  7 +++
>  10 files changed, 124 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/usb/core/led.c
>  create mode 100644 drivers/usb/gadget/udc/led.c
>
> --
> 2.1.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: [PATCH v2 00/14] Add support for parameterized events from sysfs

[Sukadev Bhattiprolu]

Jiri Olsa [jo...@redhat.com] wrote:


| > Description of the sysfs contents when events are parameterized (copied 
from an
| > included patch):
| > 
| > Examples:
| > 
| > domain=0x1,offset=0x8,starting_index=phys_cpu
| > 
| > In the case of the last example, a value replacing "phys_cpu"
| > would need to be provided by the user selecting the particular
| > event. This is refered to as "event parameterization". All
| > non-numerical values indicate an event parameter.
| > 
| > Notes on how perf-list displays parameterized events (and how to use them,
| > again culled from an included patch):
| > 
| > PARAMETERIZED EVENTS
| > 
| > 
| > Some pmu events listed by 'perf-list' will be displayed with '?' in
| > them. For example:
| > 
| >   hv_gpci/dtbp_ptitc,phys_processor_idx=?/
| > 
| > This means that when provided as an event, a value for
| > phys_processor_idx must also be supplied. For example:
| > 
| >   perf stat -e 'hv_gpci/dtbp_ptitc,phys_processor_idx=0x2/' ...
| 
| hi,
| is the reason for this to document this field for event
| in "events/" file?

We are trying to document that for the parameters that have the ? in
perf list, the parameter must be specified otherwise the event will
not be recognized.

| 
| Because once you have the field (phys_processor_idx) defined in
| "formats/phys_processor_idx" you should be able to use it as in
| your example:
| 
|perf stat -e 'hv_gpci/dtbp_ptitc,phys_processor_idx=0x2/'
| 
| without any changes

For some events 'starting_index' refers to physical processor index
as shown in the sysfs entry:

$ cd /sys/bus/event_source/devices/hv_gpci/events
$ cat dispatch_timebase_by_processor_processor_time_in_timebase_cycles

request=0x10,starting_index=phys_processor_idx,counter_info_version=0x8,length=8,offset=0

and 'perf list' for this entry shows 'starting_index' with a ?
indicating it is a requireed parameter.

IIUC, rather than have the user specify a value for 'phys_processor_idx'

-e hv_gpci/dtbp_ptitc,phys_processor_idx=4/'

we would use following right ?

-e hv_gpci/dtbp_ptitc,starting_index=4/'

If so, I think the interface change makes sense.  perf list would also
show 'starting_index=?' for the event. 

But in the sysfs entry, rather than show 'starting_index=?', should we
leave it as:

'starting_index=phys_processor_idx' 

For some events 'startind_index' refers to a physical processor id
and for others it is virtual processor id. So, showing phys_processor_idx
could serve as a hint.

Michael, Cody, Ingo, Peter, let me know if you agree or have other
comments on the inteface.

Thanks,

Sukadev



| 
| thanks,
| jirka

--
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] leds: make led_blink_set IRQ safe

[Bryan Wu]

On Tue, Aug 19, 2014 at 6:51 PM, Hugh Dickins  wrote:
> On Tue, 19 Aug 2014, Vincent Donnefort wrote:
>
>> This patch introduces a work which take care of reseting the blink workqueue 
>> and
>> avoid calling the cancel_delayed_work_sync function which may sleep, from an 
>> IRQ
>> context.
>>

Vincent, I'm just wandering can we use cancel_delayed_work() instead
of sync version here.
cancel_delayed_work() can be called from IRQ context.

>> Signed-off-by: Vincent Donnefort 
>
> Thanks.  It does work for me.  Though the problem was more general than
> stated above: not just a problem in IRQ context, but in any atomic context.
>
> I don't suppose it has any effect on Valdis's lockdep issue, which I
> didn't get to see myself; but we should let Valdis report back on that.
>
> May I (most ungratefully!) say that your patch doesn't fill me with
> confidence that it's the right solution: adding yet another work_struct
> to get around the issue seemed dubious to me, I wonder if it might expose
> new races.
>

I agree with Hugh about this new cancel work_struct. But if we revert
it back, I saw led_blink_set() will call del_timer_sync() which might
also sleep and can't be used in IRQ context. Looks like we can't call
led_blink_set() in any IRQ/atomic context.

> But rest assured that I know nothing about this, and I'm not at all
> qualified to review your patch: I hope Bryan and others will do so.
>

Let me invite Tejun to give some advice on how to solve this problem.

Tejun, Vincent's commit 8b37e1bef5a6b60e949e28a4db3006e4b00bd758
convert a timer into work_struct, but Hugh found it will cause
sleeping BUGs [1]. Could you give some opinion about that?

Thanks,
-Bryan

[1]: https://lkml.org/lkml/2014/8/16/128


>
>>
>> diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
>> index 129729d..0971554 100644
>> --- a/drivers/leds/led-class.c
>> +++ b/drivers/leds/led-class.c
>> @@ -148,6 +148,24 @@ static void led_work_function(struct work_struct *ws)
>>  msecs_to_jiffies(delay));
>>  }
>>
>> +static void reset_blink_work_delayed(struct work_struct *ws)
>> +{
>> + struct led_classdev *led_cdev =
>> + container_of(ws, struct led_classdev, reset_blink_work);
>> +
>> + cancel_delayed_work_sync(_cdev->blink_work);
>> +
>> + if (!led_cdev->blink_delay_on) {
>> + __led_set_brightness(led_cdev, LED_OFF);
>> + return;
>> + } else if (!led_cdev->blink_delay_off) {
>> + __led_set_brightness(led_cdev, led_cdev->blink_brightness);
>> + return;
>> + }
>> +
>> + queue_delayed_work(system_wq, _cdev->blink_work, 1);
>> +}
>> +
>>  static void set_brightness_delayed(struct work_struct *ws)
>>  {
>>   struct led_classdev *led_cdev =
>> @@ -234,6 +252,7 @@ int led_classdev_register(struct device *parent, struct 
>> led_classdev *led_cdev)
>>   INIT_WORK(_cdev->set_brightness_work, set_brightness_delayed);
>>
>>   INIT_DELAYED_WORK(_cdev->blink_work, led_work_function);
>> + INIT_WORK(_cdev->reset_blink_work, reset_blink_work_delayed);
>>
>>  #ifdef CONFIG_LEDS_TRIGGERS
>>   led_trigger_set_default(led_cdev);
>> diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
>> index 4bb1168..959510a 100644
>> --- a/drivers/leds/led-core.c
>> +++ b/drivers/leds/led-core.c
>> @@ -40,19 +40,7 @@ static void led_set_software_blink(struct led_classdev 
>> *led_cdev,
>>   led_cdev->blink_delay_on = delay_on;
>>   led_cdev->blink_delay_off = delay_off;
>>
>> - /* never on - just set to off */
>> - if (!delay_on) {
>> - __led_set_brightness(led_cdev, LED_OFF);
>> - return;
>> - }
>> -
>> - /* never off - just set to brightness */
>> - if (!delay_off) {
>> - __led_set_brightness(led_cdev, led_cdev->blink_brightness);
>> - return;
>> - }
>> -
>> - queue_delayed_work(system_wq, _cdev->blink_work, 1);
>> + schedule_work(_cdev->reset_blink_work);
>>  }
>>
>>
>> @@ -76,8 +64,6 @@ void led_blink_set(struct led_classdev *led_cdev,
>>  unsigned long *delay_on,
>>  unsigned long *delay_off)
>>  {
>> - cancel_delayed_work_sync(_cdev->blink_work);
>> -
>>   led_cdev->flags &= ~LED_BLINK_ONESHOT;
>>   led_cdev->flags &= ~LED_BLINK_ONESHOT_STOP;
>>
>> diff --git a/include/linux/leds.h b/include/linux/leds.h
>> index 6a599dc..6e5523d 100644
>> --- a/include/linux/leds.h
>> +++ b/include/linux/leds.h
>> @@ -69,6 +69,7 @@ struct led_classdev {
>>
>>   unsigned longblink_delay_on, blink_delay_off;
>>   struct delayed_work  blink_work;
>> + struct work_struct   reset_blink_work;
>>   int  blink_brightness;
>>
>>   struct work_struct  set_brightness_work;
>> --
>> 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  

[PATCH 0/2] Rockchip SoC thermal driver

[Caesar Wang]

This series adds support for the thermal Found on Rockhip SoCs.

Caesar Wang (2):
  dt-bindings: document Rockchip thermal
  thermal: rockchip: add driver for Rockchip thermal

Tested on rk3288 Board.
 .../bindings/thermal/rockchip-thermal.txt  |   33 +
 drivers/thermal/Kconfig|9 +
 drivers/thermal/Makefile   |1 +
 drivers/thermal/rockchip_thermal.c |  659 
 4 files changed, 702 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
 create mode 100644 drivers/thermal/rockchip_thermal.c

-- 
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/

[PATCH 2/2] thermal: rockchip: add driver for Rockchip thermal

[Caesar Wang]

Thermal is TS-ADC Controller module supports user-defined mode and automatic 
mode.

User-defined mode refers,TSADC all the control signals entirely by software
writing to register for direct control.

Automaic mode refers to the module automatically poll TSADC output,and the 
results
Were checked.

If you find that the temperature High in a period of time, an interrupt is 
generated
to the processor down-measures taken;if the temperature over a period of time 
High,
the resulting TSHUT gave CRU module,let it reset the entire chip, or via GPIO 
give PMIC.

Signed-off-by: zhaoyifeng 
Signed-off-by: Caesar Wang 
---
 drivers/thermal/Kconfig|9 +
 drivers/thermal/Makefile   |1 +
 drivers/thermal/rockchip_thermal.c |  659 
 3 files changed, 669 insertions(+)
 create mode 100644 drivers/thermal/rockchip_thermal.c

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 74226dc..43d2400 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -141,6 +141,15 @@ config SPEAR_THERMAL
  Enable this to plug the SPEAr thermal sensor driver into the Linux
  thermal framework.
 
+config ROCKCHIP_THERMAL
+   tristate "Rockchip thermal driver"
+   depends on ARCH_ROCKCHIP
+   help
+ Support for Temperature Sensor ADC (TS-ADC) found on Rockchip SoCs.
+ It supports one critical trip point and one passive trip point.  The
+ cpufreq is used as the cooling device to throttle CPUs when the
+ passive trip is crossed.
+
 config RCAR_THERMAL
tristate "Renesas R-Car thermal driver"
depends on ARCH_SHMOBILE || COMPILE_TEST
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 419c3cd..009a457 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -20,6 +20,7 @@ thermal_sys-$(CONFIG_CPU_THERMAL) += cpu_cooling.o
 
 # platform thermal drivers
 obj-$(CONFIG_SPEAR_THERMAL)+= spear_thermal.o
+obj-$(CONFIG_ROCKCHIP_THERMAL) += rockchip_thermal.o
 obj-$(CONFIG_RCAR_THERMAL) += rcar_thermal.o
 obj-$(CONFIG_KIRKWOOD_THERMAL)  += kirkwood_thermal.o
 obj-y  += samsung/
diff --git a/drivers/thermal/rockchip_thermal.c 
b/drivers/thermal/rockchip_thermal.c
new file mode 100644
index 000..93adb61
--- /dev/null
+++ b/drivers/thermal/rockchip_thermal.c
@@ -0,0 +1,659 @@
+/*
+ * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
+ * Author: Rockchip, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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.
+ *
+*/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "thermal_core.h"
+
+enum rockchip_thermal_trip {
+   ROCKCHIP_TRIP_PASSIVE,
+   ROCKCHIP_TRIP_CRITICAL,
+   ROCKCHIP_TRIP_NUM,
+};
+
+struct rockchip_thermal_data {
+   struct rockchip_tsadc_platform_data *pdata;
+   struct thermal_zone_device *tz;
+   struct thermal_cooling_device *cdev;
+   enum thermal_device_mode mode;
+   void __iomem *regs;
+
+   signed long temp_passive;
+   signed long temp_critical;
+   signed long temp_force_shut;
+   signed long alarm_temp;
+   signed long last_temp;
+   bool irq_enabled;
+   int irq;
+   struct clk *tsadc_clk;
+   struct clk *tsadc_pclk;
+};
+
+struct rockchip_tsadc_platform_data {
+   u8 irq_en;
+   signed long temp_passive;
+   signed long temp_critical;
+   signed long temp_force_shut;
+   int passive_delay;
+   int polling_delay;
+
+   int (*irq_handle)(void __iomem *reg);
+   int (*initialize)(void __iomem *reg, signed long temp_force_shut);
+   int (*control)(void __iomem *reg, bool on);
+   u32 (*code_to_temp)(int temp);
+   u32 (*temp_to_code)(int temp);
+   void (*set_alarm_temp)(void __iomem *regs, signed long temp);
+};
+
+/*TSADC V2 Sensor info define:*/
+#define TSADC_AUTO_CON 0x04
+#define TSADC_INT_EN   0x08
+#define TSADC_INT_PD   0x0c
+#define TSADC_DATA10x24
+#define TSADC_COMP1_INT0x34
+#define TSADC_COMP1_SHUT   0x44
+#define TSADC_AUTO_PERIOD  0x68
+#define TSADC_AUTO_PERIOD_HT   0x6c
+
+#define TSADC_AUTO_SRC1_EN (1 << 5)
+#define TSADC_AUTO_EN  (1 << 0)
+#define TSADC_AUTO_DISABLE ~(1 << 0)
+#define TSADC_AUTO_STAS_BUSY   (1 << 16)
+#define TSADC_AUTO_STAS_BUSY_MASK  (1 << 16)
+#define 

[PATCH 1/2] dt-bindings: document Rockchip thermal

[Caesar Wang]

This add the necessary binding documentation for the thermal
found on Rockchip SoCs

Signed-off-by: zhaoyifeng 
Signed-off-by: Caesar Wang 
---
 .../bindings/thermal/rockchip-thermal.txt  |   33 
 1 file changed, 33 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/thermal/rockchip-thermal.txt

diff --git a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt 
b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
new file mode 100644
index 000..b556eae
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
@@ -0,0 +1,33 @@
+* Temperature Sensor ADC (TSADC) on rockchip SoCs
+
+Required properties:
+- compatible : "rockchip,rk3288-tsadc"
+- reg : physical base address of the controller and length of memory mapped
+  region.
+- interrupts : The interrupt number to the cpu. The interrupt specifier format
+  depends on the interrupt controller.
+- clocks : Must contain an entry for each entry in clock-names.
+- clock-names : Shall be "tsadc_clk" for the transfer-clock, and "tsadc_pclk" 
for
+the peripheral clock.
+Optional properties:
+- clock-frequency : Thermal sensor's clock frequency.
+- pinctrl-names : Should contain only one value - "default".
+- pinctrl-0 : Should contain only one value - _int.
+- passive-temp : Temperature of trip 0.
+- critical-temp : Temperature of trip 1.
+- force-shut-temp : Temperature of force shut down.
+Example:
+
+tsadc: tsadc@ff28 {
+   compatible = "rockchip,rk3288-tsadc";
+   reg = <0xff28 0x100>;
+   interrupts = ;
+   clock-frequency = <1>;
+   clocks = < SCLK_TSADC>, < PCLK_TSADC>;
+   clock-names = "tsadc_clk", "tsadc_pclk";
+   pinctrl-names = "default";
+   pinctrl-1 = <_int>;
+   passive-temp = <80>;
+   critical-temp = <100>;
+   force-shut-temp = <120>;
+};
-- 
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/

[PATCH v2 1/3] usb: Add missing #include

[Michal Sojka]

linux/usb/hcd.h needs the definition of struct usb_bus.

Signed-off-by: Michal Sojka 
---
 include/linux/usb/hcd.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
index 485cd5e..b43f0fe 100644
--- a/include/linux/usb/hcd.h
+++ b/include/linux/usb/hcd.h
@@ -23,6 +23,7 @@
 
 #include 
 #include 
+#include 
 
 #define MAX_TOPO_LEVEL 6
 
-- 
2.1.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 v2 0/3] LED triggers for USB host and device

[Michal Sojka]

This adds LED triggers for USB host and device.

Changes from v1:
- Moved from drivers/leds/ to drivers/usb/
- Improved Kconfig help
- Linked with other modules rather than being standalone modules

Michal Sojka (3):
  usb: Add missing #include
  usb: Add LED trigger for USB host activity
  usb: Add LED trigger for USB gadget activity

 drivers/usb/core/Kconfig|  9 +
 drivers/usb/core/Makefile   |  1 +
 drivers/usb/core/hcd.c  |  2 ++
 drivers/usb/core/led.c  | 38 ++
 drivers/usb/gadget/Kconfig  | 12 
 drivers/usb/gadget/udc/Makefile |  5 -
 drivers/usb/gadget/udc/led.c| 38 ++
 drivers/usb/musb/musb_gadget.c  |  5 +++--
 include/linux/usb/gadget.h  | 10 ++
 include/linux/usb/hcd.h |  7 +++
 10 files changed, 124 insertions(+), 3 deletions(-)
 create mode 100644 drivers/usb/core/led.c
 create mode 100644 drivers/usb/gadget/udc/led.c

-- 
2.1.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 v2 2/3] usb: Add LED trigger for USB host activity

[Michal Sojka]

With this patch, USB host activity can be signaled by blinking a LED.

This should work with all host controllers. Tested only with musb.

Signed-off-by: Michal Sojka 
---
 drivers/usb/core/Kconfig  |  9 +
 drivers/usb/core/Makefile |  1 +
 drivers/usb/core/hcd.c|  2 ++
 drivers/usb/core/led.c| 38 ++
 include/linux/usb/hcd.h   |  6 ++
 5 files changed, 56 insertions(+)
 create mode 100644 drivers/usb/core/led.c

diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig
index 1060657..8295f65 100644
--- a/drivers/usb/core/Kconfig
+++ b/drivers/usb/core/Kconfig
@@ -90,3 +90,12 @@ config USB_OTG_FSM
  Implements OTG Finite State Machine as specified in On-The-Go
  and Embedded Host Supplement to the USB Revision 2.0 Specification.
 
+config USB_HOST_LED
+   bool "USB Host LED Trigger"
+   depends on LEDS_CLASS
+   select LEDS_TRIGGERS
+   help
+ This option adds a LED trigger for USB host controllers.
+
+ Say Y here if you are working on a system with led-class supported
+ LEDs and you want to use them as USB host activity indicators.
diff --git a/drivers/usb/core/Makefile b/drivers/usb/core/Makefile
index 2f6f932..324c8c9 100644
--- a/drivers/usb/core/Makefile
+++ b/drivers/usb/core/Makefile
@@ -9,5 +9,6 @@ usbcore-y += port.o
 
 usbcore-$(CONFIG_PCI)  += hcd-pci.o
 usbcore-$(CONFIG_ACPI) += usb-acpi.o
+usbcore-$(CONFIG_USB_HOST_LED) += led.o
 
 obj-$(CONFIG_USB)  += usbcore.o
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 487abcf..46d9f3a 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -1664,6 +1664,8 @@ static void __usb_hcd_giveback_urb(struct urb *urb)
usbmon_urb_complete(>self, urb, status);
usb_anchor_suspend_wakeups(anchor);
usb_unanchor_urb(urb);
+   if (status == 0)
+   usb_hcd_led_activity();
 
/* pass ownership to the completion handler */
urb->status = status;
diff --git a/drivers/usb/core/led.c b/drivers/usb/core/led.c
new file mode 100644
index 000..49ff76c
--- /dev/null
+++ b/drivers/usb/core/led.c
@@ -0,0 +1,38 @@
+/*
+ * LED Trigger for USB Host Activity
+ *
+ * Copyright 2014 Michal Sojka 
+ *
+ * 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 
+#include 
+#include 
+#include 
+#include 
+
+#define BLINK_DELAY 30
+
+DEFINE_LED_TRIGGER(ledtrig_usb_hcd);
+static unsigned long usb_hcd_blink_delay = BLINK_DELAY;
+
+void usb_hcd_led_activity(void)
+{
+   led_trigger_blink_oneshot(ledtrig_usb_hcd,
+ _hcd_blink_delay, _hcd_blink_delay, 
0);
+}
+
+int __init ledtrig_usb_hcd_init(void)
+{
+   led_trigger_register_simple("usb-host", _usb_hcd);
+   return 0;
+}
+
+void __exit ledtrig_usb_hcd_exit(void)
+{
+   led_trigger_unregister_simple(ledtrig_usb_hcd);
+}
diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
index b43f0fe..eb5fa0f 100644
--- a/include/linux/usb/hcd.h
+++ b/include/linux/usb/hcd.h
@@ -700,6 +700,12 @@ extern struct rw_semaphore ehci_cf_port_reset_rwsem;
 #define USB_EHCI_LOADED2
 extern unsigned long usb_hcds_loaded;
 
+#ifdef CONFIG_USB_HOST_LED
+extern void usb_hcd_led_activity(void);
+#else
+static inline void usb_hcd_led_activity(void) {}
+#endif
+
 #endif /* __KERNEL__ */
 
 #endif /* __USB_CORE_HCD_H */
-- 
2.1.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 v2 3/3] usb: Add LED trigger for USB gadget activity

[Michal Sojka]

With this patch, USB gadget activity can be signaled by blinking a LED.

Since there is no generic code where to put the trigger for all USB
controllers, each USB controller needs to call the trigger individually.
This patch adds the call only for the musb controller where I can test
it.

Signed-off-by: Michal Sojka 
---
 drivers/usb/gadget/Kconfig  | 12 
 drivers/usb/gadget/udc/Makefile |  5 -
 drivers/usb/gadget/udc/led.c| 38 ++
 drivers/usb/musb/musb_gadget.c  |  5 +++--
 include/linux/usb/gadget.h  | 10 ++
 5 files changed, 67 insertions(+), 3 deletions(-)
 create mode 100644 drivers/usb/gadget/udc/led.c

diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 5c822af..612c859 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -127,6 +127,18 @@ config USB_GADGET_STORAGE_NUM_BUFFERS
   a module parameter as well.
   If unsure, say 2.
 
+config USB_GADGET_LED
+   bool "USB Gadget LED Trigger"
+   depends on (USB_MUSB_GADGET || USB_MUSB_DUAL_ROLE)
+   depends on LEDS_CLASS
+   select LEDS_TRIGGERS
+   help
+ This option adds a LED trigger for USB gadgets. The trigger will
+ only work with supported USB device controllers.
+
+ Say Y here if you are working on a system with led-class supported
+ LEDs and you want to use them as USB gadget activity indicators.
+
 source "drivers/usb/gadget/udc/Kconfig"
 
 #
diff --git a/drivers/usb/gadget/udc/Makefile b/drivers/usb/gadget/udc/Makefile
index 4096122..acbe3ca 100644
--- a/drivers/usb/gadget/udc/Makefile
+++ b/drivers/usb/gadget/udc/Makefile
@@ -1,7 +1,10 @@
 #
 # USB peripheral controller drivers
 #
-obj-$(CONFIG_USB_GADGET)   += udc-core.o
+obj-$(CONFIG_USB_GADGET)   += udc.o
+udc-y  := udc-core.o
+udc-$(CONFIG_USB_GADGET_LED)   += led.o
+
 obj-$(CONFIG_USB_DUMMY_HCD)+= dummy_hcd.o
 obj-$(CONFIG_USB_NET2272)  += net2272.o
 obj-$(CONFIG_USB_NET2280)  += net2280.o
diff --git a/drivers/usb/gadget/udc/led.c b/drivers/usb/gadget/udc/led.c
new file mode 100644
index 000..29a8b3f
--- /dev/null
+++ b/drivers/usb/gadget/udc/led.c
@@ -0,0 +1,38 @@
+/*
+ * LED Trigger for USB Gadget Activity
+ *
+ * Copyright 2014 Michal Sojka 
+ *
+ * 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 
+#include 
+#include 
+#include 
+
+#define BLINK_DELAY 30
+
+DEFINE_LED_TRIGGER(ledtrig_usbgadget);
+static unsigned long usbgadget_blink_delay = BLINK_DELAY;
+
+void usb_gadget_led_activity(void)
+{
+   led_trigger_blink_oneshot(ledtrig_usbgadget,
+ _blink_delay, 
_blink_delay, 0);
+}
+EXPORT_SYMBOL(usb_gadget_led_activity);
+
+int __init ledtrig_usbgadget_init(void)
+{
+   led_trigger_register_simple("usb-gadget", _usbgadget);
+   return 0;
+}
+
+void __exit ledtrig_usbgadget_exit(void)
+{
+   led_trigger_unregister_simple(ledtrig_usbgadget);
+}
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index d4aa779..0bf06f9 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -167,11 +167,12 @@ __acquires(ep->musb->lock)
if (!dma_mapping_error(>g.dev, request->dma))
unmap_dma_buffer(req, musb);
 
-   if (request->status == 0)
+   if (request->status == 0) {
dev_dbg(musb->controller, "%s done request %p,  %d/%d\n",
ep->end_point.name, request,
req->request.actual, req->request.length);
-   else
+   usb_gadget_led_activity();
+   } else
dev_dbg(musb->controller, "%s request %p, %d/%d fault %d\n",
ep->end_point.name, request,
req->request.actual, req->request.length,
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index c3a6185..69bd9bc 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -1025,4 +1025,14 @@ extern struct usb_ep *usb_ep_autoconfig_ss(struct 
usb_gadget *,
 
 extern void usb_ep_autoconfig_reset(struct usb_gadget *);
 
+/*-*/
+
+/* LED trigger */
+
+#ifdef CONFIG_USB_GADGET_LED
+extern void usb_gadget_led_activity(void);
+#else
+static inline void usb_gadget_led_activity(void) {}
+#endif
+
 #endif /* __LINUX_USB_GADGET_H */
-- 
2.1.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 v4] spi: spi-imx: add DMA support

[Robin Gong]

After enable DMA

spi-nor read speed is
dd if=/dev/mtd0 of=/dev/null bs=1M count=1
1+0 records in
1+0 records out
1048576 bytes (1.0 MB) copied, 0.720402 s, 1.5 MB/s

spi-nor write speed is
dd if=/dev/zero of=/dev/mtd0 bs=1M count=1
1+0 records in
1+0 records out
1048576 bytes (1.0 MB) copied, 3.56044 s, 295 kB/s

Before enable DMA

spi-nor read speed is
dd if=/dev/mtd0 of=/dev/null bs=1M count=1
1+0 records in
1+0 records out
1048576 bytes (1.0 MB) copied, 2.37717 s, 441 kB/s

spi-nor write speed is

dd if=/dev/zero of=/dev/mtd0 bs=1M count=1
1+0 records in
1+0 records out
1048576 bytes (1.0 MB) copied, 4.83181 s, 217 kB/s

Signed-off-by: Frank Li 
Signed-off-by: Robin Gong 
---
 drivers/spi/spi-imx.c |  303 -
 1 file changed, 297 insertions(+), 6 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 5daff20..d8e5817 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -21,6 +21,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -37,6 +39,7 @@
 #include 
 #include 
 
+#include 
 #include 
 
 #define DRIVER_NAME "spi_imx"
@@ -51,6 +54,9 @@
 #define MXC_INT_RR (1 << 0) /* Receive data ready interrupt */
 #define MXC_INT_TE (1 << 1) /* Transmit FIFO empty interrupt */
 
+/* The maximum  bytes that a sdma BD can transfer.*/
+#define MAX_SDMA_BD_BYTES  (1 << 15)
+#define IMX_DMA_TIMEOUT (msecs_to_jiffies(3000))
 struct spi_imx_config {
unsigned int speed_hz;
unsigned int bpw;
@@ -97,6 +103,15 @@ struct spi_imx_data {
 
const struct spi_imx_devtype_data *devtype_data;
int chipselect[0];
+   /* DMA */
+   unsigned int dma_is_inited;
+   unsigned int dma_finished;
+   bool usedma;
+   u32 rx_wml;
+   u32 tx_wml;
+   u32 rxt_wml;
+   struct completion dma_rx_completion;
+   struct completion dma_tx_completion;
 };
 
 static inline int is_imx27_cspi(struct spi_imx_data *d)
@@ -181,9 +196,24 @@ static unsigned int spi_imx_clkdiv_2(unsigned int fin,
return 7;
 }
 
+static bool spi_imx_can_dma(struct spi_master *master, struct spi_device *spi,
+struct spi_transfer *transfer)
+{
+   struct spi_imx_data *spi_imx = spi_master_get_devdata(master);
+
+   if (spi_imx->dma_is_inited && (transfer->len > spi_imx->rx_wml)
+   && (transfer->len > spi_imx->tx_wml))
+   spi_imx->usedma = true;
+   else
+   spi_imx->usedma = false;
+
+   return spi_imx->usedma;
+}
+
 #define MX51_ECSPI_CTRL0x08
 #define MX51_ECSPI_CTRL_ENABLE (1 <<  0)
 #define MX51_ECSPI_CTRL_XCH(1 <<  2)
+#define MX51_ECSPI_CTRL_SMC(1 << 3)
 #define MX51_ECSPI_CTRL_MODE_MASK  (0xf << 4)
 #define MX51_ECSPI_CTRL_POSTDIV_OFFSET 8
 #define MX51_ECSPI_CTRL_PREDIV_OFFSET  12
@@ -201,6 +231,18 @@ static unsigned int spi_imx_clkdiv_2(unsigned int fin,
 #define MX51_ECSPI_INT_TEEN(1 <<  0)
 #define MX51_ECSPI_INT_RREN(1 <<  3)
 
+#define MX51_ECSPI_DMA  0x14
+#define MX51_ECSPI_DMA_TX_WML_OFFSET   0
+#define MX51_ECSPI_DMA_TX_WML_MASK 0x3F
+#define MX51_ECSPI_DMA_RX_WML_OFFSET   16
+#define MX51_ECSPI_DMA_RX_WML_MASK (0x3F << 16)
+#define MX51_ECSPI_DMA_RXT_WML_OFFSET  24
+#define MX51_ECSPI_DMA_RXT_WML_MASK(0x3F << 24)
+
+#define MX51_ECSPI_DMA_TEDEN_OFFSET7
+#define MX51_ECSPI_DMA_RXDEN_OFFSET23
+#define MX51_ECSPI_DMA_RXTDEN_OFFSET   31
+
 #define MX51_ECSPI_STAT0x18
 #define MX51_ECSPI_STAT_RR (1 <<  3)
 
@@ -257,17 +299,22 @@ static void __maybe_unused mx51_ecspi_intctrl(struct 
spi_imx_data *spi_imx, int
 
 static void __maybe_unused mx51_ecspi_trigger(struct spi_imx_data *spi_imx)
 {
-   u32 reg;
-
-   reg = readl(spi_imx->base + MX51_ECSPI_CTRL);
-   reg |= MX51_ECSPI_CTRL_XCH;
+   u32 reg = readl(spi_imx->base + MX51_ECSPI_CTRL);
+
+   if (!spi_imx->usedma)
+   reg |= MX51_ECSPI_CTRL_XCH;
+   else if (!spi_imx->dma_finished)
+   reg |= MX51_ECSPI_CTRL_SMC;
+   else
+   reg &= ~MX51_ECSPI_CTRL_SMC;
writel(reg, spi_imx->base + MX51_ECSPI_CTRL);
 }
 
 static int __maybe_unused mx51_ecspi_config(struct spi_imx_data *spi_imx,
struct spi_imx_config *config)
 {
-   u32 ctrl = MX51_ECSPI_CTRL_ENABLE, cfg = 0;
+   u32 ctrl = MX51_ECSPI_CTRL_ENABLE, cfg = 0, dma = 0;
+   u32 tx_wml_cfg, rx_wml_cfg, rxt_wml_cfg;
u32 clk = config->speed_hz, delay;
 
/*
@@ -319,6 +366,30 @@ static int __maybe_unused mx51_ecspi_config(struct 
spi_imx_data *spi_imx,
else/* SCLK is _very_ slow */
usleep_range(delay, delay + 10);
 
+   /*
+* Configure the DMA register: setup the watermark
+* and enable DMA request.
+*/
+   if (spi_imx->dma_is_inited) {
+   dma = readl(spi_imx->base + 

Re: [PATCH] Kconfig: do not select SPI bus on sub-driver auto-select

[Jeff Mahoney]

On Fri Aug 22 19:34:12 2014, Randy Dunlap wrote:
> On 08/22/14 10:04, Jeff Mahoney wrote:
>> On Fri Aug 22 13:02:09 2014, Antti Palosaari wrote:
>>> We should not select SPI bus when sub-driver auto-select is
>>> selected. That option is meant for auto-selecting all possible
>>> ancillary drivers used for selected board driver. Ancillary
>>> drivers should define needed dependencies itself.
>>>
>>> I2C and I2C_MUX are still selected here for a reason described on
>>> commit 347f7a3763601d7b466898d1f10080b7083ac4a3
>>>
>>> Reverts commit e4462ffc1602d9df21c00a0381dca9080474e27a
>>>
>>> Reported-by: Jeff Mahoney 
>>> Signed-off-by: Antti Palosaari 
>>> ---
>>>  drivers/media/Kconfig | 1 -
>>>  1 file changed, 1 deletion(-)
>>>
>>> diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
>>> index f60bad4..3c89fcb 100644
>>> --- a/drivers/media/Kconfig
>>> +++ b/drivers/media/Kconfig
>>> @@ -182,7 +182,6 @@ config MEDIA_SUBDRV_AUTOSELECT
>>> depends on HAS_IOMEM
>>> select I2C
>>> select I2C_MUX
>>> -   select SPI
>>> default y
>>> help
>>>   By default, a media driver auto-selects all possible ancillary
>>
>> FWIW, in the patch I used locally, I also did a 'select SPI' in the
>> MSI2500 driver since it wouldn't otherwise be obvious that a USB device
>> depends on SPI.
>
> It already has depends on SPI.  That should be enough.
>

Yeah. My point was more that if you want support for that device, you'd 
have to know it uses SPI internally already.

-Jeff

--
Jeff Mahoney
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/

[PATCH] staging: fix style in lustre_import.h

[Spencer Baugh]

This patch fixes style errors and warnings reported by
scripts/checkpatch.pl

Signed-off-by: Spencer Baugh 

---
 .../staging/lustre/lustre/include/lustre_import.h   | 21 -
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/lustre/lustre/include/lustre_import.h 
b/drivers/staging/lustre/lustre/include/lustre_import.h
index 8304a55..b39b283 100644
--- a/drivers/staging/lustre/lustre/include/lustre_import.h
+++ b/drivers/staging/lustre/lustre/include/lustre_import.h
@@ -103,15 +103,15 @@ enum lustre_imp_state {
 };
 
 /** Returns test string representation of numeric import state \a state */
-static inline char * ptlrpc_import_state_name(enum lustre_imp_state state)
+static inline char *ptlrpc_import_state_name(enum lustre_imp_state state)
 {
-   static char* import_state_names[] = {
+   static char *import_state_names[] = {
"", "CLOSED",  "NEW", "DISCONN",
"CONNECTING", "REPLAY", "REPLAY_LOCKS", "REPLAY_WAIT",
"RECOVER", "FULL", "EVICTED",
};
 
-   LASSERT (state <= LUSTRE_IMP_EVICTED);
+   LASSERT(state <= LUSTRE_IMP_EVICTED);
return import_state_names[state];
 }
 
@@ -302,12 +302,12 @@ struct obd_import {
intimp_connect_error;
 
__u32imp_msg_magic;
-   __u32imp_msghdr_flags;   /* adjusted based on 
server capability */
+   __u32imp_msghdr_flags;   /* adjusted based on server 
capability */
 
-   struct ptlrpc_request_pool *imp_rq_pool;  /* emergency request 
pool */
+   struct ptlrpc_request_pool *imp_rq_pool; /* emergency request pool */
 
struct imp_atimp_at; /* adaptive timeout data */
-   time_t  imp_last_reply_time;/* for health check */
+   time_t  imp_last_reply_time; /* for health check */
 };
 
 typedef void (*obd_import_callback)(struct obd_import *imp, void *closure,
@@ -346,21 +346,24 @@ static inline unsigned int at_timeout2est(unsigned int 
val)
return (max((val << 2) / 5, 5U) - 4);
 }
 
-static inline void at_reset(struct adaptive_timeout *at, int val) {
+static inline void at_reset(struct adaptive_timeout *at, int val)
+{
spin_lock(>at_lock);
at->at_current = val;
at->at_worst_ever = val;
at->at_worst_time = get_seconds();
spin_unlock(>at_lock);
 }
-static inline void at_init(struct adaptive_timeout *at, int val, int flags) {
+static inline void at_init(struct adaptive_timeout *at, int val, int flags)
+{
memset(at, 0, sizeof(*at));
spin_lock_init(>at_lock);
at->at_flags = flags;
at_reset(at, val);
 }
 extern unsigned int at_min;
-static inline int at_get(struct adaptive_timeout *at) {
+static inline int at_get(struct adaptive_timeout *at)
+{
return (at->at_current > at_min) ? at->at_current : at_min;
 }
 int at_measured(struct adaptive_timeout *at, unsigned int val);
-- 
2.0.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/

Re: [PATCH 1/2] leds: usb: Add LED trigger for USB gadget activity

[Michal Sojka]

On Fri, Aug 22 2014, Greg Kroah-Hartman wrote:
> On Fri, Aug 22, 2014 at 10:39:03AM -0700, Bryan Wu wrote:
>> On Fri, Aug 22, 2014 at 4:53 AM, Michal Sojka  wrote:
>> > With this patch, USB gadget activity can be signaled by blinking a LED.
>> >
>> > Since there is no generic code where to put the trigger for all USB
>> > controllers, each USB controller needs to call the trigger individually.
>> > This patch adds the call only for the musb controller where I can test
>> > it.
>> >
>> 
>> Generally I think one led trigger for both USB host and USB gadget
>> activity is good enough. We don't need 2 same led trigger here.
>
> What about systems that have both running at the same time?  Don't you
> want individual control?

Yes, I have a device with two USB connectors (host, device) and a LED
next to each. From the LEDs it should be clear, which connector is being
used.

Thanks,
-Michal
--
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] leds: usb: Add LED trigger for USB gadget activity

[Michal Sojka]

Hi Felipe,

On Fri, Aug 22 2014, Felipe Balbi wrote:
> Hi,
>
> On Fri, Aug 22, 2014 at 01:53:12PM +0200, Michal Sojka wrote:
>> With this patch, USB gadget activity can be signaled by blinking a LED.
>> 
>> Since there is no generic code where to put the trigger for all USB
>> controllers, each USB controller needs to call the trigger individually.
>> This patch adds the call only for the musb controller where I can test
>> it.
>> 
>> Signed-off-by: Michal Sojka 
>> ---
>>  drivers/leds/trigger/Kconfig |  8 ++
>>  drivers/leds/trigger/Makefile|  1 +
>>  drivers/leds/trigger/ledtrig-usbgadget.c | 45 
>> 
>>  drivers/usb/musb/musb_gadget.c   |  6 +++--
>>  include/linux/leds.h |  6 +
>>  5 files changed, 64 insertions(+), 2 deletions(-)
>>  create mode 100644 drivers/leds/trigger/ledtrig-usbgadget.c
>> 
>> diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig
>> index 49794b4..9562963 100644
>> --- a/drivers/leds/trigger/Kconfig
>> +++ b/drivers/leds/trigger/Kconfig
>> @@ -41,6 +41,14 @@ config LEDS_TRIGGER_IDE_DISK
>>This allows LEDs to be controlled by IDE disk activity.
>>If unsure, say Y.
>>  
>> +config LEDS_TRIGGER_USBGADGET
>> +bool "LED USB Gadget Trigger"
>> +depends on (USB_MUSB_GADGET || USB_MUSB_DUAL_ROLE)
>> +depends on LEDS_TRIGGERS
>> +help
>> +  This allows LEDs to be controlled by USB gadget activity.
>> +  If unsure, say Y.
>> +
>>  config LEDS_TRIGGER_HEARTBEAT
>>  tristate "LED Heartbeat Trigger"
>>  depends on LEDS_TRIGGERS
>> diff --git a/drivers/leds/trigger/Makefile b/drivers/leds/trigger/Makefile
>> index 1abf48d..45917c0 100644
>> --- a/drivers/leds/trigger/Makefile
>> +++ b/drivers/leds/trigger/Makefile
>> @@ -8,3 +8,4 @@ obj-$(CONFIG_LEDS_TRIGGER_CPU)   += ledtrig-cpu.o
>>  obj-$(CONFIG_LEDS_TRIGGER_DEFAULT_ON)   += ledtrig-default-on.o
>>  obj-$(CONFIG_LEDS_TRIGGER_TRANSIENT)+= ledtrig-transient.o
>>  obj-$(CONFIG_LEDS_TRIGGER_CAMERA)   += ledtrig-camera.o
>> +obj-$(CONFIG_LEDS_TRIGGER_USBGADGET)+= ledtrig-usbgadget.o
>> diff --git a/drivers/leds/trigger/ledtrig-usbgadget.c 
>> b/drivers/leds/trigger/ledtrig-usbgadget.c
>> new file mode 100644
>> index 000..1eb90da
>> --- /dev/null
>> +++ b/drivers/leds/trigger/ledtrig-usbgadget.c
>> @@ -0,0 +1,45 @@
>> +/*
>> + * LED Trigger for USB Gadget Activity
>> + *
>> + * Copyright 2014 Michal Sojka 
>> + *
>> + * 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 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define BLINK_DELAY 30
>> +
>> +DEFINE_LED_TRIGGER(ledtrig_usbgadget);
>> +static unsigned long usbgadget_blink_delay = BLINK_DELAY;
>> +
>> +void ledtrig_usbgadget_activity(void)
>> +{
>> +led_trigger_blink_oneshot(ledtrig_usbgadget,
>> +  _blink_delay, 
>> _blink_delay, 0);
>> +}
>> +EXPORT_SYMBOL(ledtrig_usbgadget_activity);
>> +
>> +static int __init ledtrig_usbgadget_init(void)
>> +{
>> +led_trigger_register_simple("usb-gadget", _usbgadget);
>> +return 0;
>> +}
>> +
>> +static void __exit ledtrig_usbgadget_exit(void)
>> +{
>> +led_trigger_unregister_simple(ledtrig_usbgadget);
>> +}
>> +
>> +module_init(ledtrig_usbgadget_init);
>> +module_exit(ledtrig_usbgadget_exit);
>> +
>> +MODULE_AUTHOR("Michal Sojka ");
>> +MODULE_DESCRIPTION("LED Trigger for USB Gadget Activity");
>> +MODULE_LICENSE("GPL");
>> diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
>> index d4aa779..98f8b24 100644
>> --- a/drivers/usb/musb/musb_gadget.c
>> +++ b/drivers/usb/musb/musb_gadget.c
>> @@ -42,6 +42,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  
>>  #include "musb_core.h"
>>  
>> @@ -167,11 +168,12 @@ __acquires(ep->musb->lock)
>>  if (!dma_mapping_error(>g.dev, request->dma))
>>  unmap_dma_buffer(req, musb);
>>  
>> -if (request->status == 0)
>> +if (request->status == 0) {
>>  dev_dbg(musb->controller, "%s done request %p,  %d/%d\n",
>>  ep->end_point.name, request,
>>  req->request.actual, req->request.length);
>> -else
>> +ledtrig_usbgadget_activity();
>
> looks like this should, somehow, be done at udc-core.c although you'd
> need some refactoring to make that happen. It shouldn't be too difficult
> to have a generic usb_gadget_giveback_request()

I'm sending a second version, where it is moved to udc directory. I'll
look at refactoring next week.

Thanks,
-Michal
--
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  

Re: [PATCH 1/2] leds: usb: Add LED trigger for USB gadget activity

[Bryan Wu]

On Fri, Aug 22, 2014 at 2:42 PM, Greg Kroah-Hartman
 wrote:
> On Fri, Aug 22, 2014 at 10:39:03AM -0700, Bryan Wu wrote:
>> On Fri, Aug 22, 2014 at 4:53 AM, Michal Sojka  wrote:
>> > With this patch, USB gadget activity can be signaled by blinking a LED.
>> >
>> > Since there is no generic code where to put the trigger for all USB
>> > controllers, each USB controller needs to call the trigger individually.
>> > This patch adds the call only for the musb controller where I can test
>> > it.
>> >
>>
>> Generally I think one led trigger for both USB host and USB gadget
>> activity is good enough. We don't need 2 same led trigger here.
>
> What about systems that have both running at the same time?  Don't you
> want individual control?
>

Actually I wanted to say we don't need 2 same driver for USB host and
USB gadget but one driver which has 2 led triggers like
usb_host_ledtrig and usb_gadget_ledtrig.

I think drivers/net/can/led.c is a good example to start.

>> And probably you can just put this code in drivers/usb subsystem,
>> since this driver is quite simple to add to USB subsystem.
>
> I have no objection to that, if the LED people don't mind it.
>

Because logically it's only used by USB subsystem and it can be a core
component of USB, also drivers/net/can/led.c is a good example.

Thanks,
-Bryan
--
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 RESEND] firmware: Update information in linux.git about adding firmware

[Ben Hutchings]

Kyle McMartin recently joined the linux-firmware maintainers, and we now
have an alias  which reaches all of us.
Include that instead of the individual addresses.

Add some further recommendations that were already included in the
README in linux-firmware.git added by Xose Vazquez Perez
.

Signed-off-by: Ben Hutchings 
---
 firmware/README.AddingFirmware | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/firmware/README.AddingFirmware b/firmware/README.AddingFirmware
index ea78c3a..bcb5f46 100644
--- a/firmware/README.AddingFirmware
+++ b/firmware/README.AddingFirmware
@@ -21,15 +21,25 @@ been permitted to redistribute under separate cover.
 
 To submit firmware to that repository, please send either a git binary
 diff or preferably a git pull request to:
-  David Woodhouse 
-  Ben Hutchings 
+  linux-firmw...@kernel.org
+and also cc: to related mailing lists.
 
 Your commit should include an update to the WHENCE file clearly
 identifying the licence under which the firmware is available, and
 that it is redistributable. If the licence is long and involved, it's
 permitted to include it in a separate file and refer to it from the
 WHENCE file.
+And if it were possible, a changelog of the firmware itself.
 
 Ideally, your commit should contain a Signed-Off-By: from someone
 authoritative on the licensing of the firmware in question (i.e. from
 within the company that owns the code).
+
+
+WARNING:
+===
+
+Don't send any "CONFIDENTIALITY STATEMENT" in your e-mail, patch or
+request. Otherwise your firmware _will never be accepted_.
+
+Maintainers are really busy, so don't expect a prompt reply.


-- 
Ben Hutchings
Lowery's Law:
 If it jams, force it. If it breaks, it needed replacing anyway.


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

[PATCH] purgatory: add clean-up for purgatory directory

[Michael Welling]

Without this patch the kexec-purgatory.c and purgatory.ro files are not removed 
after make mrproper.

Signed-off-by: Michael Welling 
---
 arch/x86/Makefile |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index c96bcec..60087ca 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -251,6 +251,7 @@ archclean:
$(Q)rm -rf $(objtree)/arch/x86_64
$(Q)$(MAKE) $(clean)=$(boot)
$(Q)$(MAKE) $(clean)=arch/x86/tools
+   $(Q)$(MAKE) $(clean)=arch/x86/purgatory
 
 PHONY += kvmconfig
 kvmconfig:
-- 
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] Kconfig: do not select SPI bus on sub-driver auto-select

[Randy Dunlap]

On 08/22/14 10:04, Jeff Mahoney wrote:
> On Fri Aug 22 13:02:09 2014, Antti Palosaari wrote:
>> We should not select SPI bus when sub-driver auto-select is
>> selected. That option is meant for auto-selecting all possible
>> ancillary drivers used for selected board driver. Ancillary
>> drivers should define needed dependencies itself.
>>
>> I2C and I2C_MUX are still selected here for a reason described on
>> commit 347f7a3763601d7b466898d1f10080b7083ac4a3
>>
>> Reverts commit e4462ffc1602d9df21c00a0381dca9080474e27a
>>
>> Reported-by: Jeff Mahoney 
>> Signed-off-by: Antti Palosaari 
>> ---
>>  drivers/media/Kconfig | 1 -
>>  1 file changed, 1 deletion(-)
>>
>> diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
>> index f60bad4..3c89fcb 100644
>> --- a/drivers/media/Kconfig
>> +++ b/drivers/media/Kconfig
>> @@ -182,7 +182,6 @@ config MEDIA_SUBDRV_AUTOSELECT
>>  depends on HAS_IOMEM
>>  select I2C
>>  select I2C_MUX
>> -select SPI
>>  default y
>>  help
>>By default, a media driver auto-selects all possible ancillary
> 
> FWIW, in the patch I used locally, I also did a 'select SPI' in the 
> MSI2500 driver since it wouldn't otherwise be obvious that a USB device 
> depends on SPI.

It already has depends on SPI.  That should be enough.

-- 
~Randy
--
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] checkpatch: look for common misspellings

[Kees Cook]

On Fri, Aug 22, 2014 at 4:22 PM, Joe Perches  wrote:
> On Fri, 2014-08-22 at 23:00 +, Elliott, Robert (Server Storage)
> wrote:
>> > From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
>> > ow...@vger.kernel.org] On Behalf Of Joe Perches
>> ...
>> > +chang||change
>>
>> Although there are at least 2 misuses in the current kernel,
>> that's also a fairly common name.
>
> True.  Thanks.
>
> That one should likely be removed.
> There are dozens of Chang name uses in the kernel.

Right, I removed a bunch similar things like this.

> I'm not attached at all to any of these btw.
>
> Any others you think should not be used or
> should be added?
>
> One I thought kind of iffy was
>
> contant||contact
>
> Maybe that should be content instead.

Or "constant". I'll go through the list and see if anything stands out.

> Another thing the script might do is to check
> if the $typo match is all upper case and then
> substitute an all upper case $typo_fix.

That might be a good idea.

> It's also kind of noisy when run using -f,
> so maybe this test should be --strict check with
> files and a warning with patches.

Sure, seems reasonable. I'll get a v2 spun up.

-Kees

-- 
Kees Cook
Chrome OS Security
--
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: [Xen-devel] [V0 PATCH 1/2] AMD-PVH: set EFER.NX and EFER.SCE for the boot vcpu

[Mukesh Rathor]

On Fri, 22 Aug 2014 12:09:27 -0700
Mukesh Rathor  wrote:

> On Fri, 22 Aug 2014 06:41:40 +0200
> Borislav Petkov  wrote:
> 
> > On Thu, Aug 21, 2014 at 07:46:56PM -0700, Mukesh Rathor wrote:
> > > Intel doesn't have EFER.NX bit.
> > 
> > Of course it does.
> > 
> 
> Right, it does. Some code/comment is misleading... Anyways, reading
> intel SDMs, if I understand the convoluted text correctly, EFER.NX is
> not required to be set for l1.nx to be set, thus allowing for page
> level protection. Where as on AMD, EFER.NX must be set for l1.nx to
> be used. So, in the end, this patch would apply to both amd/intel 
> 
> I'll reword and submit.

Err, try again, the section "4.1.1 Three Paging Modes" says:

"Execute-disable access rights are applied only if IA32_EFER.NXE = 1"

So, I guess NX is broken on Intel PVH because EFER.NX is currently 
not being set.  While AMD will #GP if l1.NX is set and EFER.NX is not, 
I guess Intel just ignores the l1.XD if EFER.NX is not set. 

Mukesh
--
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 3/3] tg3: Fix tx_pending checks for tg3_tso_bug

[Prashant Sreedharan]

Benjamin, thanks for the patch. Broadcom QA will be testing the changes.
Couple of comments below.
>   segs = skb_gso_segment(skb, tp->dev->features &
>   ~(NETIF_F_TSO | NETIF_F_TSO6));
> - if (IS_ERR(segs) || !segs)
> + if (IS_ERR_OR_NULL(segs))
>   goto tg3_tso_bug_end;
>  
>   do {
> + unsigned int desc_cnt = skb_shinfo(segs)->nr_frags + 1;
> +
>   nskb = segs;
>   segs = segs->next;
>   nskb->next = NULL;
> - tg3_start_xmit(nskb, tp->dev);
> +
> + if (tg3_tx_avail(tnapi) <= segs_remaining - 1 + desc_cnt &&
> + skb_linearize(nskb)) {
> + nskb->next = segs;
> + segs = nskb;
> + do {
> + nskb = segs->next;
> +
> + dev_kfree_skb_any(segs);
> + segs = nskb;
> + } while (segs);

If skb_linearize() fails need to increment the tp->tx_dropped count

> + goto tg3_tso_bug_end;
> + }
> + segs_remaining--;
> + if (segs_remaining)
> + __tg3_start_xmit(nskb, tp->dev, segs_remaining);

To clarify passing segs_remaining will make sure the queue is never
stopped correct ?

> + else
> + tg3_start_xmit(nskb, tp->dev);
>   } while (segs);
>  


--
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] carl9170: Remove redundant protection check

[Eric Dumazet]

On Fri, 2014-08-22 at 23:53 +0200, Christian Lamparter wrote:

> The sta_info->agg[tid] check is not needed (for reference, see [0]).
> (There is already a check in mac80211 which prevents the leak of
> sta_info->agg[tid] [1]).
> 
> Regards
> Christian
> 
> [0] 
> [1] 
> 

Hmpfff... this code is quite confusing. RCU is used both in tricky way
(carl9170_ampdu_gc() is an example) and a talisman (the part you remove)

Why is rcu_assign_pointer(sta_info->agg[tid], tid_info);
done inside the spinlock protected region, I don't know.

If this code relies on external protection, a comment would help its
comprehension for sure.

For example, you could add a 
BUG_ON(rcu_access_pointer(sta_info->agg[tid]));
so that we are sure requirements are not changed in the callers one day.



--
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] checkpatch: look for common misspellings

[Joe Perches]

On Fri, 2014-08-22 at 23:00 +, Elliott, Robert (Server Storage)
wrote:
> > From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> > ow...@vger.kernel.org] On Behalf Of Joe Perches
> ...
> > +chang||change
> 
> Although there are at least 2 misuses in the current kernel,
> that's also a fairly common name.

True.  Thanks.

That one should likely be removed.
There are dozens of Chang name uses in the kernel.

I'm not attached at all to any of these btw.

Any others you think should not be used or
should be added?

One I thought kind of iffy was

contant||contact

Maybe that should be content instead.

Another thing the script might do is to check
if the $typo match is all upper case and then
substitute an all upper case $typo_fix.

It's also kind of noisy when run using -f,
so maybe this test should be --strict check with
files and a warning with patches.


--
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 0/7] MIPS: Move device-tree files to a common location

[Jonas Gorski]

On Sat, Aug 23, 2014 at 12:10 AM, Andrew Bresticker
 wrote:
> On Fri, Aug 22, 2014 at 1:57 PM, David Daney  wrote:
>> On 08/22/2014 01:42 PM, Florian Fainelli wrote:
>>>
>>> On Aug 21, 2014 3:05 PM, "Andrew Bresticker" >> > wrote:
>>>  >
>>>  > To be consistent with other architectures and to avoid unnecessary
>>>  > makefile duplication, move all MIPS device-trees to arch/mips/boot/dts
>>>  > and build them with a common makefile.
>>>
>>> I recall reading that the ARM organization for DTS files was a bit
>>> unfortunate and should have been something like:
>>>
>>> arch/arm/boot/dts//
>>>
>>> Is this something we should do for the MIPS and update the other
>>> architectures to follow that scheme?
>>
>>
>> If we choose not to intermingle .dts files from all the vendors in a single
>> directory, why do anything at all?  Currently the .dts files for a vendor
>> are nicely segregated with the rest of the vendors code under a single
>> directory.
>>
>> Personally I think things are fine as they are.  Any common code remaining
>> in the Makefiles could be moved to the scripts directory for a smaller
>> change.
>
> Assuming we don't move them to a common location just to segregate
> them again, it makes MIPS consistent with every other architecture
> (not just ARM!) using DT.  It also makes it easier to introduce common
> changes later on, like the 'dtbs' or 'dtbs_install' make targets.

I think having dts files under a predictable location is a good idea,
especially if it allows common code/targets as "dtbs".

Maybe a totally insane idea, but how this for having the cake and eating it too:

arch/mips/boot/dts/*.dts => dts files to be built along side the kernel as .dtbs

arch/mips//*.dts => dts files built into the kernel

(the ../*.dts isn't meant as they should be in the top directory, just
somewhere in that sub tree)

Because I can see a use case where you want both. For example octeon
uses generic device tree boards to use as a basis if the bootloader
did not provide one/is too old, but maybe also provide dts files for
known boards, which shouldn't be included in the kernel binary itself.

And I would like to do a similar thing when I want to convert bcm63xx
to device tree, i.e. have dts files for supported boards, but also
include a "standard"/"fall-back" dts for each of the supported SoCs to
load if there is no dtb passed and the old board registration code is
used.


Jonas
--
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/1] ARM: exynos_defconfig: Enable options for display panel support

[Javier Martinez Canillas]

Many Exynos devices have a display panel, most of them just have
a simple panel while others have more complex configurations that
requires an embedded DisplayPort (eDP) to LVDS display bridge.

This patch enables the following features to support both setups:

- Direct Rendering Manager (DRM)
- DRM bridge registration and lookup framework
- Parade ps8622/ps8625 eDP/LVDS bridge
- NXP ptn3460 eDP/LVDS bridge
- Exynos Fully Interactive Mobile Display controller (FIMD)
- Panel registration and lookup framework
- Simple panels
- Backlight and LCD device support

Signed-off-by: Javier Martinez Canillas 
---

Some of the options enabled here (e.g: the eDP/LVDS bridges)
are still not merged in mainline so this patch depends on
the following posted patches that were still not merged:

"drm/bridge: Modify drm_bridge core to support driver model" [0]
"drm/bridge: Add i2c based driver for ptn3460 bridge" [1]
"drm/bridge: Add i2c based driver for ps8622/ps8625 bridge" [2]

But I wanted to post anyways to make easier for others to
figure out what are the needed options to have the display
working on their Exynos machines.

In order to test the display panel on the Peach machines,
the following patches are also needed:

"ARM: dts: Add DT changes for display on peach_pit" [3]
"ARM: dts: Add DT changes for display on peach_pi" [4]

Best regards,
Javier

[0]: http://patchwork.ozlabs.org/patch/373792/
[1]: http://patchwork.ozlabs.org/patch/373793/
[2]: http://patchwork.ozlabs.org/patch/373794/
[3]: http://www.spinics.net/lists/arm-kernel/msg350568.html
[4]: http://www.spinics.net/lists/arm-kernel/msg350569.html 

 arch/arm/configs/exynos_defconfig | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/configs/exynos_defconfig 
b/arch/arm/configs/exynos_defconfig
index 676c744..f69d57e 100644
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -101,11 +101,25 @@ CONFIG_REGULATOR_S2MPA01=y
 CONFIG_REGULATOR_S2MPS11=y
 CONFIG_REGULATOR_S5M8767=y
 CONFIG_REGULATOR_TPS65090=y
+CONFIG_DRM=y
+CONFIG_DRM_BRIDGE=y
+CONFIG_DRM_PS8622=y
+CONFIG_DRM_EXYNOS=y
+CONFIG_DRM_EXYNOS_FIMD=y
+CONFIG_DRM_EXYNOS_DP=y
+CONFIG_DRM_PANEL=y
+CONFIG_DRM_PANEL_SIMPLE=y
 CONFIG_FB=y
 CONFIG_FB_MODE_HELPERS=y
 CONFIG_FB_SIMPLE=y
 CONFIG_EXYNOS_VIDEO=y
 CONFIG_EXYNOS_MIPI_DSI=y
+CONFIG_BACKLIGHT_LCD_SUPPORT=y
+CONFIG_LCD_CLASS_DEVICE=y
+CONFIG_LCD_PLATFORM=y
+CONFIG_BACKLIGHT_CLASS_DEVICE=y
+CONFIG_BACKLIGHT_GENERIC=y
+CONFIG_BACKLIGHT_PWM=y
 CONFIG_FRAMEBUFFER_CONSOLE=y
 CONFIG_FONTS=y
 CONFIG_FONT_7x14=y
-- 
2.0.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/3] mtd: nand: omap: Revert to using software ECC by default

[Tony Lindgren]

* Grazvydas Ignotas  [140806 15:57]:
> On Wed, Aug 6, 2014 at 11:02 AM, Roger Quadros  wrote:
> > Hi Gražvydas,
> >
> > On 08/05/2014 07:15 PM, Grazvydas Ignotas wrote:
> >> On Tue, Aug 5, 2014 at 1:11 PM, Roger Quadros  wrote:
> >>> For v3.12 and prior, 1-bit Hamming code ECC via software was the
> >>> default choice. Commit c66d039197e4 in v3.13 changed the behaviour
> >>> to use 1-bit Hamming code via Hardware using a different ECC layout
> >>> i.e. (ROM code layout) than what is used by software ECC.
> >>>
> >>> This ECC layout change causes NAND filesystems created in v3.12
> >>> and prior to be unusable in v3.13 and later. So revert back to
> >>> using software ECC by default if an ECC scheme is not explicitely
> >>> specified.
> >>>
> >>> This defect can be observed on the following boards during legacy boot
> >>>
> >>> -omap3beagle
> >>> -omap3touchbook
> >>> -overo
> >>> -am3517crane
> >>> -devkit8000
> >>> -ldp
> >>> -3430sdp
> >>
> >> omap3pandora is also using sw ecc, with ubifs. Some time ago I tried
> >> booting mainline (I think it was 3.14) with rootfs on NAND, and while
> >> it did boot and reached a shell, there were lots of ubifs errors, fs
> >> got corrupted and I lost all my data. I used to be able to boot
> >> mainline this way fine sometime ~3.8 release. It's interesting that
> >> 3.14 was able to read the data, even with wrong ecc setup.
> >
> > This is due to another bug introduced in 3.7 by commit 
> > 65b97cf6b8deca3ad7a3e00e8316bb89617190fb.
> > Because of that bug (i.e. inverted CS_MASK in omap_calculate_ecc), 
> > omap_calculate_ecc() always fails with -EINVAL and calculated ECC bytes are 
> > always 0. I'll be sending a patch to fix that as well. But that will only 
> > affect the cases where OMAP_ECC_HAM1_CODE_HW is used which happened for 
> > pandora from 3.13 onwards.
> >
> >>
> >> Do you think it's safe again to boot ubifs created on 3.2 after
> >> applying this series?
> >>
> >
> > Yes. If you boot pandora using legacy boot (non DT method), it passes 0 for 
> > .ecc_opt in pandora_nand_data. This used to mean 
> > OMAP_ECC_HAMMING_CODE_DEFAULT which is software ecc. i.e. NAND_ECC_SOFT 
> > with default ECC layout. Until the above mentioned commits changed the 
> > meaning. We now call that option OMAP_ECC_HAM1_CODE_SW.
> >
> > Please let me know if it works for you. Thanks.
> 
> Yes it does, thank you.
> Tested-by: Grazvydas Ignotas 

OK thanks applying the whole series into omap-for-v3.17/fixes.

Tony
--
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/

CIJ inks

[John]

Dear Sir, 

  Glad to hear you're on the market for CIJ inks.
  This is Kingsfang(Xiamen)Import Co.,Ltd in China.We specialized in the 
production of replacement of inkjet printer ink,such as Imaje, Domino, 
Videojet, Linx, Willet, Hitachi, KGK and so on, we have our own factory.
   For all the ink products got the SGS approval every year. Some have passed 
non-halogen request.
  
  Hope to find a way to cooperate with you!

Saleskingsfang
Kingsfang(Xiamen)Import Co.,Ltd
Tel: +86-592-6058718
Email:sm...@kingsfang.com
Website: www.kingsfang.com

Re: [PATCH 01/19] ARM: OMAP: fix %d confusingly prefixed with 0x in format string

[Tony Lindgren]

* Hans Wennborg  [140803 17:21]:
> Signed-off-by: Hans Wennborg 
> ---
>  arch/arm/mach-omap2/id.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
> index d42022f..53841de 100644
> --- a/arch/arm/mach-omap2/id.c
> +++ b/arch/arm/mach-omap2/id.c
> @@ -663,7 +663,7 @@ void __init dra7xxx_check_revision(void)
>  
>   default:
>   /* Unknown default to latest silicon rev as default*/
> - pr_warn("%s: unknown idcode=0x%08x (hawkeye=0x%08x,rev=0x%d)\n",
> + pr_warn("%s: unknown idcode=0x%08x (hawkeye=0x%08x,rev=0x%x)\n",
>   __func__, idcode, hawkeye, rev);
>   omap_revision = DRA752_REV_ES1_1;
>   }

Thanks applying into omap-for-v3.17/fixes.

Tony
--
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] ARM: dts: DRA7: fix interrupt-cells for GPIO

[Tony Lindgren]

* Nishanth Menon  [140818 11:49]:
> On 07/30/2014 02:20 PM, Nishanth Menon wrote:
> > GPIO modules are also interrupt sources. However, they require both the
> > GPIO number and IRQ type to function properly.
> > 
> > By declaring that GPIO uses interrupt-cells=<1>, we essentially do not
> > allow users of the nodes to use the interrupt property appropritely.
> > 
> > With this change, the following now works:
> > 
> > interrupt-parent = <>;
> > interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
> > 
> > Fixes: 6e58b8f1daaf ('ARM: dts: DRA7: Add the dts files for dra7 SoC and 
> > dra7-evm board')
> > Signed-off-by: Nishanth Menon 
> > ---
> > Based on v3.16-rc7
> > 
> >  arch/arm/boot/dts/dra7.dtsi |   16 
> >  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> Tony,
> Gentle ping. we still have this issue on 3.17-rc1. any suggestions on
> if we can pick this up during RC?

Yes thanks applying into omap-for-v3.17/fixes.

Tony
--
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] checkpatch: look for common misspellings

[Elliott, Robert (Server Storage)]

> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Joe Perches
...
> +chang||change

Although there are at least 2 misuses in the current kernel,
that's also a fairly common name.

--
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] tpm_tis: Verify ACPI-specified interrupt

[Peter Hüwe]

CC: Luigi, he works at Google and is responsible for the TPMs in 
Chromebooks ;)

Thanks,
Peter

Am Freitag, 22. August 2014, 22:32:41 schrieb Jason Gunthorpe:
> On Fri, Aug 22, 2014 at 08:17:27PM +, Scot Doyle wrote:
> > On Fri, 22 Aug 2014, Jason Gunthorpe wrote:
> > > On Fri, Aug 22, 2014 at 12:58:41AM +, Scot Doyle wrote:
> > >> Some machines, such as the Acer C720 and Toshiba CB35, have 
TPMs
> > >> that do not use interrupts while also having an ACPI TPM 
entry
> > > 
> > > How do these machines work in Windows?
> > 
> > I don't know. Since they're Chromebooks (booted in legacy mode 
running
> > SeaBIOS instead of depthcharge or whatever ChromeOS uses), I 
think
> > they're mostly used to run Linux.
> 
> I remain somewhat confused - there have already been TPM patches 
for
> Chromebooks from Google - presumably the TPM actually does work
> fine. Make sure you are using a Linux with the ATMEL timeout fix, 
that
> is particularly applicable to Chromebooks IIRC.
> 
> And again, the driver uses interrupts when booting, so I'm 
somewhat
> confused what the problem is. I wouldn't think the driver would
> successfully attach if interrupts were enabled but the interrupt
> didn't work? Can you elaborate on what is going on during boot 
with
> the interrupt, and the boot time GET_DURATIONS and TPM_STARTUP
> sequences?
> 
> Perhaps the driver is timing out all commands and going ahead and
> attaching anyhow? If this is the case I think we'd get a good 
result
> if we just fixed that and had the driver simply not attach. Then 
your
> resume will not be broken.
> 
> > > I'd be more comfortable with some kind of ACPI black list or 
patch or
> > > something? What is normal for handling broken ACPI?
> > 
> > I would be more comfortable with this general approach as well. 
However,
> > I've had to submit several patches for individual Chromebooks 
related to
> > backlight control since the VBT also is misconfigured. Would it 
be
> > possible to find a blacklist mechanism that didn't require 
identifying
> > each Chromebook separately, since they seem to have this issue 
on an
> > ongoing basis?
> 
> So, if you are booting the Chromebook in some weird way, is this 
a
> problem that can be addressed by patching SeaBIOS instead of the
> kernel? The internet says the SeaBIOS payload is replaceable on 
the
> Chromebook.
> 
> Can it fix the ACPI tables to be correct before lauching Linux?
> 
> > A more general approach might be to verify the ACPI interrupt 
for
> > systems matching the first three identifiers.
> 
> Testing the interrupt and failing driver attach if it doesn't 
work
> seems very reasonable to me, I would view that as a bug fix in 
the driver.
> 
> Jason

--
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] checkpatch: look for common misspellings

[Joe Perches]

On Thu, 2014-08-21 at 17:10 -0700, Joe Perches wrote:
> On Thu, 2014-08-21 at 18:01 -0500, Kees Cook wrote:
> > On Thu, Aug 21, 2014 at 12:18 PM, Joe Perches  wrote:
> > > On Thu, 2014-08-21 at 09:20 -0700, Kees Cook wrote:
> > >> Check for misspellings, based on Debian's lintian list. Several false
> > >> positives were removed, and several additional words added that were
> > >> common in the kernel:
> > > []
> > >> diff --git a/MAINTAINERS b/MAINTAINERS
> > > []
> > >> @@ -2311,6 +2311,7 @@ M:  Andy Whitcroft 
> > >>  M:   Joe Perches 
> > >>  S:   Maintained
> > >>  F:   scripts/checkpatch.pl
> > >> +F:   scripts/spelling.txt
> > >
> > > I don't want to be responsible for misspellings.
> > >
> > > Maybe this should From 62adeee9bcc2015257834a0cbc88290a44fcf315 Mon Sep 
> > > 17 00:00:00 2001

From: Joe Perches 
Date: Fri, 22 Aug 2014 14:57:39 -0700
Subject: [PATCH] scripts/spelling.txt: Add some of Masanari Iida's spelling 
corrections

Masanari has done several spelling/typo fixes.

I wrote a little script to sift his last 100 spelling patches
from the git logs and added his corrections to this file with
a little typing afterwards to clean up some false positives.

Signed-off-by: Joe Perches 
---
 scripts/spelling.txt | 458 ++-
 1 file changed, 455 insertions(+), 3 deletions(-)

diff --git a/scripts/spelling.txt b/scripts/spelling.txt
index 03c6234..cd5bacc 100644
--- a/scripts/spelling.txt
+++ b/scripts/spelling.txt
@@ -11,9 +11,11 @@ abandonning||abandoning
 abigious||ambiguous
 abitrate||arbitrate
 abov||above
+abreviated||abbreviated
 absense||absence
 absolut||absolute
 absoulte||absolute
+acccess||access
 acceleratoin||acceleration
 accelleration||acceleration
 accesing||accessing
@@ -22,28 +24,42 @@ accessable||accessible
 accesss||access
 accidentaly||accidentally
 accidentually||accidentally
+accoding||according
 accomodate||accommodate
 accomodates||accommodates
+accordign||according
+accoring||according
 accout||account
+accquire||acquire
+accquired||acquired
 acessable||accessible
 acess||access
+achitecture||architecture
 acient||ancient
+acitions||actions
+acitve||active
 acknowldegement||acknowldegement
+acknowledgement||acknowledgment
 ackowledge||acknowledge
 ackowledged||acknowledged
 acording||according
 activete||activate
 acumulating||accumulating
+adapater||adapter
 addional||additional
 additionaly||additionally
+addres||address
 addreses||addresses
+addresss||address
 aditional||additional
 aditionally||additionally
 aditionaly||additionally
+adminstrative||administrative
 adress||address
 adresses||addresses
 adviced||advised
 afecting||affecting
+agaist||against
 albumns||albums
 alegorical||allegorical
 algorith||algorithm
@@ -52,12 +68,18 @@ algoritm||algorithm
 algoritms||algorithms
 algorrithm||algorithm
 algorritm||algorithm
+allign||align
+allocatrd||allocated
+allocte||allocate
 allpication||application
+alocate||allocate
 alogirhtms||algorithms
+alogrithm||algorithm
 alot||a lot
 alow||allow
 alows||allows
 altough||although
+alue||value
 ambigious||ambiguous
 amoung||among
 amout||amount
@@ -67,12 +89,18 @@ anniversery||anniversary
 annoucement||announcement
 anomolies||anomalies
 anomoly||anomaly
+anway||anyway
 aplication||application
 appearence||appearance
+applicaion||application
 appliction||application
 applictions||applications
+appplications||applications
 appropiate||appropriate
 appropriatly||appropriately
+approriate||appropriate
+approriately||appropriately
+aquainted||acquainted
 aquired||acquired
 arbitary||arbitrary
 architechture||architecture
@@ -83,13 +111,22 @@ arne't||aren't
 arraival||arrival
 artifical||artificial
 artillary||artillery
+assiged||assigned
 assigment||assignment
 assigments||assignments
 assistent||assistant
+assocation||association
+associcated||associated
+assotiated||associated
+assum||assume
+assumtpion||assumption
 asuming||assuming
 asycronous||asynchronous
+asynchnous||asynchronous
 atomatically||automatically
+atomicly||atomically
 attachement||attachment
+attched||attached
 attemps||attempts
 attruibutes||attributes
 authentification||authentication
@@ -101,55 +138,96 @@ automatizes||automates
 autonymous||autonomous
 auxilliary||auxiliary
 avaiable||available
+avaible||available
+availabe||available
 availabled||available
 availablity||availability
 availale||available
 availavility||availability
 availble||available
-availble||available
 availiable||available
+avalable||available
 avaliable||available
-avaliable||available
+aysnc||async
 backgroud||background
 backword||backward
 backwords||backwards
 bahavior||behavior
+bakup||backup
 baloon||balloon
 baloons||balloons
 bandwith||bandwidth
 batery||battery
+beacuse||because
+becasue||because
 becomming||becoming
 becuase||because
+beeing||being
+befor||before
 begining||beginning
+beter||better
+betweeen||between
 bianries||binaries
+bitmast||bitmask
+boardcast||broadcast
+borad||board
+boundry||boundary

Re: [PATCH 1/1] GCD: add binary GCD algorithm

[George Spelvin]

> Otherwise I don't think we can justify the additional maintenance
> cost/risk, sorry.

This is am extremely self-contained and easy to test piece of code.
Look at the history; the total edits to the function since the
beginning of git in 2005 are:
- A theoretical bug fix to handle zero arguments better
- A global header file cleanup that hit lib/gcd.c
- Relocation to lib/ from sound/core/pcm_timer.c

And... nothing else.

This is the sort of leaf function that, once it works, gets left alone
forever.

Your point about "it's not a bottleneck, so why optimize it?" is valid,
but the maintenance issue is something of a red herring.

The maintenance hassle I *do* worry about the Kconfig magic to decide
whether to enable it.  But that's something I'd defer to the ARM
maintainers on.

> And if we *do* decide to proceed with this patch, we should include a
> patch which enables it on as many architectures as possible, so it gets
> runtime tested.

It's pretty harmless even on machines which *do* have fast division,
so we could just enable it everywhere.

GMP, whose benchmarking I'm inclined to trust, uses binary GCD for all
small (3-word or less) values.

https://gmplib.org/manual/Binary-GCD.html

The expected nymber of iterations to perform the Euclidean algorithm
for two random numbers 1 <= x,y <= n is 1.216 log2(n) + 0.06.
Binary GCD is quite similar.  Its main advantage is the large gain
in the first step when the inputs are of very different size.

Binary GCD's perfoemance problems come from unpredictable branches.
Euclid's algorithm has less of those.
--
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: linux-next: build failure after merge of the pwm tree

[Stephen Rothwell]

Hi Thierry,

On Sat, 23 Aug 2014 00:15:54 +0200 Thierry Reding  
wrote:
>
> On Sat, Aug 23, 2014 at 12:06:16AM +0200, Thierry Reding wrote:
> > 
> > Ugh, that's unfortunate. I have a set of scripts I use to build-test
> > before pushing, but I don't usually do full allyesconfig builds. It
> > seems like pwm-lpss.c might only be missing a linux/io.h include. It
> > will likely be Monday before I find the time to properly test and fix
> > this, do you want me to remove the commits from the pwm/for-next branch
> > so you don't have to revert it again?
> 
> Just confirmed that adding a linux/io.h include fixes the build. Will
> push a fix in a minute.

The revert would have happened automatically, but if it is fixed I will
remove it, thanks.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


signature.asc
Description: PGP signature

Re: [PATCH v2] memory-hotplug: add sysfs zones_online_to attribute

[Dave Hansen]

On 08/22/2014 03:16 PM, Andrew Morton wrote:
> Also, it's not really clear to me why we need this sysfs file at all. 
> Do people really read sysfs files, make onlining decisions and manually
> type in commands?  Or is this stuff all automated?  If the latter then
> the script can take care of all this?  For example, attempt to online
> the memory into the desired zone and report failure if that didn't
> succeed?

I guess we can just iterate over all possible zone types from userspace
until we find one.  Seems a bit hokey, but it would work at least until
we add a new zone type and we have to teach the scripts about the new
type.  But that's a pretty rare event I guess.  Let's hope the script
writers get this right, and don't make omissions like ZONE_MOVABLE
because it's not that common in practice.
--
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: [V0 PATCH 0/2] AMD PVH domU support

[Mukesh Rathor]

On Fri, 22 Aug 2014 14:52:41 +0100
David Vrabel  wrote:

> On 21/08/14 03:16, Mukesh Rathor wrote:
> > Hi,
> > 
> > Here's first stab at AMD PVH domU support. Pretty much the only
> > thing needed is EFER bits set. Please review.
> 
> I'm not going to accept this until there is some ABI documentation
> stating explicitly what state non-boot CPUs will be in.
> 
> I'm particularly concerned that: a) there is a difference between AMD
> and Intel; and b) you want to change the ABI by clearing a the
> EFER.SCE bit.

Correct, I realize it changes the ABI, but I believe that is the right 
thing to do while we can, specially, since we need to fix the EFER for
NX anyways. Looking at the code, it appears this would be the final
cleanup for this ABI... :)..

However, if that's not possible, I suppose we can just leave it as is
too for the SC bit.

thanks
Mukesh
--
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: linux-next: build failure after merge of the pwm tree

[Thierry Reding]

On Sat, Aug 23, 2014 at 12:06:16AM +0200, Thierry Reding wrote:
> On Sat, Aug 23, 2014 at 07:07:37AM +1000, Stephen Rothwell wrote:
> > Hi Thierry,
> > 
> > After merging the pwm tree, today's linux-next build (powerpc allyesconfig)
> > failed like this:
> > 
> > drivers/pwm/pwm-lpss.c: In function 'pwm_lpss_config':
> > drivers/pwm/pwm-lpss.c:81:2: error: implicit declaration of function 
> > 'readl' [-Werror=implicit-function-declaration]
> >   ctrl = readl(lpwm->regs + PWM);
> >   ^
> > drivers/pwm/pwm-lpss.c:87:2: error: implicit declaration of function 
> > 'writel' [-Werror=implicit-function-declaration]
> >   writel(ctrl, lpwm->regs + PWM);
> >   ^
> > 
> > Caused by commit 28160b18787b ("pwm: lpss: Properly split driver to
> > parts").
> > 
> > I have reverted that commit for today (and 06c7b5394e21 ("pwm: lpss:
> > pci: Move to use pcim_enable_device()") which depends on it).
> 
> Ugh, that's unfortunate. I have a set of scripts I use to build-test
> before pushing, but I don't usually do full allyesconfig builds. It
> seems like pwm-lpss.c might only be missing a linux/io.h include. It
> will likely be Monday before I find the time to properly test and fix
> this, do you want me to remove the commits from the pwm/for-next branch
> so you don't have to revert it again?

Just confirmed that adding a linux/io.h include fixes the build. Will
push a fix in a minute.

Thierry


pgpvVVgmmLDWy.pgp
Description: PGP signature

Re: [PATCH v9 1/2] regulator: Add driver for max77802 PMIC PMIC regulators

[Doug Anderson]

Hi,

On Fri, Aug 22, 2014 at 3:02 PM, Javier Martinez Canillas
 wrote:
> Hello Mark,
>
> On 08/22/2014 08:30 PM, Mark Brown wrote:
>>
>>> The problem is that one of these regulators is used as the vqmmc-supply
>>> (VCCQ/VDD_IO) so the mmc host controller driver disables it on
>>> MMC_POWER_OFF. Now AFAIK (Yuvaraj can correct me what I got wrong) this
>>> shouldn't be an issue since on card detection, the vqmmc supply should be
>>> enabled again but on Exynos the built-in card detect line is on the same
>>> power rail as vqmmc. That means that disabling the regulator prevents card
>>> insertions to be detected.
>>
>> If the MMC host controller needs a supply enabling in order to do card
>> detection and it's supposed to be doing card detection I'd expect it to
>> be enabling that supply.  Why is it not doing that?
>>
>
> Good question. I'm not that familiar with the dw_mmc host controller nor
> its driver implementation so I'll let Yuvaraj or Doug to answer that.

I haven't seen the issue that Yuvaraj is reporting (but I also haven't
picked up all of the relevant patches and tried to reproduce), so I'm
going to have to leave it to Yuvaraj to answer.

As far as I know the dw_mmc driver ought to be enabling vqmmc when it
needs it.  Perhaps there's a bug in your patch series that adds vqmmc
support to dw_mmc?

-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 v2] memory-hotplug: add sysfs zones_online_to attribute

[Andrew Morton]

On Mon, 18 Aug 2014 11:25:36 +0800 Zhang Zhen  
wrote:

> On 2014/8/16 5:37, Toshi Kani wrote:
> > On Wed, 2014-08-13 at 12:10 +0800, Zhang Zhen wrote:
> >> 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.
> >>
> >> With this patch, we can easy to know a memory block can be onlined to
> >> which zone, and don't need to know the above two limits.
> >>
> >> Updated the related Documentation.
> >>
> >> Change v1 -> v2:
> >> - optimize the implementation following Dave Hansen's suggestion
> >>
> >> Signed-off-by: Zhang Zhen 
> >> ---
> >>  Documentation/ABI/testing/sysfs-devices-memory |  8 
> >>  Documentation/memory-hotplug.txt   |  4 +-
> >>  drivers/base/memory.c  | 62 
> >> ++
> >>  include/linux/memory_hotplug.h |  1 +
> >>  mm/memory_hotplug.c|  2 +-
> >>  5 files changed, 75 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/Documentation/ABI/testing/sysfs-devices-memory 
> >> b/Documentation/ABI/testing/sysfs-devices-memory
> >> index 7405de2..2b2a1d7 100644
> >> --- a/Documentation/ABI/testing/sysfs-devices-memory
> >> +++ b/Documentation/ABI/testing/sysfs-devices-memory
> >> @@ -61,6 +61,14 @@ Users:  hotplug memory remove tools
> >>
> >> http://www.ibm.com/developerworks/wikis/display/LinuxP/powerpc-utils
> >>
> >>
> >> +What:   /sys/devices/system/memory/memoryX/zones_online_to
> > 
> > I think this name is a bit confusing.  How about "valid_online_types"?
> > 
> Thanks for your suggestion.
> 
> This patch has been added to -mm tree.
> If most people think so, i would like to modify the interface name.
> If not, let's leave it as it is.

Yes, the name could be better.  Do we actually need "online" in there? 
How about "valid_zones"?

Also, it's not really clear to me why we need this sysfs file at all. 
Do people really read sysfs files, make onlining decisions and manually
type in commands?  Or is this stuff all automated?  If the latter then
the script can take care of all this?  For example, attempt to online
the memory into the desired zone and report failure if that didn't
succeed?

IOW, please update the changelog to show

a) example output from
   /sys/devices/system/memory/memoryX/whatever-we-call-it and

b) example use-cases which help reviewers understand why this
   feature will be valuable to users.

Also, please do address the error which Yasuaki Ishimatsu identified.

--
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 0/7] MIPS: Move device-tree files to a common location

[Andrew Bresticker]

On Fri, Aug 22, 2014 at 1:57 PM, David Daney  wrote:
> On 08/22/2014 01:42 PM, Florian Fainelli wrote:
>>
>> On Aug 21, 2014 3:05 PM, "Andrew Bresticker" > > wrote:
>>  >
>>  > To be consistent with other architectures and to avoid unnecessary
>>  > makefile duplication, move all MIPS device-trees to arch/mips/boot/dts
>>  > and build them with a common makefile.
>>
>> I recall reading that the ARM organization for DTS files was a bit
>> unfortunate and should have been something like:
>>
>> arch/arm/boot/dts//
>>
>> Is this something we should do for the MIPS and update the other
>> architectures to follow that scheme?
>
>
> If we choose not to intermingle .dts files from all the vendors in a single
> directory, why do anything at all?  Currently the .dts files for a vendor
> are nicely segregated with the rest of the vendors code under a single
> directory.
>
> Personally I think things are fine as they are.  Any common code remaining
> in the Makefiles could be moved to the scripts directory for a smaller
> change.

Assuming we don't move them to a common location just to segregate
them again, it makes MIPS consistent with every other architecture
(not just ARM!) using DT.  It also makes it easier to introduce common
changes later on, like the 'dtbs' or 'dtbs_install' make targets.
--
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: linux-next: build failure after merge of the pwm tree

[Thierry Reding]

On Sat, Aug 23, 2014 at 07:07:37AM +1000, Stephen Rothwell wrote:
> Hi Thierry,
> 
> After merging the pwm tree, today's linux-next build (powerpc allyesconfig)
> failed like this:
> 
> drivers/pwm/pwm-lpss.c: In function 'pwm_lpss_config':
> drivers/pwm/pwm-lpss.c:81:2: error: implicit declaration of function 'readl' 
> [-Werror=implicit-function-declaration]
>   ctrl = readl(lpwm->regs + PWM);
>   ^
> drivers/pwm/pwm-lpss.c:87:2: error: implicit declaration of function 'writel' 
> [-Werror=implicit-function-declaration]
>   writel(ctrl, lpwm->regs + PWM);
>   ^
> 
> Caused by commit 28160b18787b ("pwm: lpss: Properly split driver to
> parts").
> 
> I have reverted that commit for today (and 06c7b5394e21 ("pwm: lpss:
> pci: Move to use pcim_enable_device()") which depends on it).

Ugh, that's unfortunate. I have a set of scripts I use to build-test
before pushing, but I don't usually do full allyesconfig builds. It
seems like pwm-lpss.c might only be missing a linux/io.h include. It
will likely be Monday before I find the time to properly test and fix
this, do you want me to remove the commits from the pwm/for-next branch
so you don't have to revert it again?

Thierry


pgp56tVTYxOzk.pgp
Description: PGP signature

Re: [PATCH v9 1/2] regulator: Add driver for max77802 PMIC PMIC regulators

[Javier Martinez Canillas]

Hello Mark,

On 08/22/2014 08:30 PM, Mark Brown wrote:
> 
>> The problem is that one of these regulators is used as the vqmmc-supply
>> (VCCQ/VDD_IO) so the mmc host controller driver disables it on
>> MMC_POWER_OFF. Now AFAIK (Yuvaraj can correct me what I got wrong) this
>> shouldn't be an issue since on card detection, the vqmmc supply should be
>> enabled again but on Exynos the built-in card detect line is on the same
>> power rail as vqmmc. That means that disabling the regulator prevents card
>> insertions to be detected.
> 
> If the MMC host controller needs a supply enabling in order to do card
> detection and it's supposed to be doing card detection I'd expect it to
> be enabling that supply.  Why is it not doing that?
> 

Good question. I'm not that familiar with the dw_mmc host controller nor
its driver implementation so I'll let Yuvaraj or Doug to answer that.

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/

linux-next: Tree for Aug 23

[Stephen Rothwell]

Hi all,

Changes since 20140822:

The mfd tree gained a build failure so I used the version from
next-20140822.

The usb-gadget tree gained a conflict against the usb-gadget-fixes tree.

The pwm tree gained a build failure for which I reverted a couple of
commits.

The staging tree still had its build failure for which I applied a
fix patch.

Non-merge commits (relative to Linus' tree): 1435
 1372 files changed, 34371 insertions(+), 25442 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.

Below is a summary of the state of the merge.

I am currently merging 220 trees (counting Linus' and 30 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (5317821c0853 Merge branch 'for-3.17-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata)
Merging fixes/master (23cf8d3ca0fd powerpc: Fix "attempt to move .org 
backwards" error)
Merging kbuild-current/rc-fixes (7d1311b93e58 Linux 3.17-rc1)
Merging arc-current/for-curr (89ca3b881987 Linux 3.15-rc4)
Merging arm-current/fixes (e57e41931134 ARM: wire up memfd_create syscall)
Merging m68k-current/for-linus (9117710a5997 m68k/sun3: Remove define statement 
no longer needed)
Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-merge/merge (396a34340cdf powerpc: Fix endianness of 
flash_block_list in rtas_flash)
Merging sparc/master (c9d26423e56c Merge tag 'pm+acpi-3.17-rc1-2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm)
Merging net/master (08f1a1b9d1a9 cxgb4: Free completed tx skbs promptly)
Merging ipsec/master (21009686662f net: phy: smsc: move smsc_phy_config_init 
reset part in a soft_reset function)
Merging sound-current/for-linus (ee3043b2d7b1 ALSA: ctxfi: ct20k1reg: Fix typo 
in include guard)
Merging pci-current/for-linus (8d7004a6904c PCI: spear: Remove module option)
Merging wireless/master (c9d26423e56c Merge tag 'pm+acpi-3.17-rc1-2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm)
Merging driver-core.current/driver-core-linus (7d1311b93e58 Linux 3.17-rc1)
Merging tty.current/tty-linus (7d1311b93e58 Linux 3.17-rc1)
Merging usb.current/usb-linus (6835a3a02b1a usb: wusbcore: fix below build 
warning)
Merging usb-gadget-fixes/fixes (5d19703822da usb: gadget: remove $(PWD) in 
ccflags-y)
Merging usb-serial-fixes/usb-linus (646907f5bfb0 USB: ftdi_sio: Added PID for 
new ekey device)
Merging staging.current/staging-linus (eb29835fb3ae staging: android: fix a 
possible memory leak)
Merging char-misc.current/char-misc-linus (7d1311b93e58 Linux 3.17-rc1)
Merging input-current/for-linus (fb92be7ba8ca Input: sparc - i8042-sparcio.h: 
fix unused kbd_res warning)
Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" 
stripe)
Merging crypto-current/master (ce5481d01f67 crypto: drbg - fix failure of 
generating multiple of 2**16 bytes)
Merging ide/master (a53dae49b2fe ide: use module_platform_driver())
Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff)
Merging devicetree-current/devicetree/merge (5a12a597a862 arm: Add devicetree 
fixup machine function)
Merging rr-fixes/fixes (ff7e0055bb5d module: Clean up ro/nx after early module 
load failures)
Merging vfio-fixes/for-linus (239a87020b26 Merge branch 
'for-joerg/arm-smmu/fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/will/linux into for-linus)
Merging drm-intel-fixes/for-linux-next-fixes (1a125d8a2c22 drm/i915: don't try 
to retrai

Re: [PATCH 1/2] leds: usb: Add LED trigger for USB gadget activity

[Felipe Balbi]

Hi,

On Fri, Aug 22, 2014 at 01:53:12PM +0200, Michal Sojka wrote:
> With this patch, USB gadget activity can be signaled by blinking a LED.
> 
> Since there is no generic code where to put the trigger for all USB
> controllers, each USB controller needs to call the trigger individually.
> This patch adds the call only for the musb controller where I can test
> it.
> 
> Signed-off-by: Michal Sojka 
> ---
>  drivers/leds/trigger/Kconfig |  8 ++
>  drivers/leds/trigger/Makefile|  1 +
>  drivers/leds/trigger/ledtrig-usbgadget.c | 45 
> 
>  drivers/usb/musb/musb_gadget.c   |  6 +++--
>  include/linux/leds.h |  6 +
>  5 files changed, 64 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/leds/trigger/ledtrig-usbgadget.c
> 
> diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig
> index 49794b4..9562963 100644
> --- a/drivers/leds/trigger/Kconfig
> +++ b/drivers/leds/trigger/Kconfig
> @@ -41,6 +41,14 @@ config LEDS_TRIGGER_IDE_DISK
> This allows LEDs to be controlled by IDE disk activity.
> If unsure, say Y.
>  
> +config LEDS_TRIGGER_USBGADGET
> + bool "LED USB Gadget Trigger"
> + depends on (USB_MUSB_GADGET || USB_MUSB_DUAL_ROLE)
> + depends on LEDS_TRIGGERS
> + help
> +   This allows LEDs to be controlled by USB gadget activity.
> +   If unsure, say Y.
> +
>  config LEDS_TRIGGER_HEARTBEAT
>   tristate "LED Heartbeat Trigger"
>   depends on LEDS_TRIGGERS
> diff --git a/drivers/leds/trigger/Makefile b/drivers/leds/trigger/Makefile
> index 1abf48d..45917c0 100644
> --- a/drivers/leds/trigger/Makefile
> +++ b/drivers/leds/trigger/Makefile
> @@ -8,3 +8,4 @@ obj-$(CONFIG_LEDS_TRIGGER_CPU)+= ledtrig-cpu.o
>  obj-$(CONFIG_LEDS_TRIGGER_DEFAULT_ON)+= ledtrig-default-on.o
>  obj-$(CONFIG_LEDS_TRIGGER_TRANSIENT) += ledtrig-transient.o
>  obj-$(CONFIG_LEDS_TRIGGER_CAMERA)+= ledtrig-camera.o
> +obj-$(CONFIG_LEDS_TRIGGER_USBGADGET) += ledtrig-usbgadget.o
> diff --git a/drivers/leds/trigger/ledtrig-usbgadget.c 
> b/drivers/leds/trigger/ledtrig-usbgadget.c
> new file mode 100644
> index 000..1eb90da
> --- /dev/null
> +++ b/drivers/leds/trigger/ledtrig-usbgadget.c
> @@ -0,0 +1,45 @@
> +/*
> + * LED Trigger for USB Gadget Activity
> + *
> + * Copyright 2014 Michal Sojka 
> + *
> + * 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 
> +#include 
> +#include 
> +#include 
> +
> +#define BLINK_DELAY 30
> +
> +DEFINE_LED_TRIGGER(ledtrig_usbgadget);
> +static unsigned long usbgadget_blink_delay = BLINK_DELAY;
> +
> +void ledtrig_usbgadget_activity(void)
> +{
> + led_trigger_blink_oneshot(ledtrig_usbgadget,
> +   _blink_delay, 
> _blink_delay, 0);
> +}
> +EXPORT_SYMBOL(ledtrig_usbgadget_activity);
> +
> +static int __init ledtrig_usbgadget_init(void)
> +{
> + led_trigger_register_simple("usb-gadget", _usbgadget);
> + return 0;
> +}
> +
> +static void __exit ledtrig_usbgadget_exit(void)
> +{
> + led_trigger_unregister_simple(ledtrig_usbgadget);
> +}
> +
> +module_init(ledtrig_usbgadget_init);
> +module_exit(ledtrig_usbgadget_exit);
> +
> +MODULE_AUTHOR("Michal Sojka ");
> +MODULE_DESCRIPTION("LED Trigger for USB Gadget Activity");
> +MODULE_LICENSE("GPL");
> diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
> index d4aa779..98f8b24 100644
> --- a/drivers/usb/musb/musb_gadget.c
> +++ b/drivers/usb/musb/musb_gadget.c
> @@ -42,6 +42,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "musb_core.h"
>  
> @@ -167,11 +168,12 @@ __acquires(ep->musb->lock)
>   if (!dma_mapping_error(>g.dev, request->dma))
>   unmap_dma_buffer(req, musb);
>  
> - if (request->status == 0)
> + if (request->status == 0) {
>   dev_dbg(musb->controller, "%s done request %p,  %d/%d\n",
>   ep->end_point.name, request,
>   req->request.actual, req->request.length);
> - else
> + ledtrig_usbgadget_activity();

looks like this should, somehow, be done at udc-core.c although you'd
need some refactoring to make that happen. It shouldn't be too difficult
to have a generic usb_gadget_giveback_request()

cheers

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH tip/core/rcu 1/2] rcu: Parallelize and economize NOCB kthread wakeups

[Paul E. McKenney]

On Fri, Aug 22, 2014 at 02:53:44PM -0700, Paul E. McKenney wrote:
> On Fri, Aug 22, 2014 at 10:44:05PM +0530, Amit Shah wrote:
> > On (Fri) 22 Aug 2014 [07:48:19], Paul E. McKenney wrote:
> > > On Fri, Aug 22, 2014 at 06:26:49PM +0530, Amit Shah wrote:
> > > > On (Fri) 22 Aug 2014 [18:06:51], Amit Shah wrote:
> > > > > On (Fri) 22 Aug 2014 [17:54:53], Amit Shah wrote:
> > > > > > On (Mon) 18 Aug 2014 [21:01:49], Paul E. McKenney wrote:
> > > > > > 
> > > > > > > The odds are low over the next few days.  I am adding nastier 
> > > > > > > rcutorture
> > > > > > > testing, however.  It would still be very good to get debug 
> > > > > > > information
> > > > > > > from your setup.  One approach would be to convert the trace 
> > > > > > > function
> > > > > > > calls into printk(), if that would help.
> > > > > > 
> > > > > > I added a few printks on the lines of the traces in cases where
> > > > > > rcu_nocb_poll was checked -- since that reproduces the hang.  Are 
> > > > > > the
> > > > > > following traces sufficient, or should I keep adding more printks?
> > > > > > 
> > > > > > In the case of rcu-trace-nopoll.txt, the messages stop after a while
> > > > > > (when the guest locks up hard).  That's when I kill the qemu 
> > > > > > process.
> > > > > 
> > > > > And this is bt from gdb when the endless 
> > > > > 
> > > > >   RCUDEBUG __call_rcu_nocb_enqueue 2146 rcu_preempt 0 WakeNot
> > > > > 
> > > > > messages are being spewed.
> > > > > 
> > > > > I can't time it, but hope it gives some indication along with the 
> > > > > printks.
> > > > 
> > > > ... and after the system 'locks up', this is the state it's in:
> > > > 
> > > > ^C
> > > > Program received signal SIGINT, Interrupt.
> > > > native_safe_halt () at ./arch/x86/include/asm/irqflags.h:50
> > > > 50   }
> > > > (gdb) bt
> > > > #0  native_safe_halt () at ./arch/x86/include/asm/irqflags.h:50
> > > > #1  0x8100b9c1 in arch_safe_halt () at 
> > > > ./arch/x86/include/asm/paravirt.h:111
> > > > #2  default_idle () at arch/x86/kernel/process.c:311
> > > > #3  0x8100c107 in arch_cpu_idle () at 
> > > > arch/x86/kernel/process.c:302
> > > > #4  0x8106a25a in cpuidle_idle_call () at 
> > > > kernel/sched/idle.c:120
> > > > #5  cpu_idle_loop () at kernel/sched/idle.c:220
> > > > #6  cpu_startup_entry (state=) at kernel/sched/idle.c:268
> > > > #7  0x813e068b in rest_init () at init/main.c:418
> > > > #8  0x81a8cf5a in start_kernel () at init/main.c:680
> > > > #9  0x81a8c4ba in x86_64_start_reservations 
> > > > (real_mode_data=) at arch/x86/kernel/head64.c:193
> > > > #10 0x81a8c607 in x86_64_start_kernel (real_mode_data=0x13f90 
> > > >  )
> > > > at arch/x86/kernel/head64.c:182
> > > > #11 0x in ?? ()
> > > > 
> > > > 
> > > > Wondering why it's doing this.  Am stepping through
> > > > cpu_startup_entry() to see if I get any clues.
> > > 
> > > This looks to me like normal behavior in the x86 ACPI idle loop.
> > > My guess is that the lockup is caused by indefinite blocking, in
> > > which case we would expect all the CPUs to be in the idle loop.
> > 
> > Hm, found it:
> > 
> > The stall happens in do_initcalls().
> > 
> > pm_sysrq_init() is the function that causes the hang.  When I #if 0
> > the line
> > 
> > register_sysrq_key('o', _poweroff_op);
> > 
> > in pm_sysrq_init(), the boot proceeds normally.
> 
> Yow!!!
> 
> > Now what this is, and what relation this has to rcu and that patch in
> > particular is next...
> 
> Hmmm...  Please try replacing the synchronize_rcu() in
> __sysrq_swap_key_ops() with (say) schedule_timeout_interruptible(HZ / 10).
> I bet that gets rid of the hang.  (And also introduces a low-probability
> bug, but should be OK for testing.)
> 
> The other thing to try is to revert your patch that turned my event
> traces into printk()s, then put an ftrace_dump(DUMP_ALL); just after
> the synchronize_rcu() -- that might make it so that the ftrace data
> actually gets dumped out.

And one other thing to try...

Put a printk at the beginning of rcu_spawn_gp_kthread(), which is in
kernel/rcu/tree.c.  If that printk does not appear before the call
to pm_sysrq_init(), that would be an important clue.

Thanx, Paul

--
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] carl9170: Remove redundant protection check

[Christian Lamparter]

On Friday, August 22, 2014 02:08:52 PM Eric Dumazet wrote:
> On Fri, 2014-08-22 at 22:38 +0200, Christian Lamparter wrote:
> [...]
> > From: Andreea-Cristina Bernat 
> > 
> > The carl9170_op_ampdu_action() function is used only by the mac80211
> > framework. Since the mac80211 already takes care of checks and 
> > properly serializing calls to the driver's function there is no
> > need for the driver to do the same thing.
> >  
> > ---
> > @@ -1430,18 +1430,10 @@ static int carl9170_op_ampdu_action(struct 
> > ieee80211_hw *hw,
> > if (!sta_info->ht_sta)
> > return -EOPNOTSUPP;
> >  
> > -   rcu_read_lock();
> > -   if (rcu_dereference(sta_info->agg[tid])) {
> > -   rcu_read_unlock();
> > -   return -EBUSY;
> > -   }
> > -
> > [...]
> > ---
> 
> Sorry but this patch is not complete.
> 
> You need to somehow return -EBUSY if sta_info->agg[tid] is set.
The sta_info->agg[tid] check is not needed (for reference, see [0]).
(There is already a check in mac80211 which prevents the leak of
sta_info->agg[tid] [1]).

Regards
Christian

[0] 
[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 tip/core/rcu 1/2] rcu: Parallelize and economize NOCB kthread wakeups

[Paul E. McKenney]

On Fri, Aug 22, 2014 at 10:44:05PM +0530, Amit Shah wrote:
> On (Fri) 22 Aug 2014 [07:48:19], Paul E. McKenney wrote:
> > On Fri, Aug 22, 2014 at 06:26:49PM +0530, Amit Shah wrote:
> > > On (Fri) 22 Aug 2014 [18:06:51], Amit Shah wrote:
> > > > On (Fri) 22 Aug 2014 [17:54:53], Amit Shah wrote:
> > > > > On (Mon) 18 Aug 2014 [21:01:49], Paul E. McKenney wrote:
> > > > > 
> > > > > > The odds are low over the next few days.  I am adding nastier 
> > > > > > rcutorture
> > > > > > testing, however.  It would still be very good to get debug 
> > > > > > information
> > > > > > from your setup.  One approach would be to convert the trace 
> > > > > > function
> > > > > > calls into printk(), if that would help.
> > > > > 
> > > > > I added a few printks on the lines of the traces in cases where
> > > > > rcu_nocb_poll was checked -- since that reproduces the hang.  Are the
> > > > > following traces sufficient, or should I keep adding more printks?
> > > > > 
> > > > > In the case of rcu-trace-nopoll.txt, the messages stop after a while
> > > > > (when the guest locks up hard).  That's when I kill the qemu process.
> > > > 
> > > > And this is bt from gdb when the endless 
> > > > 
> > > >   RCUDEBUG __call_rcu_nocb_enqueue 2146 rcu_preempt 0 WakeNot
> > > > 
> > > > messages are being spewed.
> > > > 
> > > > I can't time it, but hope it gives some indication along with the 
> > > > printks.
> > > 
> > > ... and after the system 'locks up', this is the state it's in:
> > > 
> > > ^C
> > > Program received signal SIGINT, Interrupt.
> > > native_safe_halt () at ./arch/x86/include/asm/irqflags.h:50
> > > 50 }
> > > (gdb) bt
> > > #0  native_safe_halt () at ./arch/x86/include/asm/irqflags.h:50
> > > #1  0x8100b9c1 in arch_safe_halt () at 
> > > ./arch/x86/include/asm/paravirt.h:111
> > > #2  default_idle () at arch/x86/kernel/process.c:311
> > > #3  0x8100c107 in arch_cpu_idle () at 
> > > arch/x86/kernel/process.c:302
> > > #4  0x8106a25a in cpuidle_idle_call () at kernel/sched/idle.c:120
> > > #5  cpu_idle_loop () at kernel/sched/idle.c:220
> > > #6  cpu_startup_entry (state=) at kernel/sched/idle.c:268
> > > #7  0x813e068b in rest_init () at init/main.c:418
> > > #8  0x81a8cf5a in start_kernel () at init/main.c:680
> > > #9  0x81a8c4ba in x86_64_start_reservations 
> > > (real_mode_data=) at arch/x86/kernel/head64.c:193
> > > #10 0x81a8c607 in x86_64_start_kernel (real_mode_data=0x13f90 
> > >  )
> > > at arch/x86/kernel/head64.c:182
> > > #11 0x in ?? ()
> > > 
> > > 
> > > Wondering why it's doing this.  Am stepping through
> > > cpu_startup_entry() to see if I get any clues.
> > 
> > This looks to me like normal behavior in the x86 ACPI idle loop.
> > My guess is that the lockup is caused by indefinite blocking, in
> > which case we would expect all the CPUs to be in the idle loop.
> 
> Hm, found it:
> 
> The stall happens in do_initcalls().
> 
> pm_sysrq_init() is the function that causes the hang.  When I #if 0
> the line
> 
> register_sysrq_key('o', _poweroff_op);
> 
> in pm_sysrq_init(), the boot proceeds normally.

Yow!!!

> Now what this is, and what relation this has to rcu and that patch in
> particular is next...

Hmmm...  Please try replacing the synchronize_rcu() in
__sysrq_swap_key_ops() with (say) schedule_timeout_interruptible(HZ / 10).
I bet that gets rid of the hang.  (And also introduces a low-probability
bug, but should be OK for testing.)

The other thing to try is to revert your patch that turned my event
traces into printk()s, then put an ftrace_dump(DUMP_ALL); just after
the synchronize_rcu() -- that might make it so that the ftrace data
actually gets dumped out.

Thanx, Paul

--
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: [GIT PULL] Networking

[Linus Torvalds]

On Fri, Aug 22, 2014 at 2:40 PM, David Miller  wrote:
>
> I think you can apply it directly and none of us will mind, and GIT
> will sort it all out during the next merge.

Ok, I'll apply it directly to my tree, since it affected my machine.
Now that I'm back home I probably won't see the channel switch
requests that caused the problem, but I just feel uncomfortable
running a known-broken kernel.

  Linus
--
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 2/2] pmbus: ltc2978: add regulator gating

[Mark Brown]

On Fri, Aug 22, 2014 at 04:11:34PM -0500, at...@opensource.altera.com wrote:
> From: Alan Tull 
> 
> Add regulator with support for enabling or disabling all
> supplies.

Reviwed-by: Mark Brown 

though it still looks like you should be able to create generic
functions for the operations.


signature.asc
Description: Digital signature

Re: [PATCH v2 1/2] pmbus: add regulator support

[Mark Brown]

On Fri, Aug 22, 2014 at 04:11:33PM -0500, at...@opensource.altera.com wrote:

> + if (pdata && pdata->reg_init_data) {
> + config.init_data = pdata->reg_init_data;
> + } else {
> + config.init_data = of_get_regulator_init_data(dev, np);
> + if (!config.init_data)
> + return -ENOMEM;
> + }

It should be fine to start with no init data - just let the regulator
core worry about it.  This will allow users to read back the state even
if they can't change anything which is useful for system bringup or
general debugging.


signature.asc
Description: Digital signature

Re: [PATCH 1/2] leds: usb: Add LED trigger for USB gadget activity

[Greg Kroah-Hartman]

On Fri, Aug 22, 2014 at 10:39:03AM -0700, Bryan Wu wrote:
> On Fri, Aug 22, 2014 at 4:53 AM, Michal Sojka  wrote:
> > With this patch, USB gadget activity can be signaled by blinking a LED.
> >
> > Since there is no generic code where to put the trigger for all USB
> > controllers, each USB controller needs to call the trigger individually.
> > This patch adds the call only for the musb controller where I can test
> > it.
> >
> 
> Generally I think one led trigger for both USB host and USB gadget
> activity is good enough. We don't need 2 same led trigger here.

What about systems that have both running at the same time?  Don't you
want individual control?

> And probably you can just put this code in drivers/usb subsystem,
> since this driver is quite simple to add to USB subsystem.

I have no objection to that, if the LED people don't mind it.

thanks,

greg k-h
--
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: Revert "aio: fix aio request leak when events are reaped by user space"

[Linus Torvalds]

On Fri, Aug 22, 2014 at 11:51 AM, Dan Aloni  wrote:
>
> Ben, seems that the test program needs some twidling to make the bug
> appear still by setting MAX_IOS to 256 (and it still passes on a
> kernel with the original patch reverted). Under this condition the
> ring buffer size remains 128 (here, 32*4 CPUs), and it is overrun on
> the second attempt.

Ugh.

Ben, at this point my gut feel is that we should just revert the
original "fix", and you should take a much deeper look at this all.
The original "fix" was more broken then the leak it purported to fix,
and now the patch to fix your fix has gone through two iterations and
*still* Dan is finding bugs in it.  I'm getting the feeling that this
code needs more thinking than you are actually putting into it.

Linus
--
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/

ARM: imx6q fec watchdog timeout with TX ring dump

[John Holland]

Hello everyone,


I've been playing around with a Utilite Pro recently. It features a 
Freescale imx6q with SoC FEC as eth0 and a second ether Intel I211 
interface on PCIE being mapped to eth1 amongst various other bits.


ATM, it's running debian jessie and kernel 3.16.1 with the recent three 
patch sets from Russell King at 
http://ftp.arm.linux.org.uk/cgit/linux-arm.git/log/?h=fec-testing; from 
the tag imx-drm-fixes-urgent to fec-testing, minus the "clear IPV6 
header CS".


During normal operation, I have had the occasional FEC Watchdog Timeout 
(FWT). However, when eth0 und eth1 are bonded to balance-rr mode and two 
independent iperfs cliented by different machines with each 4 threads 
run free on the Utilite, it inevitably comes to FWTs. Raising 
packets_per_slave to four seems to help somewhat.


The bond is routed through two aggregated (trunk) ports on a Netgear 
JGS524E running to the iperf clients.



Drop me a line, if you need more information.


TIA,

John


[1] Patch set A: 
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/270173.html
[2] Patch set B: 
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/270373.html
[3] Patch set C: 
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/270393.html
[4] Linux bonding documentation 
https://www.kernel.org/doc/Documentation/networking/bonding.txt
[5] Utilite Pro product page 
http://utilite-computer.com/web/utilite-pro-specifications
[6] Utilite Pro bonding configuration http://www.utilite-co 
mputer.com/forum/viewtopic.php?f=73=1980=31eb3a1273da28916d665112f8af2350


fec-watchdog.log.gz
Description: application/gzip


config.gz
Description: application/gzip


imx6q-cm-fx6.dtb
Description: Binary data

Re: [GIT PULL] Networking

[David Miller]

From: Linus Torvalds 
Date: Fri, 22 Aug 2014 14:32:58 -0700

> On Fri, Aug 22, 2014 at 11:47 AM, David Miller  wrote:
>>
>> Here are some bug fixes that have piled up during ksummit/linuxcon.
> 
> Hmm. What happened to the patch titled "mac80211: fix channel switch
> for chanctx-based drivers" by Michal Kazior?
> 
> That one fixes a rather nasty oops that results in dead machines. It's
> generic wireless code, but hits with at least intel wireless cards. It
> needs the AP to send a channel switch request, but if that happens
> (and it does), the kernel goes belly-up.

Yeah, I haven't gotten a pull request from John Linville yet, he's
probably still busy conferencing or travelling back hom.

I think you can apply it directly and none of us will mind, and GIT
will sort it all out during the next merge.

--
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: WARNING: CPU: 0 PID: 197 at fs/proc/generic.c:521 remove_proc_entry+0x142/0x159()

[Trond Myklebust]

On Fri, Aug 22, 2014 at 3:54 PM, Thomas Glanzmann  wrote:
> Hello everyone,
> after I compiled a new kernel 2 days ago and also with current Linus tip
> I get:
>
> [0.00] Initializing cgroup subsys cpuset
> [0.00] Initializing cgroup subsys cpu
> [0.00] Initializing cgroup subsys cpuacct
> [0.00] Linux version 3.17.0-rc1+ (sithglan@mini) (gcc version 4.7.2 
> (Debian 4.7.2-5) ) #182 SMP Fri Aug 22 20:14:24 CEST 2014
> [0.00] Command line: 
> BOOT_IMAGE=/home/sithglan/work/linux-2.6/arch/x86/boot/bzImage 
> root=UUID=c98d312d-f2a1-42d8-834a-ad2f95ce56f8 ro 
> netconsole=@192.168.0.7/eth0,@192.168.0.3/00:22:4d:6b:97:8f
> [0.00] e820: BIOS-provided physical RAM map:
> [0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
> [0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved
> [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
> [0.00] BIOS-e820: [mem 0x0010-0x7fff] usable
> [0.00] BIOS-e820: [mem 0x8000-0x8fff] reserved
> [0.00] BIOS-e820: [mem 0x9000-0xbe4b6fff] usable
> [0.00] BIOS-e820: [mem 0xbe4b7000-0xbe6b7fff] ACPI NVS
> [0.00] BIOS-e820: [mem 0xbe6b8000-0xbe85] ACPI 
> data
> [0.00] BIOS-e820: [mem 0xbe86-0xbe861fff] ACPI NVS
> [0.00] BIOS-e820: [mem 0xbe862000-0xbe862fff] ACPI 
> data
> [0.00] BIOS-e820: [mem 0xbe863000-0xbe864fff] ACPI NVS
> [0.00] BIOS-e820: [mem 0xbe865000-0xbfec5fff] ACPI 
> data
> [0.00] BIOS-e820: [mem 0xbfec6000-0xbfec7fff] ACPI NVS
> [0.00] BIOS-e820: [mem 0xbfec8000-0xbfec8fff] ACPI 
> data
> [0.00] BIOS-e820: [mem 0xbfec9000-0xbfecafff] ACPI NVS
> [0.00] BIOS-e820: [mem 0xbfecb000-0xbfeccfff] ACPI 
> data
> [0.00] BIOS-e820: [mem 0xbfecd000-0xbfedefff] ACPI NVS
> [0.00] BIOS-e820: [mem 0xbfedf000-0xbfef8fff] ACPI 
> data
> [0.00] BIOS-e820: [mem 0xbfef9000-0xbfefefff] reserved
> [0.00] BIOS-e820: [mem 0xbfeff000-0xbfef] ACPI 
> data
> [0.00] BIOS-e820: [mem 0xd340-0xd3400fff] reserved
> [0.00] BIOS-e820: [mem 0xf000-0xf3ff] reserved
> [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
> [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
> [0.00] BIOS-e820: [mem 0xffc0-0x] reserved
> [0.00] BIOS-e820: [mem 0x0001-0x00013fff] usable
> [0.00] NX (Execute Disable) protection: active
> [0.00] SMBIOS 2.4 present.
> [0.00] DMI: Apple Inc. Macmini3,1/Mac-F22C86C8, BIOS 
> MM31.88Z.0081.B06.0904271717 04/27/09
> [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
> [0.00] e820: remove [mem 0x000a-0x000f] usable
> [0.00] AGP: No AGP bridge found
> [0.00] e820: last_pfn = 0x14 max_arch_pfn = 0x4
> [0.00] MTRR default type: uncachable
> [0.00] MTRR fixed ranges enabled:
> [0.00]   0-9 write-back
> [0.00]   A-F uncachable
> [0.00] MTRR variable ranges enabled:
> [0.00]   0 disabled
> [0.00]   1 base 0 mask F8000 write-back
> [0.00]   2 base 08000 mask FC000 write-back
> [0.00]   3 base 1 mask FC000 write-back
> [0.00]   4 base 0BFF0 mask 0 uncachable
> [0.00]   5 disabled
> [0.00]   6 disabled
> [0.00]   7 disabled
> [0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 
> 0x7010600070106
> [0.00] e820: update [mem 0xbff0-0x] usable ==> reserved
> [0.00] e820: last_pfn = 0xbe4b7 max_arch_pfn = 0x4
> [0.00] Base memory trampoline at [88099000] 99000 size 24576
> [0.00] init_memory_mapping: [mem 0x-0x000f]
> [0.00]  [mem 0x-0x000f] page 4k
> [0.00] BRK [0x01847000, 0x01847fff] PGTABLE
> [0.00] BRK [0x01848000, 0x01848fff] PGTABLE
> [0.00] BRK [0x01849000, 0x01849fff] PGTABLE
> [0.00] init_memory_mapping: [mem 0x13fe0-0x13fff]
> [0.00]  [mem 0x13fe0-0x13fff] page 2M
> [0.00] BRK [0x0184a000, 0x0184afff] PGTABLE
> [0.00] init_memory_mapping: [mem 0x13c00-0x13fdf]
> [0.00]  [mem 0x13c00-0x13fdf] page 2M
> [0.00] init_memory_mapping: [mem 0x1-0x13bff]
> [0.00]  [mem 0x1-0x13bff] page 2M
> [0.00] init_memory_mapping: [mem 0x0010-0x7fff]
> [

Re: [GIT PULL] Networking

[Linus Torvalds]

On Fri, Aug 22, 2014 at 11:47 AM, David Miller  wrote:
>
> Here are some bug fixes that have piled up during ksummit/linuxcon.

Hmm. What happened to the patch titled "mac80211: fix channel switch
for chanctx-based drivers" by Michal Kazior?

That one fixes a rather nasty oops that results in dead machines. It's
generic wireless code, but hits with at least intel wireless cards. It
needs the AP to send a channel switch request, but if that happens
(and it does), the kernel goes belly-up.

Linus
--
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/1] GCD: add binary GCD algorithm

[Andrew Morton]

On Fri, 15 Aug 2014 20:49:16 +0800 Zhaoxiu Zeng  wrote:

> Because some architectures (alpha, armv6, etc.) don't provide hardware 
> division,
> the mod operation is slow! Binary GCD algorithm uses simple arithmetic 
> operations,
> it replaces division with arithmetic shifts, comparisons, and subtraction.

I had a look around and it seems that most (all?) gcd() and lcd()
callers are on initialization-time slowpaths.

Do you know of a workload which will significantly benefit from this
change?  If so, by how much?

Otherwise I don't think we can justify the additional maintenance
cost/risk, sorry.

And if we *do* decide to proceed with this patch, we should include a
patch which enables it on as many architectures as possible, so it gets
runtime tested.

--
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 0/2] add regulator support for pmbus and ltc2978

[atull]

On Thu, 21 Aug 2014, at...@opensource.altera.com wrote:

> From: Alan Tull 
> 
> This set of patches adds regulator support to pmbus_core.c and to
> ltc2978.c.
> 
> Other pmbus parts can use this to add their own regulator support.
> 
> Current ltc2978 support is limited to enable/disable.
> 
> Tested on ltc2978.  Looking at the datasheets for the other parts
> supported by ltc2978.c, it looks like it should work.
> 
> Thanks,
> Alan
> 
> Alan Tull (2):
>   pmbus: add regulator support
>   pmbus: ltc2978: add regulator enable disable
> 
>  drivers/hwmon/pmbus/Kconfig  |9 +
>  drivers/hwmon/pmbus/ltc2978.c|   69 
> ++
>  drivers/hwmon/pmbus/pmbus.h  |7 
>  drivers/hwmon/pmbus/pmbus_core.c |   40 ++
>  4 files changed, 125 insertions(+)
> 
> -- 
> 1.7.9.5
> 
> 

I've posted V2 of these patches.

Alan

--
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 v2 1/2] pmbus: add regulator support

[atull]

From: Alan Tull 

To add a regulator, the pmbus device driver needs to add
regulator_desc information to its pmbus_driver_info struct.
The regulator_init_data can be intialized from either
platform data or the device tree.

Signed-off-by: Alan Tull 

v2: Remove '#include '
Only one regulator per pmbus device
Get regulator_init_data from pdata or device tree
---
 drivers/hwmon/pmbus/pmbus.h  |5 
 drivers/hwmon/pmbus/pmbus_core.c |   51 ++
 include/linux/i2c/pmbus.h|1 +
 3 files changed, 57 insertions(+)

diff --git a/drivers/hwmon/pmbus/pmbus.h b/drivers/hwmon/pmbus/pmbus.h
index fa9beb3..93fadc3 100644
--- a/drivers/hwmon/pmbus/pmbus.h
+++ b/drivers/hwmon/pmbus/pmbus.h
@@ -19,6 +19,8 @@
  * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
  */
 
+#include 
+
 #ifndef PMBUS_H
 #define PMBUS_H
 
@@ -365,6 +367,9 @@ struct pmbus_driver_info {
 */
int (*identify)(struct i2c_client *client,
struct pmbus_driver_info *info);
+
+   /* Regulator functionality, if supported by this chip driver. */
+   const struct regulator_desc *reg_desc;
 };
 
 /* Function declarations */
diff --git a/drivers/hwmon/pmbus/pmbus_core.c b/drivers/hwmon/pmbus/pmbus_core.c
index 291d11f..472baff 100644
--- a/drivers/hwmon/pmbus/pmbus_core.c
+++ b/drivers/hwmon/pmbus/pmbus_core.c
@@ -29,6 +29,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include "pmbus.h"
 
 /*
@@ -1727,6 +1729,48 @@ static int pmbus_init_common(struct i2c_client *client, 
struct pmbus_data *data,
return 0;
 }
 
+#if IS_ENABLED(CONFIG_REGULATOR)
+static int pmbus_regulator_register(struct pmbus_data *data,
+   const struct pmbus_platform_data *pdata)
+{
+   struct device *dev = data->dev;
+   struct device_node *np = dev->of_node;
+   const struct pmbus_driver_info *info = data->info;
+   const struct regulator_desc *reg_desc = info->reg_desc;
+   struct regulator_dev *rdev;
+   struct regulator_config config = { };
+
+   if (!reg_desc)
+   return 0;
+
+   if (pdata && pdata->reg_init_data) {
+   config.init_data = pdata->reg_init_data;
+   } else {
+   config.init_data = of_get_regulator_init_data(dev, np);
+   if (!config.init_data)
+   return -ENOMEM;
+   }
+
+   config.dev = dev;
+   config.driver_data = data;
+
+   rdev = devm_regulator_register(dev, reg_desc, );
+   if (IS_ERR(rdev)) {
+   dev_err(dev, "failed to register regulator %s\n",
+   reg_desc->name);
+   return PTR_ERR(rdev);
+   }
+
+   return 0;
+}
+#else
+static int pmbus_regulator_register(struct pmbus_data *data,
+   const struct pmbus_platform_data *pdata)
+{
+   return 0;
+}
+#endif
+
 int pmbus_do_probe(struct i2c_client *client, const struct i2c_device_id *id,
   struct pmbus_driver_info *info)
 {
@@ -1781,8 +1825,15 @@ int pmbus_do_probe(struct i2c_client *client, const 
struct i2c_device_id *id,
dev_err(dev, "Failed to register hwmon device\n");
goto out_kfree;
}
+
+   ret = pmbus_regulator_register(data, pdata);
+   if (ret)
+   goto out_unregister;
+
return 0;
 
+out_unregister:
+   hwmon_device_unregister(data->hwmon_dev);
 out_kfree:
kfree(data->group.attrs);
return ret;
diff --git a/include/linux/i2c/pmbus.h b/include/linux/i2c/pmbus.h
index 69280db..15e08da 100644
--- a/include/linux/i2c/pmbus.h
+++ b/include/linux/i2c/pmbus.h
@@ -40,6 +40,7 @@
 
 struct pmbus_platform_data {
u32 flags;  /* Device specific flags */
+   struct regulator_init_data *reg_init_data;
 };
 
 #endif /* _PMBUS_H_ */
-- 
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/

[PATCH v2 2/2] pmbus: ltc2978: add regulator gating

[atull]

From: Alan Tull 

Add regulator with support for enabling or disabling all
supplies.

Signed-off-by: Alan Tull 

v2:  Remove '#include '
 Kconfig fixes
 Remove hardwired regulator_init_data
---
 drivers/hwmon/pmbus/Kconfig   |7 +
 drivers/hwmon/pmbus/ltc2978.c |   60 +
 2 files changed, 67 insertions(+)

diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
index 6e1e493..79117b7 100644
--- a/drivers/hwmon/pmbus/Kconfig
+++ b/drivers/hwmon/pmbus/Kconfig
@@ -56,6 +56,13 @@ config SENSORS_LTC2978
  This driver can also be built as a module. If so, the module will
  be called ltc2978.
 
+config SENSORS_LTC2978_REGULATOR
+   boolean "Regulator support for LTC2974, LTC2978, LTC3880, and LTC3883"
+   depends on SENSORS_LTC2978 && REGULATOR
+   help
+ If you say yes here you get regulator support for Linear
+ Technology LTC2974, LTC2978, LTC3880, and LTC3883.
+
 config SENSORS_MAX16064
tristate "Maxim MAX16064"
default n
diff --git a/drivers/hwmon/pmbus/ltc2978.c b/drivers/hwmon/pmbus/ltc2978.c
index e24ed52..2bdcfe2 100644
--- a/drivers/hwmon/pmbus/ltc2978.c
+++ b/drivers/hwmon/pmbus/ltc2978.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "pmbus.h"
@@ -151,6 +152,60 @@ static int ltc2978_read_word_data_common(struct i2c_client 
*client, int page,
return ret;
 }
 
+#if IS_ENABLED(CONFIG_SENSORS_LTC2978_REGULATOR)
+static int ltc2978_write_pmbus_operation(struct regulator_dev *rdev, u8 value)
+{
+   struct device *dev = rdev_get_dev(rdev);
+   struct i2c_client *client = to_i2c_client(dev->parent);
+   int ret;
+
+   ret = pmbus_set_page(client, 0xff);
+   if (ret < 0)
+   return ret;
+
+   return i2c_smbus_write_byte_data(client, PMBUS_OPERATION, value);
+}
+
+static int ltc2978_enable_all(struct regulator_dev *rdev)
+{
+   return ltc2978_write_pmbus_operation(rdev, 0x80);
+}
+
+static int ltc2978_disable_all(struct regulator_dev *rdev)
+{
+   return ltc2978_write_pmbus_operation(rdev, 0);
+}
+
+static int ltc2978_is_enabled(struct regulator_dev *rdev)
+{
+   struct device *dev = rdev_get_dev(rdev);
+   struct i2c_client *client = to_i2c_client(dev->parent);
+   int ret;
+
+   ret = pmbus_set_page(client, 0xff);
+   if (ret < 0)
+   return ret;
+
+   ret = i2c_smbus_read_byte_data(client, PMBUS_OPERATION);
+   if (ret < 0)
+   return ret;
+
+   return !!(ret & 0x80);
+}
+
+static struct regulator_ops ltc2978_regulator_ops = {
+   .enable = ltc2978_enable_all,
+   .disable = ltc2978_disable_all,
+   .is_enabled = ltc2978_is_enabled,
+};
+
+static const struct regulator_desc ltc2978_reg_desc = {
+   .name = "ltc2978",
+   .ops = _regulator_ops,
+   .owner = THIS_MODULE,
+};
+#endif
+
 static int ltc2978_read_word_data(struct i2c_client *client, int page, int reg)
 {
const struct pmbus_driver_info *info = pmbus_get_driver_info(client);
@@ -487,6 +542,11 @@ static int ltc2978_probe(struct i2c_client *client,
default:
return -ENODEV;
}
+
+#if IS_ENABLED(CONFIG_SENSORS_LTC2978_REGULATOR)
+   info->reg_desc = _reg_desc;
+#endif
+
return pmbus_do_probe(client, id, info);
 }
 
-- 
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/

[PATCH v2 0/2] dd regulator support for pmbus and ltc2978

[atull]

From: Alan Tull 

Version 2 :
  * Get regulator_init_data from platform data or device tree.
  * One regulator per pmbus part.
  * Clean up Kconfig and #includes.

This set of patches adds regulator support to pmbus_core.c and to
ltc2978.c.  Other pmbus parts can use this to add their own
regulator support.  Current ltc2978 support is limited to
enable/disable.

Tested on ltc2978.  Looking at the datasheets for the other parts
supported by ltc2978.c, it looks like it should work.

Thanks,
Alan

Alan Tull (2):
  pmbus: add regulator support
  pmbus: ltc2978: add regulator gating

 drivers/hwmon/pmbus/Kconfig  |7 +
 drivers/hwmon/pmbus/ltc2978.c|   60 ++
 drivers/hwmon/pmbus/pmbus.h  |5 
 drivers/hwmon/pmbus/pmbus_core.c |   51 
 include/linux/i2c/pmbus.h|1 +
 5 files changed, 124 insertions(+)

-- 
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 v2] tps65910: Work around silicon erratum SWCZ010

[Mark Brown]

On Fri, Aug 22, 2014 at 05:30:56PM +0200, Arnout Vandecappelle (Essensium/Mind) 
wrote:
> From http://www.ti.com/lit/pdf/SWCZ010 :
> 
> Glitch on SDA-SCL not managed correctly by the I2C IP

Applied, thanks.


signature.asc
Description: Digital signature

Re: [patch 4/4] prctl: PR_SET_MM -- Introduce PR_SET_MM_MAP operation, v3

[Cyrill Gorcunov]

On Fri, Aug 22, 2014 at 01:46:28PM -0700, Andrew Morton wrote:
> On Sat, 23 Aug 2014 00:38:09 +0400 Cyrill Gorcunov  wrote:
> 
> > > 
> > > Or will we?  What happens if we later decide that some additional field
> > > needs to be added?  Do we version the interface?  Add a new prctl()
> > > mode?  Let's cook up a plan for that and at least add to changelog?
> > 
> > I don't expect to change it anytime soon but we still have an option --
> > if we decide to extend or shrink it we always can use sizeof/offsetof
> > helpers to check which exactly version userspace asks us to use.
> 
> How does that work?  We just have a blob of bytes coming in from
> userspace.

Not just blob. We have it as a structure where all fields have a
constant size. Say we have

struct prctl_mm_map {
__u64 start_code;
__u64 start_code;
__u64 some-new-field;
};

in the kernel, so its size will be 24 bytes but userspace
uses old definition without @some-new-field member (16 bytes).
So when we get a reguest with 16 bytes from userspace we can
find the userspace have passed old definition. It's not as
explicit as if we would have some @version field in struct
prctl_mm_mmap, but looks fine for me. Still I can add @version
into the structure if you prefer.

> > As far as I understand the mm_struct is not the structure which
> > changes that frequently, right?
> 
> We might find existing things which criu wants to access.  And criu
> lives forever, yes?  The mm_struct is likely to change over that time
> period ;)

Hopefully criu will live long enough so I would have a chance to update
prctl_mm_map accordingly :) Still the good thing is that once mm_struct
get changed the kernel fails to build in sys.c and the change will
be noticed immediately so we update sys.c as well.
--
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] drivers: target: target_core_ua_h: Add #define of include guard

[Nicholas A. Bellinger]

Hi Rasmus,

On Fri, 2014-08-22 at 14:54 +0200, Rasmus Villemoes wrote:
> Clearly the file was meant to contain an include guard, but it was
> missing the #define part.
> 
> Signed-off-by: Rasmus Villemoes 
> ---
>  drivers/target/target_core_ua.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/target/target_core_ua.h b/drivers/target/target_core_ua.h
> index be912b3..a6b56b3 100644
> --- a/drivers/target/target_core_ua.h
> +++ b/drivers/target/target_core_ua.h
> @@ -1,4 +1,5 @@
>  #ifndef TARGET_CORE_UA_H
> +#define TARGET_CORE_UA_H
>  
>  /*
>   * From spc4r17, Table D.1: ASC and ASCQ Assignement

Applied to target-pending.git.

Thanks!

--nab


--
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: For review: user_namespace(7) man page

[Serge E. Hallyn]

Quoting Michael Kerrisk (man-pages) (mtk.manpa...@gmail.com):
> Hello Eric et al.,
> 
> For various reasons, my work on the namespaces man pages 
> fell off the table a while back. Nevertheless, the pages have
> been close to completion for a while now, and I recently restarted,
> in an effort to finish them. As you also noted to me f2f, there have
> been recently been some small namespace changes that you may affect
> the content of the pages. Therefore, I'll take the opportunity to
> send the namespace-related pages out for further (final?) review.
> 
> So, here, I start with the user_namespaces(7) page, which is shown 
> in rendered form below, with source attached to this mail. I'll
> send various other pages in follow-on mails.
> 
> Review comments/suggestions for improvements / bug fixes welcome.
> 
> Cheers,
> 
> Michael
> 
> ==
> 
> NAME
>user_namespaces - overview of Linux user_namespaces
> 
> DESCRIPTION
>For an overview of namespaces, see namespaces(7).
> 
>User   namespaces   isolate   security-related   identifiers  and
>attributes, in particular, user IDs and group  IDs  (see  creden‐
>tials(7), the root directory, keys (see keyctl(2)), and capabili‐
>ties (see capabilities(7)).  A process's user and group  IDs  can
>be different inside and outside a user namespace.  In particular,
>a process can have a normal unprivileged user ID outside  a  user
>namespace while at the same time having a user ID of 0 inside the
>namespace; in other words, the process has  full  privileges  for
>operations  inside  the  user  namespace, but is unprivileged for
>operations outside the namespace.
> 
>Nested namespaces, namespace membership
>User namespaces can be nested;  that  is,  each  user  namespace—
>except  the  initial  ("root") namespace—has a parent user names‐
>pace, and can have zero or more child user namespaces.  The  par‐
>ent user namespace is the user namespace of the process that cre‐
>ates the user namespace via a call to unshare(2) or clone(2) with
>the CLONE_NEWUSER flag.
> 
>The kernel imposes (since version 3.11) a limit of 32 nested lev‐
>els of user namespaces.  Calls to  unshare(2)  or  clone(2)  that
>would cause this limit to be exceeded fail with the error EUSERS.
> 
>Each  process  is  a  member  of  exactly  one user namespace.  A
>process created via fork(2) or clone(2) without the CLONE_NEWUSER
>flag  is  a  member  of the same user namespace as its parent.  A
>process can join another user namespace with setns(2) if  it  has
>the  CAP_SYS_ADMIN  in  that namespace; upon doing so, it gains a
>full set of capabilities in that namespace.
> 
>A call to clone(2) or  unshare(2)  with  the  CLONE_NEWUSER  flag
>makes  the  new  child  process (for clone(2)) or the caller (for
>unshare(2)) a member of the new user  namespace  created  by  the
>call.
> 
>Capabilities
>The child process created by clone(2) with the CLONE_NEWUSER flag
>starts out with a complete set of capabilities in  the  new  user
>namespace.  Likewise, a process that creates a new user namespace
>using unshare(2)  or  joins  an  existing  user  namespace  using
>setns(2)  gains a full set of capabilities in that namespace.  On
>the other hand, that process has no capabilities  in  the  parent
>(in  the case of clone(2)) or previous (in the case of unshare(2)
>and setns(2)) user namespace, even if the new namespace  is  cre‐
>ated  or  joined by the root user (i.e., a process with user ID 0
>in the root namespace).
> 
>Note that a call to execve(2) will cause a process  to  lose  any
>capabilities that it has, unless it has a user ID of 0 within the
>namespace.  See the discussion of user  and  group  ID  mappings,
>below.

The above is an approximation, but a bit misleading.  On exec, the task
capability set is recalculated according to the usual rules.  So if the
file being executed has file capabilities, the result task may end up
with capabilities even if it is not root (even if it is uid -1).

Perhaps it should be phrased as:

Note that a call to execve(2) will cause a process' capabilities
to be recalculated (see capabilities(7)), so that usually, unless
it has a user ID of 0 within the namespace, it will lose all
capabilities.  See the discussion of user  and  group  ID  mappings,
below.

-serge
--
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 0/7] MIPS: Move device-tree files to a common location

[Andrew Bresticker]

On Fri, Aug 22, 2014 at 1:42 PM, Florian Fainelli  wrote:
>
> On Aug 21, 2014 3:05 PM, "Andrew Bresticker"  wrote:
> >
> > To be consistent with other architectures and to avoid unnecessary
> > makefile duplication, move all MIPS device-trees to arch/mips/boot/dts
> > and build them with a common makefile.
>
> I recall reading that the ARM organization for DTS files was a bit unfortunate
> and should have been something like:
>
> arch/arm/boot/dts//
>
> Is this something we should do for the MIPS and update the other architectures
> to follow that scheme?

I recall reading that as well and that it would be adopted for ARM64,
but that hasn't seemed to have happened.  Perhaps Olof (CC'ed) will no
more.
--
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] tcm_fc: Replace rcu_assign_pointer() with RCU_INIT_POINTER()

[Nicholas A. Bellinger]

Hi Andreea-Cristina,

On Mon, 2014-08-18 at 15:05 +0300, Andreea-Cristina Bernat wrote:
> The use of "rcu_assign_pointer()" is NULLing out the pointer.
> According to RCU_INIT_POINTER()'s block comment:
> "1.   This use of RCU_INIT_POINTER() is NULLing out the pointer"
> it is better to use it instead of rcu_assign_pointer() because it has a
> smaller overhead.
> 
> The following Coccinelle semantic patch was used:
> @@
> @@
> 
> - rcu_assign_pointer
> + RCU_INIT_POINTER
>   (..., NULL)
> 
> Signed-off-by: Andreea-Cristina Bernat 
> ---
>  drivers/target/tcm_fc/tfc_sess.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/target/tcm_fc/tfc_sess.c 
> b/drivers/target/tcm_fc/tfc_sess.c
> index 21ce508..ccee7e3 100644
> --- a/drivers/target/tcm_fc/tfc_sess.c
> +++ b/drivers/target/tcm_fc/tfc_sess.c
> @@ -98,7 +98,7 @@ static void ft_tport_delete(struct ft_tport *tport)
>   ft_sess_delete_all(tport);
>   lport = tport->lport;
>   BUG_ON(tport != lport->prov[FC_TYPE_FCP]);
> - rcu_assign_pointer(lport->prov[FC_TYPE_FCP], NULL);
> + RCU_INIT_POINTER(lport->prov[FC_TYPE_FCP], NULL);
>  
>   tpg = tport->tpg;
>   if (tpg) {

Applied to target-pending.git.

Thanks!

--nab

--
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] carl9170: Remove redundant protection check

[Eric Dumazet]

On Fri, 2014-08-22 at 22:38 +0200, Christian Lamparter wrote:
> On Friday, August 22, 2014 10:14:31 PM Andreea-Cristina Bernat wrote:
> > The carl9170_op_ampdu_action() function is used only by the mac80211
> > framework. Since the mac80211 already takes care of checks and 
> > properly serializing calls to the driver's function there is no
> > need for the driver to do the same thing.
> > 
> > Signed-off-by: Andreea-Cristina Bernat 
> > ---
> > Changes in v2:
> >  - Change subject line from
> >"carl9170: Replace rcu_dereference() with rcu_access_pointer()"
> >to
> >"carl9170: Remove redundant protection check"
> >  - Update the commit message according to the modifications
> >  - Delete the lines of interest at the suggestion and explanations of
> >Christian Lamparter 
> > 
> >  drivers/net/wireless/ath/carl9170/main.c | 6 --
> >  1 file changed, 6 deletions(-)
> > 
> > diff --git a/drivers/net/wireless/ath/carl9170/main.c 
> > b/drivers/net/wireless/ath/carl9170/main.c
> > index 12018ff..6758b9a 100644
> > --- a/drivers/net/wireless/ath/carl9170/main.c
> > +++ b/drivers/net/wireless/ath/carl9170/main.c
> > @@ -1430,12 +1430,6 @@ static int carl9170_op_ampdu_action(struct 
> > ieee80211_hw *hw,
> > if (!sta_info->ht_sta)
> > return -EOPNOTSUPP;
> >  
> > -   rcu_read_lock();
> > -   if (rcu_access_pointer(sta_info->agg[tid])) {
> > -   rcu_read_unlock();
> > -   return -EBUSY;
> > -   }
> > -
> > tid_info = kzalloc(sizeof(struct carl9170_sta_tid),
> >GFP_ATOMIC);
> > if (!tid_info) {
> > 
> 
> sparse [0] hit a bug when testing the patch:
> 
> drivers/net/wireless/ath/carl9170/main.c:1440:17: 
>   warning: context imbalance in 'carl9170_op_ampdu_action' - unexpected unlock
> 
> This warning is caused by the remaining, stray rcu_read protection
> in the code below (Sorry! Guess RCU needed a bit more explanation
> in the previous post. If you are looking for *pointers*, there are
> excellent resources available in Documentation/RCU/ [1]).
> 
> I've attached a full patch (see below) with all changes so far and
> tested if the device/driver still behaves ;-). This patch applies 
> cleanly on top of wireless-testing.
> 
> @John,
> can you please take it?
> 
> ---
> From: Andreea-Cristina Bernat 
> 
> The carl9170_op_ampdu_action() function is used only by the mac80211
> framework. Since the mac80211 already takes care of checks and 
> properly serializing calls to the driver's function there is no
> need for the driver to do the same thing.
>  
> Signed-off-by: Andreea-Cristina Bernat 
> [chunk...@googlemail.com: remove two stray rcu_read_unlock()]
> Signed-off-by: Christian Lamparter 
> ---
> diff --git a/drivers/net/wireless/ath/carl9170/main.c 
> b/drivers/net/wireless/ath/carl9170/main.c
> index f8ded84..ef5b6dc 100644
> --- a/drivers/net/wireless/ath/carl9170/main.c
> +++ b/drivers/net/wireless/ath/carl9170/main.c
> @@ -1430,18 +1430,10 @@ static int carl9170_op_ampdu_action(struct 
> ieee80211_hw *hw,
>   if (!sta_info->ht_sta)
>   return -EOPNOTSUPP;
>  
> - rcu_read_lock();
> - if (rcu_dereference(sta_info->agg[tid])) {
> - rcu_read_unlock();
> - return -EBUSY;
> - }
> -
>   tid_info = kzalloc(sizeof(struct carl9170_sta_tid),
>  GFP_ATOMIC);
> - if (!tid_info) {
> - rcu_read_unlock();
> + if (!tid_info)
>   return -ENOMEM;
> - }
>  
>   tid_info->hsn = tid_info->bsn = tid_info->snx = (*ssn);
>   tid_info->state = CARL9170_TID_STATE_PROGRESS;
> @@ -1460,7 +1452,6 @@ static int carl9170_op_ampdu_action(struct ieee80211_hw 
> *hw,
>   list_add_tail_rcu(_info->list, >tx_ampdu_list);
>   rcu_assign_pointer(sta_info->agg[tid], tid_info);
>   spin_unlock_bh(>tx_ampdu_list_lock);
> - rcu_read_unlock();
>  
>   ieee80211_start_tx_ba_cb_irqsafe(vif, sta->addr, tid);
>   break;
> ---
> 
> Regards
> Christian
> 
> [0] 
> [1] 
> 


Sorry but this patch is not complete.

You need to somehow return -EBUSY if sta_info->agg[tid] is set.

The test has to be done inside the
spin_lock_bh(>tx_ampdu_list_lock) /
spin_unlock_bh(>tx_ampdu_list_lock); region.

You are correct the RCU bits were wrong in this context, but we still
have to avoid leaks.


--
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/

linux-next: build failure after merge of the pwm tree

[Stephen Rothwell]

Hi Thierry,

After merging the pwm tree, today's linux-next build (powerpc allyesconfig)
failed like this:

drivers/pwm/pwm-lpss.c: In function 'pwm_lpss_config':
drivers/pwm/pwm-lpss.c:81:2: error: implicit declaration of function 'readl' 
[-Werror=implicit-function-declaration]
  ctrl = readl(lpwm->regs + PWM);
  ^
drivers/pwm/pwm-lpss.c:87:2: error: implicit declaration of function 'writel' 
[-Werror=implicit-function-declaration]
  writel(ctrl, lpwm->regs + PWM);
  ^

Caused by commit 28160b18787b ("pwm: lpss: Properly split driver to
parts").

I have reverted that commit for today (and 06c7b5394e21 ("pwm: lpss:
pci: Move to use pcim_enable_device()") which depends on it).
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


signature.asc
Description: PGP signature

RE: [PATCH net-next] hyperv: Add handling of IP header with option field in netvsc_set_hash()

[Haiyang Zhang]

> -Original Message-
> From: David Miller [mailto:da...@davemloft.net]
> Sent: Friday, August 22, 2014 12:31 AM
> To: Haiyang Zhang
> Cc: net...@vger.kernel.org; KY Srinivasan; o...@aepfle.de;
> jasow...@redhat.com; linux-kernel@vger.kernel.org; driverdev-
> de...@linuxdriverproject.org
> Subject: Re: [PATCH net-next] hyperv: Add handling of IP header with
> option field in netvsc_set_hash()
> 
> From: Haiyang Zhang 
> Date: Tue, 19 Aug 2014 20:53:55 +
> 
> > @@ -200,12 +202,18 @@ static bool netvsc_set_hash(u32 *hash, struct
> sk_buff *skb)
> > iphdr = ip_hdr(skb);
> >
> > if (iphdr->version == 4) {
> > -   if (iphdr->protocol == IPPROTO_TCP)
> > +   data = (u8 *)>saddr;
> > +   if (iphdr->protocol == IPPROTO_TCP) {
> > data_len = 12;
> > -   else
> > +   if (iphdr->ihl > 5) {
> > +   memcpy(dbuf, >saddr, 8);
> > +   memcpy([8], _hdr(skb)->source, 4);
> 
> This is rediculous.
> 
> Make hash_comp() take a void pointer for the buffer.
> 
> Then your code is simply:
> 
>   be32 dbuf[2];
> 
>   dbuf[1] = iph->saddr;
>   dbuf[2] = iph->daddr;
>   dbuf[3] = *(be32 *)tcph->source;
> 
>   *hash = comp_hash(netvsc_hash_key, HASH_KEYLEN, dbuf, 12);
> 
> No special cases for IP options or any garbage like that.

I have submitted a revised patch with the suggested changes.

Thanks,
- Haiyang

--
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] trace-cmd: link trace-record in ctracecmd.so

[Steven Rostedt]

On Fri, 15 Aug 2014 16:31:38 +0100
"Javi Merino"  wrote:

> Commit b1e9220819eb (trace-cmd: Report stats for all instances) moved
> tracecmd_stat_cpu() from trace-recorder.c to trace-record.c.  This
> makes import ctracecmd fail in tracecmd.py:
> 
> $ python tracecmd.py
> Traceback (most recent call last):
>   File "tracecmd.py", line 22, in 
> from ctracecmd import *
> ImportError: ctracecmd.so: undefined symbol: tracecmd_stat_cpu
> 
> Link trace-record in ctracecmd.so to add back the required symbol.
> 

I just applied this. May push this out next week. I have other changes
I'm adding and need to get them finished before I push it out. It may
not go out until September though.

-- Steve

> Signed-off-by: Javi Merino 
> ---
>  Makefile | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index cbe0eb9..308d7f8 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -317,8 +317,9 @@ KERNEL_SHARK_OBJS = $(TRACE_VIEW_OBJS) 
> $(TRACE_GRAPH_OBJS) $(TRACE_GUI_OBJS) \
>  
>  PEVENT_LIB_OBJS = event-parse.o trace-seq.o parse-filter.o parse-utils.o
>  TCMD_LIB_OBJS = $(PEVENT_LIB_OBJS) trace-util.o trace-input.o trace-ftrace.o 
> \
> - trace-output.o trace-recorder.o trace-restore.o 
> trace-usage.o \
> - trace-blk-hack.o kbuffer-parse.o event-plugin.o
> + trace-output.o trace-record.o trace-recorder.o \
> + trace-restore.o trace-usage.o trace-blk-hack.o \
> + kbuffer-parse.o event-plugin.o
>  
>  PLUGIN_OBJS =
>  PLUGIN_OBJS += plugin_jbd2.o

--
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 03/10] perf evlist: Monitor POLLERR and POLLHUP events too

[Arnaldo Carvalho de Melo]

From: Arnaldo Carvalho de Melo 

We want to know when the fd went away, like when a monitored thread
exits.

If we do not monitor such events, then the tools will wait forever on
events from a vanished thread, like when running:

 $ sleep 5s &
 $ perf record -p `pidof sleep`

This builds upon the kernel patch by Jiri Olsa that actually makes a
poll on those file descriptors to return POLLHUP.

It is also needed to change the tools to use
perf_evlist__filter_pollfd() to check if there are remainings fds to
monitor or if all are gone, in which case they will exit the
poll/mmap/read loop.

Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Don Zickus 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Mike Galbraith 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Link: http://lkml.kernel.org/n/tip-a4fslwspov0bs69nj825h...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/evlist.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index bd7896073d10..cddc700d718f 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -424,7 +424,7 @@ void perf_evlist__add_pollfd(struct perf_evlist *evlist, 
int fd)
 {
fcntl(fd, F_SETFL, O_NONBLOCK);
evlist->pollfd[evlist->nr_fds].fd = fd;
-   evlist->pollfd[evlist->nr_fds].events = POLLIN;
+   evlist->pollfd[evlist->nr_fds].events = POLLIN | POLLERR | POLLHUP;
evlist->nr_fds++;
 }
 
-- 
1.9.3

--
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/