Re: Regression in 3.15 on POWER8 with multipath SCSI

[Hannes Reinecke]

On 06/30/2014 11:28 PM, Paul Mackerras wrote:

On Mon, Jun 30, 2014 at 01:35:20PM +0200, Hannes Reinecke wrote:

On 06/30/2014 01:02 PM, Paul Mackerras wrote:

[ .. ]


No, I'm not using LVM, and in fact I deleted all the physical volumes
that were on any of the disks (they were installations of other
distros), so there are no physical or logical volumes anywhere on any
disk.  I haven't tried disabling the LVM service completely, though.
What would it mean if disabling the LVM service made a difference?


Yes. LVM integration with systemd is a science unto itself.
I'm reasonably confident with multipath, but not LVM.
Plus the fact the the LVM service apparently is waiting for something sort
of points into that direction.

So please do disable the lvm service.


I disabled the LVM service, and it's still bad.  Unmodified 3.15
booted successfully in only 18 out of 50 attempts with LVM disabled.

So it's not LVM.  In any case LVM was fine with a 3.14 kernel.


Right, that was just a cross-check to eliminate any variables.

I'll be checking here at my end.

Cheers,

Hannes
--
Dr. Hannes Reinecke   zSeries & Storage
h...@suse.de  +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
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 1/3] gpio: always compile label support

[Alexandre Courbot]

Compiling out GPIO labels results in a space gain so small that it can
hardly be justified. Labels can also be useful for printing debug
messages, so always keep them around.

Signed-off-by: Alexandre Courbot 
---
 drivers/gpio/gpiolib.c | 27 ++-
 1 file changed, 2 insertions(+), 25 deletions(-)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 2ebc9071e354..8ba9dbedcfdf 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -66,9 +66,7 @@ struct gpio_desc {
 #define GPIO_FLAGS_MASK((1 << ID_SHIFT) - 1)
 #define GPIO_TRIGGER_MASK  (BIT(FLAG_TRIG_FALL) | BIT(FLAG_TRIG_RISE))
 
-#ifdef CONFIG_DEBUG_FS
const char  *label;
-#endif
 };
 static struct gpio_desc gpio_desc[ARCH_NR_GPIOS];
 
@@ -87,7 +85,6 @@ static void gpiod_free(struct gpio_desc *desc);
 
 /* With descriptor prefix */
 
-#ifdef CONFIG_DEBUG_FS
 #define gpiod_emerg(desc, fmt, ...)   \
pr_emerg("gpio-%d (%s): " fmt, desc_to_gpio(desc), desc->label ? : "?",\
  ##__VA_ARGS__)
@@ -106,20 +103,6 @@ static void gpiod_free(struct gpio_desc *desc);
 #define gpiod_dbg(desc, fmt, ...) \
pr_debug("gpio-%d (%s): " fmt, desc_to_gpio(desc), desc->label ? : "?",\
  ##__VA_ARGS__)
-#else
-#define gpiod_emerg(desc, fmt, ...)\
-   pr_emerg("gpio-%d: " fmt, desc_to_gpio(desc), ##__VA_ARGS__)
-#define gpiod_crit(desc, fmt, ...) \
-   pr_crit("gpio-%d: " fmt, desc_to_gpio(desc), ##__VA_ARGS__)
-#define gpiod_err(desc, fmt, ...)  \
-   pr_err("gpio-%d: " fmt, desc_to_gpio(desc), ##__VA_ARGS__)
-#define gpiod_warn(desc, fmt, ...) \
-   pr_warn("gpio-%d: " fmt, desc_to_gpio(desc), ##__VA_ARGS__)
-#define gpiod_info(desc, fmt, ...) \
-   pr_info("gpio-%d: " fmt, desc_to_gpio(desc), ##__VA_ARGS__)
-#define gpiod_dbg(desc, fmt, ...)  \
-   pr_debug("gpio-%d: " fmt, desc_to_gpio(desc), ##__VA_ARGS__)
-#endif
 
 /* With chip prefix */
 
@@ -138,9 +121,7 @@ static void gpiod_free(struct gpio_desc *desc);
 
 static inline void desc_set_label(struct gpio_desc *d, const char *label)
 {
-#ifdef CONFIG_DEBUG_FS
d->label = label;
-#endif
 }
 
 /*
@@ -1906,8 +1887,8 @@ EXPORT_SYMBOL_GPL(gpio_free_array);
  * @offset: of signal within controller's 0..(ngpio - 1) range
  *
  * Returns NULL if the GPIO is not currently requested, else a string.
- * If debugfs support is enabled, the string returned is the label passed
- * to gpio_request(); otherwise it is a meaningless constant.
+ * The string returned is the label passed to gpio_request(); if none has been
+ * passed it is a meaningless, non-NULL constant.
  *
  * This function is for use by GPIO controller drivers.  The label can
  * help with diagnostics, and knowing that the signal is used as a GPIO
@@ -1924,11 +1905,7 @@ const char *gpiochip_is_requested(struct gpio_chip 
*chip, unsigned offset)
 
if (test_bit(FLAG_REQUESTED, >flags) == 0)
return NULL;
-#ifdef CONFIG_DEBUG_FS
return desc->label;
-#else
-   return "?";
-#endif
 }
 EXPORT_SYMBOL_GPL(gpiochip_is_requested);
 
-- 
2.0.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/

[RFC 0/3] gpio: move interfaces into their own files

[Alexandre Courbot]

Hi Linus,

I was thinking of doing this since a while already but the recent discussion on
shared GPIOs made me think I should push this to you and see what you think.

Right now we have 3 different interfaces for GPIO:
- The core gpiod interface
- The legacy integer interface, which mostly relies on gpiod
- The sysfs interface, which relies on gpiod but should probably rely on the
  integer interface instead

This series separates the code for the interfaces into their own source file
and shares what needs to be through the private gpiolib.h header. Label support
is made mandatory in order to reduce the amount of things added into gpiolib.h.

Separating the code should make the various interfaces easier to grasp, and
will make it easier to implement interface-specific features. It also points
out some direct usages of descriptors/gpiolib core functions that should be
gotten rid of in order to make these real "consumers" of the gpiod interface.

This series has been tested and I'm fine with it being merged now if you agree
with the idea. It would probably be preferable from a cosmetic point of view to
first turn fix the extra consumers and then separate them so less things end up
being exported in gpiolib.h, but moving things first has the advantage of
clearly highlighting what needs to be done and spares us some rebasing hassle.

Alexandre Courbot (3):
  gpio: always compile label support
  gpio: move sysfs support to its own file
  gpio: move integer GPIO support to its own file

 drivers/gpio/Makefile |2 +
 drivers/gpio/gpiolib-legacy.c |  112 +
 drivers/gpio/gpiolib-sysfs.c  |  829 
 drivers/gpio/gpiolib.c| 1043 +
 drivers/gpio/gpiolib.h|   91 
 5 files changed, 1040 insertions(+), 1037 deletions(-)
 create mode 100644 drivers/gpio/gpiolib-legacy.c
 create mode 100644 drivers/gpio/gpiolib-sysfs.c

-- 
2.0.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 RFC net-next 03/14] bpf: introduce syscall(BPF, ...) and BPF maps

[Alexei Starovoitov]

On Mon, Jun 30, 2014 at 3:09 PM, Andy Lutomirski  wrote:
> On Sat, Jun 28, 2014 at 11:36 PM, Alexei Starovoitov  
> wrote:
>> On Sat, Jun 28, 2014 at 6:52 PM, Andy Lutomirski  wrote:
>>> On Sat, Jun 28, 2014 at 1:49 PM, Alexei Starovoitov  
>>> wrote:

 Sorry I don't like 'fd' direction at all.
 1. it will make the whole thing very socket specific and 'net' dependent.
 but the goal here is to be able to use eBPF for tracing in embedded
 setups. So it's gotta be net independent.
 2. sockets are already overloaded with all sorts of stuff. Adding more
 types of sockets will complicate it a lot.
 3. and most important. read/write operations on sockets are not
 done every nanosecond, whereas lookup operations on bpf maps
 are done every dozen instructions, so we cannot have any overhead
 when accessing maps.
 In other words the verifier is done as static analyzer. I moved all
 the complexity to verify time, so at run-time the programs are as
 fast as possible. I'm strongly against run-time checks in critical path,
 since they kill performance and make the whole approach a lot less usable.
>>>
>>> I may have described my suggestion poorly.  I'm suggesting that all of
>>> these global ids be replaced *for userspace's benefit* with fds.  That
>>> is, a map would have an associated struct inode, and, when you load an
>>> eBPF program, you'd pass fds into the kernel instead of global ids.
>>> The kernel would still compile the eBPF program to use the global ids,
>>> though.
>>
>> Hmm. If I understood you correctly, you're suggesting to do it similar
>> to ipc/mqueue, shmem, sockets do. By registering and mounting
>> a file system and providing all superblock and inode hooks… and
>> probably have its own namespace type… hmm… may be. That's
>> quite a bit of work to put lightly. As I said in the other email the first
>> step is root only and all these complexity just not worth doing
>> at this stage.
>
> The downside of not doing it right away is that it's harder to
> retrofit in without breaking early users.
>
> You might be able to get away with using anon_inodes.  That will

Spent quite a bit of time playing with anon_inode_getfd(). The model
works ok for seccomp, but doesn't seem to work for tracing,
since tracepoints are global. Say, syscall(bpf, load_prog) returns
a process-local fd. This 'fd' as a string can be written to
debugfs/tracing/events/.../filter which will increment a refcnt of a global
ebpf_program structure and will keep using it. When process exits it will
close all fds which in case of ebpf_prog_fd should be a nop, since
the program is still attached to a global event. Now we have a
program and maps that still alive and dangling, since tracepoint events
keep coming, but no new process can access it. Here we just lost all
benefits of making it 'fd' based. Theoretically we can extend tracing to
be fd-based too and tracepoints will auto-detach upon process exit,
but that's not going to work for all other global events. Like networking
components (bridge, ovs, …) are global and they won't be adding
fd-based interfaces.
I'm still thinking about it, but it looks like that any process-local
ebpf_prog_id scheme is not going to work for global events. Thoughts?
--
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 3/3] gpio: move integer GPIO support to its own file

[Alexandre Courbot]

The old integer GPIO interface is, in effect, a privileged user of the
gpiod interface. Reflect this fact further by moving legacy GPIO support
into its own source file. This makes the code clearer and will allow us
to disable legacy GPIO support in the (far) future.

Signed-off-by: Alexandre Courbot 
---
 drivers/gpio/Makefile |   1 +
 drivers/gpio/gpiolib-legacy.c | 112 ++
 drivers/gpio/gpiolib.c| 105 ---
 3 files changed, 113 insertions(+), 105 deletions(-)
 create mode 100644 drivers/gpio/gpiolib-legacy.c

diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 579be6fc5edb..17ef34796d66 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -4,6 +4,7 @@ ccflags-$(CONFIG_DEBUG_GPIO)+= -DDEBUG
 
 obj-$(CONFIG_GPIO_DEVRES)  += devres.o
 obj-$(CONFIG_GPIOLIB)  += gpiolib.o
+obj-$(CONFIG_GPIOLIB)  += gpiolib-legacy.o
 obj-$(CONFIG_OF_GPIO)  += gpiolib-of.o
 obj-$(CONFIG_GPIO_SYSFS)   += gpiolib-sysfs.o
 obj-$(CONFIG_GPIO_ACPI)+= gpiolib-acpi.o
diff --git a/drivers/gpio/gpiolib-legacy.c b/drivers/gpio/gpiolib-legacy.c
new file mode 100644
index ..66dfa68cc5ba
--- /dev/null
+++ b/drivers/gpio/gpiolib-legacy.c
@@ -0,0 +1,112 @@
+#include 
+#include 
+
+#include 
+
+#include "gpiolib.h"
+
+void gpio_free(unsigned gpio)
+{
+   gpiod_free(gpio_to_desc(gpio));
+}
+EXPORT_SYMBOL_GPL(gpio_free);
+
+/**
+ * gpio_request_one - request a single GPIO with initial configuration
+ * @gpio:  the GPIO number
+ * @flags: GPIO configuration as specified by GPIOF_*
+ * @label: a literal description string of this GPIO
+ */
+int gpio_request_one(unsigned gpio, unsigned long flags, const char *label)
+{
+   struct gpio_desc *desc;
+   int err;
+
+   desc = gpio_to_desc(gpio);
+
+   err = gpiod_request(desc, label);
+   if (err)
+   return err;
+
+   if (flags & GPIOF_OPEN_DRAIN)
+   set_bit(FLAG_OPEN_DRAIN, >flags);
+
+   if (flags & GPIOF_OPEN_SOURCE)
+   set_bit(FLAG_OPEN_SOURCE, >flags);
+
+   if (flags & GPIOF_DIR_IN)
+   err = gpiod_direction_input(desc);
+   else
+   err = gpiod_direction_output_raw(desc,
+   (flags & GPIOF_INIT_HIGH) ? 1 : 0);
+
+   if (err)
+   goto free_gpio;
+
+   if (flags & GPIOF_EXPORT) {
+   err = gpiod_export(desc, flags & GPIOF_EXPORT_CHANGEABLE);
+   if (err)
+   goto free_gpio;
+   }
+
+   return 0;
+
+ free_gpio:
+   gpiod_free(desc);
+   return err;
+}
+EXPORT_SYMBOL_GPL(gpio_request_one);
+
+int gpio_request(unsigned gpio, const char *label)
+{
+   return gpiod_request(gpio_to_desc(gpio), label);
+}
+EXPORT_SYMBOL_GPL(gpio_request);
+
+/**
+ * gpio_request_array - request multiple GPIOs in a single call
+ * @array: array of the 'struct gpio'
+ * @num:   how many GPIOs in the array
+ */
+int gpio_request_array(const struct gpio *array, size_t num)
+{
+   int i, err;
+
+   for (i = 0; i < num; i++, array++) {
+   err = gpio_request_one(array->gpio, array->flags, array->label);
+   if (err)
+   goto err_free;
+   }
+   return 0;
+
+err_free:
+   while (i--)
+   gpio_free((--array)->gpio);
+   return err;
+}
+EXPORT_SYMBOL_GPL(gpio_request_array);
+
+/**
+ * gpio_free_array - release multiple GPIOs in a single call
+ * @array: array of the 'struct gpio'
+ * @num:   how many GPIOs in the array
+ */
+void gpio_free_array(const struct gpio *array, size_t num)
+{
+   while (num--)
+   gpio_free((array++)->gpio);
+}
+EXPORT_SYMBOL_GPL(gpio_free_array);
+
+int gpio_lock_as_irq(struct gpio_chip *chip, unsigned int offset)
+{
+   return gpiod_lock_as_irq(gpiochip_get_desc(chip, offset));
+}
+EXPORT_SYMBOL_GPL(gpio_lock_as_irq);
+
+void gpio_unlock_as_irq(struct gpio_chip *chip, unsigned int offset)
+{
+   return gpiod_unlock_as_irq(gpiochip_get_desc(chip, offset));
+}
+EXPORT_SYMBOL_GPL(gpio_unlock_as_irq);
+
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 7b35e5093ef5..c5509359ba88 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -845,12 +845,6 @@ done:
return status;
 }
 
-int gpio_request(unsigned gpio, const char *label)
-{
-   return gpiod_request(gpio_to_desc(gpio), label);
-}
-EXPORT_SYMBOL_GPL(gpio_request);
-
 static bool __gpiod_free(struct gpio_desc *desc)
 {
boolret = false;
@@ -891,93 +885,6 @@ void gpiod_free(struct gpio_desc *desc)
WARN_ON(extra_checks);
 }
 
-void gpio_free(unsigned gpio)
-{
-   gpiod_free(gpio_to_desc(gpio));
-}
-EXPORT_SYMBOL_GPL(gpio_free);
-
-/**
- * gpio_request_one - request a single GPIO with initial configuration
- * @gpio:  the GPIO number
- * 

[RFC 2/3] gpio: move sysfs support to its own file

[Alexandre Courbot]

sysfs support is currently entangled within the core GPIO support, while
it should relly just be a (privileged) user of the integer GPIO API.
This patch is a first step towards making the gpiolib code more readable
by splitting it into logical parts.

Move all sysfs support to their own source file, and share static
members of gpiolib that need to be in the private gpiolib.h file. In
the future we will want to put some of them back into gpiolib.c, but this
first patch let us at least identify them.

Signed-off-by: Alexandre Courbot 
---
 drivers/gpio/Makefile|   1 +
 drivers/gpio/gpiolib-sysfs.c | 829 +++
 drivers/gpio/gpiolib.c   | 911 +--
 drivers/gpio/gpiolib.h   |  91 +
 4 files changed, 925 insertions(+), 907 deletions(-)
 create mode 100644 drivers/gpio/gpiolib-sysfs.c

diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index e18e9564b073..579be6fc5edb 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -5,6 +5,7 @@ ccflags-$(CONFIG_DEBUG_GPIO)+= -DDEBUG
 obj-$(CONFIG_GPIO_DEVRES)  += devres.o
 obj-$(CONFIG_GPIOLIB)  += gpiolib.o
 obj-$(CONFIG_OF_GPIO)  += gpiolib-of.o
+obj-$(CONFIG_GPIO_SYSFS)   += gpiolib-sysfs.o
 obj-$(CONFIG_GPIO_ACPI)+= gpiolib-acpi.o
 
 # Device drivers. Generally keep list sorted alphabetically
diff --git a/drivers/gpio/gpiolib-sysfs.c b/drivers/gpio/gpiolib-sysfs.c
new file mode 100644
index ..3516502059f2
--- /dev/null
+++ b/drivers/gpio/gpiolib-sysfs.c
@@ -0,0 +1,829 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "gpiolib.h"
+
+static DEFINE_IDR(dirent_idr);
+
+
+/* lock protects against unexport_gpio() being called while
+ * sysfs files are active.
+ */
+static DEFINE_MUTEX(sysfs_lock);
+
+/*
+ * /sys/class/gpio/gpioN... only for GPIOs that are exported
+ *   /direction
+ *  * MAY BE OMITTED if kernel won't allow direction changes
+ *  * is read/write as "in" or "out"
+ *  * may also be written as "high" or "low", initializing
+ *output value as specified ("out" implies "low")
+ *   /value
+ *  * always readable, subject to hardware behavior
+ *  * may be writable, as zero/nonzero
+ *   /edge
+ *  * configures behavior of poll(2) on /value
+ *  * available only if pin can generate IRQs on input
+ *  * is read/write as "none", "falling", "rising", or "both"
+ *   /active_low
+ *  * configures polarity of /value
+ *  * is read/write as zero/nonzero
+ *  * also affects existing and subsequent "falling" and "rising"
+ */edge configuration
+ */
+
+static ssize_t gpio_direction_show(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   const struct gpio_desc  *desc = dev_get_drvdata(dev);
+   ssize_t status;
+
+   mutex_lock(_lock);
+
+   if (!test_bit(FLAG_EXPORT, >flags)) {
+   status = -EIO;
+   } else {
+   gpiod_get_direction(desc);
+   status = sprintf(buf, "%s\n",
+   test_bit(FLAG_IS_OUT, >flags)
+   ? "out" : "in");
+   }
+
+   mutex_unlock(_lock);
+   return status;
+}
+
+static ssize_t gpio_direction_store(struct device *dev,
+   struct device_attribute *attr, const char *buf, size_t size)
+{
+   struct gpio_desc*desc = dev_get_drvdata(dev);
+   ssize_t status;
+
+   mutex_lock(_lock);
+
+   if (!test_bit(FLAG_EXPORT, >flags))
+   status = -EIO;
+   else if (sysfs_streq(buf, "high"))
+   status = gpiod_direction_output_raw(desc, 1);
+   else if (sysfs_streq(buf, "out") || sysfs_streq(buf, "low"))
+   status = gpiod_direction_output_raw(desc, 0);
+   else if (sysfs_streq(buf, "in"))
+   status = gpiod_direction_input(desc);
+   else
+   status = -EINVAL;
+
+   mutex_unlock(_lock);
+   return status ? : size;
+}
+
+static /* const */ DEVICE_ATTR(direction, 0644,
+   gpio_direction_show, gpio_direction_store);
+
+static ssize_t gpio_value_show(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   struct gpio_desc*desc = dev_get_drvdata(dev);
+   ssize_t status;
+
+   mutex_lock(_lock);
+
+   if (!test_bit(FLAG_EXPORT, >flags))
+   status = -EIO;
+   else
+   status = sprintf(buf, "%d\n", gpiod_get_value_cansleep(desc));
+
+   mutex_unlock(_lock);
+   return status;
+}
+
+static ssize_t gpio_value_store(struct device *dev,
+   struct device_attribute *attr, const char *buf, size_t size)
+{
+   struct gpio_desc*desc = dev_get_drvdata(dev);
+   ssize_t status;
+
+   mutex_lock(_lock);
+
+   if (!test_bit(FLAG_EXPORT, >flags))
+ 

linux-next: Tree for Jul 1

[Stephen Rothwell]

Hi all,

The powerpc allyesconfig is again broken more than usual.

Changes since 20140630:

My fixes tree contains:
powerpc: Disable RELOCATABLE for COMPILE_TEST with PPC64

The net-next tree lost its build failure.

The staging tree still had its build failure for which I disabled a driver.

Non-merge commits (relative to Linus' tree): 2945
 2734 files changed, 108975 insertions(+), 100427 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 222 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 (16874b2cb867 Merge tag 'ext4_for_linus_stable' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4)
Merging fixes/master (b8accbbce667 powerpc: Disable RELOCATABLE for 
COMPILE_TEST with PPC64)
Merging kbuild-current/rc-fixes (c14105628b2e kbuild: fix a typo in a kbuild 
document)
Merging arc-current/for-curr (89ca3b881987 Linux 3.15-rc4)
Merging arm-current/fixes (42309ab450b6 ARM: 8087/1: ptrace: reload syscall 
number after secure_computing() check)
Merging m68k-current/for-linus (e8d6dc5ad26e m68k/hp300: Convert printk to 
pr_foo())
Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX)
Merging powerpc-merge/merge (6663a4fa6711 powerpc: Don't skip ePAPR spin-table 
CPUs)
Merging sparc/master (894e552cfaa3 Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security)
Merging net/master (dba63115ce0c powerpc: bpf: Fix the broken 
LD_VLAN_TAG_PRESENT test)
Merging ipsec/master (a0e5ef53aac8 xfrm: Fix installation of AH IPsec SAs)
Merging sound-current/for-linus (a12137e779e1 ALSA: hda - Add a fixup for 
Thinkpad T540p)
Merging pci-current/for-linus (d066c946a866 PCI: Fix unaligned access in AF 
transaction pending test)
Merging wireless/master (e055a6e20a91 Merge branch 'ath-current' of 
git://github.com/kvalo/ath)
Merging driver-core.current/driver-core-linus (4c834452aad0 Linux 3.16-rc3)
Merging tty.current/tty-linus (a497c3ba1d97 Linux 3.16-rc2)
Merging usb.current/usb-linus (8ecd93ab84ce Merge tag 'usb-serial-3.16-rc3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus)
Merging usb-gadget-fixes/fixes (8035691365b8 usb: musb: dsps: fix the base 
address for accessing the mode register)
Merging usb-serial-fixes/usb-linus (660856948664 MAINTAINERS: update e-mail 
address)
Merging staging.current/staging-linus (6b64168de843 Merge tag 
'iio-fixes-for-3.16b' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus)
Merging char-misc.current/char-misc-linus (a497c3ba1d97 Linux 3.16-rc2)
Merging input-current/for-linus (31972f6e517d Input: ti_am335x_tsc - warn about 
incorrect spelling)
Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" 
stripe)
Merging crypto-current/master (cfe82d4f45c7 crypto: sha512_ssse3 - fix byte 
count to bit count conversion)
Merging ide/master (5b40dd30bbfa ide: Fix SC1200 dependencies)
Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff)
Merging devicetree-current/devicetree/merge (4b660a7f5c80 Linux 3.15-rc6)
Merging rr-fixes/fixes (79465d2fd48e module: remove warning about waiting 
module removal.)
Merging mfd-fixes/master (73beb63d290f mfd: rtsx_pcr: Disable interrupts before 
cancelling delayed works)
Merging vfio-fixes/for-linus (239a87020b26 Merge branch 
'for-joerg/arm-smmu/fixes' of 
git://git.kernel.org/pub/scm/linux/kernel

Re: [PATCH] sched: select 'idle' cfs_rq per task-group to prevent tg-internal imbalance

[Mike Galbraith]

On Tue, 2014-07-01 at 10:57 +0800, Michael wang wrote:

> IMHO, currently the generic scheduler just try to take care both latency
> and throughput, both will take a little damage but won't be damaged too
> much, they just sacrificed for each other...

The cost can be large, so it's worth an occasional ponder.

-Mike

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

one doubt about mmc_sdio_init_card function

[Fu, Zhonghui]

Hi, all

The mmc_sdio_init_card(drivers/mmc/core/sdio.c) function calls 
mmc_alloc_card(drivers/mmc/core/bus.c) function to allocate a card structure. 
card->dev.bus is assigned with mmc_bus_type in mmc_alloc_card function. Why not 
assign sdio_bus_type to card->dev.bus?


struct mmc_card *mmc_alloc_card(struct mmc_host *host, struct device_type *type)
{
struct mmc_card *card;

card = kzalloc(sizeof(struct mmc_card), GFP_KERNEL);
if (!card)
return ERR_PTR(-ENOMEM);

card->host = host;

device_initialize(>dev);

card->dev.parent = mmc_classdev(host);
card->dev.bus = _bus_type;
card->dev.release = mmc_release_card;
card->dev.type = type;

return card;
}


Thanks,
Zhonghui
--
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/6] regulator: palmas: cleanup and fixes

[Keerthy]

On Tuesday 01 July 2014 01:52 AM, Stephen Warren wrote:

On 06/30/2014 09:57 AM, Nishanth Menon wrote:

Hi,
Original thread (v1): http://marc.info/?t=14038076654=1=2
This series is based on: 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
branch: topic/palmas (4c0c9ca Merge remote-tracking branch 
'regulator/fix/palmas' into regulator-palmas)

This series does a few cleanups to help ensure we dont make typo mistakes and 
finally provides a fix as attempted by (v1).

Basic cpufreq tests performed on OMAP5uEVM, DRA7-evm, DRA72-evm all of which 
are palmas variants.

The patches are also available here: 
https://github.com/nmenon/linux-2.6-playground/commits/broonie-topic-palmas-fixes

The series,
Tested-by: Stephen Warren 

(An NVIDIA Dalmore board boots and shuts down OK with these applied on
top of next-20140630, and various peripherals such as LCD panel, audio,
USB, and SPI flash all work)

Tested the series on DRA72 board. Checked for all the regulator
and SMPS states and voltages of TPS65917 PMIC.

Tested-by: Keerthy 

Regards,
Keerthy

--
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] staging: gdm72xx: use consistent style for header guards

[Ben Chan]

Signed-off-by: Ben Chan 
---
I forgot to add the Signed-off-by stanza in the original patch.

 drivers/staging/gdm72xx/gdm_qos.h   | 6 +++---
 drivers/staging/gdm72xx/gdm_sdio.h  | 6 +++---
 drivers/staging/gdm72xx/gdm_usb.h   | 6 +++---
 drivers/staging/gdm72xx/gdm_wimax.h | 6 +++---
 drivers/staging/gdm72xx/hci.h   | 6 +++---
 drivers/staging/gdm72xx/netlink_k.h | 7 ---
 drivers/staging/gdm72xx/sdio_boot.h | 6 +++---
 drivers/staging/gdm72xx/usb_boot.h  | 6 +++---
 drivers/staging/gdm72xx/usb_ids.h   | 6 +++---
 drivers/staging/gdm72xx/wm_ioctl.h  | 7 ---
 10 files changed, 32 insertions(+), 30 deletions(-)

diff --git a/drivers/staging/gdm72xx/gdm_qos.h 
b/drivers/staging/gdm72xx/gdm_qos.h
index 8f742f3..bbc8aab 100644
--- a/drivers/staging/gdm72xx/gdm_qos.h
+++ b/drivers/staging/gdm72xx/gdm_qos.h
@@ -11,8 +11,8 @@
  * GNU General Public License for more details.
  */
 
-#if !defined(GDM_QOS_H_20090403)
-#define GDM_QOS_H_20090403
+#ifndef __GDM72XX_GDM_QOS_H__
+#define __GDM72XX_GDM_QOS_H__
 
 #include 
 #include 
@@ -71,4 +71,4 @@ void gdm_qos_release_list(void *nic_ptr);
 int gdm_qos_send_hci_pkt(struct sk_buff *skb, struct net_device *dev);
 void gdm_recv_qos_hci_packet(void *nic_ptr, u8 *buf, int size);
 
-#endif
+#endif /* __GDM72XX_GDM_QOS_H__ */
diff --git a/drivers/staging/gdm72xx/gdm_sdio.h 
b/drivers/staging/gdm72xx/gdm_sdio.h
index 0c0e2cb..77ad9d6 100644
--- a/drivers/staging/gdm72xx/gdm_sdio.h
+++ b/drivers/staging/gdm72xx/gdm_sdio.h
@@ -11,8 +11,8 @@
  * GNU General Public License for more details.
  */
 
-#ifndef __GDM_SDIO_H__
-#define __GDM_SDIO_H__
+#ifndef __GDM72XX_GDM_SDIO_H__
+#define __GDM72XX_GDM_SDIO_H__
 
 #include 
 #include 
@@ -60,4 +60,4 @@ struct sdiowm_dev {
struct work_struct  ws;
 };
 
-#endif /* __GDM_SDIO_H__ */
+#endif /* __GDM72XX_GDM_SDIO_H__ */
diff --git a/drivers/staging/gdm72xx/gdm_usb.h 
b/drivers/staging/gdm72xx/gdm_usb.h
index 3050652..8e58a25 100644
--- a/drivers/staging/gdm72xx/gdm_usb.h
+++ b/drivers/staging/gdm72xx/gdm_usb.h
@@ -11,8 +11,8 @@
  * GNU General Public License for more details.
  */
 
-#ifndef __GDM_USB_H__
-#define __GDM_USB_H__
+#ifndef __GDM72XX_GDM_USB_H__
+#define __GDM72XX_GDM_USB_H__
 
 #include 
 #include 
@@ -75,4 +75,4 @@ struct usbwm_dev {
int padding;
 };
 
-#endif /* __GDM_USB_H__ */
+#endif /* __GDM72XX_GDM_USB_H__ */
diff --git a/drivers/staging/gdm72xx/gdm_wimax.h 
b/drivers/staging/gdm72xx/gdm_wimax.h
index 7e2c888..c640d2c 100644
--- a/drivers/staging/gdm72xx/gdm_wimax.h
+++ b/drivers/staging/gdm72xx/gdm_wimax.h
@@ -11,8 +11,8 @@
  * GNU General Public License for more details.
  */
 
-#ifndef __GDM_WIMAX_H__
-#define __GDM_WIMAX_H__
+#ifndef __GDM72XX_GDM_WIMAX_H__
+#define __GDM72XX_GDM_WIMAX_H__
 
 #include 
 #include 
@@ -57,4 +57,4 @@ int register_wimax_device(struct phy_dev *phy_dev, struct 
device *pdev);
 int gdm_wimax_send_tx(struct sk_buff *skb, struct net_device *dev);
 void unregister_wimax_device(struct phy_dev *phy_dev);
 
-#endif
+#endif /* __GDM72XX_GDM_WIMAX_H__ */
diff --git a/drivers/staging/gdm72xx/hci.h b/drivers/staging/gdm72xx/hci.h
index 059ba00..ff6941e 100644
--- a/drivers/staging/gdm72xx/hci.h
+++ b/drivers/staging/gdm72xx/hci.h
@@ -11,8 +11,8 @@
  * GNU General Public License for more details.
  */
 
-#ifndef HCI_H_20080801
-#define HCI_H_20080801
+#ifndef __GDM72XX_HCI_H__
+#define __GDM72XX_HCI_H__
 
 #define HCI_HEADER_SIZE4
 #define HCI_VALUE_OFFS (HCI_HEADER_SIZE)
@@ -204,4 +204,4 @@ struct hci_s {
unsigned char  data[0];
 } __packed;
 
-#endif
+#endif /* __GDM72XX_HCI_H__ */
diff --git a/drivers/staging/gdm72xx/netlink_k.h 
b/drivers/staging/gdm72xx/netlink_k.h
index b6caac1..1fe7198 100644
--- a/drivers/staging/gdm72xx/netlink_k.h
+++ b/drivers/staging/gdm72xx/netlink_k.h
@@ -11,8 +11,9 @@
  * GNU General Public License for more details.
  */
 
-#if !defined(NETLINK_H_20081202)
-#define NETLINK_H_20081202
+#ifndef __GDM72XX_NETLINK_K_H__
+#define __GDM72XX_NETLINK_K_H__
+
 #include 
 #include 
 
@@ -21,4 +22,4 @@ struct sock *netlink_init(int unit, void (*cb)(struct 
net_device *dev, u16 type,
 void netlink_exit(struct sock *sock);
 int netlink_send(struct sock *sock, int group, u16 type, void *msg, int len);
 
-#endif
+#endif /* __GDM72XX_NETLINK_K_H__ */
diff --git a/drivers/staging/gdm72xx/sdio_boot.h 
b/drivers/staging/gdm72xx/sdio_boot.h
index 045c1f4..e0800c6 100644
--- a/drivers/staging/gdm72xx/sdio_boot.h
+++ b/drivers/staging/gdm72xx/sdio_boot.h
@@ -11,11 +11,11 @@
  * GNU General Public License for more details.
  */
 
-#ifndef __SDIO_BOOT_H__
-#define __SDIO_BOOT_H__
+#ifndef __GDM72XX_SDIO_BOOT_H__
+#define __GDM72XX_SDIO_BOOT_H__
 
 struct sdio_func;
 
 int sdio_boot(struct sdio_func *func);
 
-#endif /* __SDIO_BOOT_H__ */
+#endif /* __GDM72XX_SDIO_BOOT_H__ */
diff --git a/drivers/staging/gdm72xx/usb_boot.h 
b/drivers/staging/gdm72xx/usb_boot.h
index 05308e2..5bf7190 100644
--- 

Re: [BUILD BUG][3.16-rc3] Error: too many copied sections (max = 13)

[Andy Lutomirski]

On Mon, Jun 30, 2014 at 9:09 PM, Steven Rostedt  wrote:
> Testing the latest kernel (3.16-rc3) I hit this build bug:
>
>   VDSO2C  arch/x86/vdso/vdso-image-64.c
> Error: too many copied sections (max = 13)
> /arch/x86/vdso/Makefile:61: recipe for target 'arch/x86/vdso/vdso-image-64.c' 
> failed
> make[3]: *** [arch/x86/vdso/vdso-image-64.c] Error 1
> /scripts/Makefile.build:404: recipe for target 'arch/x86/vdso' failed
> make[2]: *** [arch/x86/vdso] Error 2

I clearly need to improve that error message.  Sigh.

>
> I bisected it down to this commit:
>
> commit 0e3727a8839c988a3c56170bc8da76d55a16acad
> Author: Andy Lutomirski 
> Date:   Wed Jun 18 15:59:49 2014 -0700
>
> x86/vdso: Remove some redundant in-memory section headers
>
> When I revert this commit, it compiles fine.

Weird.  Reverting that commit should be safe, but I'd like to
understand what's happening.

>
> I built my gcc and binutils from their sources unmodified:
>
> gcc 4.6.0
>
> binutils 2.21
>

I just successfully built your config, albeit with a different
toolchain.  Can you do:

for i in arch/x86/vdso/*.so.dbg; do echo $i; eu-readelf -S $i; done

after a failed build?

Let the game of section whack-a-mole begin.

Thanks,
Andy
--
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: gdm72xx: use consistent style for header guards

[Ben Chan]

---
 drivers/staging/gdm72xx/gdm_qos.h   | 6 +++---
 drivers/staging/gdm72xx/gdm_sdio.h  | 6 +++---
 drivers/staging/gdm72xx/gdm_usb.h   | 6 +++---
 drivers/staging/gdm72xx/gdm_wimax.h | 6 +++---
 drivers/staging/gdm72xx/hci.h   | 6 +++---
 drivers/staging/gdm72xx/netlink_k.h | 7 ---
 drivers/staging/gdm72xx/sdio_boot.h | 6 +++---
 drivers/staging/gdm72xx/usb_boot.h  | 6 +++---
 drivers/staging/gdm72xx/usb_ids.h   | 6 +++---
 drivers/staging/gdm72xx/wm_ioctl.h  | 7 ---
 10 files changed, 32 insertions(+), 30 deletions(-)

diff --git a/drivers/staging/gdm72xx/gdm_qos.h 
b/drivers/staging/gdm72xx/gdm_qos.h
index 8f742f3..bbc8aab 100644
--- a/drivers/staging/gdm72xx/gdm_qos.h
+++ b/drivers/staging/gdm72xx/gdm_qos.h
@@ -11,8 +11,8 @@
  * GNU General Public License for more details.
  */
 
-#if !defined(GDM_QOS_H_20090403)
-#define GDM_QOS_H_20090403
+#ifndef __GDM72XX_GDM_QOS_H__
+#define __GDM72XX_GDM_QOS_H__
 
 #include 
 #include 
@@ -71,4 +71,4 @@ void gdm_qos_release_list(void *nic_ptr);
 int gdm_qos_send_hci_pkt(struct sk_buff *skb, struct net_device *dev);
 void gdm_recv_qos_hci_packet(void *nic_ptr, u8 *buf, int size);
 
-#endif
+#endif /* __GDM72XX_GDM_QOS_H__ */
diff --git a/drivers/staging/gdm72xx/gdm_sdio.h 
b/drivers/staging/gdm72xx/gdm_sdio.h
index 0c0e2cb..77ad9d6 100644
--- a/drivers/staging/gdm72xx/gdm_sdio.h
+++ b/drivers/staging/gdm72xx/gdm_sdio.h
@@ -11,8 +11,8 @@
  * GNU General Public License for more details.
  */
 
-#ifndef __GDM_SDIO_H__
-#define __GDM_SDIO_H__
+#ifndef __GDM72XX_GDM_SDIO_H__
+#define __GDM72XX_GDM_SDIO_H__
 
 #include 
 #include 
@@ -60,4 +60,4 @@ struct sdiowm_dev {
struct work_struct  ws;
 };
 
-#endif /* __GDM_SDIO_H__ */
+#endif /* __GDM72XX_GDM_SDIO_H__ */
diff --git a/drivers/staging/gdm72xx/gdm_usb.h 
b/drivers/staging/gdm72xx/gdm_usb.h
index 3050652..8e58a25 100644
--- a/drivers/staging/gdm72xx/gdm_usb.h
+++ b/drivers/staging/gdm72xx/gdm_usb.h
@@ -11,8 +11,8 @@
  * GNU General Public License for more details.
  */
 
-#ifndef __GDM_USB_H__
-#define __GDM_USB_H__
+#ifndef __GDM72XX_GDM_USB_H__
+#define __GDM72XX_GDM_USB_H__
 
 #include 
 #include 
@@ -75,4 +75,4 @@ struct usbwm_dev {
int padding;
 };
 
-#endif /* __GDM_USB_H__ */
+#endif /* __GDM72XX_GDM_USB_H__ */
diff --git a/drivers/staging/gdm72xx/gdm_wimax.h 
b/drivers/staging/gdm72xx/gdm_wimax.h
index 7e2c888..c640d2c 100644
--- a/drivers/staging/gdm72xx/gdm_wimax.h
+++ b/drivers/staging/gdm72xx/gdm_wimax.h
@@ -11,8 +11,8 @@
  * GNU General Public License for more details.
  */
 
-#ifndef __GDM_WIMAX_H__
-#define __GDM_WIMAX_H__
+#ifndef __GDM72XX_GDM_WIMAX_H__
+#define __GDM72XX_GDM_WIMAX_H__
 
 #include 
 #include 
@@ -57,4 +57,4 @@ int register_wimax_device(struct phy_dev *phy_dev, struct 
device *pdev);
 int gdm_wimax_send_tx(struct sk_buff *skb, struct net_device *dev);
 void unregister_wimax_device(struct phy_dev *phy_dev);
 
-#endif
+#endif /* __GDM72XX_GDM_WIMAX_H__ */
diff --git a/drivers/staging/gdm72xx/hci.h b/drivers/staging/gdm72xx/hci.h
index 059ba00..ff6941e 100644
--- a/drivers/staging/gdm72xx/hci.h
+++ b/drivers/staging/gdm72xx/hci.h
@@ -11,8 +11,8 @@
  * GNU General Public License for more details.
  */
 
-#ifndef HCI_H_20080801
-#define HCI_H_20080801
+#ifndef __GDM72XX_HCI_H__
+#define __GDM72XX_HCI_H__
 
 #define HCI_HEADER_SIZE4
 #define HCI_VALUE_OFFS (HCI_HEADER_SIZE)
@@ -204,4 +204,4 @@ struct hci_s {
unsigned char  data[0];
 } __packed;
 
-#endif
+#endif /* __GDM72XX_HCI_H__ */
diff --git a/drivers/staging/gdm72xx/netlink_k.h 
b/drivers/staging/gdm72xx/netlink_k.h
index b6caac1..1fe7198 100644
--- a/drivers/staging/gdm72xx/netlink_k.h
+++ b/drivers/staging/gdm72xx/netlink_k.h
@@ -11,8 +11,9 @@
  * GNU General Public License for more details.
  */
 
-#if !defined(NETLINK_H_20081202)
-#define NETLINK_H_20081202
+#ifndef __GDM72XX_NETLINK_K_H__
+#define __GDM72XX_NETLINK_K_H__
+
 #include 
 #include 
 
@@ -21,4 +22,4 @@ struct sock *netlink_init(int unit, void (*cb)(struct 
net_device *dev, u16 type,
 void netlink_exit(struct sock *sock);
 int netlink_send(struct sock *sock, int group, u16 type, void *msg, int len);
 
-#endif
+#endif /* __GDM72XX_NETLINK_K_H__ */
diff --git a/drivers/staging/gdm72xx/sdio_boot.h 
b/drivers/staging/gdm72xx/sdio_boot.h
index 045c1f4..e0800c6 100644
--- a/drivers/staging/gdm72xx/sdio_boot.h
+++ b/drivers/staging/gdm72xx/sdio_boot.h
@@ -11,11 +11,11 @@
  * GNU General Public License for more details.
  */
 
-#ifndef __SDIO_BOOT_H__
-#define __SDIO_BOOT_H__
+#ifndef __GDM72XX_SDIO_BOOT_H__
+#define __GDM72XX_SDIO_BOOT_H__
 
 struct sdio_func;
 
 int sdio_boot(struct sdio_func *func);
 
-#endif /* __SDIO_BOOT_H__ */
+#endif /* __GDM72XX_SDIO_BOOT_H__ */
diff --git a/drivers/staging/gdm72xx/usb_boot.h 
b/drivers/staging/gdm72xx/usb_boot.h
index 05308e2..5bf7190 100644
--- a/drivers/staging/gdm72xx/usb_boot.h
+++ b/drivers/staging/gdm72xx/usb_boot.h
@@ -11,12 +11,12 @@
  * 

Re: [Patch v7 3/3] usb: dwc3: qcom: Add device tree binding

[Rob Herring]

On Mon, Jun 30, 2014 at 11:03 AM, Andy Gross  wrote:
> From: "Ivan T. Ivanov" 

Please copy the right lists and maintainers.

>
> QCOM USB3.0 core wrapper consist of USB3.0 IP from Synopsys
> (SNPS) and HS, SS PHY's control and configuration registers.
>
> It could operate in device mode (SS, HS, FS) and host
> mode (SS, HS, FS, LS).
>
> Signed-off-by: Ivan T. Ivanov 
> Signed-off-by: Andy Gross 
> ---
>  .../devicetree/bindings/usb/qcom,dwc3.txt  |  104 
> 
>  1 file changed, 104 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/usb/qcom,dwc3.txt
>
> diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.txt 
> b/Documentation/devicetree/bindings/usb/qcom,dwc3.txt
> new file mode 100644
> index 000..105b6b7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.txt
> @@ -0,0 +1,104 @@
> +Qualcomm SuperSpeed DWC3 USB SoC controller
> +
> +
> +QCOM DWC3 Highspeed USB PHY
> +
> +Required properities:
> +- compatible:  should contain "qcom,dwc3-hsphy";
> +- reg: offset and length of the register set in the memory 
> map
> +- clocks:  A list of phandle + clock-specifier pairs for the
> +   clocks listed in clock-names
> +- clock-names: Should contain the following:
> +  "utmi"   UTMI clock
> +- v1p8-supply: phandle to the regulator for the 1.8v supply to HSPHY.
> +- v3p3-supply: phandle to the regulator for the 3.3v supply to HSPHY.
> +- vbus-supply: phandle to the regulator for the vbus supply for host
> +   mode.
> +- vddcx-supply: phandle to the regulator for the vdd supply for HSPHY
> +digital circuit operation.
> +
> +Optional clocks:
> +  "xo" External reference clock
> +
> +
> +QCOM DWC3 Superspeed USB PHY
> +=
> +Required properities:
> +- compatible:  should contain "qcom,dwc3-ssphy";
> +- reg: offset and length of the register set in the memory 
> map
> +- clocks:  A list of phandle + clock-specifier pairs for the
> +   clocks listed in clock-names
> +- clock-names: Should contain the following:
> +  "ref"Reference clock used in host mode.
> +- v1p8-supply: phandle to the regulator for the 1.8v supply to HSPHY.
> +- vddcx-supply: phandle to the regulator for the vdd supply for HSPHY
> +digital circuit operation.
> +
> +Optional clocks:
> +  "xo" External reference clock
> +
> +QCOM DWC3 controller wrapper
> +===
> +Required properties:
> +- compatible:  should contain "qcom,dwc3"
> +- clocks:  A list of phandle + clock-specifier pairs for the
> +   clocks listed in clock-names
> +- clock-names: Should contain the following:
> +  "core"   Master/Core clock, have to be >= 125 MHz for SS
> +   operation and >= 60MHz for HS operation
> +
> +Optional clocks:
> +  "iface"  System bus AXI clock.  Not present on all platforms

Really?, some platforms have a clockless bus?

> +  "sleep"  Sleep clock, used when USB3 core goes into low
> +   power mode (U3).
> +
> +Optional regulator:
> +- gdsc-supply: phandle to the regulator from globally distributed
> +   switch controller

The name should reflect the name of the input, not the source.

> +
> +Required child node:
> +A child node must exist to represent the core DWC3 IP block. The name of
> +the node is not important. The content of the node is defined in dwc3.txt.
> +
> +Example device nodes:
> +
> +   hs_phy_0: phy@110f8800 {
> +   compatible = "qcom,dwc3-hsphy";
> +   reg = <0x110f8800 0x30>;
> +   clocks = < USB30_0_UTMI_CLK>;
> +   clock-names = "utmi";
> +
> +   status = "disabled";
> +   };
> +
> +   ss_phy_0: phy@110f8830 {
> +   compatible = "qcom,dwc3-ssphy";
> +   reg = <0x110f8830 0x30>;
> +
> +   clocks = < USB30_0_MASTER_CLK>;
> +   clock-names = "ref";
> +
> +   status = "disabled";
> +   };
> +
> +   usb3_0: usb30@0 {
> +   compatible = "qcom,dwc3";
> +   #address-cells = <1>;
> +   #size-cells = <1>;
> +   clocks = < USB30_0_MASTER_CLK>;
> +   clock-names = "core";
> +
> +   ranges;
> +
> +   status = "disabled";
> +
> +   dwc3@1100 {
> +   compatible = "snps,dwc3";

This sub-node is just wrong. Why can't you have a single node with '
"qcom,dwc3", "snps,dwc3" ' for the 

Re: [GIT PULL] USB fixes for v3.16-rc4

[Greg KH]

On Mon, Jun 30, 2014 at 01:40:35PM -0500, Felipe Balbi wrote:
> Hi Greg,
> 
> Here's my second set of fixes. Note the revert of the patch Michal
> asked to revert.
> 
> Please consider merging to your usb-linus branch. Let me know if you
> want any changes to this pull request.
> 
> cheers
> 
> 
> The following changes since commit 5d881802c407d83c169c875dad88fe2bba066c33:
> 
>   usb: musb: core: Handle Babble condition only in HOST mode (2014-06-19 
> 15:43:07 -0500)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
> tags/fixes-for-v3.16-rc4

Pulled and pushed out, 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/

[PATCH 1/1] staging: lustre: libcfs: nidstrings.c - use ARRAY_SIZE macro

[Anil Belur]

From: Anil Belur 

- this patch replaces sizeof(a)/sizeof(a[0]) with the ARRAY_SIZE macro
  to get the number of nidstrings

Signed-off-by: Anil Belur 
---
 drivers/staging/lustre/lustre/libcfs/nidstrings.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/lustre/lustre/libcfs/nidstrings.c 
b/drivers/staging/lustre/lustre/libcfs/nidstrings.c
index 87705ae..13a2791 100644
--- a/drivers/staging/lustre/lustre/libcfs/nidstrings.c
+++ b/drivers/staging/lustre/lustre/libcfs/nidstrings.c
@@ -74,8 +74,7 @@ libcfs_next_nidstring(void)
spin_lock_irqsave(_nidstring_lock, flags);
 
str = libcfs_nidstrings[libcfs_nidstring_idx++];
-   if (libcfs_nidstring_idx ==
-   sizeof(libcfs_nidstrings)/sizeof(libcfs_nidstrings[0]))
+   if (libcfs_nidstring_idx == ARRAY_SIZE(libcfs_nidstrings))
libcfs_nidstring_idx = 0;
 
spin_unlock_irqrestore(_nidstring_lock, flags);
-- 
1.9.1

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

RE: [RESEND PATCH] memory: Freescale CoreNet Coherency Fabric error reporting driver

[bharat.bhus...@freescale.com]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, July 01, 2014 2:30 AM
> To: Bhushan Bharat-R65777
> Cc: Greg Kroah-Hartman; linuxppc-...@lists.ozlabs.org; linux-
> ker...@vger.kernel.org
> Subject: Re: [RESEND PATCH] memory: Freescale CoreNet Coherency Fabric error
> reporting driver
> 
> On Sun, 2014-06-29 at 23:58 -0500, Bhushan Bharat-R65777 wrote:
> >
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Wednesday, June 04, 2014 10:38 PM
> > > To: Bhushan Bharat-R65777
> > > Cc: Greg Kroah-Hartman; linuxppc-...@lists.ozlabs.org; linux-
> > > ker...@vger.kernel.org
> > > Subject: Re: [RESEND PATCH] memory: Freescale CoreNet Coherency
> > > Fabric error reporting driver
> > >
> > > On Wed, 2014-06-04 at 12:04 -0500, Bhushan Bharat-R65777 wrote:
> > > >
> > > > > -Original Message-
> > > > > From: Wood Scott-B07421
> > > > > Sent: Wednesday, June 04, 2014 10:12 PM
> > > > > To: Bhushan Bharat-R65777
> > > > > Cc: Greg Kroah-Hartman; linuxppc-...@lists.ozlabs.org; linux-
> > > > > ker...@vger.kernel.org
> > > > > Subject: Re: [RESEND PATCH] memory: Freescale CoreNet Coherency
> > > > > Fabric error reporting driver
> > > > >
> > > > > On Wed, 2014-06-04 at 03:17 -0500, Bhushan Bharat-R65777 wrote:
> > > > > > > +static int ccf_remove(struct platform_device *pdev) {
> > > > > > > + struct ccf_private *ccf = dev_get_drvdata(>dev);
> > > > > > > +
> > > > > > > + switch (ccf->info->version) {
> > > > > > > + case CCF1:
> > > > > > > + iowrite32be(0, >err_regs->errdis);
> > > > > > > + break;
> > > > > > > +
> > > > > > > + case CCF2:
> > > > > > > + iowrite32be(0, >err_regs->errinten);
> > > > > >
> > > > > > Do you think it is same to disable detection bits in
> > > > > > ccf->err_regs-
> > > >errdis?
> > > > >
> > > > > Disabling the interrupt is what we're aiming for here, but ccf1
> > > > > doesn't provide a way to do that separate from disabling detection.
> > > >
> > > > What I wanted to say that do we also need to disable detection
> > > > (set ERRDET_LAE | ERRDET_CV bits in errdis) apart from clearing
> > > > errinten on
> > > > ccf2 ?
> > >
> > > I don't think we "need" to.  You could argue that we should for
> > > consistency, though I think there's value in errors continuing to be
> > > detected even without the driver (e.g. can dump the registers in a
> debugger).
> >
> > Yes this comment was for consistency. Also IIUC, the state which is left 
> > when
> the driver is removed is not default reset behavior.
> 
> How many drivers leave the hardware in pristine reset state when exiting?

I do not know :)

>  And
> you could argue that having detection off by default is poor hardware design
> (enabling interrupts is another matter of course).

Ok, then can you please add a comment in _remove() function describing why 
detection is still enabled.

Thanks
-Bharat

> 
> > If we want errors to be detected then should not we have a sysfs interface?
> 
> That may be useful but it's beyond the scope of what I'm doing with this 
> patch.
> We currently don't log machine checks anywhere but via printk either.
> 
> BTW, I thought I had sent v2 of this, but I don't see it anywhere...
> I'll respin soon.
> 
> -Scott
> 

N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

[PATCH V2] powerpc/powernv: Check for IRQHAPPENED before sleeping

[Preeti U Murthy]

Commit 8d6f7c5a: "powerpc/powernv: Make it possible to skip the IRQHAPPENED
check in power7_nap()" added code that prevents cpus from checking for pending
interrupts just before entering sleep state, which is wrong. A cpu cannot enter
any idle state with pending interrupts.

Possible consequences of a cpu entering an idle state without checking for 
pending
interrupts could be a device timeout or a more serious consequence in case of
Power8 would be if doorbell IPIs are delivered when cpus have interrupts soft
disabled. Precisely the state that the cpus are in just before entering an
idle state on PowerPC.

Interrupts delivered during soft disabled state are replayed when the interrupts
are enabled again. Hence since a cpu goes to sleep with interrupts enabled
again, it will receive any pending interrupts. However doorbell IPIs are not
replayed even when the interrupts are re-enabled since they are edge 
triggered.Hence
not checking for pending interrupts just before going to sleep state would mean
that we will never take the doorbell IPI if it was delivered during the soft
disabled state, unless some other interrupt wakes us up.This could result in the
cpu that sent the doorbell IPI complaining that the sleeping cpu is stuck.

This patch fixes these issues by ensuring that cpus check for pending interrupts
just before entering any idle state as long as they are not in the path of split
core operations.

Signed-off-by: Preeti U Murthy 
Acked-by: Michael Neuling 
---
Changes from V1: Modified the changelog to add the details of the problem
that this patch fixes.

 arch/powerpc/kernel/idle_power7.S |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/idle_power7.S 
b/arch/powerpc/kernel/idle_power7.S
index 2480256..5cf3d36 100644
--- a/arch/powerpc/kernel/idle_power7.S
+++ b/arch/powerpc/kernel/idle_power7.S
@@ -131,7 +131,7 @@ _GLOBAL(power7_nap)
 
 _GLOBAL(power7_sleep)
li  r3,1
-   li  r4,0
+   li  r4,1
b   power7_powersave_common
/* No return */
 

--
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: Add TMU dt node to monitor the temperature for Exynos3250

[Sachin Kamat]

Hi Chanwoo,

On Tue, Jul 1, 2014 at 9:34 AM, Chanwoo Choi  wrote:
> Hi Sachin,
>
> On 07/01/2014 12:33 PM, Sachin Kamat wrote:
>> Hi Chanwoo,
>>
>> On Tue, Jul 1, 2014 at 6:10 AM, Chanwoo Choi  wrote:
>>> This patch add TMU (Thermal Management Unit) dt node to monitor the high
>>> temperature for Exynos3250.
>>>
>>> Signed-off-by: Chanwoo Choi 
>>> Acked-by: Kyungmin Park 
>>> ---
>>> This patch has a dependency on following patch [1]:
>>>  [1] https://lkml.org/lkml/2014/6/30/805
>>>
>>>  arch/arm/boot/dts/exynos3250.dtsi | 10 ++
>>>  1 file changed, 10 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
>>> b/arch/arm/boot/dts/exynos3250.dtsi
>>> index 3660cab..1e566af 100644
>>> --- a/arch/arm/boot/dts/exynos3250.dtsi
>>> +++ b/arch/arm/boot/dts/exynos3250.dtsi
>>> @@ -192,6 +192,16 @@
>>> status = "disabled";
>>> };
>>>
>>> +   tmu: tmu@100C {
>>> +   compatible = "samsung,exynos3250-tmu";
>>> +   interrupt-parent = <>;
>>> +   reg = <0x100C 0x100>;
>>> +   interrupts = <0 216 0>;
>>> +   clocks = < CLK_TMU_APBIF>;
>>> +   clock-names = "tmu_apbif";
>>> +   status = "disabled";
>>
>> I don't think there would be any board specific properties needed. Hence
>> leave the status as enabled (by deleting the above line).
>>
>
> I think that if specific board need TMU feature, dts file for specific board
> should include tmu dt node with 'okay' status. The specific board based on
> Exynos3250 might not need TMU feature.

The status field in DT node is not meant for stating the build configuration but
represents the readiness of the hardware for usage on the platform. If
a particular
board does not need this feature it needs to be disabled in the build
config and only
for any special requirements disable it in board file.


-- 
Regards,
Sachin.
--
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 3.15.3

[Greg KH]

I'm announcing the release of the 3.15.3 kernel.

All users of the 3.15 kernel series must upgrade.

The updated 3.15.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-3.15.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Documentation/vm/hwpoison.txt|5 
 Makefile |2 
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |2 
 arch/arm/kernel/stacktrace.c |   18 +
 arch/arm/mach-omap1/board-h2.c   |2 
 arch/arm/mach-omap1/board-h3.c   |2 
 arch/arm/mach-omap1/board-innovator.c|2 
 arch/arm/mach-omap1/board-osk.c  |2 
 arch/arm/mach-omap2/gpmc-nand.c  |2 
 arch/arm/mm/hugetlbpage.c|5 
 arch/arm/mm/proc-v7-3level.S |   18 +
 arch/arm64/include/asm/Kbuild|1 
 arch/arm64/include/asm/dma-mapping.h |2 
 arch/arm64/include/asm/pgtable.h |2 
 arch/arm64/include/uapi/asm/posix_types.h|   10 
 arch/arm64/kernel/ptrace.c   |   32 ++-
 arch/arm64/mm/hugetlbpage.c  |5 
 arch/ia64/hp/common/sba_iommu.c  |   64 +++---
 arch/ia64/mm/hugetlbpage.c   |5 
 arch/metag/mm/hugetlbpage.c  |5 
 arch/mips/mm/hugetlbpage.c   |5 
 arch/powerpc/mm/hugetlbpage.c|   10 
 arch/s390/include/asm/lowcore.h  |   11 -
 arch/s390/kernel/time.c  |2 
 arch/s390/mm/hugetlbpage.c   |5 
 arch/sh/mm/hugetlbpage.c |5 
 arch/sparc/mm/hugetlbpage.c  |5 
 arch/tile/mm/hugetlbpage.c   |5 
 arch/x86/Kconfig |4 
 arch/x86/kernel/entry_32.S   |   15 -
 arch/x86/mm/hugetlbpage.c|   10 
 arch/x86/syscalls/syscall_64.tbl |6 
 drivers/acpi/acpica/utstring.c   |2 
 drivers/acpi/bus.c   |7 
 drivers/acpi/utils.c |   64 --
 drivers/base/power/opp.c |4 
 drivers/block/virtio_blk.c   |9 
 drivers/block/zram/zram_drv.c|4 
 drivers/bluetooth/hci_ldisc.c|   24 +-
 drivers/bluetooth/hci_uart.h |1 
 drivers/char/applicom.c  |1 
 drivers/char/random.c|   17 -
 drivers/extcon/extcon-max14577.c |9 
 drivers/extcon/extcon-max77693.c |4 
 drivers/extcon/extcon-max8997.c  |2 
 drivers/firmware/efi/efi-pstore.c|2 
 drivers/gpu/drm/radeon/radeon_pm.c   |3 
 drivers/gpu/drm/radeon/radeon_uvd.c  |3 
 drivers/hid/hid-core.c   |   12 +
 drivers/infiniband/ulp/iser/iser_initiator.c |   34 ---
 drivers/infiniband/ulp/isert/ib_isert.c  |   70 +++---
 drivers/infiniband/ulp/isert/ib_isert.h  |2 
 drivers/media/pci/ivtv/ivtv-alsa-pcm.c   |6 
 drivers/media/pci/saa7134/saa7134-video.c|9 
 drivers/media/platform/exynos4-is/fimc-is.c  |3 
 drivers/media/platform/exynos4-is/media-dev.c|2 
 drivers/media/platform/exynos4-is/media-dev.h|4 
 drivers/media/usb/stk1160/stk1160-core.c |   10 
 drivers/media/usb/stk1160/stk1160.h  |1 
 drivers/media/usb/uvc/uvc_video.c|   15 -
 drivers/pci/hotplug/acpiphp.h|   10 
 drivers/pci/hotplug/acpiphp_glue.c   |   60 +++--
 drivers/phy/phy-exynos-mipi-video.c  |2 
 drivers/regulator/s2mpa01.c  |   15 -
 drivers/regulator/s2mps11.c  |   15 -
 drivers/scsi/libiscsi.c  |   18 -
 drivers/staging/imx-drm/imx-hdmi.c   |9 
 drivers/staging/media/bcm2048/radio-bcm2048.c|2 
 drivers/staging/mt29f_spinand/mt29f_spinand.c|1 
 drivers/staging/rtl8188eu/core/rtw_wlan_util.c   |7 
 drivers/staging/tidspbridge/core/dsp-clock.c |4 
 drivers/target/iscsi/iscsi_target.c  |   17 +
 drivers/target/loopback/tcm_loop.c   |   15 +
 drivers/target/target_core_sbc.c |   19 +
 drivers/target/target_core_spc.c |9 
 drivers/target/target_core_transport.c   |   29 ++
 drivers/tty/serial/of_serial.c   |1 
 drivers/usb/dwc3/gadget.c|4 
 

Re: [PATCH] ARM: dts: Add TMU dt node to monitor the temperature for Exynos3250

[Chanwoo Choi]

Hi Sachin,

On 07/01/2014 12:33 PM, Sachin Kamat wrote:
> Hi Chanwoo,
> 
> On Tue, Jul 1, 2014 at 6:10 AM, Chanwoo Choi  wrote:
>> This patch add TMU (Thermal Management Unit) dt node to monitor the high
>> temperature for Exynos3250.
>>
>> Signed-off-by: Chanwoo Choi 
>> Acked-by: Kyungmin Park 
>> ---
>> This patch has a dependency on following patch [1]:
>>  [1] https://lkml.org/lkml/2014/6/30/805
>>
>>  arch/arm/boot/dts/exynos3250.dtsi | 10 ++
>>  1 file changed, 10 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
>> b/arch/arm/boot/dts/exynos3250.dtsi
>> index 3660cab..1e566af 100644
>> --- a/arch/arm/boot/dts/exynos3250.dtsi
>> +++ b/arch/arm/boot/dts/exynos3250.dtsi
>> @@ -192,6 +192,16 @@
>> status = "disabled";
>> };
>>
>> +   tmu: tmu@100C {
>> +   compatible = "samsung,exynos3250-tmu";
>> +   interrupt-parent = <>;
>> +   reg = <0x100C 0x100>;
>> +   interrupts = <0 216 0>;
>> +   clocks = < CLK_TMU_APBIF>;
>> +   clock-names = "tmu_apbif";
>> +   status = "disabled";
> 
> I don't think there would be any board specific properties needed. Hence
> leave the status as enabled (by deleting the above line).
> 

I think that if specific board need TMU feature, dts file for specific board
should include tmu dt node with 'okay' status. The specific board based on
Exynos3250 might not need TMU feature.

Best Regards,
Chanwoo Choi


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

[Greg KH]

I'm announcing the release of the 3.14.10 kernel.

All users of the 3.14 kernel series must upgrade.

The updated 3.14.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-3.14.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Documentation/vm/hwpoison.txt|5 
 Makefile |2 
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |2 
 arch/arm/kernel/stacktrace.c |   18 +
 arch/arm/mach-omap1/board-h2.c   |2 
 arch/arm/mach-omap1/board-h3.c   |2 
 arch/arm/mach-omap1/board-innovator.c|2 
 arch/arm/mach-omap1/board-osk.c  |2 
 arch/arm/mm/hugetlbpage.c|5 
 arch/arm/mm/proc-v7-3level.S |   18 +
 arch/arm64/include/asm/dma-mapping.h |2 
 arch/arm64/kernel/ptrace.c   |   32 ++-
 arch/arm64/mm/hugetlbpage.c  |5 
 arch/ia64/mm/hugetlbpage.c   |5 
 arch/metag/mm/hugetlbpage.c  |5 
 arch/mips/mm/hugetlbpage.c   |5 
 arch/powerpc/mm/hugetlbpage.c|   10 
 arch/s390/include/asm/lowcore.h  |   11 -
 arch/s390/kernel/time.c  |2 
 arch/s390/mm/hugetlbpage.c   |5 
 arch/sh/mm/hugetlbpage.c |5 
 arch/sparc/mm/hugetlbpage.c  |5 
 arch/tile/mm/hugetlbpage.c   |5 
 arch/x86/Kconfig |4 
 arch/x86/kernel/entry_32.S   |   15 -
 arch/x86/mm/hugetlbpage.c|   10 
 arch/x86/syscalls/syscall_64.tbl |6 
 drivers/acpi/acpica/utstring.c   |2 
 drivers/acpi/bus.c   |7 
 drivers/acpi/utils.c |   64 --
 drivers/base/power/opp.c |4 
 drivers/bluetooth/hci_ldisc.c|   24 +-
 drivers/bluetooth/hci_uart.h |1 
 drivers/char/applicom.c  |1 
 drivers/extcon/extcon-max14577.c |9 
 drivers/extcon/extcon-max77693.c |4 
 drivers/extcon/extcon-max8997.c  |2 
 drivers/firmware/efi/efi-pstore.c|2 
 drivers/hid/hid-core.c   |   12 +
 drivers/infiniband/ulp/isert/ib_isert.c  |   61 ++---
 drivers/infiniband/ulp/isert/ib_isert.h  |2 
 drivers/media/pci/ivtv/ivtv-alsa-pcm.c   |6 
 drivers/media/pci/saa7134/saa7134-video.c|9 
 drivers/media/usb/stk1160/stk1160-core.c |   10 
 drivers/media/usb/stk1160/stk1160.h  |1 
 drivers/media/usb/uvc/uvc_video.c|   15 -
 drivers/net/can/sja1000/peak_pci.c   |   14 -
 drivers/net/ethernet/ti/cpsw.c   |   16 -
 drivers/phy/phy-exynos-mipi-video.c  |2 
 drivers/scsi/scsi_error.c|9 
 drivers/staging/media/bcm2048/radio-bcm2048.c|2 
 drivers/staging/mt29f_spinand/mt29f_spinand.c|1 
 drivers/staging/rtl8188eu/core/rtw_wlan_util.c   |7 
 drivers/staging/tidspbridge/core/dsp-clock.c |4 
 drivers/target/iscsi/iscsi_target.c  |   17 +
 drivers/target/target_core_rd.c  |2 
 drivers/target/target_core_sbc.c |4 
 drivers/target/target_core_spc.c |9 
 drivers/target/target_core_transport.c   |   29 ++
 drivers/usb/dwc3/gadget.c|4 
 drivers/usb/gadget/inode.c   |2 
 drivers/usb/host/pci-quirks.c|   19 +
 drivers/usb/misc/usbtest.c   |   26 ++
 drivers/usb/phy/phy-isp1301-omap.c   |2 
 drivers/usb/serial/bus.c |   14 +
 drivers/usb/serial/option.c  |   11 -
 drivers/usb/serial/qcserial.c|   21 +
 drivers/usb/serial/sierra.c  |   55 -
 drivers/usb/serial/usb_wwan.c|  125 ++-
 drivers/video/matrox/matroxfb_base.h |2 
 fs/aio.c |6 
 fs/btrfs/backref.c   |   37 ++-
 fs/btrfs/backref.h   |4 
 fs/btrfs/ctree.h |8 
 fs/btrfs/disk-io.c   |5 
 fs/btrfs/extent-tree.c   |   49 +++-
 fs/btrfs/extent_io.c |5 
 fs/btrfs/free-space-cache.c  |4 

Re: Linux 3.4.96

[Greg KH]

diff --git a/Makefile b/Makefile
index fda1dab589be..e4ecdedbfe27 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 3
 PATCHLEVEL = 4
-SUBLEVEL = 95
+SUBLEVEL = 96
 EXTRAVERSION =
 NAME = Saber-toothed Squirrel
 
diff --git a/arch/arm/kernel/stacktrace.c b/arch/arm/kernel/stacktrace.c
index af4e8c8a5422..6582c4adc182 100644
--- a/arch/arm/kernel/stacktrace.c
+++ b/arch/arm/kernel/stacktrace.c
@@ -83,13 +83,16 @@ static int save_trace(struct stackframe *frame, void *d)
return trace->nr_entries >= trace->max_entries;
 }
 
-void save_stack_trace_tsk(struct task_struct *tsk, struct stack_trace *trace)
+/* This must be noinline to so that our skip calculation works correctly */
+static noinline void __save_stack_trace(struct task_struct *tsk,
+   struct stack_trace *trace, unsigned int nosched)
 {
struct stack_trace_data data;
struct stackframe frame;
 
data.trace = trace;
data.skip = trace->skip;
+   data.no_sched_functions = nosched;
 
if (tsk != current) {
 #ifdef CONFIG_SMP
@@ -102,7 +105,6 @@ void save_stack_trace_tsk(struct task_struct *tsk, struct 
stack_trace *trace)
trace->entries[trace->nr_entries++] = ULONG_MAX;
return;
 #else
-   data.no_sched_functions = 1;
frame.fp = thread_saved_fp(tsk);
frame.sp = thread_saved_sp(tsk);
frame.lr = 0;   /* recovered from the stack */
@@ -111,11 +113,12 @@ void save_stack_trace_tsk(struct task_struct *tsk, struct 
stack_trace *trace)
} else {
register unsigned long current_sp asm ("sp");
 
-   data.no_sched_functions = 0;
+   /* We don't want this function nor the caller */
+   data.skip += 2;
frame.fp = (unsigned long)__builtin_frame_address(0);
frame.sp = current_sp;
frame.lr = (unsigned long)__builtin_return_address(0);
-   frame.pc = (unsigned long)save_stack_trace_tsk;
+   frame.pc = (unsigned long)__save_stack_trace;
}
 
walk_stackframe(, save_trace, );
@@ -123,9 +126,14 @@ void save_stack_trace_tsk(struct task_struct *tsk, struct 
stack_trace *trace)
trace->entries[trace->nr_entries++] = ULONG_MAX;
 }
 
+void save_stack_trace_tsk(struct task_struct *tsk, struct stack_trace *trace)
+{
+   __save_stack_trace(tsk, trace, 1);
+}
+
 void save_stack_trace(struct stack_trace *trace)
 {
-   save_stack_trace_tsk(current, trace);
+   __save_stack_trace(current, trace, 0);
 }
 EXPORT_SYMBOL_GPL(save_stack_trace);
 #endif
diff --git a/arch/s390/include/asm/lowcore.h b/arch/s390/include/asm/lowcore.h
index 47853debb3b9..025415e7346a 100644
--- a/arch/s390/include/asm/lowcore.h
+++ b/arch/s390/include/asm/lowcore.h
@@ -142,9 +142,9 @@ struct _lowcore {
__u8pad_0x02fc[0x0300-0x02fc];  /* 0x02fc */
 
/* Interrupt response block */
-   __u8irb[64];/* 0x0300 */
+   __u8irb[96];/* 0x0300 */
 
-   __u8pad_0x0340[0x0e00-0x0340];  /* 0x0340 */
+   __u8pad_0x0360[0x0e00-0x0360];  /* 0x0360 */
 
/*
 * 0xe00 contains the address of the IPL Parameter Information
@@ -288,12 +288,13 @@ struct _lowcore {
__u8pad_0x03a0[0x0400-0x03a0];  /* 0x03a0 */
 
/* Interrupt response block. */
-   __u8irb[64];/* 0x0400 */
+   __u8irb[96];/* 0x0400 */
+   __u8pad_0x0460[0x0480-0x0460];  /* 0x0460 */
 
/* Per cpu primary space access list */
-   __u32   paste[16];  /* 0x0440 */
+   __u32   paste[16];  /* 0x0480 */
 
-   __u8pad_0x0480[0x0e00-0x0480];  /* 0x0480 */
+   __u8pad_0x04c0[0x0e00-0x04c0];  /* 0x04c0 */
 
/*
 * 0xe00 contains the address of the IPL Parameter Information
diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
index 2af4ccd88d16..e1e7f9c831da 100644
--- a/arch/x86/kernel/entry_32.S
+++ b/arch/x86/kernel/entry_32.S
@@ -426,9 +426,10 @@ sysenter_past_esp:
jnz sysenter_audit
 sysenter_do_call:
cmpl $(NR_syscalls), %eax
-   jae syscall_badsys
+   jae sysenter_badsys
call *sys_call_table(,%eax,4)
movl %eax,PT_EAX(%esp)
+sysenter_after_call:
LOCKDEP_SYS_EXIT
DISABLE_INTERRUPTS(CLBR_ANY)
TRACE_IRQS_OFF
@@ -550,11 +551,6 @@ ENTRY(iret_exc)
 
CFI_RESTORE_STATE
 ldt_ss:
-   larl PT_OLDSS(%esp), %eax
-   jnz restore_nocheck
-   testl $0x0040, %eax # returning to 32bit stack?
-   jnz restore_nocheck # allright, normal return
-
 #ifdef CONFIG_PARAVIRT
/*
 * The kernel can't run on a non-flat stack if paravirt mode
@@ -683,7 +679,12 @@ END(syscall_fault)
 
 syscall_badsys:
movl 

Linux 3.10.46

[Greg KH]

I'm announcing the release of the 3.10.46 kernel.

All users of the 3.10 kernel series must upgrade.

The updated 3.10.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-3.10.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile |2 
 arch/arm/kernel/stacktrace.c |   18 ++-
 arch/arm/mach-omap1/board-h2.c   |2 
 arch/arm/mach-omap1/board-h3.c   |2 
 arch/arm/mach-omap1/board-innovator.c|2 
 arch/arm/mach-omap1/board-osk.c  |2 
 arch/arm/mm/proc-v7-3level.S |   18 ++-
 arch/arm64/kernel/ptrace.c   |4 
 arch/s390/include/asm/lowcore.h  |   11 +-
 arch/x86/kernel/entry_32.S   |   15 +--
 arch/x86/syscalls/syscall_64.tbl |6 -
 drivers/acpi/acpica/utstring.c   |2 
 drivers/acpi/bus.c   |7 +
 drivers/bluetooth/hci_ldisc.c|   24 -
 drivers/bluetooth/hci_uart.h |1 
 drivers/char/applicom.c  |1 
 drivers/extcon/extcon-max8997.c  |2 
 drivers/hid/hid-core.c   |   12 ++
 drivers/infiniband/ulp/isert/ib_isert.c  |   59 ++--
 drivers/infiniband/ulp/isert/ib_isert.h  |2 
 drivers/media/pci/ivtv/ivtv-alsa-pcm.c   |6 +
 drivers/media/usb/stk1160/stk1160-core.c |   10 +-
 drivers/media/usb/stk1160/stk1160.h  |1 
 drivers/media/usb/uvc/uvc_video.c|   15 ++-
 drivers/net/can/sja1000/peak_pci.c   |   14 +--
 drivers/net/ethernet/ti/cpsw.c   |4 
 drivers/staging/tidspbridge/core/dsp-clock.c |4 
 drivers/target/iscsi/iscsi_target.c  |3 
 drivers/target/iscsi/iscsi_target_login.c|7 -
 drivers/target/target_core_rd.c  |2 
 drivers/target/target_core_sbc.c |4 
 drivers/target/target_core_spc.c |9 +
 drivers/target/target_core_transport.c   |   29 +-
 drivers/usb/dwc3/gadget.c|4 
 drivers/usb/gadget/inode.c   |2 
 drivers/usb/host/pci-quirks.c|   19 +++-
 drivers/usb/misc/usbtest.c   |   40 +++-
 drivers/usb/phy/phy-isp1301-omap.c   |2 
 drivers/usb/serial/bus.c |   14 ++-
 drivers/usb/serial/option.c  |   11 ++
 drivers/usb/serial/qcserial.c|   21 
 drivers/usb/serial/sierra.c  |   55 +--
 drivers/usb/serial/usb_wwan.c|  125 ++-
 drivers/video/matrox/matroxfb_base.h |2 
 fs/aio.c |6 -
 fs/btrfs/backref.c   |   32 --
 fs/btrfs/backref.h   |4 
 fs/btrfs/disk-io.c   |5 +
 fs/btrfs/extent_io.c |5 -
 fs/btrfs/free-space-cache.c  |4 
 fs/btrfs/scrub.c |5 -
 fs/btrfs/send.c  |4 
 fs/btrfs/volumes.c   |   32 +-
 fs/ext4/mballoc.c|2 
 fs/ext4/page-io.c|   24 ++---
 include/linux/irqdesc.h  |4 
 include/linux/ptrace.h   |   32 ++
 include/target/target_core_backend.h |1 
 kernel/fork.c|   10 +-
 kernel/irq/manage.c  |4 
 kernel/irq/spurious.c|  106 ++
 lib/idr.c|8 -
 mm/memory-failure.c  |   25 +++--
 mm/rmap.c|8 +
 mm/vmscan.c  |   46 -
 net/bluetooth/l2cap_sock.c   |5 -
 net/core/skbuff.c|2 
 net/iucv/af_iucv.c   |2 
 68 files changed, 709 insertions(+), 262 deletions(-)

Alan Stern (2):
  USB: usbtest: add a timeout for scatter-gather tests
  USB: EHCI: avoid BIOS handover on the HASEE E200

Aleksander Morgado (2):
  usb: qcserial: add Netgear AirCard 341U
  usb: qcserial: add additional Sierra Wireless QMI devices

Andy Lutomirski (1):
  x86_32, entry: Do syscall exit work on badsys (CVE-2014-4508)

Benjamin LaHaise (2):
  aio: fix aio request leak when events are reaped by userspace
  aio: fix kernel memory disclosure in io_getevents() introduced in v3.10

Chris Mason (1):
  Btrfs: fix double free in find_lock_delalloc_range

Christian Borntraeger (1):
  s390/lowcore: reserve 96 bytes for IRB in 

Linux 3.4.96

[Greg KH]

I'm announcing the release of the 3.4.96 kernel.

All users of the 3.4 kernel series must upgrade.

The updated 3.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-3.4.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile |2 
 arch/arm/kernel/stacktrace.c |   18 ++-
 arch/s390/include/asm/lowcore.h  |   11 +-
 arch/x86/kernel/entry_32.S   |   15 +--
 arch/x86/syscalls/syscall_64.tbl |6 -
 drivers/acpi/bus.c   |7 +
 drivers/char/applicom.c  |1 
 drivers/hid/hid-core.c   |   12 ++
 drivers/net/can/sja1000/peak_pci.c   |   14 +--
 drivers/staging/tidspbridge/core/dsp-clock.c |4 
 drivers/target/target_core_rd.c  |2 
 drivers/usb/dwc3/gadget.c|4 
 drivers/usb/gadget/inode.c   |2 
 drivers/usb/host/pci-quirks.c|   19 +++-
 drivers/usb/misc/usbtest.c   |   40 +++-
 drivers/usb/serial/option.c  |   15 ++-
 drivers/usb/serial/sierra.c  |   54 +--
 drivers/usb/serial/usb_wwan.c|  123 ++-
 drivers/video/matrox/matroxfb_base.h |2 
 fs/btrfs/backref.c   |2 
 fs/btrfs/extent_io.c |3 
 fs/btrfs/volumes.c   |5 -
 fs/ext4/mballoc.c|2 
 include/linux/irqdesc.h  |4 
 include/linux/skbuff.h   |   16 +++
 kernel/irq/manage.c  |4 
 kernel/irq/spurious.c|  106 ++-
 mm/memory-failure.c  |   25 +++--
 mm/rmap.c|8 +
 mm/vmscan.c  |3 
 net/core/skbuff.c|5 -
 31 files changed, 399 insertions(+), 135 deletions(-)

Alan Stern (2):
  USB: usbtest: add a timeout for scatter-gather tests
  USB: EHCI: avoid BIOS handover on the HASEE E200

Andy Lutomirski (1):
  x86_32, entry: Do syscall exit work on badsys (CVE-2014-4508)

Chris Mason (1):
  Btrfs: fix double free in find_lock_delalloc_range

Christian Borntraeger (1):
  s390/lowcore: reserve 96 bytes for IRB in lowcore

Dan Carpenter (1):
  applicom: dereferencing NULL on error path

Eric Sandeen (1):
  btrfs: fix use of uninit "ret" in end_extent_writepage()

Felipe Balbi (1):
  usb: dwc3: gadget: clear stall when disabling endpoint

Greg Kroah-Hartman (1):
  Linux 3.4.96

H. Peter Anvin (1):
  x86-32, espfix: Remove filter for espfix32 due to race

Huang Rui (1):
  usb: usbtest: fix unlink write error with pattern 1

Hugh Dickins (1):
  mm: fix sleeping function warning from __put_anon_vma

Johan Hovold (10):
  USB: option: fix runtime PM handling
  USB: usb_wwan: fix write and suspend race
  USB: usb_wwan: fix urb leak at shutdown
  USB: usb_wwan: fix potential NULL-deref at resume
  USB: usb_wwan: fix potential blocked I/O after resume
  USB: sierra: fix AA deadlock in open error path
  USB: sierra: fix use after free at suspend/resume
  USB: sierra: fix urb and memory leak in resume error path
  USB: sierra: fix urb and memory leak on disconnect
  USB: sierra: fix remote wakeup

Johannes Weiner (1):
  mm: vmscan: clear kswapd's special reclaim powers before exiting

Kees Cook (1):
  HID: core: fix validation of report id 0

Liu Bo (1):
  Btrfs: use right type to get real comparison

Lv Zheng (1):
  ACPI: Fix conflict between customized DSDT and DSDT local copy

Maurizio Lombardi (1):
  ext4: fix wrong assert in ext4_mb_normalize_request()

Michael S. Tsirkin (3):
  skbuff: add an api to orphan frags
  skbuff: export skb_copy_ubufs
  skbuff: skb_segment: orphan frags before copying

Mike Frysinger (1):
  x86, x32: Use compat shims for io_{setup,submit}

Mikulas Patocka (1):
  matroxfb: perform a dummy read of M_STATUS

Nicholas A. Bellinger (1):
  target: Explicitly clear ramdisk_mcp backend pages

Paul Bolle (2):
  staging: tidspbridge: check for CONFIG_SND_OMAP_SOC_MCBSP
  usb: gadget: rename CONFIG_USB_GADGET_PXA25X

Rickard Strandqvist (1):
  fs: btrfs: volumes.c: Fix for possible null pointer dereference

Roger Quadros (1):
  usb: usbtest: Add timetout to simple_io()

Russell King (1):
  ARM: stacktrace: avoid listing stacktrace functions in stacktrace

Stephane Grosjean (1):
  can: peak_pci: prevent use after free at netdev removal

Thomas Gleixner (1):
  genirq: Sanitize spurious interrupt 

Re: [PATCH] firmware loader: inform direct failure when udev loader is disabled

[Ming Lei]

On Tue, Jul 1, 2014 at 7:30 AM, Luis R. Rodriguez
 wrote:
> From: "Luis R. Rodriguez" 
>
> Now that the udev firmware loader is optional request_firmware()
> will not provide any information on the kernel ring buffer if
> direct firmware loading failed and udev firmware loading is disabled.
> If no information is needed request_firmware_direct() should be used
> for optional firmware, at which point drivers can take on the onus
> over informing of any failures, if udev firmware loading is disabled
> though we should at the very least provide some sort of information
> as when the udev loader was enabled by default back in the days.
>
> With this change with a simple firmware load test module [0]:
>
> Example output without FW_LOADER_USER_HELPER_FALLBACK
>
> platform fake-dev.0: Direct firmware load for fake.bin failed with error -2
>
> Example without FW_LOADER_USER_HELPER_FALLBACK
>
> platform fake-dev.0: Direct firmware load for fake.bin failed with error -2
> platform fake-dev.0: Falling back to user helper
>
> Without this change without FW_LOADER_USER_HELPER_FALLBACK we get no output
> logged upon failure.
>
> [0] https://github.com/mcgrof/fake-firmware-test.git
>
> Cc: Tom Gundersen 
> Cc: Ming Lei 
> Cc: Greg Kroah-Hartman 
> Cc: Abhay Salunke 
> Cc: Stefan Roese 
> Cc: Arnd Bergmann 
> Cc: Kay Sievers 
> Cc: Takashi Iwai 
> Signed-off-by: Luis R. Rodriguez 
> ---
>
>  drivers/base/firmware_class.c | 12 
>  1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
> index 46ea5f4..23274d8 100644
> --- a/drivers/base/firmware_class.c
> +++ b/drivers/base/firmware_class.c
> @@ -101,8 +101,10 @@ static inline long firmware_loading_timeout(void)
>  #define FW_OPT_NOWAIT  (1U << 1)
>  #ifdef CONFIG_FW_LOADER_USER_HELPER
>  #define FW_OPT_USERHELPER  (1U << 2)
> +#define FW_OPT_FAIL_WARN   0
>  #else
>  #define FW_OPT_USERHELPER  0
> +#define FW_OPT_FAIL_WARN   (1U << 3)
>  #endif
>  #ifdef CONFIG_FW_LOADER_USER_HELPER_FALLBACK
>  #define FW_OPT_FALLBACKFW_OPT_USERHELPER
> @@ -1116,10 +1118,11 @@ _request_firmware(const struct firmware **firmware_p, 
> const char *name,
>
> ret = fw_get_filesystem_firmware(device, fw->priv);
> if (ret) {
> -   if (opt_flags & FW_OPT_USERHELPER) {
> +   if (opt_flags & (FW_OPT_FAIL_WARN | FW_OPT_USERHELPER))
> dev_warn(device,
> -"Direct firmware load failed with error 
> %d\n",
> -ret);
> +"Direct firmware load for %s failed with 
> error %d\n",
> +name, ret);

Maybe the warning can be always printed out since
(FW_OPT_FAIL_WARN | FW_OPT_USERHELPER) should be
always true.


Thanks,
--
Ming Lei
--
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: Add TMU dt node to monitor the temperature for Exynos3250

[Sachin Kamat]

Hi Chanwoo,

On Tue, Jul 1, 2014 at 6:10 AM, Chanwoo Choi  wrote:
> This patch add TMU (Thermal Management Unit) dt node to monitor the high
> temperature for Exynos3250.
>
> Signed-off-by: Chanwoo Choi 
> Acked-by: Kyungmin Park 
> ---
> This patch has a dependency on following patch [1]:
>  [1] https://lkml.org/lkml/2014/6/30/805
>
>  arch/arm/boot/dts/exynos3250.dtsi | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
> b/arch/arm/boot/dts/exynos3250.dtsi
> index 3660cab..1e566af 100644
> --- a/arch/arm/boot/dts/exynos3250.dtsi
> +++ b/arch/arm/boot/dts/exynos3250.dtsi
> @@ -192,6 +192,16 @@
> status = "disabled";
> };
>
> +   tmu: tmu@100C {
> +   compatible = "samsung,exynos3250-tmu";
> +   interrupt-parent = <>;
> +   reg = <0x100C 0x100>;
> +   interrupts = <0 216 0>;
> +   clocks = < CLK_TMU_APBIF>;
> +   clock-names = "tmu_apbif";
> +   status = "disabled";

I don't think there would be any board specific properties needed. Hence
leave the status as enabled (by deleting the above line).

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

[PATCH 1/2] ASoC: sirf: Add audio usp interface driver

[Rongjun Ying]

This patch adds ASoC support for SiRF SoCs USP interface.
Features include:
1. Only support slave mode.
2. Support I2S and DSP_A mode.
3. Support S16_LE, S24_LE and S24_3LE formats.
4. Support stereo and mono mode.
5. The biggest Support is 192Khz sample rate.

Signed-off-by: Rongjun Ying 
---
 sound/soc/sirf/Kconfig|   6 +
 sound/soc/sirf/Makefile   |   2 +
 sound/soc/sirf/sirf-usp.c | 409 ++
 sound/soc/sirf/sirf-usp.h | 293 +
 4 files changed, 710 insertions(+)
 create mode 100644 sound/soc/sirf/sirf-usp.c
 create mode 100644 sound/soc/sirf/sirf-usp.h

diff --git a/sound/soc/sirf/Kconfig b/sound/soc/sirf/Kconfig
index 89e8942..840058d 100644
--- a/sound/soc/sirf/Kconfig
+++ b/sound/soc/sirf/Kconfig
@@ -12,3 +12,9 @@ config SND_SOC_SIRF_AUDIO
 config SND_SOC_SIRF_AUDIO_PORT
select REGMAP_MMIO
tristate
+
+config SND_SOC_SIRF_USP
+   tristate "SoC Audio (I2S protocol) for SiRF SoC USP interface"
+   depends on SND_SOC_SIRF
+   select REGMAP_MMIO
+   tristate
diff --git a/sound/soc/sirf/Makefile b/sound/soc/sirf/Makefile
index 913b932..dd917f2 100644
--- a/sound/soc/sirf/Makefile
+++ b/sound/soc/sirf/Makefile
@@ -1,5 +1,7 @@
 snd-soc-sirf-audio-objs := sirf-audio.o
 snd-soc-sirf-audio-port-objs := sirf-audio-port.o
+snd-soc-sirf-usp-objs := sirf-usp.o
 
 obj-$(CONFIG_SND_SOC_SIRF_AUDIO) += snd-soc-sirf-audio.o
 obj-$(CONFIG_SND_SOC_SIRF_AUDIO_PORT) += snd-soc-sirf-audio-port.o
+obj-$(CONFIG_SND_SOC_SIRF_USP) += snd-soc-sirf-usp.o
diff --git a/sound/soc/sirf/sirf-usp.c b/sound/soc/sirf/sirf-usp.c
new file mode 100644
index 000..fe2a2f9
--- /dev/null
+++ b/sound/soc/sirf/sirf-usp.c
@@ -0,0 +1,409 @@
+/*
+ * SiRF USP in I2S/DSP mode
+ *
+ * Copyright (c) 2011 Cambridge Silicon Radio Limited, a CSR plc group company.
+ *
+ * Licensed under GPLv2 or later.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "sirf-usp.h"
+
+struct sirf_usp {
+   struct regmap *regmap;
+   struct clk *clk;
+   u32 mode1_reg;
+   u32 mode2_reg;
+   int daifmt_format;
+   struct snd_dmaengine_dai_dma_data playback_dma_data;
+   struct snd_dmaengine_dai_dma_data capture_dma_data;
+};
+
+static void sirf_usp_tx_enable(struct sirf_usp *usp)
+{
+   regmap_update_bits(usp->regmap, USP_TX_FIFO_OP,
+   USP_TX_FIFO_RESET, USP_TX_FIFO_RESET);
+   regmap_write(usp->regmap, USP_TX_FIFO_OP, 0);
+
+   regmap_update_bits(usp->regmap, USP_TX_FIFO_OP,
+   USP_TX_FIFO_START, USP_TX_FIFO_START);
+
+   regmap_update_bits(usp->regmap, USP_TX_RX_ENABLE,
+   USP_TX_ENA, USP_TX_ENA);
+}
+
+static void sirf_usp_tx_disable(struct sirf_usp *usp)
+{
+   regmap_update_bits(usp->regmap, USP_TX_RX_ENABLE,
+   USP_TX_ENA, ~USP_TX_ENA);
+   /* FIFO stop */
+   regmap_write(usp->regmap, USP_TX_FIFO_OP, 0);
+}
+
+static void sirf_usp_rx_enable(struct sirf_usp *usp)
+{
+   regmap_update_bits(usp->regmap, USP_RX_FIFO_OP,
+   USP_RX_FIFO_RESET, USP_RX_FIFO_RESET);
+   regmap_write(usp->regmap, USP_RX_FIFO_OP, 0);
+
+   regmap_update_bits(usp->regmap, USP_RX_FIFO_OP,
+   USP_RX_FIFO_START, USP_RX_FIFO_START);
+
+   regmap_update_bits(usp->regmap, USP_TX_RX_ENABLE,
+   USP_RX_ENA, USP_RX_ENA);
+}
+
+static void sirf_usp_rx_disable(struct sirf_usp *usp)
+{
+   regmap_update_bits(usp->regmap, USP_TX_RX_ENABLE,
+   USP_RX_ENA, ~USP_RX_ENA);
+   /* FIFO stop */
+   regmap_write(usp->regmap, USP_RX_FIFO_OP, 0);
+}
+
+static int sirf_usp_pcm_dai_probe(struct snd_soc_dai *dai)
+{
+   struct sirf_usp *usp = snd_soc_dai_get_drvdata(dai);
+   snd_soc_dai_init_dma_data(dai, >playback_dma_data,
+   >capture_dma_data);
+   return 0;
+}
+
+static int sirf_usp_pcm_set_dai_fmt(struct snd_soc_dai *dai,
+   unsigned int fmt)
+{
+   struct sirf_usp *usp = snd_soc_dai_get_drvdata(dai);
+
+   /* set master/slave audio interface */
+   switch (fmt & SND_SOC_DAIFMT_MASTER_MASK) {
+   case SND_SOC_DAIFMT_CBM_CFM:
+   break;
+   default:
+   dev_err(dai->dev, "Only CBM and CFM supported\n");
+   return -EINVAL;
+   }
+
+   switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) {
+   case SND_SOC_DAIFMT_I2S:
+   case SND_SOC_DAIFMT_DSP_A:
+   usp->daifmt_format = (fmt & SND_SOC_DAIFMT_FORMAT_MASK);
+   break;
+   default:
+   dev_err(dai->dev, "Only I2S and DSP_A format supported\n");
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+static int sirf_usp_i2s_startup(struct snd_pcm_substream *substream,
+   struct snd_soc_dai *dai)
+{
+   struct sirf_usp *usp = snd_soc_dai_get_drvdata(dai);
+
+   /* Configure RISC mode */
+   regmap_update_bits(usp->regmap, 

[PATCH 0/2] ASoC: add CSR SiRFSoC audio USP interface driver

[Rongjun Ying]

This patchset adds the SiRF USP controller driver, this
driver uses the USP as I2S or DSP_A mode interface.

Rongjun Ying (2):
  ASoC: sirf: Add audio usp interface driver
  ASoC: sirf: Add device tree binding for the USP audio device

 .../devicetree/bindings/sound/sirf-usp.txt |  27 ++
 sound/soc/sirf/Kconfig |   6 +
 sound/soc/sirf/Makefile|   2 +
 sound/soc/sirf/sirf-usp.c  | 409 +
 sound/soc/sirf/sirf-usp.h  | 293 +++
 5 files changed, 737 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/sirf-usp.txt
 create mode 100644 sound/soc/sirf/sirf-usp.c
 create mode 100644 sound/soc/sirf/sirf-usp.h

-- 
1.9.3



Member of the CSR plc group of companies. CSR plc registered in England and 
Wales, registered number 4187346, registered office Churchill House, Cambridge 
Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Keep up to date with CSR on our 
technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people, YouTube, 
www.youtube.com/user/CSRplc, Facebook, 
www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at 
www.twitter.com/CSR_plc.
New for 2014, you can now access the wide range of products powered by aptX at 
www.aptx.com.
--
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] powerpc/powernv: Check for IRQHAPPENED before sleeping

[Michael Neuling]

On Tue, 2014-07-01 at 10:52 +1000, Michael Ellerman wrote:
> On Mon, 2014-06-30 at 11:54 +0530, Preeti U Murthy wrote:
> > Commit 8d6f7c5a: "powerpc/powernv: Make it possible to skip the IRQHAPPENED
> > check in power7_nap()" added code that prevents even cores which enter sleep
> > on idle, from checking for pending interrupts. Fix this.
> 
> To be clear, it is a bug in the original commit. Mikey and I pair programmed
> that code, and he was *definitely* typing at that point ;)

It's always nice to know that in battle a comrade will throw himself on
a grenade to save you. :-P

Actually, I'm pretty sure this happened when you were away (probably on
a beach somewhere), I was forward porting the patch set, hit a conflict
and fucked it up.  

Mikey

> 
> Can you please include in the changelog what the symptom of the bug is, and
> have you seen it in practice?
> 
> The bad commit went into 3.16-rc1, so we don't need to backport this to any
> stable release.
> 
> cheers
> 
> > diff --git a/arch/powerpc/kernel/idle_power7.S 
> > b/arch/powerpc/kernel/idle_power7.S
> > index 2480256..5cf3d36 100644
> > --- a/arch/powerpc/kernel/idle_power7.S
> > +++ b/arch/powerpc/kernel/idle_power7.S
> > @@ -131,7 +131,7 @@ _GLOBAL(power7_nap)
> >  
> >  _GLOBAL(power7_sleep)
> > li  r3,1
> > -   li  r4,0
> > +   li  r4,1
> > b   power7_powersave_common
> > /* No return */
> >  
> > 
> 
> 
> 
> 
> 

--
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] ASoC: sirf: Add device tree binding for the USP audio device

[Rongjun Ying]

Signed-off-by: Rongjun Ying 
---
 .../devicetree/bindings/sound/sirf-usp.txt | 27 ++
 1 file changed, 27 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/sirf-usp.txt

diff --git a/Documentation/devicetree/bindings/sound/sirf-usp.txt 
b/Documentation/devicetree/bindings/sound/sirf-usp.txt
new file mode 100644
index 000..02f85b3
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/sirf-usp.txt
@@ -0,0 +1,27 @@
+* SiRF SoC USP module
+
+Required properties:
+- compatible: "sirf,prima2-usp-pcm"
+- reg: Base address and size entries:
+- dmas: List of DMA controller phandle and DMA request line ordered pairs.
+- dma-names: Identifier string for each DMA request line in the dmas property.
+  These strings correspond 1:1 with the ordered pairs in dmas.
+
+  One of the DMA channels will be responsible for transmission (should be
+  named "tx") and one for reception (should be named "rx").
+
+- clocks: USP controller clock source
+- pinctrl-names: Must contain a "default" entry.
+- pinctrl-NNN: One property must exist for each entry in pinctrl-names.
+
+Example:
+usp0: usp@b008 {
+   compatible = "sirf,prima2-usp-pcm";
+   reg = <0xb008 0x1>;
+   clocks = < 28>;
+   dmas = < 1>, < 2>;
+   dma-names = "rx", "tx";
+   pinctrl-names = "default";
+   pinctrl-0 = <_only_utfs_pins_a>;
+};
+
-- 
1.9.3



Member of the CSR plc group of companies. CSR plc registered in England and 
Wales, registered number 4187346, registered office Churchill House, Cambridge 
Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Keep up to date with CSR on our 
technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people, YouTube, 
www.youtube.com/user/CSRplc, Facebook, 
www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at 
www.twitter.com/CSR_plc.
New for 2014, you can now access the wide range of products powered by aptX at 
www.aptx.com.
--
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] Deletes arch/arm/mach-gemini/idle.c

[Nick Krause]

This is only one patch please disregard patch 1/2.
Cheers Nick

On Mon, Jun 30, 2014 at 11:11 PM, Nicholas Krause  wrote:
> This patch deletes the above file in order to remove the function
> in this file that may cause races. In addition this function is
> no longer needed due to commit 8182a34d85698 fixing this issue.
> Therefore gemmi_idle is no longer needed and due to in being the
> only function in this file I am removing it.
>
> Signed-off-by: Nicholas Krause 
> ---
>  arch/arm/mach-gemini/idle.c | 30 --
>  1 file changed, 30 deletions(-)
>  delete mode 100644 arch/arm/mach-gemini/idle.c
>
> diff --git a/arch/arm/mach-gemini/idle.c b/arch/arm/mach-gemini/idle.c
> deleted file mode 100644
> index 2880f5a..000
> --- a/arch/arm/mach-gemini/idle.c
> +++ /dev/null
> @@ -1,30 +0,0 @@
> -/*
> - * arch/arm/mach-gemini/idle.c
> - */
> -
> -#include 
> -#include 
> -#include 
> -
> -static void gemini_idle(void)
> -{
> -   /*
> -* Because of broken hardware we have to enable interrupts or the CPU
> -* will never wakeup... Acctualy it is not very good to enable
> -* interrupts first since scheduler can miss a tick, but there is
> -* no other way around this. Platforms that needs it for power saving
> -* should enable it in init code, since by default it is
> -* disabled.
> -*/
> -
> -   local_irq_disable();
> -   cpu_do_idle();
> -}
> -
> -static int __init gemini_idle_init(void)
> -{
> -   arm_pm_idle = gemini_idle;
> -   return 0;
> -}
> -
> -arch_initcall(gemini_idle_init);
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] Deletes arch/arm/mach-gemini/idle.c

[Nicholas Krause]

This patch deletes the above file in order to remove the function
in this file that may cause races. In addition this function is
no longer needed due to commit 8182a34d85698 fixing this issue.
Therefore gemmi_idle is no longer needed and due to in being the
only function in this file I am removing it.

Signed-off-by: Nicholas Krause 
---
 arch/arm/mach-gemini/idle.c | 30 --
 1 file changed, 30 deletions(-)
 delete mode 100644 arch/arm/mach-gemini/idle.c

diff --git a/arch/arm/mach-gemini/idle.c b/arch/arm/mach-gemini/idle.c
deleted file mode 100644
index 2880f5a..000
--- a/arch/arm/mach-gemini/idle.c
+++ /dev/null
@@ -1,30 +0,0 @@
-/*
- * arch/arm/mach-gemini/idle.c
- */
-
-#include 
-#include 
-#include 
-
-static void gemini_idle(void)
-{
-   /*
-* Because of broken hardware we have to enable interrupts or the CPU
-* will never wakeup... Acctualy it is not very good to enable
-* interrupts first since scheduler can miss a tick, but there is
-* no other way around this. Platforms that needs it for power saving
-* should enable it in init code, since by default it is
-* disabled.
-*/
-
-   local_irq_disable();
-   cpu_do_idle();
-}
-
-static int __init gemini_idle_init(void)
-{
-   arm_pm_idle = gemini_idle;
-   return 0;
-}
-
-arch_initcall(gemini_idle_init);
-- 
1.9.1

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

[PATCH] Remove memory start and memory end

[Nicholas Krause]

This patch removes the uneeded variables memory start and memory
stated in FIXME message before declaring this variables as extern
unsigned longs.

Signed-off-by: Nicholas Krause 
---
 arch/avr32/include/asm/page.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/avr32/include/asm/page.h b/arch/avr32/include/asm/page.h
index f805d1c..16ac83a 100644
--- a/arch/avr32/include/asm/page.h
+++ b/arch/avr32/include/asm/page.h
@@ -42,9 +42,6 @@ typedef struct page *pgtable_t;
 #define __pgd(x)   ((pgd_t) { (x) })
 #define __pgprot(x)((pgprot_t) { (x) })
 
-/* FIXME: These should be removed soon */
-extern unsigned long memory_start, memory_end;
-
 /* Pure 2^n version of get_order */
 static inline int get_order(unsigned long size)
 {
-- 
1.9.1

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

Re: Filesystem lockup with CONFIG_PREEMPT_RT

[Austin Schuh]

On Fri, Jun 27, 2014 at 7:24 AM, Thomas Gleixner  wrote:
> Completely untested patch below.

By chance, I found this in my boot logs.  I'll do some more startup
testing tomorrow.

Jun 30 19:54:40 vpc5 kernel: [0.670955] [ cut here ]
Jun 30 19:54:40 vpc5 kernel: [0.670962] WARNING: CPU: 0 PID: 4 at
kernel/workqueue.c:1604 worker_enter_idle+0x65/0x16b()
Jun 30 19:54:40 vpc5 kernel: [0.670970] Modules linked in:
Jun 30 19:54:40 vpc5 kernel: [0.670973] CPU: 0 PID: 4 Comm:
kworker/0:0 Not tainted 3.14.3-rt4abs+ #8
Jun 30 19:54:40 vpc5 kernel: [0.670974] Hardware name: CompuLab
Intense-PC/Intense-PC, BIOS CR_2.2.0.377 X64 04/10/2013
Jun 30 19:54:40 vpc5 kernel: [0.670983]  0009
88040ce75de8 81510faf 0002
Jun 30 19:54:40 vpc5 kernel: [0.670985]  
88040ce75e28 81042085 0001
Jun 30 19:54:40 vpc5 kernel: [0.670987]  81057a60
88042d406900 88042da63fc0 88042da64030
Jun 30 19:54:40 vpc5 kernel: [0.670988] Call Trace:
Jun 30 19:54:40 vpc5 kernel: [0.670995]  []
dump_stack+0x4f/0x7c
Jun 30 19:54:40 vpc5 kernel: [0.670999]  []
warn_slowpath_common+0x81/0x9c
Jun 30 19:54:40 vpc5 kernel: [0.671002]  [] ?
worker_enter_idle+0x65/0x16b
Jun 30 19:54:40 vpc5 kernel: [0.671005]  []
warn_slowpath_null+0x1a/0x1c
Jun 30 19:54:40 vpc5 kernel: [0.671007]  []
worker_enter_idle+0x65/0x16b
Jun 30 19:54:40 vpc5 kernel: [0.671010]  []
worker_thread+0x1b3/0x22b
Jun 30 19:54:40 vpc5 kernel: [0.671013]  [] ?
rescuer_thread+0x293/0x293
Jun 30 19:54:40 vpc5 kernel: [0.671015]  [] ?
rescuer_thread+0x293/0x293
Jun 30 19:54:40 vpc5 kernel: [0.671018]  []
kthread+0xdc/0xe4
Jun 30 19:54:40 vpc5 kernel: [0.671022]  [] ?
flush_kthread_worker+0xe1/0xe1
Jun 30 19:54:40 vpc5 kernel: [0.671025]  []
ret_from_fork+0x7c/0xb0
Jun 30 19:54:40 vpc5 kernel: [0.671027]  [] ?
flush_kthread_worker+0xe1/0xe1
Jun 30 19:54:40 vpc5 kernel: [0.671029] ---[ end trace 0001 ]---
--
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/2] block: virtio-blk: support multi vq per virtio-blk

[Jens Axboe]

On 2014-06-30 19:36, Ming Lei wrote:

Hi Jens and Rusty,

On Thu, Jun 26, 2014 at 8:04 PM, Ming Lei  wrote:

On Thu, Jun 26, 2014 at 5:41 PM, Ming Lei  wrote:

Hi,

These patches try to support multi virtual queues(multi-vq) in one
virtio-blk device, and maps each virtual queue(vq) to blk-mq's
hardware queue.

With this approach, both scalability and performance on virtio-blk
device can get improved.

For verifying the improvement, I implements virtio-blk multi-vq over
qemu's dataplane feature, and both handling host notification
from each vq and processing host I/O are still kept in the per-device
iothread context, the change is based on qemu v2.0.0 release, and
can be accessed from below tree:

 git://kernel.ubuntu.com/ming/qemu.git #v2.0.0-virtblk-mq.1

For enabling the multi-vq feature, 'num_queues=N' need to be added into
'-device virtio-blk-pci ...' of qemu command line, and suggest to pass
'vectors=N+1' to keep one MSI irq vector per each vq, and the feature
depends on x-data-plane.

Fio(libaio, randread, iodepth=64, bs=4K, jobs=N) is run inside VM to
verify the improvement.

I just create a small quadcore VM and run fio inside the VM, and
num_queues of the virtio-blk device is set as 2, but looks the
improvement is still obvious. The host is 2 sockets, 8cores(16threads)
server.

1), about scalability
- jobs = 2, thoughput: +33%
- jobs = 4, thoughput: +100%

2), about top thoughput: +39%

So in my test, even for a quad-core VM, if the virtqueue number
is increased from 1 to 2, both scalability and performance can
get improved a lot.

In above qemu implementation of virtio-blk-mq device, only one
IOthread handles requests from all vqs, and the above throughput
data has been very close to same fio test in host side with single
job. So more improvement should be observed once more IOthreads are
used for handling requests from multi vqs.

TODO:
 - adjust vq's irq smp_affinity according to blk-mq hw queue's cpumask

V3:
 - fix use-after-free on vq->name reported by Michael

V2: (suggestions from Michael and Dave Chinner)
 - allocate virtqueues' pointers dynamically
 - make sure the per-queue spinlock isn't kept in same cache line
 - make each queue's name different

V1:
 - remove RFC since no one objects
 - add '__u8 unused' for pending as suggested by Rusty
 - use virtio_cread_feature() directly, suggested by Rusty


Sorry, please add Jens' reviewed-by.

 Reviewed-by: Jens Axboe 


I appreciate very much that one of you may queue these two
patches into your tree so that userspace work can be kicked off,
since Michael has acked both patches and all comments have
been addressed already.


Given that Michael also acked it and Rusty is on his sabbatical, I'll 
queue it up for 3.17.


--
Jens Axboe

--
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] sched: select 'idle' cfs_rq per task-group to prevent tg-internal imbalance

[Michael wang]

On 06/30/2014 05:27 PM, Mike Galbraith wrote:
> On Mon, 2014-06-30 at 16:47 +0800, Michael wang wrote: 
[snip]
>>> While you're getting rid of the concept of 'GENTLE_FAIR_SLEEPERS', don't
>>> forget to also get rid of the concept of 'over-scheduling' :)
>>
>> I'm new to this word... could you give more details on that?
> 
> Massive context switching.  When heavily overloaded, wakeup preemption
> tends to hurt.  Trouble being that when overloaded, that's when
> fast/light tasks also need to get in and back out quickly the most. 

That's true... but for those who sensitive to latency, more frequently
the preemption is, more quickly they could have chances to run, although
that's really a very small piece of slice, but some time they just need
so much... like the mouse scurrying.

> 
[snip]
>> The preemtion based on vruntime sounds fair enough, but vruntime-bonus
>> for wakee do need few more thinking... although I don't want to count
>> the gentle-stuff in any more, but disable it do help dbench a lot...
> 
> It's scaled, but that's not really enough.  Zillion tasks can sleep in
> parallel, and when they are doing that, sleep time becomes a rather
> meaningless preemption yardstick.  It's only meaningful when there is a
> significant delta between task behaviors.  When running a homogeneous
> load of sleepers, eg a zillion java threads all doing the same damn
> thing, you're better off turning wakeup preemption off, because trying
> to smooth out microscopic vruntime deltas via wakeup preemption then
> does nothing but trashes caches.

I see, for those who prefer throughput, the effort on latency is
meaningless...

IMHO, currently the generic scheduler just try to take care both latency
and throughput, both will take a little damage but won't be damaged too
much, they just sacrificed for each other...

Fortunately, we still have various knobs and features to custom our own
scheduler, The flash or The Hulk ;-)

Regards,
Michael Wang

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

--
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] Remove FIXME messages in arch/powerpc/sysdev/uic.c

[Nicholas Krause]

This removes FIXME messages in the function uic_init_one
as this FIXMEs are not valid due to the kernel being better
to panic due to boards without these allocated not being
able to service IRQs.

Signed-off-by: Nicholas Krause 
---
 arch/powerpc/sysdev/uic.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/sysdev/uic.c b/arch/powerpc/sysdev/uic.c
index 9203393..937f6a5 100644
--- a/arch/powerpc/sysdev/uic.c
+++ b/arch/powerpc/sysdev/uic.c
@@ -239,7 +239,7 @@ static struct uic * __init uic_init_one(struct device_node 
*node)
 
uic = kzalloc(sizeof(*uic), GFP_KERNEL);
if (! uic)
-   return NULL; /* FIXME: panic? */
+   return NULL;
 
raw_spin_lock_init(>lock);
indexp = of_get_property(node, "cell-index", );
@@ -261,7 +261,7 @@ static struct uic * __init uic_init_one(struct device_node 
*node)
uic->irqhost = irq_domain_add_linear(node, NR_UIC_INTS, _host_ops,
 uic);
if (! uic->irqhost)
-   return NULL; /* FIXME: panic? */
+   return NULL;
 
/* Start with all interrupts disabled, level and non-critical */
mtdcr(uic->dcrbase + UIC_ER, 0);
-- 
1.9.1

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

[PATCH] Remove FIXME messages in arch/powerpc/sysdev/uic.c

[Nicholas Krause]

This removes FIXME messages in the function uic_init_one
as this FIXMEs are not valid due to the kernel being better
to panic due to boards without these allocated not being
able to service IRQs.

Signed-off-by: Nicholas Krause 
---
 arch/powerpc/sysdev/uic.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/sysdev/uic.c b/arch/powerpc/sysdev/uic.c
index 9203393..937f6a5 100644
--- a/arch/powerpc/sysdev/uic.c
+++ b/arch/powerpc/sysdev/uic.c
@@ -239,7 +239,7 @@ static struct uic * __init uic_init_one(struct device_node 
*node)
 
uic = kzalloc(sizeof(*uic), GFP_KERNEL);
if (! uic)
-   return NULL; /* FIXME: panic? */
+   return NULL;
 
raw_spin_lock_init(>lock);
indexp = of_get_property(node, "cell-index", );
@@ -261,7 +261,7 @@ static struct uic * __init uic_init_one(struct device_node 
*node)
uic->irqhost = irq_domain_add_linear(node, NR_UIC_INTS, _host_ops,
 uic);
if (! uic->irqhost)
-   return NULL; /* FIXME: panic? */
+   return NULL;
 
/* Start with all interrupts disabled, level and non-critical */
mtdcr(uic->dcrbase + UIC_ER, 0);
-- 
1.9.1

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

Re: [PATCH] powerpc: Disable RELOCATABLE for COMPILE_TEST with PPC64

[Guenter Roeck]

On 06/30/2014 05:55 PM, Stephen Rothwell wrote:

Hi Guenter,

On Mon, 30 Jun 2014 11:45:30 -0700 Guenter Roeck  wrote:


powerpc:allmodconfig has been failing for some time with the following
error.

arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
arch/powerpc/kernel/exceptions-64s.S:1312: Error: attempt to move .org backwards
make[1]: *** [arch/powerpc/kernel/head_64.o] Error 1

A number of attempts to fix the problem by moving around code have been
unsuccessful and resulted in failed builds for some configurations and
the discovery of toolchain bugs.

Fix the problem by disabling RELOCATABLE for COMPILE_TEST builds instead.


s/Fix/Work around/

would probably be a better here.


While this is less than perfect, it avoids substantial code changes
which would otherwise be necessary just to make COMPILE_TEST builds
happy and might have undesired side effects.

Signed-off-by: Guenter Roeck 


I'll dump this in my "fixes" tree today and see how it goes.



Would be great. Note that allyescconfig still fails with relocation errors
after this patch has been applied.

Thanks,
Guenter

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

Re: Re: [PATCH v4] [BUGFIX] kprobes: Fix "Failed to find blacklist" error on ia64 and ppc64

[Masami Hiramatsu]

(2014/06/30 20:36), Michael Ellerman wrote:
> On Mon, 2014-06-30 at 12:14 +0900, Masami Hiramatsu wrote:
>> Ping? :)
> 
> Yeah sorry. I started looking at this and got dragged into another mess.
> 
> You seem to have duplicated the functionality of arch_deref_entry_point(),
> which was also added for kprobes, and for the same reason - ie. because some
> arches have strange function pointers. Is there some reason you can't use it?

Ah, right! Hmm, it seems some more work to update it. but basically, we can do.
BTW, is there any other users who need to access the actual function entry (for
kallsyms case)?

If so, I guess it'd better to merge this version and replace kprobe's local
arch_deref_entry_point() with generic function_entry() macro.

Thank you,

-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com


--
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: [V2 PATCH] ALSA: hda - Enable mute/mic-mute LEDs for more Thinkpads with Conexant codec

[Hui Wang]

On 06/30/2014 02:45 PM, Jan Kiszka wrote:

On 2014-06-30 04:04, Hui Wang wrote:

On 06/29/2014 07:33 PM, Jan Kiszka wrote:

On 2013-11-27 07:47, Hui Wang wrote:

Most Thinkpad Edge series laptops use conexant codec, so far although
the codecs have different minor Vendor Id and minor Subsystem Id,
they all belong to the cxt5066 family, this change can make the
mute/mic-mute LEDs support more generic among cxt_5066 family.

This design refers to the similar solution for the realtek codec
ALC269 family in the patch_realtek.c.

Cc: Alex Hung 
Cc: David Henningsson 
Signed-off-by: Hui Wang 
---
   sound/pci/hda/patch_conexant.c | 23 +++
   1 file changed, 23 insertions(+)

diff --git a/sound/pci/hda/patch_conexant.c
b/sound/pci/hda/patch_conexant.c
index c205bb1..1f2717f 100644
--- a/sound/pci/hda/patch_conexant.c
+++ b/sound/pci/hda/patch_conexant.c
@@ -3244,9 +3244,29 @@ enum {
   #if IS_ENABLED(CONFIG_THINKPAD_ACPI)
 #include 
+#include 
 static int (*led_set_func)(int, bool);
   +static acpi_status acpi_check_cb(acpi_handle handle, u32 lvl, void
*context,
+ void **rv)
+{
+bool *found = context;
+*found = true;
+return AE_OK;
+}
+
+static bool is_thinkpad(struct hda_codec *codec)
+{
+bool found = false;
+if (codec->subsystem_id >> 16 != 0x17aa)
+return false;
+if (ACPI_SUCCESS(acpi_get_devices("LEN0068", acpi_check_cb,
, NULL)) && found)
+return true;
+found = false;
+return ACPI_SUCCESS(acpi_get_devices("IBM0068", acpi_check_cb,
, NULL)) && found;
+}
+
   static void update_tpacpi_mute_led(void *private_data, int enabled)
   {
   struct hda_codec *codec = private_data;
@@ -3279,6 +3299,8 @@ static void cxt_fixup_thinkpad_acpi(struct
hda_codec *codec,
   bool removefunc = false;
 if (action == HDA_FIXUP_ACT_PROBE) {
+if (!is_thinkpad(codec))
+return;
   if (!led_set_func)
   led_set_func = symbol_request(tpacpi_led_set);
   if (!led_set_func) {
@@ -3494,6 +3516,7 @@ static const struct snd_pci_quirk
cxt5066_fixups[] = {
   SND_PCI_QUIRK(0x17aa, 0x3975, "Lenovo U300s",
CXT_FIXUP_STEREO_DMIC),
   SND_PCI_QUIRK(0x17aa, 0x3977, "Lenovo IdeaPad U310",
CXT_FIXUP_STEREO_DMIC),
   SND_PCI_QUIRK(0x17aa, 0x397b, "Lenovo S205",
CXT_FIXUP_STEREO_DMIC),
+SND_PCI_QUIRK_VENDOR(0x17aa, "Thinkpad", CXT_FIXUP_THINKPAD_ACPI),
   SND_PCI_QUIRK(0x1c06, 0x2011, "Lemote A1004",
CXT_PINCFG_LEMOTE_A1004),
   SND_PCI_QUIRK(0x1c06, 0x2012, "Lemote A1205",
CXT_PINCFG_LEMOTE_A1205),
   {}


Starting with this patch, my Lenovo Thinkpad X121e netbook (it's without
any mute LEDs, BTW, there is only a power LED) considers the power
button as hard reset. I have to exclude my machine from that ACPI fixup
(this is on top of current Linus master):

It seems more like a firmware issue, in the acpi code, the "SSMS" is for
mute led, and the "MMTS" is for micmute led, I don't know why your
machine can pass "SSMS" or "MMTS" scanning even without mute LEDs.


Is there anything I can debug or any information I can collect from my
box to examine this?
What is the linux distribution on your machine? And use showkey to catch 
the keycode of that button.




Jan




--
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] hwpoison: Fix race with changing page during offlining v2

[Andi Kleen]

> Acked-by: Naoya Horiguchi 
> 
> Is it -stable matter?
> Maybe 2.6.38+ can profit from this.

Probably not, it's not a critical bug fix.

-Andi
--
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] hid-appleir: Fix kernel panic due to null pointer

[Nicholas Krause]

Fixes a null pointer in appleir_input_configured due to reading
into wrong size array. Changed the variable to input_dev->keycodemax.

Signed-off-by: Nicholas Krause 
---
 drivers/hid/hid-appleir.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hid/hid-appleir.c b/drivers/hid/hid-appleir.c
index 0e6a42d..cc02df4 100644
--- a/drivers/hid/hid-appleir.c
+++ b/drivers/hid/hid-appleir.c
@@ -272,7 +272,7 @@ static void appleir_input_configured(struct hid_device *hid,
input_dev->evbit[0] = BIT(EV_KEY) | BIT(EV_REP);
 
memcpy(appleir->keymap, appleir_key_table, sizeof(appleir->keymap));
-   for (i = 0; i < ARRAY_SIZE(appleir_key_table); i++)
+   for (i = 0; i < appleir->keymap; i++)
set_bit(appleir->keymap[i], input_dev->keybit);
clear_bit(KEY_RESERVED, input_dev->keybit);
 }
-- 
1.9.1

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

Re: [PATCH v2 0/9] thermal: exynos: various cleanups

[Zhang Rui]

Eduardo,

what do you think of this patch set?

thanks,
rui

On Tue, 2014-06-17 at 19:27 +0200, Bartlomiej Zolnierkiewicz wrote:
> Hi,
> 
> This patch series contains various cleanups for EXYNOS thermal
> driver.  Overall it decreases driver's LOC by 12%.  It is based
> on next-20140617 kernel.  It should not cause any functionality
> changes.
> 
> Changes since v1:
> - synced patches against next-20140617
> - merged patch "thermal: exynos: remove unused defines" into
>   "thermal: exynos: remove unused struct exynos_tmu_registers
>   entries" one (per request from Eduardo)
> - improved patch descriptions for patches #1-5
> - fixed documentation for pdata->gain and pdata->reference_voltage
> - added Reviewed-by from Amit to patches #6, #7 and #10
> - added missing Acked-by from Kyungmin Park
> 
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R Institute Poland
> Samsung Electronics
> 
> 
> Bartlomiej Zolnierkiewicz (9):
>   thermal: exynos: remove unused struct exynos_tmu_registers entries
>   thermal: exynos: remove dead code for HW_MODE calibration
>   thermal: exynos: remove dead code for TYPE_TWO_POINT_TRIMMING
> calibration
>   thermal: exynos: remove redundant pdata checks from
> exynos_tmu_initialize()
>   thermal: exynos: remove redundant threshold_code checks from
> exynos_tmu_initialize()
>   thermal: exynos: simplify temp_to_code() and code_to_temp()
>   thermal: exynos: cache non_hw_trigger_levels in pdata
>   thermal: exynos: remove redundant pdata checks from
> exynos_tmu_control()
>   thermal: exynos: remove identical values from exynos*_tmu_registers
> structures
> 
>  drivers/thermal/samsung/exynos_thermal_common.h |   1 -
>  drivers/thermal/samsung/exynos_tmu.c| 181 
> 
>  drivers/thermal/samsung/exynos_tmu.h|  90 +---
>  drivers/thermal/samsung/exynos_tmu_data.c   |  64 +
>  drivers/thermal/samsung/exynos_tmu_data.h   |  33 +
>  5 files changed, 41 insertions(+), 328 deletions(-)
> 


--
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] block: fix uint overflow when merging io requests

[Junxiao Bi]

On 06/27/2014 03:24 PM, Junxiao Bi wrote:
> This uint overflow will cause req->__data_len < req->bio->bi_size,
> this will confuse block layer and device driver.
>
> I watched a panic caused by this when mkfs.ext4 a volume of a large
> virtual disk on vm guest, blkdev_issue_discard() issue two bio with
> a total size over UINT_MAX, but the check in ll_back_merge_fn() didn't
> take affect due to the overflow and they were merged into one request.
> After the request is done, in blk_end_request_all(), BUG_ON(pending)
> was triggered and kernel panic. "pending" is true is because
> blk_update_request() return ture when req->__data_len is less
> than req->bio->bi_size.
Any body help review this patch?
blk_rq_sectors(), bio_sectors(), blk_rq_get_max_sectors() are all uint.

blk_rq_sectors(req) + bio_sectors(bio) > blk_rq_get_max_sectors(req)

This checking is bypassed when overflow happen. It will cause an io
request's
length less than its child bio's size.

Thanks,
Junxiao.
>
> Signed-off-by: Junxiao Bi 
> ---
>  block/blk-merge.c |   40 ++--
>  1 file changed, 34 insertions(+), 6 deletions(-)
>
> diff --git a/block/blk-merge.c b/block/blk-merge.c
> index b3bf0df..340c0a7 100644
> --- a/block/blk-merge.c
> +++ b/block/blk-merge.c
> @@ -325,11 +325,41 @@ no_merge:
>   return 0;
>  }
>  
> -int ll_back_merge_fn(struct request_queue *q, struct request *req,
> +static inline bool ll_allow_merge_bio(struct request *req,
>struct bio *bio)
>  {
>   if (blk_rq_sectors(req) + bio_sectors(bio) >
> - blk_rq_get_max_sectors(req)) {
> + blk_rq_get_max_sectors(req))
> + return false;
> +
> + /* check uint overflow */
> + if (blk_rq_sectors(req) + bio_sectors(bio) < blk_rq_sectors(req)
> + || blk_rq_sectors(req) + bio_sectors(bio) < bio_sectors(bio))
> + return false;
> +
> + return true;
> +}
> +
> +static inline bool ll_allow_merge_req(struct request *req,
> +  struct request *next)
> +{
> + if (blk_rq_sectors(req) + blk_rq_sectors(next) >
> + blk_rq_get_max_sectors(req))
> + return false;
> +
> + /* check uint overflow */
> + if (blk_rq_sectors(req) + blk_rq_sectors(next) < blk_rq_sectors(req)
> + || blk_rq_sectors(req) + blk_rq_sectors(next) <
> + blk_rq_sectors(next))
> + return false;
> +
> + return true;
> +}
> +
> +int ll_back_merge_fn(struct request_queue *q, struct request *req,
> +  struct bio *bio)
> +{
> + if (!ll_allow_merge_bio(req, bio)) {
>   req->cmd_flags |= REQ_NOMERGE;
>   if (req == q->last_merge)
>   q->last_merge = NULL;
> @@ -346,8 +376,7 @@ int ll_back_merge_fn(struct request_queue *q, struct 
> request *req,
>  int ll_front_merge_fn(struct request_queue *q, struct request *req,
> struct bio *bio)
>  {
> - if (blk_rq_sectors(req) + bio_sectors(bio) >
> - blk_rq_get_max_sectors(req)) {
> + if (!ll_allow_merge_bio(req, bio)) {
>   req->cmd_flags |= REQ_NOMERGE;
>   if (req == q->last_merge)
>   q->last_merge = NULL;
> @@ -389,8 +418,7 @@ static int ll_merge_requests_fn(struct request_queue *q, 
> struct request *req,
>   /*
>* Will it become too large?
>*/
> - if ((blk_rq_sectors(req) + blk_rq_sectors(next)) >
> - blk_rq_get_max_sectors(req))
> + if (!ll_allow_merge_req(req, next))
>   return 0;
>  
>   total_phys_segments = req->nr_phys_segments + next->nr_phys_segments;

--
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/6] thermal: sti: Add new Thermal driver

[Zhang Rui]

Hi, Eduardo,

what do you think of this patch set?

thanks,
rui

On Fri, 2014-05-30 at 10:38 +0100, Lee Jones wrote:
> This patchset adds full support for 2 types of Thermal Controllers
> produced by STMicroelectronics.  One is a more traditional memory
> mapped variant, the other is controlled solely by system configuration
> registers.
> 
>  Documentation/devicetree/bindings/thermal/st-thermal.txt |  42 
> 
>  arch/arm/boot/dts/stih416.dtsi   |  18 +++
>  arch/arm/configs/multi_v7_defconfig  |   2 +
>  drivers/thermal/Kconfig  |   5 ++
>  drivers/thermal/Makefile |   1 +
>  drivers/thermal/st/Kconfig   |  12 +
>  drivers/thermal/st/Makefile  |   3 ++
>  drivers/thermal/st/st_thermal.c  | 313 
> ++
>  drivers/thermal/st/st_thermal.h  | 104 
> ++
>  drivers/thermal/st/st_thermal_memmap.c   | 209 
> 
>  drivers/thermal/st/st_thermal_syscfg.c   | 179 
> +
>  11 files changed, 888 insertions(+)
> 


--
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 4/6] mmu_notifier: pass through vma to invalidate_range and invalidate_page

[Linus Torvalds]

On Fri, Jun 27, 2014 at 7:00 PM, Jérôme Glisse  wrote:
>
> This needs small refactoring in memory.c to call invalidate_range on
> vma boundary the overhead should be low enough.

.. and looking at it, doesn't that mean that the whole invalidate call
should be moved inside unmap_single_vma() then, instead of being
duplicated in all the callers?

I really get the feeling that somebody needs to go over this
patch-series with a fine comb to fix these kinds of ugly things.

 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: [RFC] CMA page migration failure due to buffers on bh_lru

[Laura Abbott]

On 6/30/2014 6:07 PM, Gioh Kim wrote:
> Hi,Laura.
> 
> I have a question.
> 
> Does the __evict_bh_lru() not need bh_lru_lock()?
> The get_cpu_var() has already preenpt_disable() and can prevent other thread.
> But get_cpu_var cannot prevent IRQ context such like page-fault.
> I think if a page-fault occured and a file is read in IRQ context it can 
> change cpu-lru.
> 
> Is my concern correct?
> 
> 

__evict_bh_lru is called via on_each_cpu_cond which I believe will disable irqs.
I based the code on the existing invalidate_bh_lru which did not take the 
bh_lru_lock
either. It's possible I missed something though.

Thanks,
Laura

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
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] Fixes gemmi_idle in file idle.c

[Nick Krause]

Thanks for the good feedback on kernel development , I will delete this file
in order to clean up race conditions caused by it.
Cheers Nick

On Mon, Jun 30, 2014 at 5:41 AM, Russell King - ARM Linux
 wrote:
> On Sun, Jun 29, 2014 at 10:52:40PM -0400, Nicholas Krause wrote:
>> disables the IRQ line in gemmi_idle before calling cpu_do_idle.
>> In addition, according to the Fixme message in this file fixes
>> races that may occur due to not disabling the IRQ before calling
>> cpu_do_idle.
>
> 1) the idle method is called with interrupts already disabled.
> 2) I wonder if you read the comment above the comment you removed, and
>if so, why it wasn't removed.
> 3) can you indicate how the hardware problem has been fixed, or give some
>justification why this change should be accepted.
>
> --
> FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
> improving, and getting towards what was expected from it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/6] mmu_notifier: add event information to address invalidation v2

[Linus Torvalds]

On Fri, Jun 27, 2014 at 7:00 PM, Jérôme Glisse  wrote:
> From: Jérôme Glisse 
>
> The event information will be useful [...]

That needs to be cleaned up, though.

Why the heck are you making up ew and stupid event types? Now you make
the generic VM code do stupid things like this:

+   if ((vma->vm_flags & VM_READ) && (vma->vm_flags & VM_WRITE))
+   event = MMU_MPROT_RANDW;
+   else if (vma->vm_flags & VM_WRITE)
+   event = MMU_MPROT_WONLY;
+   else if (vma->vm_flags & VM_READ)
+   event = MMU_MPROT_RONLY;

which makes no sense at all. The names are some horrible abortion too
("RANDW"? That sounds like "random write" to me, not "read-and-write",
which is commonly shortened RW or perhaps RDWR. Same foes for
RONLY/WONLY - what kind of crazy names are those?

But more importantly, afaik none of that is needed. Instead, tell us
why you need particular flags, and don't make up crazy names like
this. As far as I can tell, you're already passing in the new
protection information (thanks to passing in the vma), so all those
badly named states you've made up seem to be totally pointless. They
add no actual information, but they *do* add crazy code like the above
to generic code that doesn't even WANT any of this crap. The only
thing this should need is a MMU_MPROT event, and just use that. Then
anybody who wants to look at whether the protections are being changed
to read-only, they can just look at the vma->vm_flags themselves.

So things like this need to be tightened up and made sane before any
chance of merging it.

So NAK NAK NAK in the meantime.

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] Fixes q40_irq_startup to return -ENXIO

[Nick Krause]

Seems fair if there is another way of doing it then I will rewrite this patch.
Cheers Nick

On Mon, Jun 30, 2014 at 1:52 PM, Geert Uytterhoeven
 wrote:
> On Mon, Jun 30, 2014 at 7:27 PM, Andreas Schwab  wrote:
>> Nicholas Krause  writes:
>>
>>> Fixes q40_irq_startup to return -ENXIO for cases 11-13 in the switch
>>> statement of this function to handle these failure cases.
>>>
>>> Signed-off-by: Nicholas Krause 
>>> ---
>>>  arch/m68k/q40/q40ints.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/m68k/q40/q40ints.c b/arch/m68k/q40/q40ints.c
>>> index 513f9bb..9dfa1ea 100644
>>> --- a/arch/m68k/q40/q40ints.c
>>> +++ b/arch/m68k/q40/q40ints.c
>>> @@ -49,7 +49,7 @@ static unsigned int q40_irq_startup(struct irq_data *data)
>>>   case 1: case 2: case 8: case 9:
>>>   case 11: case 12: case 13:
>>>   printk("%s: ISA IRQ %d not implemented by HW\n", __func__, 
>>> irq);
>>> - /* FIXME return -ENXIO; */
>>> + return -ENXIO;
>>
>> There must be more to it, given the FIXME.
>
> I think I really just forgot to get rid of it. It was introduced in commit
> c288bf2533e57174b90b07860c4391bcd1ea269c ("m68k/irq: Rename
> irq_controller to irq_chip").
>
> I think I added the FIXME because I got puzzled by the return value change
> from (signed) int to unsigned int, which doesn't match well with a negative
> error number.
>
> However:
>   1. While irq_chip.irq_startup() returns unsigned int, irq_startup()
> does return
>  int (why this difference, historical reasons?), so it becomes a negative
>  number again later,
>   2. The return value of irq_startup() seems to used in
>  kernel/irq/autoprobe.c:probe_irq_on() only, and the actual (non-zero) 
> value
>  doesn't matter, just whether it returns zero or non-zero.
>
> So I'm gonna take this patch, unless someone screams with a very good reason.
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds
--
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 RESEND] clk: samsung: Make of_device_id array const

[Jingoo Han]

On Thursday, June 26, 2014 9:00 PM, Krzysztof Kozlowski wrote:
> 
> Array of struct of_device_id may be be const as expected by
> of_match_table field and of_find_matching_node_and_match() function.
> 
> Signed-off-by: Krzysztof Kozlowski 

Reviewed-by: Jingoo Han 

Best regards,
Jingoo Han

> ---
>  drivers/clk/samsung/clk-exynos4.c| 2 +-
>  drivers/clk/samsung/clk-exynos5250.c | 2 +-
>  drivers/clk/samsung/clk-exynos5420.c | 2 +-
>  drivers/clk/samsung/clk-exynos5440.c | 2 +-
>  drivers/clk/samsung/clk.c| 2 +-
>  drivers/clk/samsung/clk.h| 2 +-
>  6 files changed, 6 insertions(+), 6 deletions(-)
> 

--
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] tools/thermal: tmon: fix compilation errors when building statically

[Zhang Rui]

On Tue, 2014-06-10 at 16:16 +0100, Javi Merino wrote:
> Hi Rui,
> 
> On Mon, Jun 02, 2014 at 12:54:57PM +0100, Jacob Pan wrote:
> > On Mon,  2 Jun 2014 18:08:17 +0100
> > "Javi Merino"  wrote:
> > 
> > > tmon fails to build statically with the following error:
> > > 
> > > $ make LDFLAGS=-static
> > > gcc -O1 -Wall -Wshadow -W -Wformat -Wimplicit-function-declaration
> > > -Wimplicit-int -fstack-protector -D VERSION=\"1.0\" -static tmon.o
> > > tui.o sysfs.o pid.o   -o tmon -lm -lpanel -lncursesw  -lpthread
> > > tmon.o: In function `tmon_sig_handler': tmon.c:(.text+0x21):
> > > undefined reference to `stdscr' tmon.o: In function `tmon_cleanup':
> > > tmon.c:(.text+0xb9): undefined reference to `stdscr'
> > > tmon.c:(.text+0x11e): undefined reference to `stdscr'
> > > tmon.c:(.text+0x123): undefined reference to `keypad'
> > > tmon.c:(.text+0x12d): undefined reference to `nocbreak' tmon.o: In
> > > function `main': tmon.c:(.text+0x785): undefined reference to `stdscr'
> > > tmon.c:(.text+0x78a): undefined reference to `nodelay'
> > > tui.o: In function `setup_windows':
> > > tui.c:(.text+0x131): undefined reference to `stdscr'
> > > tui.c:(.text+0x176): undefined reference to `stdscr'
> > > tui.c:(.text+0x19f): undefined reference to `stdscr'
> > > tui.c:(.text+0x1cc): undefined reference to `stdscr'
> > > tui.c:(.text+0x1ff): undefined reference to `stdscr'
> > > tui.o:tui.c:(.text+0x229): more undefined references to `stdscr'
> > > follow tui.o: In function `show_cooling_device':
> > > [...]
> > > 
> > > stdscr() and friends are in libtinfo (part of ncurses) so add it to
> > > the libraries that are linked in when compiling tmon to fix it.
> > > 
> > Acked-by: Jacob Pan 
> 
> Thanks!
> 
> Rui, can you pick this up?

Done, thanks!

-rui
> 
> Cheers,
> Javi
> 


--
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] thermal: ti-soc-thermal: ti-bandgap.c: Cleaning up wrong address is checked

[Zhang Rui]

On Mon, 2014-06-02 at 23:25 +0200, Rickard Strandqvist wrote:
> Wrong address is checked after memory allocation.
> 
> Signed-off-by: Rickard Strandqvist 

applied, thanks.

-rui
> ---
>  drivers/thermal/ti-soc-thermal/ti-bandgap.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c 
> b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> index 3ab12ee..43c0f83 100644
> --- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> +++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> @@ -1155,7 +1155,7 @@ static struct ti_bandgap *ti_bandgap_build(struct 
> platform_device *pdev)
>   /* register shadow for context save and restore */
>   bgp->regval = devm_kzalloc(>dev, sizeof(*bgp->regval) *
>  bgp->conf->sensor_count, GFP_KERNEL);
> - if (!bgp) {
> + if (!bgp->regval) {
>   dev_err(>dev, "Unable to allocate mem for driver ref\n");
>   return ERR_PTR(-ENOMEM);
>   }


--
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 07/12] usb: chipidea: add a generic driver

[Peter Chen]

On Mon, Jun 30, 2014 at 03:33:13PM +0200, Antoine Ténart wrote:
> Peter,
> 
> On Fri, Jun 27, 2014 at 11:25:07AM +0800, Peter Chen wrote:
> > On Tue, Jun 24, 2014 at 12:35:16PM +0200, Antoine Ténart wrote:
> > >  
> > >  ifneq ($(CONFIG_OF),)
> > >   obj-$(CONFIG_USB_CHIPIDEA)  += usbmisc_imx.o ci_hdrc_imx.o
> > > + obj-$(CONFIG_USB_CHIPIDEA)  += ci_hdrc_generic.o
> > >  endif
> > 
> > As a generic driver, you may need to support both dt and non-dt
> > solution.
> 
> Since the dt is now the best practice and since there is no need (yet)
> for a non-dt usage of this driver shouldn't we let anyone needing it
> implement it when the time comes?
> 

No, at least your code structure should support both dt and non-dt,
and let the compile pass for non-dt platform if you don't have one.
Then, someone with non-dt platform can change few to support it. 
A good example is: drivers/usb/host/ehci-platform.c

> > > +static int ci_hdrc_generic_probe(struct platform_device *pdev)
> > > +{
> > > + struct device *dev = >dev;
> > > + struct ci_hdrc_generic_priv *priv;
> > > + struct ci_hdrc_platform_data ci_pdata = {
> > > + .name   = "ci_hdrc",
> > 
> > How about this using dev_name(>dev) for name?
> 
> Yes, why not. I don't have a strong preference.
> 
> > > +
> > > +clk_err:
> > > + clk_disable_unprepare(priv->clk);
> > 
> > You may need to add "if (!IS_ERR(priv->clk))"
> 
> Right! I'll update this.
> 
> > > +
> > > +static const struct of_device_id ci_hdrc_generic_of_match[] = {
> > > + { .compatible = "chipidea-usb" },
> > > + { }
> > > +};
> > 
> > Even as a generic driver, you can also use your own compatible string.
> 
> Well, there is nothing specific about the Berlin CI. Some subsystems
> use the 'generic' keyword in these cases. Do you see a particular reason
> I should use some Berlin related compatible here?
> 

Not must, one suggestion is: can you change the compatible string
to "chipidea-usb-generic"?

-- 

Best Regards,
Peter Chen
--
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] gpu:drm:i915:intel_detect_pch: back to check devfn instead of check class type

[Chen, Tiejun]

On 2014/6/30 19:18, Michael S. Tsirkin wrote:

On Thu, Jun 19, 2014 at 05:53:51PM +0800, Tiejun Chen wrote:

Originally the reason to probe ISA bridge instead of Dev31:Fun0
is to make graphics device passthrough work easy for VMM, that
only need to expose ISA bridge to let driver know the real
hardware underneath. This is a requirement from virtualization
team. Especially in that virtualized environments, XEN, there
is irrelevant ISA bridge in the system with that legacy qemu
version specific to xen, qemu-xen-traditional. So to work
reliably, we should scan through all the ISA bridge devices
and check for the first match, instead of only checking the
first one.

But actually, qemu-xen-traditional, is always enumerated with
Dev31:Fun0, 00:1f.0 as follows:

hw/pt-graphics.c:

intel_pch_init()
 |
 + pci_isa_bridge_init(bus, PCI_DEVFN(0x1f, 0), ...);

so this mean that isa bridge is still represented with Dev31:Func0
like the native OS. Furthermore, currently we're pushing VGA
passthrough support into qemu upstream, and with some discussion,
we wouldn't set the bridge class type and just expose this devfn.

So we just go back to check devfn to make life normal.

Signed-off-by: Tiejun Chen 
---
  drivers/gpu/drm/i915/i915_drv.c | 19 +++
  1 file changed, 3 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 651e65e..cb2526e 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -417,18 +417,8 @@ void intel_detect_pch(struct drm_device *dev)
return;
}

-   /*
-* The reason to probe ISA bridge instead of Dev31:Fun0 is to
-* make graphics device passthrough work easy for VMM, that only
-* need to expose ISA bridge to let driver know the real hardware
-* underneath. This is a requirement from virtualization team.
-*
-* In some virtualized environments (e.g. XEN), there is irrelevant
-* ISA bridge in the system. To work reliably, we should scan trhough
-* all the ISA bridge devices and check for the first match, instead
-* of only checking the first one.
-*/
-   while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
+   pch = pci_get_bus_and_slot(0, PCI_DEVFN(0x1f, 0));
+   if (pch) {


Then if you want to use this slot for something else, what happens?


I think this slot is always occupied to be dedicated to this ISA bridge 
in the platform.


So don't worry, the drivers in Linux and Windows can live with this.

Thanks
Tiejun


If you want to relax the PCI_CLASS_BRIDGE_ISA requirement when
running on top of a hypervisor, just scan all devices.


if (pch->vendor == PCI_VENDOR_ID_INTEL) {
unsigned short id = pch->device & 
INTEL_PCH_DEVICE_ID_MASK;
dev_priv->pch_id = id;
@@ -462,10 +452,7 @@ void intel_detect_pch(struct drm_device *dev)
DRM_DEBUG_KMS("Found LynxPoint LP PCH\n");
WARN_ON(!IS_HASWELL(dev));
WARN_ON(!IS_ULT(dev));
-   } else
-   continue;
-
-   break;
+   }
}
}
if (!pch)
--
1.9.1




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

Re: [PATCH cgroup/for-3.16-fixes] cpuset: break kernfs active protection in cpuset_write_resmask()

[Li Zefan]

On 2014/7/1 3:47, Tejun Heo wrote:
> Hey, Li.
> 
> Can you please test this patch and ack it?
> 
...
> Signed-off-by: Tejun Heo 
> Reported-by: Li Zefan 

Tested-by: Li Zefan 

Thanks!

> ---
>  kernel/cpuset.c |   12 
>  1 file changed, 12 insertions(+)

--
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] USB: ehci-pci: USB host controller support for Intel Quark X1000

[Chen, Alvin]

> >
> > /*
> > -*/
> > +#define PCI_DEVICE_ID_INTEL_QUARK_X1000_SOC0x0939
> > +static inline bool is_intel_quark_x1000(struct pci_dev *pdev) {
> > +   return pdev->vendor == PCI_VENDOR_ID_INTEL &&
> > +   pdev->device == PCI_DEVICE_ID_INTEL_QUARK_X1000_SOC;
> > +}
> 
> Whether to put this test directly into ehci_pci_reset() or leave it as a 
> separate
> subroutine is up to you.  I don't care either way.
I will just keep it.

> > +
> > +/*
> > +   * The offset of in/out threshold register is 0x84.
> > +   * And it is the register of 'hostpc'
> > +   * in memory-mapped EHCI controller.
> > +*/
> 
> 0x84 is the same as offset of the hostpc register in the Intel Moorestown
> controller.  hostpc is not present in general EHCI controllers.
>
OK, I will improve the comments.

> > +#defineintel_quark_x1000_insnreg01 hostpc
> > +
> > +/* The maximal ehci packet buffer size is 512 bytes */
> > +#define INTEL_QUARK_X1000_EHCI_MAX_PACKET_BUFFER_SIZE  512
> > +
> > +/* The threshold value set the register is in DWORD */
> > +#define INTEL_QUARK_X1000_EHCI_THRESHOLD(size) ((size)/4u)
> > +#define INTEL_QUARK_X1000_EHCI_THRESHOLD_OUT_SHIFT 16
> > +#define INTEL_QUARK_X1000_EHCI_THRESHOLD_IN_SHIFT  0
> > +
> >  /* called after powerup, by probe or system-pm "wakeup" */  static
> > int ehci_pci_reinit(struct ehci_hcd *ehci, struct pci_dev *pdev)  {
> > int retval;
> > +   u32 val;
> > +   u32 thr;
> >
> > /* we expect static quirk code to handle the "extended capabilities"
> >  * (currently just BIOS handoff) allowed starting with EHCI 0.96 @@
> > -50,6 +74,22 @@ static int ehci_pci_reinit(struct ehci_hcd *ehci, struct
> pci_dev *pdev)
> > if (!retval)
> > ehci_dbg(ehci, "MWI active\n");
> >
> > +   /* Reset the threshold limit */
> > +   if (is_intel_quark_x1000(pdev)) {
> > +   /*
> > +   * In order to support the isochronous/interrupt
> > +   * transactions, 508 bytes should be used as
> > +   * max threshold values to maximize the
> > +   * performance
> > +   */
> > +   thr = INTEL_QUARK_X1000_EHCI_THRESHOLD(
> > +   INTEL_QUARK_X1000_EHCI_MAX_PACKET_BUFFER_SIZE - 4
> > +   );
> > +   val = thr< > +   thr< > +   ehci_writel(ehci, val, ehci->regs->intel_quark_x1000_insnreg01);
> 
> I saw what other people told you about the original patch version, and I
> disagree with them.  It is not necessary to include a detailed calculation 
> like
> this, it only makes the code harder to read.  It will be better to have a 
> single
> #define with a comment explaining it, like
> this:
> 
> /* Maximum usable threshold value is 0x7f dwords for both IN and OUT */
> #define INTEL_QUARK_X1000_EHCI_MAX_THRESHOLD  0x007f007f
> 
> Then here, just use INTEL_QUARK_X1000_EHCI_MAX_THRESHOLD instead of
> val.  The comment can simply say:
> 
>   /*
>* For the Intel QUARK X1000, raise the I/O threshold to the
>* maximum usable value in order to improve performance.
>*/
> 
I think so also. It is not necessary to make so complicated. I will adopt your 
suggestions, it is more simple and clearly.

> Alan Stern

--
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: mm: slub: invalid memory access in setup_object

[Wei Yang]

On Mon, Jun 30, 2014 at 03:03:21PM -0700, David Rientjes wrote:
>On Wed, 25 Jun 2014, Christoph Lameter wrote:
>
>> On Wed, 25 Jun 2014, Sasha Levin wrote:
>> 
>> > [  791.669480] ? init_object (mm/slub.c:665)
>> > [  791.669480] setup_object.isra.34 (mm/slub.c:1008 mm/slub.c:1373)
>> > [  791.669480] new_slab (mm/slub.c:278 mm/slub.c:1412)
>> 
>> So we just got a new page from the page allocator but somehow cannot
>> write to it. This is the first write access to the page.
>> 
>
>I'd be inclined to think that this was a result of "slub: reduce duplicate 
>creation on the first object" from -mm[*] that was added the day before 
>Sasha reported the problem.
>
>It's not at all clear to me that that patch is correct.  Wei?
>
>Sasha, with a revert of that patch, does this reproduce?
>
> [*] 
> http://ozlabs.org/~akpm/mmotm/broken-out/slub-reduce-duplicate-creation-on-the-first-object.patch

David,

So sad to see the error after applying my patch. In which case this is
triggered? The kernel with this patch runs fine on my laptop. Maybe there is
some corner case I missed? If you could tell me the way you reproduce it, I
would have a try on my side.

I did a simple test for this patch, my test code and result is attached.

1. kmem_cache.c
   The test module.
2. kmem_log.txt
   In this log, you can see 26 objects are initialized once exactly, while
   without this patch, the first object will be initialized twice.

 Fetch a cache from kmem_cache
 new_slab: page->objects is 26
 new_slab: setup on 880097038000, 8800970384e0
   init_once: [00]880097038000 is created
 new_slab: setup on 8800970384e0, 8800970389c0
   init_once: [01]8800970384e0 is created
 new_slab: setup on 8800970389c0, 880097038ea0
   init_once: [02]8800970389c0 is created
 new_slab: setup on 880097038ea0, 880097039380
   init_once: [03]880097038ea0 is created
 new_slab: setup on 880097039380, 880097039860
   init_once: [04]880097039380 is created
 new_slab: setup on 880097039860, 880097039d40
   init_once: [05]880097039860 is created
 new_slab: setup on 880097039d40, 88009703a220
   init_once: [06]880097039d40 is created
 new_slab: setup on 88009703a220, 88009703a700
   init_once: [07]88009703a220 is created
 new_slab: setup on 88009703a700, 88009703abe0
   init_once: [08]88009703a700 is created
 new_slab: setup on 88009703abe0, 88009703b0c0
   init_once: [09]88009703abe0 is created
 new_slab: setup on 88009703b0c0, 88009703b5a0
   init_once: [10]88009703b0c0 is created
 new_slab: setup on 88009703b5a0, 88009703ba80
   init_once: [11]88009703b5a0 is created
 new_slab: setup on 88009703ba80, 88009703bf60
   init_once: [12]88009703ba80 is created
 new_slab: setup on 88009703bf60, 88009703c440
   init_once: [13]88009703bf60 is created
 new_slab: setup on 88009703c440, 88009703c920
   init_once: [14]88009703c440 is created
 new_slab: setup on 88009703c920, 88009703ce00
   init_once: [15]88009703c920 is created
 new_slab: setup on 88009703ce00, 88009703d2e0
   init_once: [16]88009703ce00 is created
 new_slab: setup on 88009703d2e0, 88009703d7c0
   init_once: [17]88009703d2e0 is created
 new_slab: setup on 88009703d7c0, 88009703dca0
   init_once: [18]88009703d7c0 is created
 new_slab: setup on 88009703dca0, 88009703e180
   init_once: [19]88009703dca0 is created
 new_slab: setup on 88009703e180, 88009703e660
   init_once: [20]88009703e180 is created
 new_slab: setup on 88009703e660, 88009703eb40
   init_once: [21]88009703e660 is created
 new_slab: setup on 88009703eb40, 88009703f020
   init_once: [22]88009703eb40 is created
 new_slab: setup on 88009703f020, 88009703f500
   init_once: [23]88009703f020 is created
 new_slab: setup on 88009703f500, 88009703f9e0
   init_once: [24]88009703f500 is created
 new_slab: do it again? 88009703f9e0
   init_once: [25]88009703f9e0 is created

-- 
Richard Yang
Help you, Help me
/*
 * =
 *
 *   Filename:  kmem_cache.c
 *
 *Description:  /proc/slabinfo
 *
 *Version:  1.0
 *Created:  04/26/2014 09:12:04 PM
 *   Revision:  none
 *   Compiler:  gcc
 *
 * Author:  Wei Yang (weiyang), weiyang.ker...@gmail.com
 *Company:  
 *
 * =
 */

#include 
#include 
#include 
MODULE_LICENSE("Dual BSD/GPL");

static struct kmem_cache *test_cache;
void *tmp;

static void init_once(void *foo)
{
	static int num;
	

RE: [PATCH v3] USB: ehci-pci: USB host controller support for Intel Quark X1000

[Chen, Alvin]

> > /*
> > -*/
> > +#define PCI_DEVICE_ID_INTEL_QUARK_X1000_SOC0x0939
> > +static inline bool is_intel_quark_x1000(struct pci_dev *pdev) {
> > +   return pdev->vendor == PCI_VENDOR_ID_INTEL &&
> > +   pdev->device == PCI_DEVICE_ID_INTEL_QUARK_X1000_SOC;
> > +}
> 
> Why not just put this check inline into ehci_pci_reinit()?
Alan Stern said it is not a problem, I think so also since it just a inline 
subroutine.

> 
> > +
> > +/*
> > +   * The offset of in/out threshold register is 0x84.
> > +   * And it is the register of 'hostpc'
> > +   * in memory-mapped EHCI controller.
> > +*/
> 
> The preferred multi-line kernel style is this:
> 
> /*
>   * bla
>   * bla
>   */
I will improve it.

> > +#defineintel_quark_x1000_insnreg01 hostpc
> > +
> > +/* The maximal ehci packet buffer size is 512 bytes */
> 
> s/ehci/EHCI/
> 
> > +#define INTEL_QUARK_X1000_EHCI_MAX_PACKET_BUFFER_SIZE  512
> > +
> > +/* The threshold value set the register is in DWORD */
> > +#define INTEL_QUARK_X1000_EHCI_THRESHOLD(size) ((size)/4u)
> > +#define INTEL_QUARK_X1000_EHCI_THRESHOLD_OUT_SHIFT 16
> > +#define INTEL_QUARK_X1000_EHCI_THRESHOLD_IN_SHIFT  0
> > +
> >
> 
> Too many empty lines...
> 
> >   /* called after powerup, by probe or system-pm "wakeup" */
> >   static int ehci_pci_reinit(struct ehci_hcd *ehci, struct pci_dev *pdev)
> >   {
> > int retval;
> > +   u32 val;
> > +   u32 thr;
> 
> Why not declare these where they are used?
All will be removed as Alan Stern's suggestion.

> > +   /* Reset the threshold limit */
> > +   if (is_intel_quark_x1000(pdev)) {
> > +   /*
> > +   * In order to support the isochronous/interrupt
> > +   * transactions, 508 bytes should be used as
> > +   * max threshold values to maximize the
> > +   * performance
> > +   */
> 
> Same comment about the comment style...
> 
> > +   thr = INTEL_QUARK_X1000_EHCI_THRESHOLD(
> > +   INTEL_QUARK_X1000_EHCI_MAX_PACKET_BUFFER_SIZE - 4
> > +   );
> > +   val = thr< > +   thr< 
> Please surround << with spaces for consistency.
The above code will be removed as Alan Stern's suggestion.

> 

--
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/2] block: virtio-blk: support multi vq per virtio-blk

[Ming Lei]

Hi Jens and Rusty,

On Thu, Jun 26, 2014 at 8:04 PM, Ming Lei  wrote:
> On Thu, Jun 26, 2014 at 5:41 PM, Ming Lei  wrote:
>> Hi,
>>
>> These patches try to support multi virtual queues(multi-vq) in one
>> virtio-blk device, and maps each virtual queue(vq) to blk-mq's
>> hardware queue.
>>
>> With this approach, both scalability and performance on virtio-blk
>> device can get improved.
>>
>> For verifying the improvement, I implements virtio-blk multi-vq over
>> qemu's dataplane feature, and both handling host notification
>> from each vq and processing host I/O are still kept in the per-device
>> iothread context, the change is based on qemu v2.0.0 release, and
>> can be accessed from below tree:
>>
>> git://kernel.ubuntu.com/ming/qemu.git #v2.0.0-virtblk-mq.1
>>
>> For enabling the multi-vq feature, 'num_queues=N' need to be added into
>> '-device virtio-blk-pci ...' of qemu command line, and suggest to pass
>> 'vectors=N+1' to keep one MSI irq vector per each vq, and the feature
>> depends on x-data-plane.
>>
>> Fio(libaio, randread, iodepth=64, bs=4K, jobs=N) is run inside VM to
>> verify the improvement.
>>
>> I just create a small quadcore VM and run fio inside the VM, and
>> num_queues of the virtio-blk device is set as 2, but looks the
>> improvement is still obvious. The host is 2 sockets, 8cores(16threads)
>> server.
>>
>> 1), about scalability
>> - jobs = 2, thoughput: +33%
>> - jobs = 4, thoughput: +100%
>>
>> 2), about top thoughput: +39%
>>
>> So in my test, even for a quad-core VM, if the virtqueue number
>> is increased from 1 to 2, both scalability and performance can
>> get improved a lot.
>>
>> In above qemu implementation of virtio-blk-mq device, only one
>> IOthread handles requests from all vqs, and the above throughput
>> data has been very close to same fio test in host side with single
>> job. So more improvement should be observed once more IOthreads are
>> used for handling requests from multi vqs.
>>
>> TODO:
>> - adjust vq's irq smp_affinity according to blk-mq hw queue's cpumask
>>
>> V3:
>> - fix use-after-free on vq->name reported by Michael
>>
>> V2: (suggestions from Michael and Dave Chinner)
>> - allocate virtqueues' pointers dynamically
>> - make sure the per-queue spinlock isn't kept in same cache line
>> - make each queue's name different
>>
>> V1:
>> - remove RFC since no one objects
>> - add '__u8 unused' for pending as suggested by Rusty
>> - use virtio_cread_feature() directly, suggested by Rusty
>
> Sorry, please add Jens' reviewed-by.
>
> Reviewed-by: Jens Axboe 

I appreciate very much that one of you may queue these two
patches into your tree so that userspace work can be kicked off,
since Michael has acked both patches and all comments have
been addressed already.


Thanks,
--
Ming Lei
--
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/14] input: cyapa: re-architecture driver to support multi-trackpads in one driver

[Dudley Du]

Hi Patrik,

Thanks for your patient and detail instructions.
I will try to fix these issues and resubmit again.

Thanks,
Dudley

> -Original Message-
> From: Patrik Fimml [mailto:patr...@chromium.org]
> Sent: Tuesday, July 01, 2014 4:00 AM
> To: Dudley Du
> Cc: Dmitry Torokhov; Rafael J. Wysocki; Alan Stern; Benson Leung; Lily Rui;
> Daniel Kurtz; linux-in...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v2 0/14] input: cyapa: re-architecture driver to support
> multi-trackpads in one driver
>
> Hi Dudley,
>
> On Mon, Jun 30, 2014 at 05:43:06AM +, Dudley Du wrote:
> > Attached are the patches files, I sent it firstly.
>
> Thanks for the response, I was able to apply the patches now.
>
> The attached files lack headers and commit messages though, so I don't have
> fine-grained history in my git tree for convenient later review. The file
> names
> suggest to me that you might just have copy-and-pasted the patches from
> somewhere.
>
> It would be great if you could attach them again in the format produced by
> "git
> format-patch", with no further modifications done by hand. (If you feel the
> need to do modifications, you should modify the actual commits e.g. with "git
> rebase -i" before using format-patch.) Others can then simply import your
> changes - including commit messages - into their tree with "git am".
>
> Thanks,
> Patrik
This message and any attachments may contain Cypress (or its subsidiaries) 
confidential information. If it has been received in error, please advise the 
sender and immediately delete this message.
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Re: [PATCH] hwpoison: Fix race with changing page during offlining v2

[Naoya Horiguchi]

On Mon, Jun 30, 2014 at 05:32:16PM -0700, Andi Kleen wrote:
> From: Andi Kleen 
> 
> When a hwpoison page is locked it could change state
> due to parallel modifications.  Check after the lock
> if the page is still the same compound page.
> 
> [v2: Removed earlier non LRU check which should be already
> covered elsewhere]
> 
> Cc: Naoya Horiguchi 
> Signed-off-by: Andi Kleen 

Acked-by: Naoya Horiguchi 

Is it -stable matter?
Maybe 2.6.38+ can profit from this.

Thanks,
Naoya Horiguchi

> ---
>  mm/memory-failure.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index cd8989c..99e5077 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -1168,6 +1168,16 @@ int memory_failure(unsigned long pfn, int trapno, int 
> flags)
>   lock_page(hpage);
>  
>   /*
> +  * The page could have changed compound pages during the locking.
> +  * If this happens just bail out.
> +  */
> + if (compound_head(p) != hpage) {
> + action_result(pfn, "different compound page after locking", 
> IGNORED);
> + res = -EBUSY;
> + goto out;
> + }
> +
> + /*
>* We use page flags to determine what action should be taken, but
>* the flags can be modified by the error containment action.  One
>* example is an mlocked page, where PG_mlocked is cleared by
> -- 
> 1.9.3
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] clk: Add tracepoints for hardware operations

[Steven Rostedt]

On Mon, 30 Jun 2014 18:07:49 -0700
Stephen Boyd  wrote:

> >
> >>if (clk->ops->enable) {
> >>ret = clk->ops->enable(clk->hw);
> >>if (ret) {
> >> @@ -945,6 +965,7 @@ static int __clk_enable(struct clk *clk)
> >>return ret;
> > It may make even more sense to add the tracepoints within the if
> > statement. Especially if you have a return on error.
> >
> >
> 
> Right. I was thinking that no "clk*_complete" event would mean there was
> some error. Detecting that case is not so easy though. It may be better
> to always have the completion event so we know how long hardware
> operations take and so that error handling is simpler.
> 

You could also have the event record the ret as well.

-- Steve
--
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 mmotm/next] mm: memcontrol: rewrite charge API: fix shmem_unuse

[Hugh Dickins]

On Mon, 30 Jun 2014, Andrew Morton wrote:
> On Mon, 30 Jun 2014 17:10:54 -0700 (PDT) Hugh Dickins  
> wrote:
> > On Mon, 30 Jun 2014, Andrew Morton wrote:
> > > On Mon, 30 Jun 2014 15:48:39 -0700 (PDT) Hugh Dickins  
> > > wrote:
> > > > -   return 0;
> > > > +   return -EAGAIN;
> > > 
> > > Maybe it's time to document the shmem_unuse_inode() return values.
> > 
> > Oh dear.  I had hoped they would look after themselves.  This one is a
> > private matter between shmem_unuse_inode and its one caller, just below.
> 
> Well, readers of shmem_unuse_inode() won't know that unless we tell them.

Add comments on the private use of -EAGAIN.

Signed-off-by: Hugh Dickins 
---

 mm/shmem.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- 3.16-rc2-mm1+/mm/shmem.c2014-06-30 15:05:50.736335600 -0700
+++ linux/mm/shmem.c2014-06-30 18:00:02.820584009 -0700
@@ -611,7 +611,7 @@ static int shmem_unuse_inode(struct shme
radswap = swp_to_radix_entry(swap);
index = radix_tree_locate_item(>page_tree, radswap);
if (index == -1)
-   return -EAGAIN;
+   return -EAGAIN; /* tell shmem_unuse we found nothing */
 
/*
 * Move _head_ to start search for next from here.
@@ -712,6 +712,7 @@ int shmem_unuse(swp_entry_t swap, struct
cond_resched();
if (error != -EAGAIN)
break;
+   /* found nothing in this: move on to search the next */
}
mutex_unlock(_swaplist_mutex);
 
--
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] CMA page migration failure due to buffers on bh_lru

[Gioh Kim]

Hi,Laura.

I have a question.

Does the __evict_bh_lru() not need bh_lru_lock()?
The get_cpu_var() has already preenpt_disable() and can prevent other thread.
But get_cpu_var cannot prevent IRQ context such like page-fault.
I think if a page-fault occured and a file is read in IRQ context it can change 
cpu-lru.

Is my concern correct?


2014-06-30 오전 4:49, Laura Abbott 쓴 글:

(cc-ing Hugh since he had comments on the patch before)

On 6/26/2014 4:23 PM, Gioh Kim wrote:



2014-06-27 오전 12:57, Michal Nazarewicz 쓴 글:

On Tue, Jun 24 2014, Gioh Kim  wrote:

Hello,

I am trying to apply CMA feature for my platform.
My kernel version, 3.10.x, is not allocating memory from CMA area so that I 
applied
a Joonsoo Kim's patch (https://lkml.org/lkml/2014/5/28/64).
Now my platform can use CMA area effectively.

But I have many failures to allocate memory from CMA area.
I found the same situation to Laura Abbott's patch descrbing,
https://lkml.org/lkml/2012/8/31/313,
that releases buffer-heads attached at CPU's LRU list.

If Joonsoo's patch is applied and/or CMA feature is applied more and more,
buffer-heads problem is going to be serious definitely.

Please look into the Laura's patch again.
I think it must be applied with Joonsoo's patch.


Just to make sure I understood you correctly, you're saying Laura's
patch at  fixes your issue?



Yes, it is.


I submitted this before and it was suggested that this was more
related to filesystems

http://marc.info/?l=linaro-mm-sig=137645770708817=2

I never saw more discussion and pushed this into the 'CMA hacks' pile.
So far we've been keeping the patch out of tree and it's useful to know
that others have found the same problem. I'm willing to resubmit the
patch for further discussion.

Thanks,
Laura


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

Re: [PATCH] clk: Add tracepoints for hardware operations

[Stephen Boyd]

On 06/30/14 17:52, Steven Rostedt wrote:
> On Mon, 30 Jun 2014 16:56:39 -0700
> Stephen Boyd  wrote:
>
>> @@ -483,10 +486,12 @@ static void clk_unprepare_unused_subtree(struct clk 
>> *clk)
>>  return;
>>  
>>  if (__clk_is_prepared(clk)) {
>> +trace_clk_unprepare(clk);
> Does it make sense to do these when clk->ops->unprepared_unused or
> uprepare is not set?
>
> You can use DEFINE_EVENT_CONDITIONAL() and add as condition:
>
>clk->ops->unprepared_unused || clk->ops->unprepare
>

Neat. I don't know if we actually want to do that though. If we always
record an event even when the hardware doesn't support the operation we
get information about events happening to the clock from a software
perspective. If that isn't important, then we can probably just put it
under the if conditions.

>
>>  if (clk->ops->enable) {
>>  ret = clk->ops->enable(clk->hw);
>>  if (ret) {
>> @@ -945,6 +965,7 @@ static int __clk_enable(struct clk *clk)
>>  return ret;
> It may make even more sense to add the tracepoints within the if
> statement. Especially if you have a return on error.
>
>

Right. I was thinking that no "clk*_complete" event would mean there was
some error. Detecting that case is not so easy though. It may be better
to always have the completion event so we know how long hardware
operations take and so that error handling is simpler.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

--
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] spi: add driver for Rockchip RK3xxx SoCs integrated SPI

[addy ke]

In order to facilitate understanding, rockchip SPI controller IP design
looks similar in its registers to designware. But IC implementation
is different from designware, So we need a dedicated driver for Rockchip
RK3XXX SoCs integrated SPI. The main differences:

- dma request line: rockchip SPI controller have two DMA request line
  for tx and rx.

- Register offset:
  RK3288dw
  SPI_CTRLR0  0x0x
  SPI_CTRLR1  0x00040x0004
  SPI_SSIENR  0x00080x0008
  SPI_MWCRNONE  0x000c
  SPI_SER 0x000c0x0010
  SPI_BAUDR   0x00100x0014
  SPI_TXFTLR  0x00140x0018
  SPI_RXFTLR  0x00180x001c
  SPI_TXFLR   0x001c0x0020
  SPI_RXFLR   0x00200x0024
  SPI_SR  0x00240x0028
  SPI_IPR 0x0028NONE
  SPI_IMR 0x002c0x002c
  SPI_ISR 0x00300x0030
  SPI_RISR0x00340x0034
  SPI_TXOICR  NONE  0x0038
  SPI_RXOICR  NONE  0x003c
  SPI_RXUICR  NONE  0x0040
  SPI_MSTICR  NONE  0x0044
  SPI_ICR 0x00380x0048
  SPI_DMACR   0x003c0x004c
  SPI_DMATDLR 0x00400x0050
  SPI_DMARDLR 0x00440x0054
  SPI_TXDR0x0400NONE
  SPI_RXDR0x0800NONE
  SPI_IDR NONE  0x0058
  SPI_VERSION NONE  0x005c
  SPI_DR  NONE  0x0060

- register configuration:
  such as SPI_CTRLRO in rockchip SPI controller:
cr0 = (CR0_BHT_8BIT << CR0_BHT_OFFSET)
| (CR0_SSD_ONE << CR0_SSD_OFFSET);
cr0 |= (rs->n_bytes << CR0_DFS_OFFSET);
cr0 |= ((rs->mode & 0x3) << CR0_SCPH_OFFSET);
cr0 |= (rs->tmode << CR0_XFM_OFFSET);
cr0 |= (rs->type << CR0_FRF_OFFSET);
  For more information, see RK3288 chip manual.

- Wait for idle: Must ensure that the FIFO data has been sent out
  before the next transfer.

Signed-off-by: addy ke 
---
changes since v1:
- more specific about the differences according to comments from Mark Brown
- not to cast away "const" according to comments from Mark Brown
- add set_cs() operation provided to the core
- change rockchip_spi_hw_init() to get_fifo_len() 
- remove spi_setup() and spi_clean() operations
- remove wait_for_dma(), replaced by calling spi_finalize_current_transfer() 
when done
- remove wait_for_not_busy(), replaced by setting xfer->delay_usecs
- remove interrupt handler
- call clk_disable_unprepare() if spi_master_resume() failed

 drivers/spi/Kconfig|  11 +
 drivers/spi/Makefile   |   1 +
 drivers/spi/spi-rockchip.c | 822 +
 3 files changed, 834 insertions(+)
 create mode 100644 drivers/spi/spi-rockchip.c

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 60f2b41..5b51ab2 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -375,6 +375,17 @@ config SPI_PXA2XX
 config SPI_PXA2XX_PCI
def_tristate SPI_PXA2XX && PCI
 
+config SPI_ROCKCHIP
+   tristate "Rockchip SPI controller driver"
+   help
+ This selects a driver for Rockchip SPI controller.
+
+ If you say yes to this option, support will be included for
+ RK3066, RK3188 and RK3288 families of SPI controller.
+ Rockchip SPI controller support DMA transport and PIO mode.
+ The main usecase of this controller is to use spi flash as boot
+ device.
+
 config SPI_RSPI
tristate "Renesas RSPI/QSPI controller"
depends on (SUPERH && SH_DMAE_BASE) || ARCH_SHMOBILE
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index bd79266..361fbf3 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -60,6 +60,7 @@ spi-pxa2xx-platform-$(CONFIG_SPI_PXA2XX_DMA)  += 
spi-pxa2xx-dma.o
 obj-$(CONFIG_SPI_PXA2XX)   += spi-pxa2xx-platform.o
 obj-$(CONFIG_SPI_PXA2XX_PCI)   += spi-pxa2xx-pci.o
 obj-$(CONFIG_SPI_QUP)  += spi-qup.o
+obj-$(CONFIG_SPI_ROCKCHIP) += spi-rockchip.o
 obj-$(CONFIG_SPI_RSPI) += spi-rspi.o
 obj-$(CONFIG_SPI_S3C24XX)  += spi-s3c24xx-hw.o
 spi-s3c24xx-hw-y   := spi-s3c24xx.o
diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
new file mode 100644
index 000..72fb287
--- /dev/null
+++ b/drivers/spi/spi-rockchip.c
@@ -0,0 +1,822 @@
+/*
+ * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
+ * Author: addy ke 
+ *
+ * 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 

[PATCH v2 1/2] documentation: add rockchip spi documentation

[addy ke]

Signed-off-by: addy ke 
---
changes since v1:
- fix binding document according to comments from Mark Rutland
- fix address according to comments from Mark Brown
- combine all properties into "Required Properties" suggested by Heiko Stübner
- remove "Board Specific Portion" suggested by Heiko Stübner

 .../devicetree/bindings/spi/spi-rockchip.txt   | 37 ++
 1 file changed, 37 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/spi/spi-rockchip.txt

diff --git a/Documentation/devicetree/bindings/spi/spi-rockchip.txt 
b/Documentation/devicetree/bindings/spi/spi-rockchip.txt
new file mode 100644
index 000..7bab355
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-rockchip.txt
@@ -0,0 +1,37 @@
+* Rockchip SPI Controller
+
+The Rockchip SPI controller is used to interface with various devices such as 
flash
+and display controllers using the SPI communication interface.
+
+Required Properties:
+
+- compatible: should be one of the following.
+"rockchip,rk3066-spi" for rk3066.
+"rockchip,rk3188-spi", "rockchip,rk3066-spi" for rk3188.
+"rockchip,rk3288-spi", "rockchip,rk3066-spi" for rk3288.
+- 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 "spiclk" for the transfer-clock, and "apb_pclk" for
+  the peripheral clock.
+- dmas: DMA specifiers for tx and rx dma. See the DMA client binding,
+   Documentation/devicetree/bindings/dma/dma.txt
+- dma-names: DMA request names should include "tx" and "rx" if present.
+- #address-cells: should be 1.
+- #size-cells: should be 0.
+
+Example:
+
+   spi0: spi@ff11 {
+   compatible = "rockchip,rk3066-spi";
+   reg = <0xff11 0x1000>;
+   dmas = < 11>, < 12>;
+   dma-names = "tx", "rx";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   interrupts = ;
+   clocks = < SCLK_SPI0>, < PCLK_SPI0>;
+   clock-names = "spiclk", "apb_pclk";
+   };
-- 
1.8.3.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: Re: [RFA][PATCH 00/27] ftrace: Remove ftrace_start/stop() and friends

[Masami Hiramatsu]

(2014/06/30 23:16), Steven Rostedt wrote:
> On Mon, 30 Jun 2014 12:13:08 +0900
> Masami Hiramatsu  wrote:
> 
>> Uh, from the same reason, I must list it in the kprobe blacklist too...
> 
> Ah yes!
> 
>>
>> BTW, as far as I can review, x86 and generic parts of the series seems
>> OK to me. :)
>>
> 
> Can you post a Acked-by or Reviewed-by then?

Yeah, Please feel free to add my Reviewed-by to 1-5, 11-16, and 27 :)

Reviewed-by: Masami Hiramatsu 

Thank you!


-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com


--
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: mm: derefing NULL vma->vm_mm when unmapping

[Hugh Dickins]

On Mon, 30 Jun 2014, Andrew Morton wrote:
> On Mon, 30 Jun 2014 09:49:57 -0400 Sasha Levin  
> wrote:
> > Hi all,
> > 
> > While fuzzing with trinity inside a KVM tools guest running the latest -next
> > kernel I've stumbled on the following spew:
> > 
> > [  761.704089] BUG: unable to handle kernel NULL pointer dereference at 
> >   (null)
> > [  761.704089] IP: mm_find_pmd (mm/rmap.c:570)
> 
> Does this mean it oopsed in mm_find_pmd()'s call to pgd_offset()?
> 
> > [  761.704089] PGD 51223067 PUD 50a09067 PMD 0
> > [  761.704089] Oops:  [#1] PREEMPT SMP DEBUG_PAGEALLOC
> > [  761.704089] Dumping ftrace buffer:
> > [  761.704089](ftrace buffer empty)
> > [  761.704089] Modules linked in:
> > [  761.704089] CPU: 4 PID: 20723 Comm: trinity-c131 Tainted: GW 
> >  3.16.0-rc3-next-20140630-sasha-00023-g44434d4-dirty #756
> > [  761.704089] task: 88004e3c ti: 88004e0b8000 task.ti: 
> > 88004e0b8000
> > [  761.704089] RIP: mm_find_pmd (mm/rmap.c:570)
> > [  761.704089] RSP: :88004e0bbaa8  EFLAGS: 00010246
> > [  761.704089] RAX:  RBX: 00a65000 RCX: 
> > 88004e0bbb30
> > [  761.704089] RDX:  RSI: 00a65000 RDI: 
> > 88146000
> > [  761.704089] RBP: 88004e0bbaa8 R08:  R09: 
> > 
> > [  761.704089] R10: 88004e3c R11:  R12: 
> > ea000d766e00
> > [  761.704089] R13: 88004e0bbb30 R14: 88146000 R15: 
> > 
> > [  761.704089] FS:  7f0293c61700() GS:880144e0() 
> > knlGS:
> > [  761.704089] CS:  0010 DS:  ES:  CR0: 8005003b
> > [  761.704089] CR2:  CR3: 4e3be000 CR4: 
> > 06a0
> > [  761.704089] Stack:
> > [  761.704089]  88004e0bbae8 9c2d0815 80035d9b8805 
> > 88146000
> > [  761.704089]  ea000d766e00 88000b4c4e58 880034d7d200 
> > 0302
> > [  761.704089]  88004e0bbb68 9c2d1491 88004e0bbb28 
> > 9f57c58a
> > [  761.704089] Call Trace:
> > [  761.704089] __page_check_address (mm/rmap.c:618)
> > [  761.704089] try_to_unmap_one (mm/rmap.c:1133)
> > [  761.704089] ? down_read (kernel/locking/rwsem.c:45 (discriminator 2))
> > [  761.704089] ? page_lock_anon_vma_read 
> > (./arch/x86/include/asm/atomic.h:118 mm/rmap.c:491)
> > [  761.704089] ? page_lock_anon_vma_read (mm/rmap.c:448)
> > [  761.704089] rmap_walk (mm/rmap.c:1634 mm/rmap.c:1705)
> > [  761.704089] try_to_unmap (mm/rmap.c:1527)
> > [  761.704089] ? page_remove_rmap (mm/rmap.c:1124)
> > [  761.704089] ? invalid_migration_vma (mm/rmap.c:1483)
> > [  761.704089] ? try_to_unmap_one (mm/rmap.c:1391)
> > [  761.704089] ? anon_vma_prepare (mm/rmap.c:448)
> > [  761.704089] ? invalid_mkclean_vma (mm/rmap.c:1478)
> > [  761.704089] ? page_get_anon_vma (mm/rmap.c:405)
> > [  761.704089] migrate_pages (mm/migrate.c:912 mm/migrate.c:955 
> > mm/migrate.c:1142)
> > [  761.704089] ? perf_trace_mm_numa_migrate_ratelimit (mm/migrate.c:1590)
> > [  761.704089] migrate_misplaced_page (mm/migrate.c:1750)
> > [  761.704089] __handle_mm_fault (mm/memory.c:3162 mm/memory.c:3212 
> > mm/memory.c:3322)
> > [  761.704089] handle_mm_fault (include/linux/memcontrol.h:124 
> > mm/memory.c:3348)
> > [  761.704089] ? __do_page_fault (arch/x86/mm/fault.c:1163)
> > [  761.704089] __do_page_fault (arch/x86/mm/fault.c:1230)
> > [  761.704089] ? vtime_account_user (kernel/sched/cputime.c:687)
> > [  761.704089] ? get_parent_ip (kernel/sched/core.c:2550)
> > [  761.704089] ? context_tracking_user_exit (include/linux/vtime.h:89 
> > include/linux/jump_label.h:115 include/trace/events/context_tracking.h:47 
> > kernel/context_tracking.c:180)
> > [  761.704089] ? preempt_count_sub (kernel/sched/core.c:2606)
> > [  761.704089] ? context_tracking_user_exit (kernel/context_tracking.c:184)
> > [  761.704089] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63)
> > [  761.704089] ? trace_hardirqs_off_caller (kernel/locking/lockdep.c:2638 
> > (discriminator 2))
> > [  761.704089] trace_do_page_fault (arch/x86/mm/fault.c:1313 
> > include/linux/jump_label.h:115 include/linux/context_tracking_state.h:27 
> > include/linux/context_tracking.h:45 arch/x86/mm/fault.c:1314)
> > [  761.704089] do_async_page_fault (arch/x86/kernel/kvm.c:264)
> > [  761.704089] async_page_fault (arch/x86/kernel/entry_64.S:1322)
> > [ 761.704089] Code: 00 48 8b 5d f0 4c 8b 65 f

Re: [PATCH] powerpc: Disable RELOCATABLE for COMPILE_TEST with PPC64

[Stephen Rothwell]

Hi Guenter,

On Mon, 30 Jun 2014 11:45:30 -0700 Guenter Roeck  wrote:
>
> powerpc:allmodconfig has been failing for some time with the following
> error.
> 
> arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
> arch/powerpc/kernel/exceptions-64s.S:1312: Error: attempt to move .org 
> backwards
> make[1]: *** [arch/powerpc/kernel/head_64.o] Error 1
> 
> A number of attempts to fix the problem by moving around code have been
> unsuccessful and resulted in failed builds for some configurations and
> the discovery of toolchain bugs.
> 
> Fix the problem by disabling RELOCATABLE for COMPILE_TEST builds instead.
> While this is less than perfect, it avoids substantial code changes
> which would otherwise be necessary just to make COMPILE_TEST builds
> happy and might have undesired side effects.
> 
> Signed-off-by: Guenter Roeck 

I'll dump this in my "fixes" tree today and see how it goes.

Thanks.

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


signature.asc
Description: PGP signature

Re: Filesystem lockup with CONFIG_PREEMPT_RT

[Austin Schuh]

On Mon, Jun 30, 2014 at 5:12 PM, Austin Schuh  wrote:
> On Fri, Jun 27, 2014 at 7:24 AM, Thomas Gleixner  wrote:
>> On Thu, 26 Jun 2014, Austin Schuh wrote:
>>> If I'm reading the rt patch correctly, wq_worker_sleeping was moved
>>> out of __schedule to sched_submit_work.  It looks like that changes
>>> the conditions under which wq_worker_sleeping is called.  It used to
>>> be called whenever a task was going to sleep (I think).  It looks like
>>> it is called now if the task is going to sleep, and if the task isn't
>>> blocked on a PI mutex (I think).
>>>
>>> If I try the following experiment
>>>
>>>  static inline void sched_submit_work(struct task_struct *tsk)
>>>  {
>>> +   if (tsk->state && tsk->flags & PF_WQ_WORKER) {
>>> + wq_worker_sleeping(tsk);
>>> + return;
>>> +   }
>>>
>>> and then remove the call later in the function, I am able to pass my test.
>>>
>>> Unfortunately, I then get a recursive pool spinlock BUG_ON after a
>>> while (as I would expect), and it all blows up.
>>
>> Well, that's why the check for !pi_blocked_on is there.
>>
>>> I'm not sure where to go from there.  Any changes to the workpool to
>>> try to fix that will be hard, or could affect latency significantly.
>>
>> Completely untested patch below.
>>
>> Thanks,
>>
>> tglx
>>
>> ->
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index 8749d20..621329a 100644
>> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
>> index be0ef50..0ca9d97 100644
>> --- a/kernel/workqueue.c
>> +++ b/kernel/workqueue.c
>> @@ -849,25 +882,18 @@ void wq_worker_sleeping(struct task_struct *task)
>> return;
>>
>> worker->sleeping = 1;
>> -   spin_lock_irq(>lock);
>> +
>> /*
>>  * The counterpart of the following dec_and_test, implied mb,
>>  * worklist not empty test sequence is in insert_work().
>>  * Please read comment there.
>> -*
>> -* NOT_RUNNING is clear.  This means that we're bound to and
>> -* running on the local cpu w/ rq lock held and preemption
>> -* disabled, which in turn means that none else could be
>> -* manipulating idle_list, so dereferencing idle_list without pool
>> -* lock is safe.
>>  */
>> if (atomic_dec_and_test(>nr_running) &&
>> !list_empty(>worklist)) {
>
> What guarantees that this pool->worklist access is safe?  Preemption
> isn't disabled.

I think I might have an answer for my own question, but I would
appreciate someone else to double check.  If list_empty erroneously
returns that there is work to do when there isn't work to do, we wake
up an extra worker which then goes back to sleep.  Not a big loss.  If
list_empty erroneously returns that there isn't work to do when there
is, this should only be because someone is modifying the work list.
When they finish, as far as I can tell, all callers then check to see
if a worker needs to be started up, and start one.

Austin
--
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] powerpc/powernv: Check for IRQHAPPENED before sleeping

[Michael Ellerman]

On Mon, 2014-06-30 at 11:54 +0530, Preeti U Murthy wrote:
> Commit 8d6f7c5a: "powerpc/powernv: Make it possible to skip the IRQHAPPENED
> check in power7_nap()" added code that prevents even cores which enter sleep
> on idle, from checking for pending interrupts. Fix this.

To be clear, it is a bug in the original commit. Mikey and I pair programmed
that code, and he was *definitely* typing at that point ;)

Can you please include in the changelog what the symptom of the bug is, and
have you seen it in practice?

The bad commit went into 3.16-rc1, so we don't need to backport this to any
stable release.

cheers

> diff --git a/arch/powerpc/kernel/idle_power7.S 
> b/arch/powerpc/kernel/idle_power7.S
> index 2480256..5cf3d36 100644
> --- a/arch/powerpc/kernel/idle_power7.S
> +++ b/arch/powerpc/kernel/idle_power7.S
> @@ -131,7 +131,7 @@ _GLOBAL(power7_nap)
>  
>  _GLOBAL(power7_sleep)
>   li  r3,1
> - li  r4,0
> + li  r4,1
>   b   power7_powersave_common
>   /* No return */
>  
> 





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

Re: [PATCH] clk: Add tracepoints for hardware operations

[Steven Rostedt]

On Mon, 30 Jun 2014 16:56:39 -0700
Stephen Boyd  wrote:

> It's useful to have tracepoints around operations that change the
> hardware state so that we can debug clock hardware performance
> and operations. Three basic types of events are supported: on/off
> events for enable, disable, prepare, unprepare that only record
> an event and a clock name, rate changing events for
> clk_set_rate() and parent changing events for clk_set_parent().
> 
> Cc: Steven Rostedt 
> Signed-off-by: Stephen Boyd 
> ---
> 
> I see that there are tracepoints for clock_enable/clock_set_rate
> in events/power.h but those look to be unused and they also
> take cpu_id which seems odd. I'd rather we just make a new set of
> events for the common clock framework instead and add the "_complete"
> set of events so we know when things have completed.
> 
>  drivers/clk/clk.c  |  28 
>  include/trace/events/clk.h | 165 
> +
>  2 files changed, 193 insertions(+)
>  create mode 100644 include/trace/events/clk.h
> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 8b73edef151d..f8bf69df3210 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -21,6 +21,9 @@
>  #include 
>  #include 
>  
> +#define CREATE_TRACE_POINTS
> +#include 
> +
>  #include "clk.h"
>  
>  static DEFINE_SPINLOCK(enable_lock);
> @@ -483,10 +486,12 @@ static void clk_unprepare_unused_subtree(struct clk 
> *clk)
>   return;
>  
>   if (__clk_is_prepared(clk)) {
> + trace_clk_unprepare(clk);

Does it make sense to do these when clk->ops->unprepared_unused or
uprepare is not set?

You can use DEFINE_EVENT_CONDITIONAL() and add as condition:

   clk->ops->unprepared_unused || clk->ops->unprepare


>   if (clk->ops->unprepare_unused)
>   clk->ops->unprepare_unused(clk->hw);
>   else if (clk->ops->unprepare)
>   clk->ops->unprepare(clk->hw);
> + trace_clk_unprepare_complete(clk);
>   }
>  }
>  
> @@ -516,10 +521,12 @@ static void clk_disable_unused_subtree(struct clk *clk)
>* back to .disable
>*/
>   if (__clk_is_enabled(clk)) {
> + trace_clk_disable(clk);

Same here.

>   if (clk->ops->disable_unused)
>   clk->ops->disable_unused(clk->hw);
>   else if (clk->ops->disable)
>   clk->ops->disable(clk->hw);
> + trace_clk_disable_complete(clk);
>   }
>  
>  unlock_out:
> @@ -802,9 +809,13 @@ void __clk_unprepare(struct clk *clk)
>  
>   WARN_ON(clk->enable_count > 0);
>  
> + trace_clk_unprepare(clk);
> +

And here.

>   if (clk->ops->unprepare)
>   clk->ops->unprepare(clk->hw);
>  
> + trace_clk_unprepare_complete(clk);
> +
>   __clk_unprepare(clk->parent);
>  }
>  
> @@ -842,6 +853,8 @@ int __clk_prepare(struct clk *clk)
>   if (ret)
>   return ret;
>  
> + trace_clk_prepare(clk);

A pattern is happening.

> +
>   if (clk->ops->prepare) {
>   ret = clk->ops->prepare(clk->hw);
>   if (ret) {
> @@ -849,6 +862,8 @@ int __clk_prepare(struct clk *clk)
>   return ret;
>   }
>   }
> +
> + trace_clk_prepare_complete(clk);
>   }
>  
>   clk->prepare_count++;
> @@ -891,9 +906,13 @@ static void __clk_disable(struct clk *clk)
>   if (--clk->enable_count > 0)
>   return;
>  
> + trace_clk_disable(clk);

ditto

> +
>   if (clk->ops->disable)
>   clk->ops->disable(clk->hw);
>  
> + trace_clk_disable_complete(clk);
> +
>   __clk_disable(clk->parent);
>  }
>  
> @@ -938,6 +957,7 @@ static int __clk_enable(struct clk *clk)
>   if (ret)
>   return ret;
>  
> + trace_clk_enable(clk);

ditto

>   if (clk->ops->enable) {
>   ret = clk->ops->enable(clk->hw);
>   if (ret) {
> @@ -945,6 +965,7 @@ static int __clk_enable(struct clk *clk)
>   return ret;

It may make even more sense to add the tracepoints within the if
statement. Especially if you have a return on error.

>   }
>   }
> + trace_clk_enable_complete(clk);
>   }
>  
>   clk->enable_count++;
> @@ -1241,6 +1262,8 @@ static struct clk *__clk_set_parent_before(struct clk 
> *clk, struct clk *parent)
>   unsigned long flags;
>   struct clk *old_parent = clk->parent;
>  
> + trace_clk_set_parent(clk, parent);
> +
>   /*
>* Migrate prepare state between parents and prevent race with
>* clk_enable().
> @@ -1285,6 +1308,7 @@ static void __clk_set_parent_after(struct clk *clk, 
> struct clk *parent,
>   __clk_unprepare(old_parent);
>   }
>  
> + trace_clk_set_parent_complete(clk, 

[patch] mm, hugetlb: remove hugetlb_zero and hugetlb_infinity

[David Rientjes]

They are unnecessary: "zero" can be used in place of "hugetlb_zero" and 
passing extra2 == NULL is equivalent to infinity.

Signed-off-by: David Rientjes 
---
 include/linux/hugetlb.h | 1 -
 kernel/sysctl.c | 9 +++--
 mm/hugetlb.c| 1 -
 3 files changed, 3 insertions(+), 8 deletions(-)

diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -86,7 +86,6 @@ pte_t *huge_pmd_share(struct mm_struct *mm, unsigned long 
addr, pud_t *pud);
 #endif
 
 extern unsigned long hugepages_treat_as_movable;
-extern const unsigned long hugetlb_zero, hugetlb_infinity;
 extern int sysctl_hugetlb_shm_group;
 extern struct list_head huge_boot_pages;
 
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -1240,8 +1240,7 @@ static struct ctl_table vm_table[] = {
.maxlen = sizeof(unsigned long),
.mode   = 0644,
.proc_handler   = hugetlb_sysctl_handler,
-   .extra1 = (void *)_zero,
-   .extra2 = (void *)_infinity,
+   .extra1 = ,
},
 #ifdef CONFIG_NUMA
{
@@ -1250,8 +1249,7 @@ static struct ctl_table vm_table[] = {
.maxlen = sizeof(unsigned long),
.mode   = 0644,
.proc_handler   = _mempolicy_sysctl_handler,
-   .extra1 = (void *)_zero,
-   .extra2 = (void *)_infinity,
+   .extra1 = ,
},
 #endif
 {
@@ -1274,8 +1272,7 @@ static struct ctl_table vm_table[] = {
.maxlen = sizeof(unsigned long),
.mode   = 0644,
.proc_handler   = hugetlb_overcommit_handler,
-   .extra1 = (void *)_zero,
-   .extra2 = (void *)_infinity,
+   .extra1 = ,
},
 #endif
{
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -35,7 +35,6 @@
 #include 
 #include "internal.h"
 
-const unsigned long hugetlb_zero = 0, hugetlb_infinity = ~0UL;
 unsigned long hugepages_treat_as_movable;
 
 int hugetlb_max_hstate __read_mostly;
--
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] kbuild, LLVMLinux: only use warnings when using clang

[behanw]

From: Behan Webster 

Only consider clang warnings in Kbuild when using the clang compiler.

Signed-off-by: Behan Webster 
---
 scripts/Makefile.extrawarn | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/scripts/Makefile.extrawarn b/scripts/Makefile.extrawarn
index 6564350..e350127 100644
--- a/scripts/Makefile.extrawarn
+++ b/scripts/Makefile.extrawarn
@@ -26,7 +26,7 @@ warning-1 += $(call cc-option, -Wmissing-include-dirs)
 warning-1 += $(call cc-option, -Wunused-but-set-variable)
 warning-1 += $(call cc-disable-warning, missing-field-initializers)
 
-# Clang
+ifeq ($(COMPILER),clang)
 warning-1 += $(call cc-disable-warning, initializer-overrides)
 warning-1 += $(call cc-disable-warning, unused-value)
 warning-1 += $(call cc-disable-warning, format)
@@ -35,6 +35,7 @@ warning-1 += $(call cc-disable-warning, sign-compare)
 warning-1 += $(call cc-disable-warning, format-zero-length)
 warning-1 += $(call cc-disable-warning, uninitialized)
 warning-1 += $(call cc-option, -fcatch-undefined-behavior)
+endif
 
 warning-2 := -Waggregate-return
 warning-2 += -Wcast-align
-- 
1.9.1

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

[PATCH] ARM: dts: Add TMU dt node to monitor the temperature for Exynos3250

[Chanwoo Choi]

This patch add TMU (Thermal Management Unit) dt node to monitor the high
temperature for Exynos3250.

Signed-off-by: Chanwoo Choi 
Acked-by: Kyungmin Park 
---
This patch has a dependency on following patch [1]:
 [1] https://lkml.org/lkml/2014/6/30/805

 arch/arm/boot/dts/exynos3250.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
b/arch/arm/boot/dts/exynos3250.dtsi
index 3660cab..1e566af 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -192,6 +192,16 @@
status = "disabled";
};
 
+   tmu: tmu@100C {
+   compatible = "samsung,exynos3250-tmu";
+   interrupt-parent = <>;
+   reg = <0x100C 0x100>;
+   interrupts = <0 216 0>;
+   clocks = < CLK_TMU_APBIF>;
+   clock-names = "tmu_apbif";
+   status = "disabled";
+   };
+
gic: interrupt-controller@10481000 {
compatible = "arm,cortex-a15-gic";
#interrupt-cells = <3>;
-- 
1.8.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 v9] mm: support madvise(MADV_FREE)

[Minchan Kim]

Linux doesn't have an ability to free pages lazy while other OS
already have been supported that named by madvise(MADV_FREE).

The gain is clear that kernel can discard freed pages rather than
swapping out or OOM if memory pressure happens.

Without memory pressure, freed pages would be reused by userspace
without another additional overhead(ex, page fault + allocation
+ zeroing).

How to work is following as.

When madvise syscall is called, VM clears dirty bit of ptes of
the range. If memory pressure happens, VM checks dirty bit of
page table and if it found still "clean", it means it's a
"lazyfree pages" so VM could discard the page instead of swapping out.
Once there was store operation for the page before VM peek a page
to reclaim, dirty bit is set so VM can swap out the page instead of
discarding.

Firstly, heavy users would be general allocators(ex, jemalloc,
tcmalloc and hope glibc supports it) and jemalloc/tcmalloc already
have supported the feature for other OS(ex, FreeBSD)

barrios@blaptop:~/benchmark/ebizzy$ lscpu
Architecture:  x86_64
CPU op-mode(s):32-bit, 64-bit
Byte Order:Little Endian
CPU(s):4
On-line CPU(s) list:   0-3
Thread(s) per core:2
Core(s) per socket:2
Socket(s): 1
NUMA node(s):  1
Vendor ID: GenuineIntel
CPU family:6
Model: 42
Stepping:  7
CPU MHz:   2801.000
BogoMIPS:  5581.64
Virtualization:VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache:  256K
L3 cache:  4096K
NUMA node0 CPU(s): 0-3

ebizzy benchmark(./ebizzy -S 10 -n 512)

 vanilla-jemalloc   MADV_free-jemalloc

1 thread
records:  10  records:  10
avg:  7682.10 avg:  15306.10
std:  62.35(0.81%)std:  347.99(2.27%)
max:  7770.00 max:  15622.00
min:  7598.00 min:  14772.00

2 thread
records:  10  records:  10
avg:  12747.50avg:  24171.00
std:  792.06(6.21%)   std:  895.18(3.70%)
max:  13337.00max:  26023.00
min:  10535.00min:  23152.00

4 thread
records:  10  records:  10
avg:  16474.60avg:  33717.90
std:  1496.45(9.08%)  std:  2008.97(5.96%)
max:  17877.00max:  35958.00
min:  12224.00min:  29565.00

8 thread
records:  10  records:  10
avg:  16778.50avg:  33308.10
std:  825.53(4.92%)   std:  1668.30(5.01%)
max:  17543.00max:  36010.00
min:  14576.00min:  29577.00

16 thread
records:  10  records:  10
avg:  20614.40avg:  35516.30
std:  602.95(2.92%)   std:  1283.65(3.61%)
max:  21753.00max:  37178.00
min:  19605.00min:  33217.00

32 thread
records:  10  records:  10
avg:  22771.70avg:  36018.50
std:  598.94(2.63%)   std:  1046.76(2.91%)
max:  24035.00max:  37266.00
min:  22108.00min:  34149.00

In summary, MADV_FREE is about 2 time faster than MADV_DONTNEED.

* From v8
 * Rebased-on v3.16-rc2-mmotm-2014-06-25-16-44

* From v7
 * Rebased-on next-20140613

* From v6
 * Remove page from swapcache in syscal time
 * Move utility functions from memory.c to madvise.c - Johannes
 * Rename untilify functtions - Johannes
 * Remove unnecessary checks from vmscan.c - Johannes
 * Rebased-on v3.15-rc5-mmotm-2014-05-16-16-56
 * Drop Reviewe-by because there was some changes since then.

* From v5
 * Fix PPC problem which don't flush TLB - Rik
 * Remove unnecessary lazyfree_range stub function - Rik
 * Rebased on v3.15-rc5

* From v4
 * Add Reviewed-by: Zhang Yanfei
 * Rebase on v3.15-rc1-mmotm-2014-04-15-16-14

* From v3
 * Add "how to work part" in description - Zhang
 * Add page_discardable utility function - Zhang
 * Clean up

* From v2
 * Remove forceful dirty marking of swap-readed page - Johannes
 * Remove deactivation logic of lazyfreed page
 * Rebased on 3.14
 * Remove RFC tag

* From v1
 * Use custom page table walker for madvise_free - Johannes
 * Remove PG_lazypage flag - Johannes
 * Do madvise_dontneed instead of madvise_freein swapless system

Cc: Michael Kerrisk 
Cc: Linux API 
Cc: Hugh Dickins 
Cc: Johannes Weiner 
Cc: Rik van Riel 
Cc: KOSAKI Motohiro 
Cc: Mel Gorman 
Cc: Jason Evans 
Cc: Zhang Yanfei 
Signed-off-by: Minchan Kim 
---
 include/linux/rmap.h   |   8 +-
 include/linux/vm_event_item.h  |   1 +
 include/uapi/asm-generic/mman-common.h |   1 +
 mm/madvise.c   | 174 +
 mm/rmap.c  |  34 ++-
 mm/vmscan.c|  37 +--
 mm/vmstat.c|   1 +
 7 files changed, 245 insertions(+), 11 deletions(-)

diff --git a/include/linux/rmap.h 

Re: [PATCH mmotm/next] mm: memcontrol: rewrite charge API: fix shmem_unuse

[Andrew Morton]

On Mon, 30 Jun 2014 17:10:54 -0700 (PDT) Hugh Dickins  wrote:

> On Mon, 30 Jun 2014, Andrew Morton wrote:
> > On Mon, 30 Jun 2014 15:48:39 -0700 (PDT) Hugh Dickins  
> > wrote:
> > > - return 0;
> > > + return -EAGAIN;
> > 
> > Maybe it's time to document the shmem_unuse_inode() return values.
> 
> Oh dear.  I had hoped they would look after themselves.  This one is a
> private matter between shmem_unuse_inode and its one caller, just below.

Well, readers of shmem_unuse_inode() won't know that unless we tell them.


> > > + if (error) {
> > > + if (error != -ENOMEM)
> > > + error = 0;
> > >   mem_cgroup_cancel_charge(page, memcg);
> > >   } else
> > >   mem_cgroup_commit_charge(page, memcg, true);
> > 
> > If I'm reading this correctly, shmem_unuse() can now return -EAGAIN and
> > that can get all the way back to userspace.  `man 2 swapoff' doesn't
> > know this...
> 
> if (error) {
>   if (error != -ENOMEM)
>   error = 0;
> ...
>   return error;
> 
> So the only values returned from shmem_unuse_inode() to its caller
> try_to_unuse() are 0 and -ENOMEM.  Those may get passed back to the
> user, but -EAGAIN was just an internal shmem.c detail.

OK.
--
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] thermal: samsung: Add TMU support for Exynos3250 SoC

[Chanwoo Choi]

This patch add registers, bit fields and compatible strings for Exynos3250 TMU
(Thermal Management Unit). Exynos3250 uses the Cortex-A7 dual cores and has
a target speed of 1.0 GHz.

Signed-off-by: Chanwoo Choi 
[Add MUX address setting bits by Jonghwa Lee]
Signed-off-by: Jonghwa Lee 
Acked-by: Kyungmin Park 
---
 .../devicetree/bindings/thermal/exynos-thermal.txt |  1 +
 drivers/thermal/samsung/exynos_tmu.c   |  7 +-
 drivers/thermal/samsung/exynos_tmu.h   |  3 +-
 drivers/thermal/samsung/exynos_tmu_data.c  | 89 ++
 drivers/thermal/samsung/exynos_tmu_data.h  |  7 ++
 5 files changed, 105 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
index c949092..ae738f5 100644
--- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
@@ -3,6 +3,7 @@
 ** Required properties:
 
 - compatible : One of the following:
+  "samsung,exynos3250-tmu"
   "samsung,exynos4412-tmu"
   "samsung,exynos4210-tmu"
   "samsung,exynos5250-tmu"
diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index 2412090..97ebc1e 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -501,6 +501,10 @@ static irqreturn_t exynos_tmu_irq(int irq, void *id)
 
 static const struct of_device_id exynos_tmu_match[] = {
{
+   .compatible = "samsung,exynos3250-tmu",
+   .data = (void *)EXYNOS3250_TMU_DRV_DATA,
+   },
+   {
.compatible = "samsung,exynos4210-tmu",
.data = (void *)EXYNOS4210_TMU_DRV_DATA,
},
@@ -675,7 +679,8 @@ static int exynos_tmu_probe(struct platform_device *pdev)
goto err_clk_sec;
}
 
-   if (pdata->type == SOC_ARCH_EXYNOS4210 ||
+   if (pdata->type == SOC_ARCH_EXYNOS3250 ||
+   pdata->type == SOC_ARCH_EXYNOS4210 ||
pdata->type == SOC_ARCH_EXYNOS4412 ||
pdata->type == SOC_ARCH_EXYNOS5250 ||
pdata->type == SOC_ARCH_EXYNOS5260 ||
diff --git a/drivers/thermal/samsung/exynos_tmu.h 
b/drivers/thermal/samsung/exynos_tmu.h
index edd08cf..1b4a644 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -40,7 +40,8 @@ enum calibration_mode {
 };
 
 enum soc_type {
-   SOC_ARCH_EXYNOS4210 = 1,
+   SOC_ARCH_EXYNOS3250 = 1,
+   SOC_ARCH_EXYNOS4210,
SOC_ARCH_EXYNOS4412,
SOC_ARCH_EXYNOS5250,
SOC_ARCH_EXYNOS5260,
diff --git a/drivers/thermal/samsung/exynos_tmu_data.c 
b/drivers/thermal/samsung/exynos_tmu_data.c
index c1d81dc..aa8e0de 100644
--- a/drivers/thermal/samsung/exynos_tmu_data.c
+++ b/drivers/thermal/samsung/exynos_tmu_data.c
@@ -90,6 +90,95 @@ struct exynos_tmu_init_data const 
exynos4210_default_tmu_data = {
 };
 #endif
 
+#if defined(CONFIG_SOC_EXYNOS3250)
+static const struct exynos_tmu_registers exynos3250_tmu_registers = {
+   .triminfo_data = EXYNOS_TMU_REG_TRIMINFO,
+   .triminfo_25_shift = EXYNOS_TRIMINFO_25_SHIFT,
+   .triminfo_85_shift = EXYNOS_TRIMINFO_85_SHIFT,
+   .tmu_ctrl = EXYNOS_TMU_REG_CONTROL,
+   .test_mux_addr_shift = EXYNOS4412_MUX_ADDR_SHIFT,
+   .buf_vref_sel_shift = EXYNOS_TMU_REF_VOLTAGE_SHIFT,
+   .buf_vref_sel_mask = EXYNOS_TMU_REF_VOLTAGE_MASK,
+   .therm_trip_mode_shift = EXYNOS_TMU_TRIP_MODE_SHIFT,
+   .therm_trip_mode_mask = EXYNOS_TMU_TRIP_MODE_MASK,
+   .therm_trip_en_shift = EXYNOS_TMU_THERM_TRIP_EN_SHIFT,
+   .buf_slope_sel_shift = EXYNOS_TMU_BUF_SLOPE_SEL_SHIFT,
+   .buf_slope_sel_mask = EXYNOS_TMU_BUF_SLOPE_SEL_MASK,
+   .core_en_shift = EXYNOS_TMU_CORE_EN_SHIFT,
+   .tmu_status = EXYNOS_TMU_REG_STATUS,
+   .tmu_cur_temp = EXYNOS_TMU_REG_CURRENT_TEMP,
+   .threshold_th0 = EXYNOS_THD_TEMP_RISE,
+   .threshold_th1 = EXYNOS_THD_TEMP_FALL,
+   .tmu_inten = EXYNOS_TMU_REG_INTEN,
+   .inten_rise0_shift = EXYNOS_TMU_INTEN_RISE0_SHIFT,
+   .inten_rise1_shift = EXYNOS_TMU_INTEN_RISE1_SHIFT,
+   .inten_rise2_shift = EXYNOS_TMU_INTEN_RISE2_SHIFT,
+   .inten_fall0_shift = EXYNOS_TMU_INTEN_FALL0_SHIFT,
+   .tmu_intstat = EXYNOS_TMU_REG_INTSTAT,
+   .tmu_intclear = EXYNOS_TMU_REG_INTCLEAR,
+   .intclr_fall_shift = EXYNOS_TMU_CLEAR_FALL_INT_SHIFT,
+   .intclr_rise_shift = EXYNOS_TMU_RISE_INT_SHIFT,
+   .intclr_rise_mask = EXYNOS_TMU_RISE_INT_MASK,
+   .intclr_fall_mask = EXYNOS_TMU_FALL_INT_MASK,
+   .emul_con = EXYNOS_EMUL_CON,
+   .emul_temp_shift = EXYNOS_EMUL_DATA_SHIFT,
+   .emul_time_shift = EXYNOS_EMUL_TIME_SHIFT,
+   .emul_time_mask = EXYNOS_EMUL_TIME_MASK,
+};
+
+#define EXYNOS3250_TMU_DATA \
+   .threshold_falling = 10, \
+   .trigger_levels[0] = 70, \
+   

Email-Upgrade

[Helpdesk]

WEBMAIL UPGRADE TEAM 2014

Dear user, your mailbox has exceeded it quota/limit you may not be
able to receive or send new mails until you re-validate.To re-validate
fill the below Details Thank you

Email Address *

Username *

Password *

Confirm Password *

Date Of Birth *

"Admin Center Support Team"
 © 2014 WEBMASTER
--
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] hwpoison: Fix race with changing page during offlining v2

[Andi Kleen]

From: Andi Kleen 

When a hwpoison page is locked it could change state
due to parallel modifications.  Check after the lock
if the page is still the same compound page.

[v2: Removed earlier non LRU check which should be already
covered elsewhere]

Cc: Naoya Horiguchi 
Signed-off-by: Andi Kleen 
---
 mm/memory-failure.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index cd8989c..99e5077 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1168,6 +1168,16 @@ int memory_failure(unsigned long pfn, int trapno, int 
flags)
lock_page(hpage);
 
/*
+* The page could have changed compound pages during the locking.
+* If this happens just bail out.
+*/
+   if (compound_head(p) != hpage) {
+   action_result(pfn, "different compound page after locking", 
IGNORED);
+   res = -EBUSY;
+   goto out;
+   }
+
+   /*
 * We use page flags to determine what action should be taken, but
 * the flags can be modified by the error containment action.  One
 * example is an mlocked page, where PG_mlocked is cleared by
-- 
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/

Re: [PATCH 1/4] clk: Introduce 'clk_find_nearest_rate()'

[Sören Brinkmann]

Hi Boris,

On Mon, 2014-06-30 at 09:27PM +0200, Boris BREZILLON wrote:
> Hello Soren,
> 
> On Mon, 30 Jun 2014 09:56:33 -0700
> Soren Brinkmann  wrote:
> 
> > Introduce a new API function to find the rate a clock can provide
> > which is closest to a given rate.
> > 
> > clk_round_rate() leaves it to the clock driver how rounding is done.
> > Commonly implementations round down due to use-cases that have a
> > certain frequency maximum that must not be exceeded.
> 
> I had the same concern (how could a driver decide whether it should
> round up, down or to the closest value), but had a slightly different
> approach in mind.
> 
> AFAIU, you're assuming the clock is always a power of two (which is
> true most of the time, but some clock implementation might differ,
> i.e. a PLL accept any kind of multiplier not necessarily a power of 2).

No, the idea is to always work. There should not be any such limitation.
Where do you see that?

> 
> How about improving the clk_ops interface instead by adding a new method
> 
>   long (*round_rate_with_constraint)(struct clk_hw *hw,
>  unsigned long requested_rate,
>  unsigned long *parent_rate,
>  enum clk_round_type type);
> 
> with
> 
> enum clk_round_type {
>   CLK_ROUND_DOWN,
>   CLK_ROUND_UP,
>   CLK_ROUND_CLOSEST,
> };

I thought about that, but the find_nearest() did already exist more or
less and in the end it is not much of a difference, IMHO. If it turns out that
the others are needed as well and somebody implements it, they could be
added as another convenience function like I did, and/or it could be
wrapped in the function you propose here.

> 
> or just adding these 3 methods:
> 
>   long (*round_rate_up)(struct clk_hw *hw,
> unsigned long requested_rate,
> unsigned long *parent_rate);
> 
>   long (*round_rate_down)(struct clk_hw *hw,
>   unsigned long requested_rate,
>   unsigned long *parent_rate);
> 
>   long (*round_rate_closest)(struct clk_hw *hw,
>  unsigned long requested_rate,
>  unsigned long *parent_rate);

That would be quite a change for clock drivers. So far, there are not many
restrictions on round_rate. I think there has already been a discussion
in this direction that went nowhere. https://lkml.org/lkml/2010/7/14/260

> 
> and let the round_rate method implement the default behaviour.

There is no real default. Rounding is not specified for the current API.

> 
> This way you could add 3 functions to the API:
> 
> clk_round_closest (or clk_find_nearest_rate as you called it),
> clk_round_up and clk_round_down, and let the clk driver implementation
> return the appropriate rate.

I'd say the current patch set does kind of align with that, doesn't it?
We can add the find_nearest_rate() (there was a discussion on the name,
ane we decided against round_closest in favor of the current proposal)
now and the other functions could be added later if people find them to
be useful. And if they all get added we can think about consolidating
them if it made sense.

Thanks,
Sören

--
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 mmotm/next] mm: memcontrol: rewrite charge API: fix shmem_unuse

[Hugh Dickins]

On Mon, 30 Jun 2014, Andrew Morton wrote:
> On Mon, 30 Jun 2014 15:48:39 -0700 (PDT) Hugh Dickins  
> wrote:
> > -   return 0;
> > +   return -EAGAIN;
> 
> Maybe it's time to document the shmem_unuse_inode() return values.

Oh dear.  I had hoped they would look after themselves.  This one is a
private matter between shmem_unuse_inode and its one caller, just below.

> > +   if (error) {
> > +   if (error != -ENOMEM)
> > +   error = 0;
> > mem_cgroup_cancel_charge(page, memcg);
> > } else
> > mem_cgroup_commit_charge(page, memcg, true);
> 
> If I'm reading this correctly, shmem_unuse() can now return -EAGAIN and
> that can get all the way back to userspace.  `man 2 swapoff' doesn't
> know this...

if (error) {
if (error != -ENOMEM)
error = 0;
...
return error;

So the only values returned from shmem_unuse_inode() to its caller
try_to_unuse() are 0 and -ENOMEM.  Those may get passed back to the
user, but -EAGAIN was just an internal shmem.c detail.

Hugh
--
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: Filesystem lockup with CONFIG_PREEMPT_RT

[Austin Schuh]

On Fri, Jun 27, 2014 at 7:24 AM, Thomas Gleixner  wrote:
> On Thu, 26 Jun 2014, Austin Schuh wrote:
>> If I'm reading the rt patch correctly, wq_worker_sleeping was moved
>> out of __schedule to sched_submit_work.  It looks like that changes
>> the conditions under which wq_worker_sleeping is called.  It used to
>> be called whenever a task was going to sleep (I think).  It looks like
>> it is called now if the task is going to sleep, and if the task isn't
>> blocked on a PI mutex (I think).
>>
>> If I try the following experiment
>>
>>  static inline void sched_submit_work(struct task_struct *tsk)
>>  {
>> +   if (tsk->state && tsk->flags & PF_WQ_WORKER) {
>> + wq_worker_sleeping(tsk);
>> + return;
>> +   }
>>
>> and then remove the call later in the function, I am able to pass my test.
>>
>> Unfortunately, I then get a recursive pool spinlock BUG_ON after a
>> while (as I would expect), and it all blows up.
>
> Well, that's why the check for !pi_blocked_on is there.
>
>> I'm not sure where to go from there.  Any changes to the workpool to
>> try to fix that will be hard, or could affect latency significantly.
>
> Completely untested patch below.
>
> Thanks,
>
> tglx
>
> ->
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 8749d20..621329a 100644
> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> index be0ef50..0ca9d97 100644
> --- a/kernel/workqueue.c
> +++ b/kernel/workqueue.c
> @@ -849,25 +882,18 @@ void wq_worker_sleeping(struct task_struct *task)
> return;
>
> worker->sleeping = 1;
> -   spin_lock_irq(>lock);
> +
> /*
>  * The counterpart of the following dec_and_test, implied mb,
>  * worklist not empty test sequence is in insert_work().
>  * Please read comment there.
> -*
> -* NOT_RUNNING is clear.  This means that we're bound to and
> -* running on the local cpu w/ rq lock held and preemption
> -* disabled, which in turn means that none else could be
> -* manipulating idle_list, so dereferencing idle_list without pool
> -* lock is safe.
>  */
> if (atomic_dec_and_test(>nr_running) &&
> !list_empty(>worklist)) {

What guarantees that this pool->worklist access is safe?  Preemption
isn't disabled.

I'm seeing some inconsistency when accessing the idle list.  You seem
to only disable preemption when writing to the idle list?  I'm unsure
if I'm missing something, or what.  With that question in mind, I took
a stab at adding locking around all the idle_list calls.

I went through and double checked to make sure that rt_lock_idle_list
and rt_unlock_idle_list surround all idle_list or entry accesses.  The
following are places where I think you should be locking, but aren't.

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 8900da8..314a098 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -778,8 +805,12 @@ static bool too_many_workers(struct worker_pool *pool)
  * nr_idle and idle_list may disagree if idle rebinding is in
  * progress.  Never return %true if idle_list is empty.
  */
- if (list_empty(>idle_list))
+ rt_lock_idle_list(pool);
+ if (list_empty(>idle_list)) {
+ rt_unlock_idle_list(pool);
  return false;
+ }
+ rt_unlock_idle_list(pool);

  return nr_idle > 2 && (nr_idle - 2) * MAX_IDLE_WORKERS_RATIO >= nr_busy;
 }
@@ -788,7 +819,7 @@ static bool too_many_workers(struct worker_pool *pool)
  * Wake up functions.
  */

-/* Return the first worker.  Safe with preemption disabled */
+/* Return the first worker.  Preemption must be disabled */
 static struct worker *first_worker(struct worker_pool *pool)
 {
  if (unlikely(list_empty(>idle_list)))
@@ -1567,10 +1598,16 @@ static void worker_enter_idle(struct worker *worker)
 {
  struct worker_pool *pool = worker->pool;

- if (WARN_ON_ONCE(worker->flags & WORKER_IDLE) ||
-WARN_ON_ONCE(!list_empty(>entry) &&
- (worker->hentry.next || worker->hentry.pprev)))
- return;
+ if (WARN_ON_ONCE(worker->flags & WORKER_IDLE)) return;
+
+ rt_lock_idle_list(pool);
+ if (WARN_ON_ONCE(!list_empty(>entry))) {
+ rt_unlock_idle_list(pool);
+ if (worker->hentry.next || worker->hentry.pprev)
+ return;
+ } else {
+ rt_unlock_idle_list(pool);
+ }

  /* can't use worker_set_flags(), also called from start_worker() */
  worker->flags |= WORKER_IDLE;
@@ -1882,7 +1925,9 @@ static void idle_worker_timeout(unsigned long __pool)
  unsigned long expires;

  /* idle_list is kept in LIFO order, check the last one */
+ rt_lock_idle_list(pool);
  worker = list_entry(pool->idle_list.prev, struct worker, entry);
+ rt_unlock_idle_list(pool);
  expires = worker->last_active + IDLE_WORKER_TIMEOUT;

  if (time_before(jiffies, expires))
@@ -2026,7 +2071,9 @@ static bool maybe_destroy_workers(struct
worker_pool *pool)
  struct worker *worker;
  unsigned long expires;

+ rt_lock_idle_list(pool);
  worker = list_entry(pool->idle_list.prev, struct worker, entry);
+ 

Re: [PATCH 0/3] platform/chrome: chromeos_laptop - Add Haswell Chromebooks

[Olof Johansson]

No, not yet. I'll do a pass of merges of this (and arm-soc) on Wednesday.


-Olof

On Mon, Jun 30, 2014 at 5:05 PM, Scot Doyle  wrote:
> Hi Olof, did you apply these patches? I haven't seen them in 3.16-rc3,
> linux-next, kernel/git/olof/chrome-platform, kernel/git/olof/misc, or
> kernel/git/arm/arm-soc.
>
> Thanks,
> Scot
>
>
> On Tue, 17 Jun 2014, Benson Leung wrote:
>>
>> Looks like -rc1 is here, so I'll respin these and send them out again.
>>
>> On Tue, Jun 3, 2014 at 3:59 PM, Olof Johansson  wrote:
>>>
>>> Hi,
>>>
>>> On Tue, Jun 3, 2014 at 3:44 PM, Benson Leung  wrote:

 This patch series should be applied after Mika Westerberg's patch here:
 https://patchwork.kernel.org/patch/4288591/

 It will add support for the cypress touchpads on the HP Chromebook 14,
 Dell Chromebook 11, and Toshiba CB35.

 [PATCH 1/3] platform/chrome: chromeos_laptop - Add HP Chromebook 14
 [PATCH 2/3] platform/chrome: chromeos_laptop - Add Dell Chromebook 11
 Touch
 [PATCH 3/3] platform/chrome: chromeos_laptop - Add Toshiba CB35 Touch
>>>
>>>
>>> The 3.16 merge window is open, please resend after -rc1 and I'll queue it
>>> up.
>>>
>>>
>>> -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/

Re: [PATCH 0/3] platform/chrome: chromeos_laptop - Add Haswell Chromebooks

[Scot Doyle]

Hi Olof, did you apply these patches? I haven't seen them in 3.16-rc3, 
linux-next, kernel/git/olof/chrome-platform, kernel/git/olof/misc, or 
kernel/git/arm/arm-soc.


Thanks,
Scot

On Tue, 17 Jun 2014, Benson Leung wrote:

Looks like -rc1 is here, so I'll respin these and send them out again.

On Tue, Jun 3, 2014 at 3:59 PM, Olof Johansson  wrote:

Hi,

On Tue, Jun 3, 2014 at 3:44 PM, Benson Leung  wrote:

This patch series should be applied after Mika Westerberg's patch here:
https://patchwork.kernel.org/patch/4288591/

It will add support for the cypress touchpads on the HP Chromebook 14,
Dell Chromebook 11, and Toshiba CB35.

[PATCH 1/3] platform/chrome: chromeos_laptop - Add HP Chromebook 14
[PATCH 2/3] platform/chrome: chromeos_laptop - Add Dell Chromebook 11 Touch
[PATCH 3/3] platform/chrome: chromeos_laptop - Add Toshiba CB35 Touch


The 3.16 merge window is open, please resend after -rc1 and I'll queue it up.


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

[RFC PATCH] power/restart: Call machine_restart instead of arm_pm_restart

[Guenter Roeck]

machine_restart is supported on non-ARM platforms, and ultimately calls
arm_pm_restart, so dont call arm_pm_restart directly but use the more
generic function.

Cc: Russell King 
Signed-off-by: Guenter Roeck 
---
 drivers/power/reset/restart-poweroff.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/power/reset/restart-poweroff.c 
b/drivers/power/reset/restart-poweroff.c
index 5758033..47f10eb 100644
--- a/drivers/power/reset/restart-poweroff.c
+++ b/drivers/power/reset/restart-poweroff.c
@@ -20,7 +20,8 @@
 
 static void restart_poweroff_do_poweroff(void)
 {
-   arm_pm_restart(REBOOT_HARD, NULL);
+   reboot_mode = REBOOT_HARD;
+   machine_restart(NULL);
 }
 
 static int restart_poweroff_probe(struct platform_device *pdev)
-- 
1.9.1

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

[patch] mm, hugetlb: generalize writes to nr_hugepages

[David Rientjes]

Three different interfaces alter the maximum number of hugepages for an
hstate:

 - /proc/sys/vm/nr_hugepages for global number of hugepages of the default
   hstate,

 - /sys/kernel/mm/hugepages/hugepages-X/nr_hugepages for global number of
   hugepages for a specific hstate, and

 - /sys/kernel/mm/hugepages/hugepages-X/nr_hugepages/mempolicy for number of
   hugepages for a specific hstate over the set of allowed nodes.

Generalize the code so that a single function handles all of these writes 
instead of duplicating the code in two different functions.

This decreases the number of lines of code, but also reduces the size of
.text by about half a percent since set_max_huge_pages() can be inlined.

Signed-off-by: David Rientjes 
---
 mm/hugetlb.c | 61 ++--
 1 file changed, 26 insertions(+), 35 deletions(-)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1734,21 +1734,13 @@ static ssize_t nr_hugepages_show_common(struct kobject 
*kobj,
return sprintf(buf, "%lu\n", nr_huge_pages);
 }
 
-static ssize_t nr_hugepages_store_common(bool obey_mempolicy,
-   struct kobject *kobj, struct kobj_attribute *attr,
-   const char *buf, size_t len)
+static ssize_t __nr_hugepages_store_common(bool obey_mempolicy,
+  struct hstate *h, int nid,
+  unsigned long count, size_t len)
 {
int err;
-   int nid;
-   unsigned long count;
-   struct hstate *h;
NODEMASK_ALLOC(nodemask_t, nodes_allowed, GFP_KERNEL | __GFP_NORETRY);
 
-   err = kstrtoul(buf, 10, );
-   if (err)
-   goto out;
-
-   h = kobj_to_hstate(kobj, );
if (hstate_is_gigantic(h) && !gigantic_page_supported()) {
err = -EINVAL;
goto out;
@@ -1784,6 +1776,23 @@ out:
return err;
 }
 
+static ssize_t nr_hugepages_store_common(bool obey_mempolicy,
+struct kobject *kobj, const char *buf,
+size_t len)
+{
+   struct hstate *h;
+   unsigned long count;
+   int nid;
+   int err;
+
+   err = kstrtoul(buf, 10, );
+   if (err)
+   return err;
+
+   h = kobj_to_hstate(kobj, );
+   return __nr_hugepages_store_common(obey_mempolicy, h, nid, count, len);
+}
+
 static ssize_t nr_hugepages_show(struct kobject *kobj,
   struct kobj_attribute *attr, char *buf)
 {
@@ -1793,7 +1802,7 @@ static ssize_t nr_hugepages_show(struct kobject *kobj,
 static ssize_t nr_hugepages_store(struct kobject *kobj,
   struct kobj_attribute *attr, const char *buf, size_t len)
 {
-   return nr_hugepages_store_common(false, kobj, attr, buf, len);
+   return nr_hugepages_store_common(false, kobj, buf, len);
 }
 HSTATE_ATTR(nr_hugepages);
 
@@ -1812,7 +1821,7 @@ static ssize_t nr_hugepages_mempolicy_show(struct kobject 
*kobj,
 static ssize_t nr_hugepages_mempolicy_store(struct kobject *kobj,
   struct kobj_attribute *attr, const char *buf, size_t len)
 {
-   return nr_hugepages_store_common(true, kobj, attr, buf, len);
+   return nr_hugepages_store_common(true, kobj, buf, len);
 }
 HSTATE_ATTR(nr_hugepages_mempolicy);
 #endif
@@ -2248,36 +2257,18 @@ static int hugetlb_sysctl_handler_common(bool 
obey_mempolicy,
 void __user *buffer, size_t *length, loff_t *ppos)
 {
struct hstate *h = _hstate;
-   unsigned long tmp;
+   unsigned long tmp = h->max_huge_pages;
int ret;
 
-   if (!hugepages_supported())
-   return -ENOTSUPP;
-
-   tmp = h->max_huge_pages;
-
-   if (write && hstate_is_gigantic(h) && !gigantic_page_supported())
-   return -EINVAL;
-
table->data = 
table->maxlen = sizeof(unsigned long);
ret = proc_doulongvec_minmax(table, write, buffer, length, ppos);
if (ret)
goto out;
 
-   if (write) {
-   NODEMASK_ALLOC(nodemask_t, nodes_allowed,
-   GFP_KERNEL | __GFP_NORETRY);
-   if (!(obey_mempolicy &&
-  init_nodemask_of_mempolicy(nodes_allowed))) {
-   NODEMASK_FREE(nodes_allowed);
-   nodes_allowed = _states[N_MEMORY];
-   }
-   h->max_huge_pages = set_max_huge_pages(h, tmp, nodes_allowed);
-
-   if (nodes_allowed != _states[N_MEMORY])
-   NODEMASK_FREE(nodes_allowed);
-   }
+   if (write)
+   ret = __nr_hugepages_store_common(obey_mempolicy, h,
+ NUMA_NO_NODE, tmp, *length);
 out:
return ret;
 }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to 

mm: memcontrol: rewrite uncharge API: problems

[Hugh Dickins]

Hi Hannes,

Your rewrite of the memcg charge/uncharge API is bold and attractive,
but I'm having some problems with the way release_pages() now does
uncharging in I/O completion context.

At the bottom see the lockdep message I get when I start shmem swapping.
Which I have not begun to attempt to decipher (over to you!), but I do
see release_pages() mentioned in there (also i915, hope it's irrelevant).

Which was already worrying me on the PowerPC G5, when moving tasks from
one memcg to another and removing the old, while swapping and swappingoff
(I haven't tried much else actually, maybe it's much easier to reproduce).

I get "unable to handle kernel paging at 0x180" oops in __raw_spinlock <
res_counter_uncharge_until < mem_cgroup_uncharge_end < release_pages <
free_pages_and_swap_cache < tlb_flush_mmu_free < tlb_finish_mmu <
unmap_region < do_munmap (or from exit_mmap < mmput < do_exit).

I do have CONFIG_MEMCG_SWAP=y, and I think 0x180 corresponds to the
memsw res_counter spinlock, if memcg is NULL.  I don't understand why
usually the PowerPC: I did see something like it once on this x86 laptop,
maybe having lockdep in on this slows things down enough not to hit that.

I've stopped those crashes with patch below: the memcg_batch uncharging
was never designed for use from interrupts.  But I bet it needs more work:
to disable interrupts, or do something clever with atomics, or... over to
you again.

As it stands, I think an interrupt in the wrong place risks leaking
charges (but actually I see the reverse - kernel/res_counter.c:28!
underflow warnings; though I don't know if it's merely that the patch
lets the machine stay up long enough to reach those, or causes them).

Not-really-Signed-off-by: Hugh Dickins 
---

 mm/memcontrol.c |9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

--- 3.16-rc2-mm1/mm/memcontrol.c2014-06-25 18:43:59.856588121 -0700
+++ linux/mm/memcontrol.c   2014-06-29 21:45:03.896588350 -0700
@@ -3636,12 +3636,11 @@ void mem_cgroup_uncharge_end(void)
if (!batch->do_batch)
return;
 
-   batch->do_batch--;
-   if (batch->do_batch) /* If stacked, do nothing. */
-   return;
+   if (batch->do_batch > 1) /* If stacked, do nothing. */
+   goto out;
 
if (!batch->memcg)
-   return;
+   goto out;
/*
 * This "batch->memcg" is valid without any css_get/put etc...
 * bacause we hide charges behind us.
@@ -3655,6 +3654,8 @@ void mem_cgroup_uncharge_end(void)
memcg_oom_recover(batch->memcg);
/* forget this pointer (for sanity check) */
batch->memcg = NULL;
+out:
+   batch->do_batch--;
 }
 
 #ifdef CONFIG_MEMCG_SWAP

And here's lockdep's little fortune cookie:

==
[ INFO: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected ]
3.16.0-rc2-mm1 #3 Not tainted
--
cc1/2771 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
 (&(>lock)->rlock){+.+.-.}, at: [] 
memcg_check_events+0x17e/0x206
dd
and this task is already holding:
 (&(>lru_lock)->rlock){..-.-.}, at: [] 
release_pages+0xe7/0x239
which would create a new lock dependency:
 (&(>lru_lock)->rlock){..-.-.} -> (&(>lock)->rlock){+.+.-.}

but this new dependency connects a SOFTIRQ-irq-safe lock:
 (&(>lru_lock)->rlock){..-.-.}
... which became SOFTIRQ-irq-safe at:
  [] __lock_acquire+0x59f/0x17e8
  [] lock_acquire+0x61/0x78
  [] _raw_spin_lock_irqsave+0x3f/0x51
  [] pagevec_lru_move_fn+0x7d/0xf6
  [] pagevec_move_tail+0x1d/0x2c
  [] rotate_reclaimable_page+0xb2/0xd4
  [] end_page_writeback+0x1c/0x45
  [] end_swap_bio_write+0x5c/0x69
  [] bio_endio+0x50/0x6e
  [] blk_update_request+0x163/0x255
  [] blk_update_bidi_request+0x17/0x65
  [] blk_end_bidi_request+0x1a/0x56
  [] blk_end_request+0xb/0xd
  [] scsi_io_completion+0x16d/0x553
  [] scsi_finish_command+0xb6/0xbf
  [] scsi_softirq_done+0xe9/0xf0
  [] blk_done_softirq+0x79/0x8b
  [] __do_softirq+0xfc/0x21f
  [] irq_exit+0x3d/0x92
  [] do_IRQ+0xcc/0xe5
  [] ret_from_intr+0x0/0x13
  [] cpuidle_enter+0x12/0x14
  [] cpu_startup_entry+0x187/0x243
  [] rest_init+0x12f/0x133
  [] start_kernel+0x396/0x3a3
  [] x86_64_start_reservations+0x2a/0x2c
  [] x86_64_start_kernel+0xc7/0xca

to a SOFTIRQ-irq-unsafe lock:
 (&(>lock)->rlock){+.+.-.}
... which became SOFTIRQ-irq-unsafe at:
...  [] __lock_acquire+0x616/0x17e8
  [] lock_acquire+0x61/0x78
  [] _raw_spin_lock+0x34/0x41
  [] memcg_check_events+0x17e/0x206
  [] commit_charge+0x260/0x26f
  [] mem_cgroup_commit_charge+0xb1/0xdb
  [] shmem_getpage_gfp+0x400/0x6c2
  [] shmem_write_begin+0x33/0x35
  [] generic_perform_write+0xb7/0x1a4
  [] __generic_file_write_iter+0x25b/0x29b
  [] generic_file_write_iter+0x3b/0xa5
  [] new_sync_write+0x7b/0x9f
  [] vfs_write+0xb5/0x169
  [] SyS_write+0x45/0x8c
  [] system_call_fastpath+0x16/0x1b

other info that might help us debug this:

 Possible interrupt unsafe locking 

[PATCH] clk: Add tracepoints for hardware operations

[Stephen Boyd]

It's useful to have tracepoints around operations that change the
hardware state so that we can debug clock hardware performance
and operations. Three basic types of events are supported: on/off
events for enable, disable, prepare, unprepare that only record
an event and a clock name, rate changing events for
clk_set_rate() and parent changing events for clk_set_parent().

Cc: Steven Rostedt 
Signed-off-by: Stephen Boyd 
---

I see that there are tracepoints for clock_enable/clock_set_rate
in events/power.h but those look to be unused and they also
take cpu_id which seems odd. I'd rather we just make a new set of
events for the common clock framework instead and add the "_complete"
set of events so we know when things have completed.

 drivers/clk/clk.c  |  28 
 include/trace/events/clk.h | 165 +
 2 files changed, 193 insertions(+)
 create mode 100644 include/trace/events/clk.h

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 8b73edef151d..f8bf69df3210 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -21,6 +21,9 @@
 #include 
 #include 
 
+#define CREATE_TRACE_POINTS
+#include 
+
 #include "clk.h"
 
 static DEFINE_SPINLOCK(enable_lock);
@@ -483,10 +486,12 @@ static void clk_unprepare_unused_subtree(struct clk *clk)
return;
 
if (__clk_is_prepared(clk)) {
+   trace_clk_unprepare(clk);
if (clk->ops->unprepare_unused)
clk->ops->unprepare_unused(clk->hw);
else if (clk->ops->unprepare)
clk->ops->unprepare(clk->hw);
+   trace_clk_unprepare_complete(clk);
}
 }
 
@@ -516,10 +521,12 @@ static void clk_disable_unused_subtree(struct clk *clk)
 * back to .disable
 */
if (__clk_is_enabled(clk)) {
+   trace_clk_disable(clk);
if (clk->ops->disable_unused)
clk->ops->disable_unused(clk->hw);
else if (clk->ops->disable)
clk->ops->disable(clk->hw);
+   trace_clk_disable_complete(clk);
}
 
 unlock_out:
@@ -802,9 +809,13 @@ void __clk_unprepare(struct clk *clk)
 
WARN_ON(clk->enable_count > 0);
 
+   trace_clk_unprepare(clk);
+
if (clk->ops->unprepare)
clk->ops->unprepare(clk->hw);
 
+   trace_clk_unprepare_complete(clk);
+
__clk_unprepare(clk->parent);
 }
 
@@ -842,6 +853,8 @@ int __clk_prepare(struct clk *clk)
if (ret)
return ret;
 
+   trace_clk_prepare(clk);
+
if (clk->ops->prepare) {
ret = clk->ops->prepare(clk->hw);
if (ret) {
@@ -849,6 +862,8 @@ int __clk_prepare(struct clk *clk)
return ret;
}
}
+
+   trace_clk_prepare_complete(clk);
}
 
clk->prepare_count++;
@@ -891,9 +906,13 @@ static void __clk_disable(struct clk *clk)
if (--clk->enable_count > 0)
return;
 
+   trace_clk_disable(clk);
+
if (clk->ops->disable)
clk->ops->disable(clk->hw);
 
+   trace_clk_disable_complete(clk);
+
__clk_disable(clk->parent);
 }
 
@@ -938,6 +957,7 @@ static int __clk_enable(struct clk *clk)
if (ret)
return ret;
 
+   trace_clk_enable(clk);
if (clk->ops->enable) {
ret = clk->ops->enable(clk->hw);
if (ret) {
@@ -945,6 +965,7 @@ static int __clk_enable(struct clk *clk)
return ret;
}
}
+   trace_clk_enable_complete(clk);
}
 
clk->enable_count++;
@@ -1241,6 +1262,8 @@ static struct clk *__clk_set_parent_before(struct clk 
*clk, struct clk *parent)
unsigned long flags;
struct clk *old_parent = clk->parent;
 
+   trace_clk_set_parent(clk, parent);
+
/*
 * Migrate prepare state between parents and prevent race with
 * clk_enable().
@@ -1285,6 +1308,7 @@ static void __clk_set_parent_after(struct clk *clk, 
struct clk *parent,
__clk_unprepare(old_parent);
}
 
+   trace_clk_set_parent_complete(clk, parent);
/* update debugfs with new clk tree topology */
clk_debug_reparent(clk, parent);
 }
@@ -1507,6 +1531,8 @@ static void clk_change_rate(struct clk *clk)
else if (clk->parent)
best_parent_rate = clk->parent->rate;
 
+   trace_clk_set_rate(clk, clk->new_rate);
+
if (clk->new_parent && clk->new_parent != clk->parent) {
old_parent = __clk_set_parent_before(clk, clk->new_parent);
 
@@ -1525,6 +1551,8 @@ static void clk_change_rate(struct clk *clk)
if (!skip_set_rate && clk->ops->set_rate)

[PATCH net-next v1 1/2] netpoll: fix use after free

[David Decotigny]

After a bonding master reclaims the netpoll info struct, slaves could
still hold a pointer to the reclaimed data. This patch fixes it: as
soon as netpoll_async_cleanup is called for a slave (eg. when
un-enslaved), we make sure that this slave doesn't point to the data.

The style of this patch is not nice, but it represents the simplest
fix. The function is restructured by the next patch anyway ("netpoll:
avoid reference leaks").

Tested:
  One way to reproduce the panic is with netconsole: with the script
  below run in a loop without this patch. Same procedure with this
  patch can run without panic.
CONFIG_NETCONSOLE=m
CONFIG_NETCONSOLE_DYNAMIC=y
  Then run in a loop (dual port NIC makes it easier to crash):
ifconfig eth0 192.168.42.4 up
ifconfig eth1 192.168.56.4 up
sleep 10
modprobe -r netconsole
modprobe -r bonding
modprobe netconsole
modprobe bonding mode=4
echo +bond0 > /sys/class/net/bonding_masters
ifconfig bond0 192.168.56.3 up
mkdir /sys/kernel/config/netconsole/blah
echo 0 > /sys/kernel/config/netconsole/blah/enabled
echo bond0 > /sys/kernel/config/netconsole/blah/dev_name
echo 192.168.56.42 > /sys/kernel/config/netconsole/blah/remote_ip
echo 1 > /sys/kernel/config/netconsole/blah/enabled
# npinfo refcnt ->1
ifenslave bond0 eth1
# npinfo refcnt ->2
ifenslave bond0 eth0
# (this should be optional, preventing ndo_cleanup_nepoll below)
# npinfo refcnt ->3
sleep 3
ifenslave -d bond0 eth1
# npinfo refcnt ->2, eth1 keeps ptr to npinfo reclaimed later => garbage
sleep 1
echo -bond0 > /sys/class/net/bonding_masters
# netpoll_cleanup(bond0) + dec(refcnt)
# (should be optional: becomes -> 1 (aka. != 0)
#  ==> do not call ndo_cleanup_nepoll)
# try to increase chance of writing garbage onto npinfo:
ls -lR / 2>&1 | tail -30
echo +bond0 > /sys/class/net/bonding_masters
ifconfig bond0 192.168.56.3 up
ifenslave bond0 eth1
# dev_open() called --> netpoll_rx_disable() + npinfo is garbage
#-> down(>dev_lock);

Signed-off-by: David Decotigny 
---
 net/core/netpoll.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index e33937f..907fb5e 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -822,7 +822,8 @@ void __netpoll_cleanup(struct netpoll *np)
 
RCU_INIT_POINTER(np->dev->npinfo, NULL);
call_rcu_bh(>rcu, rcu_cleanup_netpoll_info);
-   }
+   } else
+   RCU_INIT_POINTER(np->dev->npinfo, NULL);
 }
 EXPORT_SYMBOL_GPL(__netpoll_cleanup);
 
-- 
2.0.0.526.g5318336

--
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 net-next v1 2/2] netpoll: avoid reference leaks

[David Decotigny]

This ensures that the ndo_netpoll_cleanup callback is called for every
device that provides one. Otherwise there is a risk of reference leak
with bonding for example, which depends on this callback to cleanup
the slaves' references to netpoll info.

Tested:
  see patch "netpoll: fix use after free"

Signed-off-by: David Decotigny 
---
 net/core/netpoll.c | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index 907fb5e..1e10d5d 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -802,6 +802,7 @@ static void rcu_cleanup_netpoll_info(struct rcu_head 
*rcu_head)
 void __netpoll_cleanup(struct netpoll *np)
 {
struct netpoll_info *npinfo;
+   const struct net_device_ops *ops;
 
/* rtnl_dereference would be preferable here but
 * rcu_cleanup_netpoll path can put us in here safely without
@@ -813,17 +814,17 @@ void __netpoll_cleanup(struct netpoll *np)
 
synchronize_srcu(_srcu);
 
-   if (atomic_dec_and_test(>refcnt)) {
-   const struct net_device_ops *ops;
+   ops = np->dev->netdev_ops;
+   if (ops->ndo_netpoll_cleanup)
+   ops->ndo_netpoll_cleanup(np->dev);
 
-   ops = np->dev->netdev_ops;
-   if (ops->ndo_netpoll_cleanup)
-   ops->ndo_netpoll_cleanup(np->dev);
+   /* before dropping ref count, make sure this device does not
+* reference npinfo anymore
+*/
+   RCU_INIT_POINTER(np->dev->npinfo, NULL);
 
-   RCU_INIT_POINTER(np->dev->npinfo, NULL);
+   if (atomic_dec_and_test(>refcnt))
call_rcu_bh(>rcu, rcu_cleanup_netpoll_info);
-   } else
-   RCU_INIT_POINTER(np->dev->npinfo, NULL);
 }
 EXPORT_SYMBOL_GPL(__netpoll_cleanup);
 
-- 
2.0.0.526.g5318336

--
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] x86: numa: setup_node_data(): drop dead code and rename function

[David Rientjes]

On Thu, 19 Jun 2014, Luiz Capitulino wrote:

> The setup_node_data() function allocates a pg_data_t object, inserts it
> into the node_data[] array and initializes the following fields:
> node_id, node_start_pfn and node_spanned_pages.
> 
> However, a few function calls later during the kernel boot,
> free_area_init_node() re-initializes those fields, possibly with
> different values. This means that the initialization done by
> setup_node_data() is not used.
> 
> This causes a small glitch when running Linux as a hyperv numa guest:
> 
> [0.00] SRAT: PXM 0 -> APIC 0x00 -> Node 0
> [0.00] SRAT: PXM 0 -> APIC 0x01 -> Node 0
> [0.00] SRAT: PXM 1 -> APIC 0x02 -> Node 1
> [0.00] SRAT: PXM 1 -> APIC 0x03 -> Node 1
> [0.00] SRAT: Node 0 PXM 0 [mem 0x-0x7fff]
> [0.00] SRAT: Node 1 PXM 1 [mem 0x8020-0xf7ff]
> [0.00] SRAT: Node 1 PXM 1 [mem 0x1-0x1081f]
> [0.00] NUMA: Node 1 [mem 0x8020-0xf7ff] + [mem 
> 0x1-0x1081f] -> [mem 0x8020-0x1081f]
> [0.00] Initmem setup node 0 [mem 0x-0x7fff]
> [0.00]   NODE_DATA [mem 0x7ffec000-0x7ffe]
> [0.00] Initmem setup node 1 [mem 0x8080-0x1081f]
> [0.00]   NODE_DATA [mem 0x1081fa000-0x1081fdfff]
> [0.00] crashkernel: memory value expected
> [0.00]  [ea00-ea0001ff] PMD -> 
> [88007de0-88007fdf] on node 0
> [0.00]  [ea000200-ea00043f] PMD -> 
> [88010560-8801077f] on node 1
> [0.00] Zone ranges:
> [0.00]   DMA  [mem 0x1000-0x00ff]
> [0.00]   DMA32[mem 0x0100-0x]
> [0.00]   Normal   [mem 0x1-0x1081f]
> [0.00] Movable zone start for each node
> [0.00] Early memory node ranges
> [0.00]   node   0: [mem 0x1000-0x0009efff]
> [0.00]   node   0: [mem 0x0010-0x7ffe]
> [0.00]   node   1: [mem 0x8020-0xf7ff]
> [0.00]   node   1: [mem 0x1-0x1081f]
> [0.00] On node 0 totalpages: 524174
> [0.00]   DMA zone: 64 pages used for memmap
> [0.00]   DMA zone: 21 pages reserved
> [0.00]   DMA zone: 3998 pages, LIFO batch:0
> [0.00]   DMA32 zone: 8128 pages used for memmap
> [0.00]   DMA32 zone: 520176 pages, LIFO batch:31
> [0.00] On node 1 totalpages: 524288
> [0.00]   DMA32 zone: 7672 pages used for memmap
> [0.00]   DMA32 zone: 491008 pages, LIFO batch:31
> [0.00]   Normal zone: 520 pages used for memmap
> [0.00]   Normal zone: 33280 pages, LIFO batch:7
> 
> In this dmesg, the SRAT table reports that the memory range for node 1
> starts at 0x8020. However, the line starting with "Initmem" reports
> that node 1 memory range starts at 0x8080. The "Initmem" line is
> reported by setup_node_data() and is wrong, because the kernel ends up
> using the range as reported in the SRAT table.
> 
> This commit drops all that dead code from setup_node_data(), renames it
> to alloc_node_data() and adds a printk() to free_area_init_node() so
> that we report a node's memory range accurately.
> 
> Here's the same dmesg section with this patch applied:
> 
> [0.00] SRAT: PXM 0 -> APIC 0x00 -> Node 0
> [0.00] SRAT: PXM 0 -> APIC 0x01 -> Node 0
> [0.00] SRAT: PXM 1 -> APIC 0x02 -> Node 1
> [0.00] SRAT: PXM 1 -> APIC 0x03 -> Node 1
> [0.00] SRAT: Node 0 PXM 0 [mem 0x-0x7fff]
> [0.00] SRAT: Node 1 PXM 1 [mem 0x8020-0xf7ff]
> [0.00] SRAT: Node 1 PXM 1 [mem 0x1-0x1081f]
> [0.00] NUMA: Node 1 [mem 0x8020-0xf7ff] + [mem 
> 0x1-0x1081f] -> [mem 0x8020-0x1081f]
> [0.00] NODE_DATA(0) allocated [mem 0x7ffec000-0x7ffe]
> [0.00] NODE_DATA(1) allocated [mem 0x1081fa000-0x1081fdfff]
> [0.00] crashkernel: memory value expected
> [0.00]  [ea00-ea0001ff] PMD -> 
> [88007de0-88007fdf] on node 0
> [0.00]  [ea000200-ea00043f] PMD -> 
> [88010560-8801077f] on node 1
> [0.00] Zone ranges:
> [0.00]   DMA  [mem 0x1000-0x00ff]
> [0.00]   DMA32[mem 0x0100-0x]
> [0.00]   Normal   [mem 0x1-0x1081f]
> [0.00] Movable zone start for each node
> [0.00] Early memory node ranges
> [0.00]   node   0: [mem 0x1000-0x0009efff]
> [0.00]   node   0: [mem 0x0010-0x7ffe]
> [0.00]   node   1: [mem 0x8020-0xf7ff]
> [0.00]   node   1: [mem 0x1-0x1081f]
> [0.00] Node 0 memory range 0x1000-0x7ffe
> [0.00] On node 0 totalpages: 524174
> [0.00]   DMA zone: 64 pages used for memmap
> [0.00]   DMA zone: 21 pages reserved
> [0.00]   

Re: [PATCH 1/4] fs.h: Remove unnecessary extern prototypes

[Andrew Morton]

On Mon, 30 Jun 2014 16:31:31 -0700 Joe Perches  wrote:

> On Mon, 2014-06-30 at 16:19 -0700, Andrew Morton wrote:
> > On Sat, 28 Jun 2014 17:20:13 -0700 Joe Perches  wrote:
> > 
> > > This file has a mixture of prototypes with and without extern.
> > > Remove the extern uses.
> > 
> > urgh, it's been two days and this already throws a huge reject.  I fix
> > that and the other two patches throw great piles of rejects as well.
> > 
> > Dunno.  Maybe `diff -u1' will make it feasible.
> 
> This was against -next and was done almost completely
> by automated tool.

Ah, didn't know that.

I get the same issues with current -next.

> I can fix it and resubmit if you like.

OK.  How about we wait for -rc6 or thereabouts?  That should minimise
the pain profile.

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

Re: [PATCH 1/4] fs.h: Remove unnecessary extern prototypes

[Joe Perches]

On Mon, 2014-06-30 at 16:19 -0700, Andrew Morton wrote:
> On Sat, 28 Jun 2014 17:20:13 -0700 Joe Perches  wrote:
> 
> > This file has a mixture of prototypes with and without extern.
> > Remove the extern uses.
> 
> urgh, it's been two days and this already throws a huge reject.  I fix
> that and the other two patches throw great piles of rejects as well.
> 
> Dunno.  Maybe `diff -u1' will make it feasible.

This was against -next and was done almost completely
by automated tool.

I can fix it and resubmit if you like.


--
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] firmware loader: inform direct failure when udev loader is disabled

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" 

Now that the udev firmware loader is optional request_firmware()
will not provide any information on the kernel ring buffer if
direct firmware loading failed and udev firmware loading is disabled.
If no information is needed request_firmware_direct() should be used
for optional firmware, at which point drivers can take on the onus
over informing of any failures, if udev firmware loading is disabled
though we should at the very least provide some sort of information
as when the udev loader was enabled by default back in the days.

With this change with a simple firmware load test module [0]:

Example output without FW_LOADER_USER_HELPER_FALLBACK

platform fake-dev.0: Direct firmware load for fake.bin failed with error -2

Example without FW_LOADER_USER_HELPER_FALLBACK

platform fake-dev.0: Direct firmware load for fake.bin failed with error -2 
platform fake-dev.0: Falling back to user helper 

Without this change without FW_LOADER_USER_HELPER_FALLBACK we get no output
logged upon failure.

[0] https://github.com/mcgrof/fake-firmware-test.git

Cc: Tom Gundersen 
Cc: Ming Lei 
Cc: Greg Kroah-Hartman 
Cc: Abhay Salunke 
Cc: Stefan Roese 
Cc: Arnd Bergmann 
Cc: Kay Sievers 
Cc: Takashi Iwai 
Signed-off-by: Luis R. Rodriguez 
---

 drivers/base/firmware_class.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 46ea5f4..23274d8 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -101,8 +101,10 @@ static inline long firmware_loading_timeout(void)
 #define FW_OPT_NOWAIT  (1U << 1)
 #ifdef CONFIG_FW_LOADER_USER_HELPER
 #define FW_OPT_USERHELPER  (1U << 2)
+#define FW_OPT_FAIL_WARN   0
 #else
 #define FW_OPT_USERHELPER  0
+#define FW_OPT_FAIL_WARN   (1U << 3)
 #endif
 #ifdef CONFIG_FW_LOADER_USER_HELPER_FALLBACK
 #define FW_OPT_FALLBACKFW_OPT_USERHELPER
@@ -1116,10 +1118,11 @@ _request_firmware(const struct firmware **firmware_p, 
const char *name,
 
ret = fw_get_filesystem_firmware(device, fw->priv);
if (ret) {
-   if (opt_flags & FW_OPT_USERHELPER) {
+   if (opt_flags & (FW_OPT_FAIL_WARN | FW_OPT_USERHELPER))
dev_warn(device,
-"Direct firmware load failed with error %d\n",
-ret);
+"Direct firmware load for %s failed with error 
%d\n",
+name, ret);
+   if (opt_flags & FW_OPT_USERHELPER) {
dev_warn(device, "Falling back to user helper\n");
ret = fw_load_from_user_helper(fw, name, device,
   opt_flags, timeout);
@@ -1170,7 +1173,8 @@ request_firmware(const struct firmware **firmware_p, 
const char *name,
/* Need to pin this module until return */
__module_get(THIS_MODULE);
ret = _request_firmware(firmware_p, name, device,
-   FW_OPT_UEVENT | FW_OPT_FALLBACK);
+   FW_OPT_UEVENT | FW_OPT_FALLBACK |
+   FW_OPT_FAIL_WARN);
module_put(THIS_MODULE);
return ret;
 }
-- 
2.0.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 1/4] fs.h: Remove unnecessary extern prototypes

[Andrew Morton]

On Sat, 28 Jun 2014 17:20:13 -0700 Joe Perches  wrote:

> This file has a mixture of prototypes with and without extern.
> Remove the extern uses.

urgh, it's been two days and this already throws a huge reject.  I fix
that and the other two patches throw great piles of rejects as well.

Dunno.  Maybe `diff -u1' will make it feasible.
--
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/