date:20140224

Mark function as static in lib/decompress_unlzo.c because it is not used
outside this file.

This eliminates the following warning in lib/decompress_unlzo.c:
lib/decompress_unlzo.c:54:24: warning: no previous prototype for ‘parse_header’ 
[-Wmissing-prototypes]

Signed-off-by: Rashika Kheria 
Reviewed-by: Josh Triplett 
---
 lib/decompress_unlzo.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/decompress_unlzo.c b/lib/decompress_unlzo.c
index 960183d..7ae2c04 100644
--- a/lib/decompress_unlzo.c
+++ b/lib/decompress_unlzo.c
@@ -51,7 +51,7 @@ static const unsigned char lzop_magic[] = {
 #define HEADER_SIZE_MIN   (9 + 7 + 4 + 8 + 1   + 4)
 #define HEADER_SIZE_MAX   (9 + 7 + 1 + 8 + 8 + 4 + 1 + 255 + 4)
 
-STATIC inline int INIT parse_header(u8 *input, int *skip, int in_len)
+static inline int INIT parse_header(u8 *input, int *skip, int in_len)
 {
int l;
u8 *parse = input;
-- 
1.7.9.5

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

[PATCH 7/8] lib: Include appropriate header file in lib/decompress_unxz.c

Include appropriate header file include/linux/decompress/unxz.h in
lib/decompress_unxz.c because it has prototype declaration of function
defined in lib/decompress_unxz.c.

This eliminates the following warning in lib/decompress_unxz.c:
lib/decompress_unxz.c:251:17: warning: no previous prototype for ‘unxz’ 
[-Wmissing-prototypes]

Signed-off-by: Rashika Kheria 
Reviewed-by: Josh Triplett 
---
 lib/decompress_unxz.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/decompress_unxz.c b/lib/decompress_unxz.c
index 9f34eb5..db22fcc 100644
--- a/lib/decompress_unxz.c
+++ b/lib/decompress_unxz.c
@@ -237,6 +237,8 @@ void *memmove(void *dest, const void *src, size_t size)
 
 #endif /* XZ_PREBOOT */
 
+#include 
+
 /* Size of the input and output buffers in multi-call mode */
 #define XZ_IOBUF_SIZE 4096
 
-- 
1.7.9.5

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

[PATCH 6/8] lib: Include appropriate header file in lib/libcrc32c.c

Include appropriate header file include/linux/crc32c.h in
lib/libcrc32c.c because it has prototype declaration of function defined
in lib/libcrc32c.c.

This eliminates the following warning in lib/libcrc32c.c:
lib/libcrc32c.c:42:5: warning: no previous prototype for ‘crc32c’ 
[-Wmissing-prototypes]

Signed-off-by: Rashika Kheria 
Reviewed-by: Josh Triplett 
---
 lib/libcrc32c.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/libcrc32c.c b/lib/libcrc32c.c
index 244f548..793a6a3 100644
--- a/lib/libcrc32c.c
+++ b/lib/libcrc32c.c
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static struct crypto_shash *tfm;
 
-- 
1.7.9.5

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

Re: [PATCHv3] tty: Set correct tty name in 'active' sysfs attribute

2014-02-24 Thread Hannes Reinecke

On 02/24/2014 03:58 PM, David Herrmann wrote:
> Hi
> 
> On Mon, Feb 24, 2014 at 3:50 PM, Hannes Reinecke  wrote:
>> The 'active' sysfs attribute should refer to the currently
>> active tty devices the console is running on, not the currently
>> active console.
>> The console structure doesn't refer to any device in sysfs,
>> only the tty the console is running on has.
>> So we need to print out the tty names in 'active', not
>> the console names.
>> But we need to take care for the virtual console to always display
>> 'tty0' so as not to break existing programs.
>>
>> Cc: Lennart Poettering 
>> Cc: Kay Sievers 
>> Cc: Greg Kroah-Hartman 
>> Cc: Jiri Slaby 
>> Signed-off-by: Werner Fink 
>> Signed-off-by: Hannes Reinecke 
>> ---
>>  drivers/tty/tty_io.c | 24 ++--
>>  1 file changed, 18 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
>> index c74a00a..96eb462 100644
>> --- a/drivers/tty/tty_io.c
>> +++ b/drivers/tty/tty_io.c
>> @@ -1271,12 +1271,13 @@ static void pty_line_name(struct tty_driver *driver, 
>> int index, char *p)
>>   *
>>   * Locking: None
>>   */
>> -static void tty_line_name(struct tty_driver *driver, int index, char *p)
>> +static ssize_t tty_line_name(struct tty_driver *driver, int index, char *p)
>>  {
>> if (driver->flags & TTY_DRIVER_UNNUMBERED_NODE)
>> -   strcpy(p, driver->name);
>> +   return sprintf(p, "%s", driver->name);
>> else
>> -   sprintf(p, "%s%d", driver->name, index + driver->name_base);
>> +   return sprintf(p, "%s%d", driver->name,
>> +  index + driver->name_base);
>>  }
>>
>>  /**
>> @@ -3545,9 +3546,20 @@ static ssize_t show_cons_active(struct device *dev,
>> if (i >= ARRAY_SIZE(cs))
>> break;
>> }
>> -   while (i--)
>> -   count += sprintf(buf + count, "%s%d%c",
>> -cs[i]->name, cs[i]->index, i ? ' ':'\n');
>> +   while (i--) {
>> +   struct tty_driver *driver;
>> +   const char *name = cs[i]->name;
>> +   int index = cs[i]->index;
>> +
>> +   driver = cs[i]->device(cs[i], );
>> +   /* Some programs rely on 'tty0' for console */
>> +   if (driver && (index > 0 || driver->major != TTY_MAJOR)) {
> 
> As Ray mentioned in the previous discussion, this has to be
> cs[i]->index instead of "index" as ->device() changes the parameter.
> See drivers/tty/vt/vt.c vt_console_device().
> 
Positive?
I thought this was precisely the problem, ->device() changing the
index '0' into something non-zero.
The reports we had were that the line 'tty0' changed into 'tty1'.
Hence ->device() converted cs[i]->index (which is '0') into index
(which is '1').
Hence the check would be correct, wouldn't it?

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/

Re: [PATCH] r8169: initialize rtl8169_stats seqlock

2014-02-24 Thread Borislav Petkov

On Mon, Feb 24, 2014 at 08:32:40PM -0500, David Miller wrote:
> > Boris reports he's seeing:
> >> [9.195943] INFO: trying to register non-static key.
> >> [9.196031] the code is fine but needs lockdep annotation.
> >> [9.196031] turning off the locking correctness validator.
> >> [9.196031] CPU: 1 PID: 933 Comm: modprobe Not tainted 3.14.0-rc4+ #1
> > with the r8169 driver.
> > 
> > These are occuring because the seqcount embedded in u64_stats_sync on
> > 32-bit SMP is uninitialized which is making lockdep unhappy.
> > 
> > Signed-off-by: Kyle McMartin 
> 
> Good catch, applied, thanks Kyle.

Thanks Kyle!

Tested-by: Borislav Petkov 

-- 
Regards/Gruss,
Boris.

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

[PATCH 5/8] lib: Include appropriate header file in lib/decompress_inflate.c

Include appropriate header file include/linux/decompress/inflate.h in
lib/decompress_inflate.c because it has prototype declaration of
function defined in lib/decompress_inflate.c.

Also, fix the guard around the header file
include/linux/decompress/inflate.h to use a more unique guard symbol.
This avoids conflict with the INFLATE_H defined by
zlib_inflate/inflate.h.

This eliminates the following warning in lib/decompress_inflate.c:
lib/decompress_inflate.c:35:17: warning: no previous prototype for ‘gunzip’ 
[-Wmissing-prototypes]

Signed-off-by: Rashika Kheria 
Reviewed-by: Josh Triplett 
---
 include/linux/decompress/inflate.h |4 ++--
 lib/decompress_inflate.c   |1 +
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/linux/decompress/inflate.h 
b/include/linux/decompress/inflate.h
index 8c0aef1..1d0aede 100644
--- a/include/linux/decompress/inflate.h
+++ b/include/linux/decompress/inflate.h
@@ -1,5 +1,5 @@
-#ifndef INFLATE_H
-#define INFLATE_H
+#ifndef LINUX_DECOMPRESS_INFLATE_H
+#define LINUX_DECOMPRESS_INFLATE_H
 
 int gunzip(unsigned char *inbuf, int len,
   int(*fill)(void*, unsigned int),
diff --git a/lib/decompress_inflate.c b/lib/decompress_inflate.c
index d619b28..0edfd74 100644
--- a/lib/decompress_inflate.c
+++ b/lib/decompress_inflate.c
@@ -19,6 +19,7 @@
 #include "zlib_inflate/inflate.h"
 
 #include "zlib_inflate/infutil.h"
+#include 
 
 #endif /* STATIC */
 
-- 
1.7.9.5

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

linux-next: Tree for Feb 25

Hi all,

This tree fails (more than usual) the powerpc allyesconfig build.

Changes since 20140224:

The powerpc tree still had its build failure.

The mfd-lj tree still had its build failure so I used the version from
next-20140210.

The wireless-next tree gained a build failure so I used the version from
next-20140224.

The spi tree lost its build failure.

The watchdog tree gained a conflict against the mvebu tree.

The staging tree gained conflicts against the arm-soc and imx-mxs trees.

The char-misc tree still had its build failure for which I applied a
merge fix patch.

Non-merge commits (relative to Linus' tree): 41340
 4327 files changed, 156351 insertions(+), 81744 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" as mentioned in the FAQ on the wiki
(see below).

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 (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final
link) and i386, sparc, sparc64 and arm defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.

Below is a summary of the state of the merge.

I am currently merging 210 trees (counting Linus' and 28 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.

There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ .  Thanks to Frank Seidel.

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

$ git checkout master
$ git reset --hard stable
Merging origin/master (7472e009a3f1 Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security)
Merging fixes/master (b0031f227e47 Merge tag 's2mps11-build' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator)
Merging kbuild-current/rc-fixes (38dbfb59d117 Linus 3.14-rc1)
Merging arc-current/for-curr (7e22e91102c6 Linux 3.13-rc8)
Merging arm-current/fixes (b36345759308 ARM: 7980/1: kernel: improve error 
message when LPAE config doesn't match CPU)
Merging m68k-current/for-linus (7247f55381d5 m68k: Wire up sched_setattr and 
sched_getattr)
Merging metag-fixes/fixes (e6cfc0295c7d asm-generic: add 
sched_setattr/sched_getattr syscalls)
Merging powerpc-merge/merge (66f9af83e56b powerpc/eeh: Disable EEH on reboot)
Merging sparc/master (10527106abec Merge tag 'dt-for-linus' of 
git://git.secretlab.ca/git/linux)
Merging net/master (0e7ede80d929 virtio-net: alloc big buffers also when guest 
can receive UFO)
Merging ipsec/master (ee5c23176fcc xfrm: Clone states properly on migration)
Merging sound-current/for-linus (c60666bd2224 ALSA: hda/realtek - Add more 
entry for enable HP mute led)
Merging pci-current/for-linus (fc40363b2140 ahci: Fix broken fallback to single 
MSI mode)
Merging wireless/master (558ff225de80 ath9k: fix ps-poll responses under a-mpdu 
sessions)
Merging driver-core.current/driver-core-linus (6d0abeca3242 Linux 3.14-rc3)
Merging tty.current/tty-linus (5c0a2450d695 Revert "tty: Set correct tty name 
in 'active' sysfs attribute")
Merging usb.current/usb-linus (5bf5dbeda245 usb: chipidea: need to mask when 
writting endptflush and endptprime)
Merging staging.current/staging-linus (cfbf8d4857c2 Linux 3.14-rc4)
Merging char-misc.current/char-misc-linus (58e868be77bd Merge 3.14-rc4 into 
char-misc-linus)
Merging input-current/for-linus (70b0052425ff Input: da9052_onkey - use correct 
register bit for key status)
Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" 
stripe)
Merging crypto-current/master (ee97dc7db4cb crypto: s390 - fix des and des3_ede 
ctr concurrency issue)
Merging ide/master (738b52bb9845 Merge tag 'microblaze-3.14-rc3' of 
git://git.monstr.eu/linux-2.6-microblaze)
Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff)
Merging devicetree-current/dev

RE: [PATCH 2/6] usb: gadget: mv_udc: disable HW zlt for ep0



 
> >
> >
> >
> >
> > > > On Mon, Feb 24, 2014 at 04:03:12PM +0800, Neil Zhang wrote:
> > > > > Hardware zlt will try to send the zero length packet
> > > > > automatically when the data transferd is multiple times of max
> > > > > packet, this will cause issues on Windows.
> > > > > So let's disable HW zlt by default.
> > > >
> > > > Would you have description that what kinds of issue on Windows if
> > > > zlt is is selected?
> > > >
> > >
> > > Enumeration will fail.
> > >
> >
> > What causes enumeration fail, why it does not occur before?
> >
> A unexpected zero packet cause enumeration fail.
> It's not easy that the descriptor is actually 1024 bytes, so not easy to
> be found.
> 

Chipidea bug too? Does it follow ch 8.5.3.2 Variable-length Data Stage, USB 2.0 
spec?

Peter

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

[PATCH 4/8] lib: Add prototype declarations in lib/clz_ctz.c

Add prototype declarations of functions in lib/clz_ctz.c. These
functions are required by GCC builtins and hence can not be removed
despite of their unreferenced appearance in kernel source.

This eliminates the following warning in lib/clz_ctz.c:
lib/clz_ctz.c:16:12: warning: no previous prototype for ‘__ctzsi2’ 
[-Wmissing-prototypes]
lib/clz_ctz.c:22:12: warning: no previous prototype for ‘__clzsi2’ 
[-Wmissing-prototypes]
lib/clz_ctz.c:44:12: warning: no previous prototype for ‘__clzdi2’ 
[-Wmissing-prototypes]
lib/clz_ctz.c:50:12: warning: no previous prototype for ‘__ctzdi2’ 
[-Wmissing-prototypes]

Signed-off-by: Rashika Kheria 
Reviewed-by: Josh Triplett 
---
 lib/clz_ctz.c |7 +++
 1 file changed, 7 insertions(+)

diff --git a/lib/clz_ctz.c b/lib/clz_ctz.c
index a8f8379..2e11e48 100644
--- a/lib/clz_ctz.c
+++ b/lib/clz_ctz.c
@@ -6,6 +6,9 @@
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
+ * The functions in this file aren't called directly, but are required by
+ * GCC builtins such as __builtin_ctz, and therefore they can't be removed
+ * despite appearing unreferenced in kernel source.
  *
  * __c[lt]z[sd]i2 can be overridden by linking arch-specific versions.
  */
@@ -13,18 +16,22 @@
 #include 
 #include 
 
+int __weak __ctzsi2(int val);
 int __weak __ctzsi2(int val)
 {
return __ffs(val);
 }
 EXPORT_SYMBOL(__ctzsi2);
 
+int __weak __clzsi2(int val);
 int __weak __clzsi2(int val)
 {
return 32 - fls(val);
 }
 EXPORT_SYMBOL(__clzsi2);
 
+int __weak __clzdi2(long val);
+int __weak __ctzdi2(long val);
 #if BITS_PER_LONG == 32
 
 int __weak __clzdi2(long val)
-- 
1.7.9.5

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

[PATCH 3/8] lib: Move prototype declaration to header file include/linux/swiotlb.h

Move prototype declaration of function to header file
include/linux/swiotlb.h from arch/ia64/hp/common/hwsw_iommu.c,
arch/ia64/hp/common/sba_iommu.c and arch/x86/pci/sta2x11-fixup.c because
it is used by more than one file.

This eliminates the following warning in lib/swiotlb.c:
lib/swiotlb.c:240:1: warning: no previous prototype for 
‘swiotlb_late_init_with_default_size’ [-Wmissing-prototypes]
lib/swiotlb.c:537:13: warning: no previous prototype for ‘map_single’ 
[-Wmissing-prototypes]

Signed-off-by: Rashika Kheria 
Reviewed-by: Josh Triplett 
---
 arch/ia64/hp/common/hwsw_iommu.c |3 ---
 arch/ia64/hp/common/sba_iommu.c  |2 --
 arch/x86/pci/sta2x11-fixup.c |1 -
 include/linux/swiotlb.h  |4 +++-
 4 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/arch/ia64/hp/common/hwsw_iommu.c b/arch/ia64/hp/common/hwsw_iommu.c
index 1e4cae5..b14cab1 100644
--- a/arch/ia64/hp/common/hwsw_iommu.c
+++ b/arch/ia64/hp/common/hwsw_iommu.c
@@ -20,9 +20,6 @@
 
 extern struct dma_map_ops sba_dma_ops, swiotlb_dma_ops;
 
-/* swiotlb declarations & definitions: */
-extern int swiotlb_late_init_with_default_size (size_t size);
-
 /*
  * Note: we need to make the determination of whether or not to use
  * the sw I/O TLB based purely on the device structure.  Anything else
diff --git a/arch/ia64/hp/common/sba_iommu.c b/arch/ia64/hp/common/sba_iommu.c
index 8e858b5..b341994 100644
--- a/arch/ia64/hp/common/sba_iommu.c
+++ b/arch/ia64/hp/common/sba_iommu.c
@@ -46,8 +46,6 @@
 
 #include 
 
-extern int swiotlb_late_init_with_default_size (size_t size);
-
 #define PFX "IOC: "
 
 /*
diff --git a/arch/x86/pci/sta2x11-fixup.c b/arch/x86/pci/sta2x11-fixup.c
index 9d8a509..a39000b 100644
--- a/arch/x86/pci/sta2x11-fixup.c
+++ b/arch/x86/pci/sta2x11-fixup.c
@@ -28,7 +28,6 @@
 #include 
 
 #define STA2X11_SWIOTLB_SIZE (4*1024*1024)
-extern int swiotlb_late_init_with_default_size(size_t default_size);
 
 /*
  * We build a list of bus numbers that are under the ConneXt. The
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index a5ffd32..7f419b6 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -27,7 +27,9 @@ int swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, 
int verbose);
 extern unsigned long swiotlb_nr_tbl(void);
 unsigned long swiotlb_size_or_default(void);
 extern int swiotlb_late_init_with_tbl(char *tlb, unsigned long nslabs);
-
+int swiotlb_late_init_with_default_size (size_t );
+phys_addr_t map_single(struct device *hwdev, phys_addr_t phys, size_t size,
+  enum dma_data_direction dir);
 /*
  * Enumeration for sync targets
  */
-- 
1.7.9.5

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

[PATCH] rcu: Copyright string update

2014-02-24 Thread Hidetoshi Seto

Fix corporate name for copyright.

Signed-off-by: Hidetoshi Seto 
---
 include/linux/srcu.h |2 +-
 kernel/rcu/srcu.c|2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/srcu.h b/include/linux/srcu.h
index 9b058ee..04f5abb 100644
--- a/include/linux/srcu.h
+++ b/include/linux/srcu.h
@@ -16,7 +16,7 @@
  * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
  *
  * Copyright (C) IBM Corporation, 2006
- * Copyright (C) Fujitsu, 2012
+ * Copyright (C) 2012 FUJITSU LIMITED
  *
  * Author: Paul McKenney 
  *Lai Jiangshan 
diff --git a/kernel/rcu/srcu.c b/kernel/rcu/srcu.c
index 3318d82..c9f29ea 100644
--- a/kernel/rcu/srcu.c
+++ b/kernel/rcu/srcu.c
@@ -16,7 +16,7 @@
  * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
  *
  * Copyright (C) IBM Corporation, 2006
- * Copyright (C) Fujitsu, 2012
+ * Copyright (C) 2012 FUJITSU LIMITED
  *
  * Author: Paul McKenney 
  *Lai Jiangshan 
-- 
1.7.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] btrfs: Copyright string update

2014-02-24 Thread Hidetoshi Seto

Fix corporate name for copyright.

Signed-off-by: Hidetoshi Seto 
---
 fs/btrfs/delayed-inode.c |2 +-
 fs/btrfs/delayed-inode.h |2 +-
 fs/btrfs/math.h  |2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/btrfs/delayed-inode.c b/fs/btrfs/delayed-inode.c
index 451b00c..483b918 100644
--- a/fs/btrfs/delayed-inode.c
+++ b/fs/btrfs/delayed-inode.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2011 Fujitsu.  All rights reserved.
+ * Copyright (C) 2011 FUJITSU LIMITED.  All rights reserved.
  * Written by Miao Xie 
  *
  * This program is free software; you can redistribute it and/or
diff --git a/fs/btrfs/delayed-inode.h b/fs/btrfs/delayed-inode.h
index f70119f..a07746d 100644
--- a/fs/btrfs/delayed-inode.h
+++ b/fs/btrfs/delayed-inode.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2011 Fujitsu.  All rights reserved.
+ * Copyright (C) 2011 FUJITSU LIMITED.  All rights reserved.
  * Written by Miao Xie 
  *
  * This program is free software; you can redistribute it and/or
diff --git a/fs/btrfs/math.h b/fs/btrfs/math.h
index b7816ce..1ce7e18 100644
--- a/fs/btrfs/math.h
+++ b/fs/btrfs/math.h
@@ -1,6 +1,6 @@
 
 /*
- * Copyright (C) 2012 Fujitsu.  All rights reserved.
+ * Copyright (C) 2012 FUJITSU LIMITED.  All rights reserved.
  * Written by Miao Xie 
  *
  * This program is free software; you can redistribute it and/or
-- 
1.7.1

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

[PATCH 2/8] lib: Mark function as static in lib/lru_cache.c

Mark function as static in lib/lru_cache.c because it is not used
outside this file.

This eliminates the following warning in lib/lru_cache.c:
lib/lru_cache.c:172:6: warning: no previous prototype for ‘lc_free_by_index’ 
[-Wmissing-prototypes]

Signed-off-by: Rashika Kheria 
Reviewed-by: Josh Triplett 
---
 lib/lru_cache.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/lru_cache.c b/lib/lru_cache.c
index 4a83ecd..6111cd1 100644
--- a/lib/lru_cache.c
+++ b/lib/lru_cache.c
@@ -169,7 +169,7 @@ out_fail:
return NULL;
 }
 
-void lc_free_by_index(struct lru_cache *lc, unsigned i)
+static void lc_free_by_index(struct lru_cache *lc, unsigned i)
 {
void *p = lc->lc_element[i];
WARN_ON(!p);
-- 
1.7.9.5

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

[PATCH 1/8] lib: Include appropriate header file in lib/iommu-helper.c

Include appropriate header file include/linux/iommu-helper.h in
lib/iommu-helper.c because it has prototype declaration of function
defined in lib/iommu-helper.c.

This eliminates the following warning in lib/iommu-helper.c:
lib/iommu-helper.c:9:5: warning: no previous prototype for 
‘iommu_is_span_boundary’ [-Wmissing-prototypes]
lib/iommu-helper.c:19:15: warning: no previous prototype for ‘iommu_area_alloc’ 
[-Wmissing-prototypes]

Signed-off-by: Rashika Kheria 
Reviewed-by: Josh Triplett 
---
 lib/iommu-helper.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/iommu-helper.c b/lib/iommu-helper.c
index c27e269..41d35fb 100644
--- a/lib/iommu-helper.c
+++ b/lib/iommu-helper.c
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 
 int iommu_is_span_boundary(unsigned int index, unsigned int nr,
   unsigned long shift,
-- 
1.7.9.5

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

Re: [PATCH v3 07/11] watchdog: xilinx: Use of_property_read_u32

2014-02-24 Thread Michal Simek

On 02/24/2014 08:25 PM, Wim Van Sebroeck wrote:
> Hi Michal,
> 
>> On 02/23/2014 08:00 PM, Alejandro Cabrera wrote:
>>> On 23/2/2014 6:43 AM, Guenter Roeck wrote:
 On 02/23/2014 08:25 AM, Alejandro Cabrera wrote:
> On 22/2/2014 7:44 PM, Guenter Roeck wrote:
>> On 02/22/2014 10:14 PM, Alejandro Cabrera wrote:
>>> On 22/2/2014 5:36 PM, Guenter Roeck wrote:
 On 02/22/2014 07:52 PM, Alejandro Cabrera wrote:
> On 22/2/2014 3:18 PM, Guenter Roeck wrote:
>> On 02/22/2014 05:08 PM, Alejandro Cabrera wrote:
>>> On 22/2/2014 10:46 AM, Wim Van Sebroeck wrote:
 Hi All,

> Hi Michal,
>
> On Wed, Feb 12, 2014 at 02:41:21PM +0100, Michal Simek wrote:
>> Use of_property_read_u32 functions to clean probe function.
>>
>> Signed-off-by: Michal Simek
>> Reviewed-by: Guenter Roeck
>> ---
>>
>> Changes in v3:
>> - Remove one if checking and use variable directly
>>
> Looks good.
>
> Another comment/remark.
>
>> -pfreq = (u32 *)of_get_property(pdev->dev.of_node,
>> -"clock-frequency", NULL);
>> -
>> -if (pfreq == NULL) {
>> +rc = of_property_read_u32(pdev->dev.of_node, 
>> "clock-frequency",);
>> +if (rc) {
>>   dev_warn(>dev,
>>"The watchdog clock frequency cannot be 
>> obtained\n");
>>   no_timeout = true;
>>   }
>>
>> -tmptr = (u32 *)of_get_property(pdev->dev.of_node,
>> -"xlnx,wdt-interval", NULL);
>> -if (tmptr == NULL) {
>> +rc = of_property_read_u32(pdev->dev.of_node, 
>> "xlnx,wdt-interval",
>> + >wdt_interval);
>> +if (rc) {
>>   dev_warn(>dev,
>>"Parameter \"xlnx,wdt-interval\" not found\n");
>>   no_timeout = true;
>> -} else {
>> -xdev->wdt_interval = *tmptr;
>>   }
>>
>> -tmptr = (u32 *)of_get_property(pdev->dev.of_node,
>> -"xlnx,wdt-enable-once", NULL);
>> -if (tmptr == NULL) {
>> +rc = of_property_read_u32(pdev->dev.of_node, 
>> "xlnx,wdt-enable-once",
>> + _once);
>> +if (rc)
>>   dev_warn(>dev,
>>"Parameter \"xlnx,wdt-enable-once\" not found\n");
>> -watchdog_set_nowayout(xilinx_wdt_wdd, true);
>> -}
> All the above properties are optional. Is a warning really
> warranted in this case ? I usually associate a warning with
> something that is wrong, which is not the case here.
>
> I would encourage you to drop those warnings, but that should be
> a separate patch.
 I agree with Guenter: these are not really warnings. Seperate 
 patch is thus welcome.
>>> Hi
>>>
>>> I support Michal intention, I think it is a warning because device 
>>> tree blob must have the "xlnx,wdt-enable-once" property specified 
>>> in order to allow the system to be sure of the real value of this 
>>> property. In addition to, this warning can be helpful to detect a 
>>> wrong device tree specification.
>>>
>>
>> The dt documentation states that the properties are optional.
>>
>> Optional properties:
>> - clock-frequency   : Frequency of clock in Hz
>> - xlnx,wdt-enable-once  : 0 - Watchdog can be restarted
>>   1 - Watchdog can be enabled just once
>> - xlnx,wdt-interval : Watchdog timeout interval in 2^ clock 
>> cycles,
>>  is integer from 8 to 31.
>>
>> This clearly conflicts with your statement. An optional property
>> is just that, optional. If it warrants a warning, it must
>> not be optional. If you claim that not providing the properties
>> would be "wrong", why are they defined as optional ?
> Hi Guenter
>
> I didn't know that these properties was classified as optional...
> I think that they should not be, because all xilinx watchog devices 
> (at least for microblaze processor)
> have these properties defined in theirs MPD files and theirs values 
> can be obtained during the
> hardware specification to device tree conversion.
>> What is your definition of "wrong" and "must have" ?
> what I mean for "must have"

Re: [PATCH 6/8] security: smack: Use a more current logging style

2014-02-24 Thread James Morris

On Mon, 24 Feb 2014, Casey Schaufler wrote:

> On 2/24/2014 2:35 PM, Casey Schaufler wrote:
> > On 2/24/2014 1:59 PM, Joe Perches wrote:
> >> Convert printks to pr_
> >> Add pr_fmt.
> >>
> >> Signed-off-by: Joe Perches 
> > Acked-by: Casey Schaufler 
> >
> > I will take this into the smack-next tree.
> 
> Unless James would rather take the whole set, that is.

Yep, I'll take the whole set.


> 
> >
> >> ---
> >>  security/smack/smack_lsm.c |  7 ---
> >>  security/smack/smackfs.c   | 25 +++--
> >>  2 files changed, 15 insertions(+), 17 deletions(-)
> >>
> >> diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
> >> index 14f52be..a273aad 100644
> >> --- a/security/smack/smack_lsm.c
> >> +++ b/security/smack/smack_lsm.c
> >> @@ -18,6 +18,8 @@
> >>   *  as published by the Free Software Foundation.
> >>   */
> >>  
> >> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> >> +
> >>  #include 
> >>  #include 
> >>  #include 
> >> @@ -2106,8 +2108,7 @@ static int smack_inode_setsecurity(struct inode 
> >> *inode, const char *name,
> >>if (sock->sk->sk_family == PF_INET) {
> >>rc = smack_netlabel(sock->sk, SMACK_CIPSO_SOCKET);
> >>if (rc != 0)
> >> -  printk(KERN_WARNING
> >> -  "Smack: \"%s\" netlbl error %d.\n",
> >> +  pr_warn("\"%s\" netlbl error %d\n",
> >>__func__, -rc);
> >>}
> >>} else
> >> @@ -3916,7 +3917,7 @@ static __init int smack_init(void)
> >>if (tsp == NULL)
> >>return -ENOMEM;
> >>  
> >> -  printk(KERN_INFO "Smack:  Initializing.\n");
> >> +  pr_info("Initializing\n");
> >>  
> >>/*
> >> * Set the security state for the initial task.
> >> diff --git a/security/smack/smackfs.c b/security/smack/smackfs.c
> >> index 3198cfe..2e25220 100644
> >> --- a/security/smack/smackfs.c
> >> +++ b/security/smack/smackfs.c
> >> @@ -16,6 +16,8 @@
> >>   *
> >>   */
> >>  
> >> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> >> +
> >>  #include 
> >>  #include 
> >>  #include 
> >> @@ -698,8 +700,7 @@ static void smk_cipso_doi(void)
> >>  
> >>rc = netlbl_cfg_map_del(NULL, PF_INET, NULL, NULL, );
> >>if (rc != 0)
> >> -  printk(KERN_WARNING "%s:%d remove rc = %d\n",
> >> - __func__, __LINE__, rc);
> >> +  pr_warn("%s:%d remove rc = %d\n", __func__, __LINE__, rc);
> >>  
> >>doip = kmalloc(sizeof(struct cipso_v4_doi), GFP_KERNEL);
> >>if (doip == NULL)
> >> @@ -713,15 +714,13 @@ static void smk_cipso_doi(void)
> >>  
> >>rc = netlbl_cfg_cipsov4_add(doip, );
> >>if (rc != 0) {
> >> -  printk(KERN_WARNING "%s:%d cipso add rc = %d\n",
> >> - __func__, __LINE__, rc);
> >> +  pr_warn("%s:%d cipso add rc = %d\n", __func__, __LINE__, rc);
> >>kfree(doip);
> >>return;
> >>}
> >>rc = netlbl_cfg_cipsov4_map_add(doip->doi, NULL, NULL, NULL, );
> >>if (rc != 0) {
> >> -  printk(KERN_WARNING "%s:%d map add rc = %d\n",
> >> - __func__, __LINE__, rc);
> >> +  pr_warn("%s:%d map add rc = %d\n", __func__, __LINE__, rc);
> >>kfree(doip);
> >>return;
> >>}
> >> @@ -741,8 +740,8 @@ static void smk_unlbl_ambient(char *oldambient)
> >>if (oldambient != NULL) {
> >>rc = netlbl_cfg_map_del(oldambient, PF_INET, NULL, NULL, );
> >>if (rc != 0)
> >> -  printk(KERN_WARNING "%s:%d remove rc = %d\n",
> >> - __func__, __LINE__, rc);
> >> +  pr_warn("%s:%d remove rc = %d\n",
> >> +  __func__, __LINE__, rc);
> >>}
> >>if (smack_net_ambient == NULL)
> >>smack_net_ambient = _known_floor;
> >> @@ -750,8 +749,7 @@ static void smk_unlbl_ambient(char *oldambient)
> >>rc = netlbl_cfg_unlbl_map_add(smack_net_ambient->smk_known, PF_INET,
> >>  NULL, NULL, );
> >>if (rc != 0)
> >> -  printk(KERN_WARNING "%s:%d add rc = %d\n",
> >> - __func__, __LINE__, rc);
> >> +  pr_warn("%s:%d add rc = %d\n", __func__, __LINE__, rc);
> >>  }
> >>  
> >>  /*
> >> @@ -2302,8 +2300,7 @@ static int smk_fill_super(struct super_block *sb, 
> >> void *data, int silent)
> >>  
> >>rc = simple_fill_super(sb, SMACK_MAGIC, smack_files);
> >>if (rc != 0) {
> >> -  printk(KERN_ERR "%s failed %d while creating inodes\n",
> >> -  __func__, rc);
> >> +  pr_err("%s failed %d while creating inodes\n", __func__, rc);
> >>return rc;
> >>}
> >>  
> >> @@ -2369,13 +2366,13 @@ static int __init init_smk_fs(void)
> >>  
> >>err = smk_init_sysfs();
> >>if (err)
> >> -  printk(KERN_ERR "smackfs: sysfs mountpoint problem.\n");
> >> +  pr_err("smackfs: sysfs mountpoint problem\n");
> >>  
> >>

Re: [PATCH 1/1] hfsplus: fix longname handling

2014-02-24 Thread Vyacheslav Dubeyko

Hi Sougata,

On Mon, 2014-02-24 at 21:28 +0200, Sougata Santra wrote:
> -ENAMETOOLONG returned from hfsplus_asc2uni was not propaged to iops. This
> allowed hfsplus to create files/directories with HFSPLUS_MAX_STRLEN and
> incorrect keys, leaving the FS in an inconsistent state. This patch fixes
> this issue.
> 

Good fix. Thank you.

I have some small remarks. Please, see below.

> Signed-off-by: Sougata Santra 
> Reviewed-by: Christoph Hellwig 
> ---
>  fs/hfsplus/catalog.c| 89 
> -
>  fs/hfsplus/dir.c| 11 --
>  fs/hfsplus/hfsplus_fs.h |  4 ++-
>  fs/hfsplus/super.c  |  4 ++-
>  4 files changed, 79 insertions(+), 29 deletions(-)
> 
> diff --git a/fs/hfsplus/catalog.c b/fs/hfsplus/catalog.c
> index 968ce41..389c474 100644
> --- a/fs/hfsplus/catalog.c
> +++ b/fs/hfsplus/catalog.c
> @@ -38,21 +38,30 @@ int hfsplus_cat_bin_cmp_key(const hfsplus_btree_key *k1,
>   return hfsplus_strcmp(>cat.name, >cat.name);
>  }
>  
> -void hfsplus_cat_build_key(struct super_block *sb, hfsplus_btree_key *key,
> -u32 parent, struct qstr *str)
> +/* Generates key for catalog file/folders record. */
> +int hfsplus_cat_build_key(struct super_block *sb,
> + hfsplus_btree_key *key, u32 parent, struct qstr *str)
>  {
> - int len;
> + int len, err;
>  
>   key->cat.parent = cpu_to_be32(parent);
> - if (str) {
> - hfsplus_asc2uni(sb, >cat.name, HFSPLUS_MAX_STRLEN,
> - str->name, str->len);
> - len = be16_to_cpu(key->cat.name.length);
> - } else {
> - key->cat.name.length = 0;
> - len = 0;
> - }
> + err = hfsplus_asc2uni(sb, >cat.name, HFSPLUS_MAX_STRLEN,
> + str->name, str->len);
> + if (unlikely(err < 0))
> + return err;
> +
> + len = be16_to_cpu(key->cat.name.length);
>   key->key_len = cpu_to_be16(6 + 2 * len);

I think that maybe it is time to change hardcoded 6 on sensible named
constant. What do you think?

> + return 0;
> +}
> +
> +/* Generates key for catalog thread record. */
> +void hfsplus_cat_build_key_with_cnid(struct super_block *sb,
> + hfsplus_btree_key *key, u32 parent)
> +{
> + key->cat.parent = cpu_to_be32(parent);
> + key->cat.name.length = 0;
> + key->key_len = cpu_to_be16(6);

Ditto.

>  }
>  
>  static void hfsplus_cat_build_key_uni(hfsplus_btree_key *key, u32 parent,

We have such code for hfsplus_cat_build_key_uni():

 58 static void hfsplus_cat_build_key_uni(hfsplus_btree_key *key, u32 parent,
 59   struct hfsplus_unistr *name)
 60 {
 61 int ustrlen;
 62 
 63 ustrlen = be16_to_cpu(name->length);

I suppose that it makes sense to check name->length here and return
error. We can check possible volume corruption here.

 64 key->cat.parent = cpu_to_be32(parent);
 65 key->cat.name.length = cpu_to_be16(ustrlen);
 66 ustrlen *= 2;
 67 memcpy(key->cat.name.unicode, name->unicode, ustrlen);
 68 key->key_len = cpu_to_be16(6 + ustrlen);
 69 }

What do you think about such suggestion?

> diff --git a/fs/hfsplus/hfsplus_fs.h b/fs/hfsplus/hfsplus_fs.h
> index 08846425b..66671c4 100644
> --- a/fs/hfsplus/hfsplus_fs.h
> +++ b/fs/hfsplus/hfsplus_fs.h
> @@ -443,8 +443,10 @@ int hfsplus_cat_case_cmp_key(const hfsplus_btree_key *,
>   const hfsplus_btree_key *);
>  int hfsplus_cat_bin_cmp_key(const hfsplus_btree_key *,
>   const hfsplus_btree_key *);
> -void hfsplus_cat_build_key(struct super_block *sb,
> +int hfsplus_cat_build_key(struct super_block *sb,
>   hfsplus_btree_key *, u32, struct qstr *);
> +void hfsplus_cat_build_key_with_cnid(struct super_block *sb,

The whole style of the fix is good. But such mess looks not very good.
But it is not critical, of course. :)

Thanks,
Vyacheslav Dubeyko.


--
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] ASoC: simple-card: Fix device node locks

2014-02-24 Thread Jean-Francois Moine

On Mon, 24 Feb 2014 02:17:00 +
"li.xi...@freescale.com"  wrote:

> > @@ -169,22 +164,26 @@ static int asoc_simple_card_parse_of(struct 
> > device_node
> > *node,
> > /* CPU sub-node */
> > ret = -EINVAL;
> > np = of_get_child_by_name(node, "simple-audio-card,cpu");
> > -   if (np)
> > +   if (np) {
> > ret = asoc_simple_card_sub_parse_of(np, priv->daifmt,
> >   >cpu_dai,
> >   _link->cpu_of_node,
> >   _link->cpu_dai_name);
> > +   of_node_put(np);
> 
> Does the of_node_put(np) is really needed here ?
[snip]

Yes, of_get_child_by_name() increments the node refcount and np is not
used afterwards.

But, you are right, this creates a bug in the next patch when using
of_get_next_child(). I will fix it.

Thanks.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
--
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] usb: gadget: mv_udc: clear corresponding interrupt when flush fifo



> -Original Message-
> From: Peter Chen [mailto:peter.c...@freescale.com]
> Sent: 2014年2月25日 9:59
> To: Neil Zhang
> Cc: ba...@ti.com; gre...@linuxfoundation.org; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 3/6] usb: gadget: mv_udc: clear corresponding interrupt
> when flush fifo
> 
> On Mon, Feb 24, 2014 at 04:03:13PM +0800, Neil Zhang wrote:
> > The interruts are useless when this endpoint is going to be flushed.
> > Especially in the enumeration phase, let's take get device description
> > for example.
> > 1. Device doesn't ACK the status package from host in time due to irq
> > is disabled by some module.
> > 2. Host find no ACK in time, and send another request.
> 
> Why device does not send NAK at that time?
> Besides, you can try to prime status at data stage, it can also avoid the
> problem usb 2.0 8.5.3.3 "Error Handling on the Last Data Transaction"
> described.
> 
> > 3. Device gets the chance to handle the interrupt, the sequence is as
> > following.
> > a. Flush pending requests in ep0.
> > b. Queue a request in ep0 according to host's request and change
> >the ep0 state to DATA_STATE_XMIT.
> > c. Handle the pending interrupt for the last status package. But
> >actually it will check the new added request instead of the status
> >package and because of wront ep0 state, device will request an
> 
> %s/wront/wrong


Thanks for the catch.
> 
> Peter
> 
> >unexpected status package from host.
> > d. The ep0 state is going mad.
> >
> > The solution is that we need clear the pending corresponding interrupt
> > as well as flush endpoint.
> >
> > Signed-off-by: Neil Zhang 
> > ---
> >  drivers/usb/gadget/mv_udc_core.c |2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/usb/gadget/mv_udc_core.c
> > b/drivers/usb/gadget/mv_udc_core.c
> > index 657ac5c..d5a9bdf 100644
> > --- a/drivers/usb/gadget/mv_udc_core.c
> > +++ b/drivers/usb/gadget/mv_udc_core.c
> > @@ -692,6 +692,8 @@ static void mv_ep_fifo_flush(struct usb_ep *_ep)
> > }
> > loops--;
> > } while (readl(>op_regs->epstatus) & bit_pos);
> > +
> > +   writel(bit_pos, >op_regs->epcomplete);
> >  }
> >
> >  /* queues (submits) an I/O request to an endpoint */
> > --
> > 1.7.9.5
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-usb"
> > in the body of a message to majord...@vger.kernel.org More majordomo
> > info at  http://vger.kernel.org/majordomo-info.html
> >
> >
> 

Best Regards,
Neil Zhang

> --
> 
> Best Regards,
> Peter Chen

RE: [PATCH 5/6] USB: gadget: mv_udc: workaroud for missing dTD



 
> > From: Peter Chen [mailto:peter.c...@freescale.com]
> > Sent: 2014年2月25日 12:19
> > To: Neil Zhang
> > Cc: ba...@ti.com; gre...@linuxfoundation.org;
> > linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH 5/6] USB: gadget: mv_udc: workaroud for missing
> > dTD
> >
> > On Mon, Feb 24, 2014 at 04:03:15PM +0800, Neil Zhang wrote:
> > > There is an issue with the add dTD tripwire semaphore (ATDTW bit in
> > > USBCMD register) that can cause the controller to ignore a dTD that
> > > is added to a primed endpoint. When this happens, the software can
> > > read the tripwire bit and the status bit at '1' even though the
> > > endpoint is unprimed.
> > >
> > > After executing a dTD, the device controller endpoint state machine
> > > executes a final read of the dTD terminate bit to check if the
> > > application added a dTD to the linked list at the last moment. This
> > > read is done in the finpkt_read_latest_next_td (44) state. After the
> > > read is performed, if the terminate bit is still set, the state
> > > machine moves to unprime the endpoint. The decision to unprime the
> > > endpoint is done in the checkqh_decision (59) state, based on the
> > > value of
> > the terminate bit.
> > >
> > > Before reaching the checkqh_decision state, the state machine
> > > traverses the writeqhtd_status (57), writeqh_status (56), and
> > > release_prime_mask
> > > (42) states. As shown in the waveform, the ep_addtd_tripwire_clr
> > > signal is not set to clear the tripwire bit in these states.
> > >
> > > Signed-off-by: Neil Zhang 
> > > ---
> > >  drivers/usb/gadget/mv_udc_core.c |   20 
> > >  1 file changed, 20 insertions(+)
> > >
> > > diff --git a/drivers/usb/gadget/mv_udc_core.c
> > > b/drivers/usb/gadget/mv_udc_core.c
> > > index a620cff..8df8606 100644
> > > --- a/drivers/usb/gadget/mv_udc_core.c
> > > +++ b/drivers/usb/gadget/mv_udc_core.c
> > > @@ -196,7 +196,27 @@ static int process_ep_req(struct mv_udc *udc,
> > > int
> > index,
> > >   while (readl(>op_regs->epstatus) & bit_pos)
> > >   udelay(1);
> > >   break;
> > > + } else {
> > > + if (!(readl(>op_regs->epstatus) & bit_pos)) {
> > > + /* The DMA engine thinks there is no more dTD */
> > > + curr_dqh->next_dtd_ptr = curr_dtd->dtd_next
> > > + & EP_QUEUE_HEAD_NEXT_POINTER_MASK;
> > > +
> > > + /* clear active and halt bit */
> > > + curr_dqh->size_ioc_int_sts &=
> > > + ~(DTD_STATUS_ACTIVE
> > > + | DTD_STATUS_HALTED);
> > > +
> > > + /* Do prime again */
> > > + wmb();
> > > + writel(bit_pos, >op_regs->epprime);
> > > + while (readl(>op_regs->epprime) & bit_pos)
> > > + cpu_relax();
> > > +
> > > + break;
> > > + }
> > >   }
> > > +
> > >   udelay(1);
> > >   }
> > >
> >
> > Is it a chipidea IP issue? Any errate number for this issue?
> > Does we need it for chipidea driver?
> >
> 
> Yes, I think so.
> 9000531823B2-Medium   Adding a dTD to a Primed Endpoint May Not Get
> Recognized
> Impacted Configuration: All device mode configurations.
> 
 
Thanks for your information.

Peter

--
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] drivercore: deferral race condition fix

2014-02-24 Thread Peter Ujfalusi

On 02/24/2014 07:22 PM, Greg Kroah-Hartman wrote:
> On Mon, Feb 24, 2014 at 10:40:32AM +0900, Mark Brown wrote:
>> On Mon, Dec 23, 2013 at 02:41:31PM +0200, Peter Ujfalusi wrote:
>>
>>> The proposed solution is to try the deferred queue once more when the last
>>> driver is asking for deferring and we had drivers probed while this last
>>> driver was probing.
>>
>> Greg, this patch doesn't seem to have been applied but it looks like
>> it's addressing a real issue and seems like a reasonable fix?  Peter's
>> analysis seems good to me.
> 
> I really don't remember, it's not in my queue anymore, as I can't apply
> [RFC] patches :(

Do you want me to resend as a patch?

-- 
Péter
--
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] bug fix for mv_udc_core.c


> -Original Message-
> From: Peter Chen [mailto:peter.c...@freescale.com]
> Sent: 2014年2月25日 12:18
> To: Neil Zhang
> Cc: Matthieu CASTET; ba...@ti.com; gre...@linuxfoundation.org;
> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 0/6] bug fix for mv_udc_core.c
> 
> On Mon, Feb 24, 2014 at 04:42:40AM -0800, Neil Zhang wrote:
> >
> > > -Original Message-
> > > From: Matthieu CASTET [mailto:matthieu.cas...@parrot.com]
> > > Sent: 2014年2月24日 18:32
> > > To: Neil Zhang
> > > Cc: ba...@ti.com; gre...@linuxfoundation.org;
> > > linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
> > > Subject: Re: [PATCH 0/6] bug fix for mv_udc_core.c
> > >
> > > Le Mon, 24 Feb 2014 16:03:10 +0800,
> > > Neil Zhang  a écrit :
> > >
> > > > This patch set is mainly for bug fix.
> > > >
> > > > Neil Zhang (6):
> > > >   usb: gadget: mv_udc: remove redundant pull up in udc_start
> > > >   usb: gadget: mv_udc: disable HW zlt for ep0
> > > >   usb: gadget: mv_udc: clear corresponding interrupt when flush fifo
> > > >   usb: gadget: mv_udc: check endpoint before queue dtd
> > > >   USB: gadget: mv_udc: workaroud for missing dTD
> > > >   USB: gadget: mv_udc: fix corner case for missiong dTD
> > > >
> > > >  drivers/usb/gadget/mv_udc_core.c |   47
> > > ++
> > > >  1 file changed, 42 insertions(+), 5 deletions(-)
> > > >
> > >
> > > Do you have plan to move to the chipidea udc driver ?
> > >
> > > You could have some bug fix for free or share your bug fix with others.
> > >
> >
> >
> > Not yet.
> > Will estimate it later.
> > >
> 
> Freescale uses mv udc driver at u-boot, so the chipidea IP should be
> compatible for two SoCs , both Intel and msm are using chipidea driver at 
> linux
> kernel, it should be not difficult for marvell to use it.
> 
> For this patchset, some of them may already be fixed at chipidea driver (3/6,
> 4/6), some of them may not (5/6, 6/6).
> 
> --

Thanks for the comments.
Since we are using it in our product, so it's not that easy to switch to a new 
driver.

> 
> Best Regards,
> Peter Chen

Best Regards,
Neil Zhang

Re: A Bug Inquiry in linux/tools/perf/builtin-record.c

2014-02-24 Thread xiakaixu

于 2014/2/19 9:48, xiakaixu 写道:
> Hi all,
> 
> There is a bug found in my work when running "perf record". The basic 
> information
> is here. As we know, perf record is a parent process and the programme traced 
> is
> a child process when running "perf record". Sometimes the child process become
> zombie state and disappear until the parent process is killed. The bug stays 
> in linux/
> tools/perf/builtin-record.c.
> *
> static int __cmd_record(struct perf_record *rec, int argc, const char **argv)
> ..
>   if (hits == rec->samples) {
>  if (done)
>  break;
>  err = poll(evsel_list->pollfd, evsel_list->nr_fds, 
> -1);
>  waking++;
>  }
> ..
> *
> The parent process still call the function
> poll(evsel_list->pollfd, evsel_list->nr_fds, -1) when the child process has 
> exited
> already, which caused a zombie process.
> 
> May I have your opinion ?
> Waiting for your reply!
> 
> Best Regards
> Kaixu Xia
> 


--
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 5/6] USB: gadget: mv_udc: workaroud for missing dTD



> -Original Message-
> From: Peter Chen [mailto:peter.c...@freescale.com]
> Sent: 2014年2月25日 12:19
> To: Neil Zhang
> Cc: ba...@ti.com; gre...@linuxfoundation.org; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 5/6] USB: gadget: mv_udc: workaroud for missing dTD
> 
> On Mon, Feb 24, 2014 at 04:03:15PM +0800, Neil Zhang wrote:
> > There is an issue with the add dTD tripwire semaphore (ATDTW bit in
> > USBCMD register) that can cause the controller to ignore a dTD that is
> > added to a primed endpoint. When this happens, the software can read
> > the tripwire bit and the status bit at '1' even though the endpoint is
> > unprimed.
> >
> > After executing a dTD, the device controller endpoint state machine
> > executes a final read of the dTD terminate bit to check if the
> > application added a dTD to the linked list at the last moment. This
> > read is done in the finpkt_read_latest_next_td (44) state. After the
> > read is performed, if the terminate bit is still set, the state
> > machine moves to unprime the endpoint. The decision to unprime the
> > endpoint is done in the checkqh_decision (59) state, based on the value of
> the terminate bit.
> >
> > Before reaching the checkqh_decision state, the state machine
> > traverses the writeqhtd_status (57), writeqh_status (56), and
> > release_prime_mask
> > (42) states. As shown in the waveform, the ep_addtd_tripwire_clr
> > signal is not set to clear the tripwire bit in these states.
> >
> > Signed-off-by: Neil Zhang 
> > ---
> >  drivers/usb/gadget/mv_udc_core.c |   20 
> >  1 file changed, 20 insertions(+)
> >
> > diff --git a/drivers/usb/gadget/mv_udc_core.c
> > b/drivers/usb/gadget/mv_udc_core.c
> > index a620cff..8df8606 100644
> > --- a/drivers/usb/gadget/mv_udc_core.c
> > +++ b/drivers/usb/gadget/mv_udc_core.c
> > @@ -196,7 +196,27 @@ static int process_ep_req(struct mv_udc *udc, int
> index,
> > while (readl(>op_regs->epstatus) & bit_pos)
> > udelay(1);
> > break;
> > +   } else {
> > +   if (!(readl(>op_regs->epstatus) & bit_pos)) {
> > +   /* The DMA engine thinks there is no more dTD */
> > +   curr_dqh->next_dtd_ptr = curr_dtd->dtd_next
> > +   & EP_QUEUE_HEAD_NEXT_POINTER_MASK;
> > +
> > +   /* clear active and halt bit */
> > +   curr_dqh->size_ioc_int_sts &=
> > +   ~(DTD_STATUS_ACTIVE
> > +   | DTD_STATUS_HALTED);
> > +
> > +   /* Do prime again */
> > +   wmb();
> > +   writel(bit_pos, >op_regs->epprime);
> > +   while (readl(>op_regs->epprime) & bit_pos)
> > +   cpu_relax();
> > +
> > +   break;
> > +   }
> > }
> > +
> > udelay(1);
> > }
> >
> 
> Is it a chipidea IP issue? Any errate number for this issue?
> Does we need it for chipidea driver?
> 

Yes, I think so.
9000531823  B2-Medium   Adding a dTD to a Primed Endpoint May Not Get 
Recognized
Impacted Configuration: All device mode configurations. 

> --
> 
> Best Regards,
> Peter Chen

Best Regards,
Neil Zhang

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 2/6] usb: gadget: mv_udc: disable HW zlt for ep0


> -Original Message-
> From: Peter Chen [mailto:peter.c...@freescale.com]
> Sent: 2014年2月25日 13:15
> To: Neil Zhang
> Cc: ba...@ti.com; gre...@linuxfoundation.org; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: RE: [PATCH 2/6] usb: gadget: mv_udc: disable HW zlt for ep0
> 
> 
> 
> 
> > > On Mon, Feb 24, 2014 at 04:03:12PM +0800, Neil Zhang wrote:
> > > > Hardware zlt will try to send the zero length packet automatically
> > > > when the data transferd is multiple times of max packet, this will
> > > > cause issues on Windows.
> > > > So let's disable HW zlt by default.
> > >
> > > Would you have description that what kinds of issue on Windows if
> > > zlt is is selected?
> > >
> >
> > Enumeration will fail.
> >
> 
> What causes enumeration fail, why it does not occur before?
> 
A unexpected zero packet cause enumeration fail.
It's not easy that the descriptor is actually 1024 bytes, so not easy to be 
found.

> Peter

Best Regards,
Neil Zhang

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] tools: Unify export.h

2014-02-24 Thread Borislav Petkov

On Tue, Feb 25, 2014 at 12:09:23PM +1030, Rusty Russell wrote:
> Should we get more ambitious and start a fake-kernel/ directory where
> we can put userspace equivs/stubs of kernel functionality?

Dunno - people like to do that now, it seems.

In any case, cleanups and unifications like that would definitely help
if we decide to do that because, in this particular example, we have
only one export.h to go and fish out.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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] regulator: core: allow enabling without enable op

2014-02-24 Thread Alexandre Courbot

Commit 14c32a3ce6676265d7a27ea64a4d406e6dbad111 replaced direct uses of
ops->enable by calls to _regulator_do_enable. This prevents a fixed
regulators without a GPIO from being probed, since the former code
checked the existence of ops->enable and continued if it did not exist,
while _regulator_do_enable return -EINVAL in that case.

This patch fixes this by allowing _regulator_do_enable to go through
without error if ops->enable is not defined, similarly to what
_regulator_do_disable already does.

Signed-off-by: Alexandre Courbot 
---
 drivers/regulator/core.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index bdb12659dd41..4306422cee5d 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1763,8 +1763,6 @@ static int _regulator_do_enable(struct regulator_dev 
*rdev)
ret = rdev->desc->ops->enable(rdev);
if (ret < 0)
return ret;
-   } else {
-   return -EINVAL;
}
 
/* Allow the regulator to ramp; it would be useful to extend
-- 
1.9.0

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

Re: [RFC PATCH v1 1/2] perf/sdt : Listing of SDT markers by perf

2014-02-24 Thread Namhyung Kim

Hi Hemant,

On Mon, 24 Feb 2014 14:45:43 +0530, Hemant Kumar wrote:
> This patch enables perf to list the SDT markers present in a system. It looks
> in dsos given by ldconfig --print-cache and for other binaries, it looks into
> the PATH environment variable. After preparing a list of the binaries, then
> it starts searching for SDT markers in them.
> To find the SDT markers, first an elf section named .note.stapsdt is searched
> for. And then the SDT notes are retreived one by one from that section.
> To counter the effect of prelinking, the section ".stapsdt.base" is searched.
> If its found, then the location of the SDT marker is adjusted.
>
> All these markers' info is written into a cache file
> "/var/cache/perf/perf-sdt.cache".
> Since, the presence of SDT markers is quite common these days, hence, its 
> better
> to make them visible to a user easily. Also, creating a cache file will help 
> a user
> to probe (to be implemented) these markers without much hussle. This cache 
> file will
> hold most of the SDT markers.
> The format of each entry is -
>
> %provider : marker : file_path : build_id : location : semaphore_loc
>
> % - marks the beginning of each entry.
> provider - The provider name of the SDT marker.
> marker - The marker name of the SDT marker.
> file_path - Full/absolute path of the file in which this marker is present.
> location : Adjusted location of the SDT marker inside the program.
> semaphore_loc : The semaphore address if present otherwise 0x0.
>
> This format should help when probing will be implemented. The adjusted address
> from the required entry can be directly used in probing if the build_id 
> matches.
>
> To use this feature, invoke :
> # perf list sdt --scan
>
> "--scan" should be used for the first time and whenever there is any change in
> the files containing the SDT markers.
>
> And then use :
> # perf list sdt
>
> This displays a list of SDT markers (read from the cache file) present in 
> most of
> the dsos and other binaries.

The default action of perf list (with no argument) prints all available
events on the system - so it should also print SDT markers IMHO.

>
> However, not all the SDT markers are present in the cache file. Only the ELFs
> present in the directories in PATH variable are looked into.
> An individual file argument can be given to "perf list" to find out the SDT 
> markers
> present in that file. Usage is as below :
>
> # perf list sdt /home/hemant/tmp
>
> /home/hemant/tmp:
> %user : foo
> %user : bar
>
> Signed-off-by : hks...@linux.vnet.ibm.com
> ---

[SNIP]
> +/*
> + * Finds out the libraries present in a system as shown by the command
> + * "ldconfig --print-cache". Uses "=>" and '/' to find out the start of a
> + * dso path.
> + */
> +static void parse_lib_name(char *str, char *path)
> +{
> + char *ptr, *q, *r;
> + char c = '=';
> +
> + while (str != NULL) {
> + /* look for "=>" and then '/' */
> + ptr = strchr(str, c);
> + if (ptr && (*(ptr + 1) == '>')) {

Hmm.. why not searching "=>" by strstr() then?


> + ptr++;
> + q = strchr(ptr, '/');
> + if (!q)
> + return;
> + r = strchr(ptr, '\n');
> + *r = '\0';
> + strcpy(path, q);
> + return;
> + } else if (ptr == NULL) {
> + return;
> + } else {
> + str = ptr + 1;
> + continue;
> + }
> + }
> +}

[SNIP]
> + /*
> +  * Take a line from the o/p of ldconfig and
> +  * parse it to find a library path
> +  */
> + while (getline(, , fp) != -1) {
> + memset(path, '\0', PATH_MAX);
> + parse_lib_name(line, path);
> + if (strcmp(path, ""))

I think it'd better changing the parse_lib_name to return a value
instead of checking whether the path is an empty string.


> + append_path(path, _list.list);
> + }
> + /* line and fp no more required */
> + free(line);
> + pclose(fp);
> +
> + /* Find and write the SDT markers in the perf-sdt cache*/
> + flush_sdt_list(_list.list, cache);
> +
> + cleanup_path_list(_list.list);
> + return;
> +}

[SNIP]
> +static int populate_sdt_note(Elf **elf, const char *data, size_t len, int 
> type,
> +  struct sdt_note **note)
> +{
> + const char *provider, *name;
> + struct sdt_note *tmp = NULL;
> + GElf_Ehdr ehdr;
> + GElf_Addr base_off = 0;
> + GElf_Shdr shdr;
> + int ret = -1;
> + int i;
> +
> + union {
> + Elf64_Addr a64[3];
> + Elf32_Addr a32[3];
> + } buf;
> +
> + Elf_Data dst = {
> + .d_buf = , .d_type = ELF_T_ADDR, .d_version = EV_CURRENT,
> + .d_size = gelf_fsize((*elf), ELF_T_ADDR, 3, EV_CURRENT),
> + .d_off = 0, .d_align = 0

[PATCH net] vhost: net: switch to use data copy if pending DMAs exceed the limit

2014-02-24 Thread Jason Wang

We used to stop the handling of tx when the number of pending DMAs
exceeds VHOST_MAX_PEND. This is used to reduce the memory occupation
of both host and guest. But it was too aggressive in some cases, since
any delay or blocking of a single packet may delay or block the guest
transmission. Consider the following setup:

+-++-+
| VM1 || VM2 |
+--+--++--+--+
   |  |
+--+--++--+--+
| tap0|| tap1|
+--+--++--+--+
   |  |
pfifo_fast   htb(10Mbit/s)
   |  |
+--+--+---+
| bridge  |
+--+--+
   |
pfifo_fast
   |
+-+
| eth0|(100Mbit/s)
+-+

- start two VMs and connect them to a bridge
- add an physical card (100Mbit/s) to that bridge
- setup htb on tap1 and limit its throughput to 10Mbit/s
- run two netperfs in the same time, one is from VM1 to VM2. Another is
  from VM1 to an external host through eth0.
- result shows that not only the VM1 to VM2 traffic were throttled but
  also the VM1 to external host through eth0 is also throttled somehow.

This is because the delay added by htb may lead the delay the finish
of DMAs and cause the pending DMAs for tap0 exceeds the limit
(VHOST_MAX_PEND). In this case vhost stop handling tx request until
htb send some packets. The problem here is all of the packets
transmission were blocked even if it does not go to VM2.

We can solve this issue by relaxing it a little bit: switching to use
data copy instead of stopping tx when the number of pending DMAs
exceed the VHOST_MAX_PEND. This is safe because:

- The number of pending DMAs were still limited by VHOST_MAX_PEND
- The out of order completion during mode switch can make sure that
  most of the tx buffers were freed in time in guest.

So even if about 50% packets were delayed in zero-copy case, vhost
could continue to do the transmission through data copy in this case.

Test result:

Before this patch:
VM1 to VM2 throughput is 9.3Mbit/s
VM1 to External throughput is 40Mbit/s

After this patch:
VM1 to VM2 throughput is 9.3Mbit/s
Vm1 to External throughput is 93Mbit/s

Simple performance test on 40gbe shows no obvious changes in
throughput after this patch.

The patch only solve this issue when unlimited sndbuf. We still need a
solution for limited sndbuf.

Cc: Michael S. Tsirkin 
Cc: Qin Chuanyu 
Signed-off-by: Jason Wang 
---
 drivers/vhost/net.c | 17 +++--
 1 file changed, 7 insertions(+), 10 deletions(-)

diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index a0fa5de..3e96e47 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -345,7 +345,7 @@ static void handle_tx(struct vhost_net *net)
.msg_flags = MSG_DONTWAIT,
};
size_t len, total_len = 0;
-   int err;
+   int err, num_pends;
size_t hdr_size;
struct socket *sock;
struct vhost_net_ubuf_ref *uninitialized_var(ubufs);
@@ -366,13 +366,6 @@ static void handle_tx(struct vhost_net *net)
if (zcopy)
vhost_zerocopy_signal_used(net, vq);
 
-   /* If more outstanding DMAs, queue the work.
-* Handle upend_idx wrap around
-*/
-   if (unlikely((nvq->upend_idx + vq->num - VHOST_MAX_PEND)
- % UIO_MAXIOV == nvq->done_idx))
-   break;
-
head = vhost_get_vq_desc(>dev, vq, vq->iov,
 ARRAY_SIZE(vq->iov),
 , ,
@@ -405,9 +398,13 @@ static void handle_tx(struct vhost_net *net)
break;
}
 
+   num_pends = likely(nvq->upend_idx >= nvq->done_idx) ?
+   (nvq->upend_idx - nvq->done_idx) :
+   (nvq->upend_idx + UIO_MAXIOV -
+nvq->done_idx);
+
zcopy_used = zcopy && len >= VHOST_GOODCOPY_LEN
-  && (nvq->upend_idx + 1) % UIO_MAXIOV !=
- nvq->done_idx
+  && num_pends <= VHOST_MAX_PEND
   && vhost_net_tx_select_zcopy(net);
 
/* use msg_control to pass vhost zerocopy ubuf info to skb */
-- 
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: [PATCH V2 1/5] idle/cpuidle: Split cpuidle_idle_call main function into smaller functions

2014-02-24 Thread Daniel Lezcano


On 02/25/2014 04:47 AM, Preeti U Murthy wrote:

Hi Daniel,

On 02/24/2014 07:25 PM, Daniel Lezcano wrote:

---
  drivers/cpuidle/cpuidle.c |  114 
++
  include/linux/cpuidle.h   |   19 +++
  2 files changed, 105 insertions(+), 28 deletions(-)

Index: cpuidle-next/drivers/cpuidle/cpuidle.c
===
--- cpuidle-next.orig/drivers/cpuidle/cpuidle.c
+++ cpuidle-next/drivers/cpuidle/cpuidle.c
@@ -65,6 +65,26 @@ int cpuidle_play_dead(void)
  }

  /**
+ * cpuidle_enabled - check if the cpuidle framework is ready
+ * @dev: cpuidle device for this cpu
+ * @drv: cpuidle driver for this cpu
+ *
+ * Return 0 on success, otherwise:
+ * -NODEV : the cpuidle framework is not available
+ * -EBUSY : the cpuidle framework is not initialized
+ */
+int cpuidle_enabled(struct cpuidle_driver *drv, struct cpuidle_device *dev)
+{
+   if (off || !initialized)
+   return -ENODEV;
+
+   if (!drv || !dev || !dev->enabled)
+   return -EBUSY;
+
+   return 0;
+}
+
+/**
   * cpuidle_enter_state - enter the state and update stats
   * @dev: cpuidle device for this cpu
   * @drv: cpuidle driver for this cpu
@@ -108,6 +128,63 @@ int cpuidle_enter_state(struct cpuidle_d
  }

  /**
+ * cpuidle_select - ask the cpuidle framework to choose an idle state
+ *
+ * @drv: the cpuidle driver
+ * @dev: the cpuidle device
+ *
+ * Returns the index of the idle state.
+ */
+int cpuidle_select(struct cpuidle_driver *drv, struct cpuidle_device *dev)
+{
+   return cpuidle_curr_governor->select(drv, dev);
+}
+
+/**
+ * cpuidle_enter - enter into the specified idle state
+ *
+ * @drv:   the cpuidle driver tied with the cpu
+ * @dev:   the cpuidle device
+ * @index: the index in the idle state table
+ *
+ * Returns the index in the idle state, < 0 in case of error.
+ * The error code depends on the backend driver
+ */
+int cpuidle_enter(struct cpuidle_driver *drv, struct cpuidle_device *dev,
+ int index)
+{
+   int entered_state;
+   bool broadcast = !!(drv->states[index].flags & CPUIDLE_FLAG_TIMER_STOP);
+
+   if (broadcast)
+   clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, >cpu);
+
+   if (cpuidle_state_is_coupled(dev, drv, index))
+   entered_state = cpuidle_enter_state_coupled(dev, drv, index);
+   else
+   entered_state = cpuidle_enter_state(dev, drv, index);
+
+   if (broadcast)
+   clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, >cpu);
+
+   return entered_state;
+}
+
+/**
+ * cpuidle_reflect - tell the underlying governor what was the state
+ * we were in
+ *
+ * @dev  : the cpuidle device
+ * @index: the index in the idle state table
+ *
+ */
+void cpuidle_reflect(struct cpuidle_device *dev, int index)
+{
+   if (cpuidle_curr_governor->reflect)
+   cpuidle_curr_governor->reflect(dev, index);
+}
+
+/**
   * cpuidle_idle_call - the main idle loop
   *
   * NOTE: no locks or semaphores should be used here
@@ -116,51 +193,32 @@ int cpuidle_enter_state(struct cpuidle_d
  int cpuidle_idle_call(void)
  {
struct cpuidle_device *dev = __this_cpu_read(cpuidle_devices);
-   struct cpuidle_driver *drv;
+   struct cpuidle_driver *drv = cpuidle_get_cpu_driver(dev);
int next_state, entered_state;
-   bool broadcast;

-   if (off || !initialized)
-   return -ENODEV;
-
-   /* check if the device is ready */
-   if (!dev || !dev->enabled)
-   return -EBUSY;
-
-   drv = cpuidle_get_cpu_driver(dev);
+   next_state = cpuidle_enabled(drv, dev);


Accepting the return of cpuidle_enabled() into a parameter named
"next_state" looks misleading. You are not returning any idle state. You
could use ret/enabled to accept the return value here perhaps?


Yes, it was to save an extra variable. I can replace it by a 'ret'.


+   if (next_state < 0)
+   return next_state;

/* ask the governor for the next state */
-   next_state = cpuidle_curr_governor->select(drv, dev);
+   next_state = cpuidle_select(drv, dev);
+
if (need_resched()) {
dev->last_residency = 0;
/* give the governor an opportunity to reflect on the outcome */
-   if (cpuidle_curr_governor->reflect)
-   cpuidle_curr_governor->reflect(dev, next_state);
+   cpuidle_reflect(dev, next_state);
local_irq_enable();
return 0;
}

trace_cpu_idle_rcuidle(next_state, dev->cpu);

-   broadcast = !!(drv->states[next_state].flags & CPUIDLE_FLAG_TIMER_STOP);
-
-   if (broadcast)
-   clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, >cpu);
-
-   if (cpuidle_state_is_coupled(dev, drv, next_state))
-   entered_state = cpuidle_enter_state_coupled(dev, drv,
-

Your Credible ACP Partner

2014-02-24 Thread Grace

Dear Purchasing Manager,

Hello,this is Grace from Shanghai Jixiang Industry Co.,Ltd. Our company is a 
large powerful professional aluminum composite panel manufacturer with 18 
years’s experience. We want to avail ourselves of opportunity establishing 
business relation with you.

For more information, kindly please visit our company website 
http://www.alusunbond.com.  

If you're interested in any products, kindly please send me by email. I'll give 
you the best price and service upon receipt of your inquiry.

Looking forward to being your acp partner!

Thank you in advance!
Best regards

Grace 

---

Shanghai Jixiang Industry Co.,Ltd

Add: No. 2180 Songzheng Rd, Songjiang District, 

Shanghai,201604, China

Mob:0086-136-71607863

Fax:0086-21-58418832

Email:alusunb...@live.cn

Website: www.alusunbond.com

Re: [PATCH 1/2] hwmon: (lm90) split set temp as common codes

2014-02-24 Thread Guenter Roeck


On 02/24/2014 10:21 PM, Wei Ni wrote:

Split set temp codes as common functions, so we can use it
directly when implement linux thermal framework.
And handle error return value for the lm90_select_remote_channel
and write_tempx, then set_temp8 and set_temp11 could return it
to user-space.

Signed-off-by: Wei Ni 
Signed-off-by: Jean Delvare 
---
  drivers/hwmon/lm90.c |  170 ++
  1 file changed, 115 insertions(+), 55 deletions(-)

diff --git a/drivers/hwmon/lm90.c b/drivers/hwmon/lm90.c
index c9ff08d..fb9e224 100644
--- a/drivers/hwmon/lm90.c
+++ b/drivers/hwmon/lm90.c
@@ -473,20 +473,29 @@ static int lm90_read16(struct i2c_client *client, u8 
regh, u8 regl, u16 *value)
   * various registers have different meanings as a result of selecting a
   * non-default remote channel.
   */
-static inline void lm90_select_remote_channel(struct i2c_client *client,
- struct lm90_data *data,
- int channel)
+static inline int lm90_select_remote_channel(struct i2c_client *client,
+struct lm90_data *data,
+int channel)
  {
u8 config;
+   int err;

if (data->kind == max6696) {
lm90_read_reg(client, LM90_REG_R_CONFIG1, );
config &= ~0x08;
if (channel)
config |= 0x08;
-   i2c_smbus_write_byte_data(client, LM90_REG_W_CONFIG1,
- config);
+   err = i2c_smbus_write_byte_data(client, LM90_REG_W_CONFIG1,
+   config);
+   if (err < 0) {
+   dev_err(>dev,
+   "Failed to select remote channel %d, err %d\n",
+   channel, err);
+   return err;


Not my call to make, but I really dislike all that new noisiness.
Sure, it is ok to pass the error back, but in my opinion that is
good enough. If every driver in the kernel would be that noisy,
the log would be all but useless.

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/

[PATCH RESEND v10 4/4] arm64: Add APM X-Gene SoC 15Gbps Multi-purpose PHY DTS entries

This patch adds the DTS entries for the APM X-Gene SoC 15Gbps Multi-purpose
PHY driver. The PHY for SATA controller 2 and 3 are enabled by default.

Signed-off-by: Loc Ho 
Signed-off-by: Tuan Phan 
Signed-off-by: Suman Tripathi 
---
 arch/arm64/boot/dts/apm-storm.dtsi |   75 
 1 files changed, 75 insertions(+), 0 deletions(-)

diff --git a/arch/arm64/boot/dts/apm-storm.dtsi 
b/arch/arm64/boot/dts/apm-storm.dtsi
index d37d736..c78ddcf 100644
--- a/arch/arm64/boot/dts/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm-storm.dtsi
@@ -176,6 +176,51 @@
reg-names = "csr-reg";
clock-output-names = "eth8clk";
};
+
+   sataphy1clk: sataphy1clk@1f21c000 {
+   compatible = "apm,xgene-device-clock";
+   #clock-cells = <1>;
+   clocks = < 0>;
+   clock-names = "socplldiv2";
+   reg = <0x0 0x1f21c000 0x0 0x1000>;
+   reg-names = "csr-reg";
+   clock-output-names = "sataphy1clk";
+   status = "disabled";
+   csr-offset = <0x4>;
+   csr-mask = <0x00>;
+   enable-offset = <0x0>;
+   enable-mask = <0x06>;
+   };
+
+   sataphy2clk: sataphy1clk@1f22c000 {
+   compatible = "apm,xgene-device-clock";
+   #clock-cells = <1>;
+   clocks = < 0>;
+   clock-names = "socplldiv2";
+   reg = <0x0 0x1f22c000 0x0 0x1000>;
+   reg-names = "csr-reg";
+   clock-output-names = "sataphy2clk";
+   status = "ok";
+   csr-offset = <0x4>;
+   csr-mask = <0x3a>;
+   enable-offset = <0x0>;
+   enable-mask = <0x06>;
+   };
+
+   sataphy3clk: sataphy1clk@1f23c000 {
+   compatible = "apm,xgene-device-clock";
+   #clock-cells = <1>;
+   clocks = < 0>;
+   clock-names = "socplldiv2";
+   reg = <0x0 0x1f23c000 0x0 0x1000>;
+   reg-names = "csr-reg";
+   clock-output-names = "sataphy3clk";
+   status = "ok";
+   csr-offset = <0x4>;
+   csr-mask = <0x3a>;
+   enable-offset = <0x0>;
+   enable-mask = <0x06>;
+   };
};
 
serial0: serial@1c02 {
@@ -187,5 +232,35 @@
interrupt-parent = <>;
interrupts = <0x0 0x4c 0x4>;
};
+
+   phy1: phy@1f21a000 {
+   compatible = "apm,xgene-phy";
+   reg = <0x0 0x1f21a000 0x0 0x100>;
+   #phy-cells = <1>;
+   clocks = < 0>;
+   status = "disabled";
+   apm,tx-boost-gain = <30 30 30 30 30 30>;
+   apm,tx-eye-tuning = <2 10 10 2 10 10>;
+   };
+
+   phy2: phy@1f22a000 {
+   compatible = "apm,xgene-phy";
+   reg = <0x0 0x1f22a000 0x0 0x100>;
+   #phy-cells = <1>;
+   clocks = < 0>;
+   status = "ok";
+   apm,tx-boost-gain = <30 30 30 30 30 30>;
+   apm,tx-eye-tuning = <1 10 10 2 10 10>;
+   };
+
+   phy3: phy@1f23a000 {
+   compatible = "apm,xgene-phy";
+   reg = <0x0 0x1f23a000 0x0 0x100>;
+   #phy-cells = <1>;
+   clocks = < 0>;
+   status = "ok";
+   apm,tx-boost-gain = <31 31 31 31 31 31>;
+   apm,tx-eye-tuning = <2 10 10 2 10 10>;
+   };
};
 };
-- 
1.5.5

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

[PATCH 2/2] hwmon: lm90: expose to thermal fw via DT nodes

2014-02-24 Thread Wei Ni

This patch adds to lm90 temperature sensor the possibility
to expose itself as thermal zone device, registered on the
thermal framework.

The thermal zone is built only if a device tree node
describing a thermal zone for this sensor is present
inside the lm90 DT node. Otherwise, the driver behavior
will be the same.

Signed-off-by: Wei Ni 
---
 drivers/hwmon/lm90.c |   58 ++
 1 file changed, 58 insertions(+)

diff --git a/drivers/hwmon/lm90.c b/drivers/hwmon/lm90.c
index fb9e224..8f52269 100644
--- a/drivers/hwmon/lm90.c
+++ b/drivers/hwmon/lm90.c
@@ -96,6 +96,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 /*
  * Addresses to scan
@@ -119,6 +121,13 @@ static const unsigned short normal_i2c[] = {
 enum chips { lm90, adm1032, lm99, lm86, max6657, max6659, adt7461, max6680,
max6646, w83l771, max6696, sa56004, g781, tmp451 };
 
+enum sensor_id {
+   LOCAL = 0,
+   REMOTE,
+   REMOTE2,
+   SENSOR_ID_END,
+};
+
 /*
  * The LM90 registers
  */
@@ -368,6 +377,7 @@ struct lm90_data {
struct i2c_client *client;
struct device *hwmon_dev;
const struct attribute_group *groups[6];
+   struct thermal_zone_device *tz[SENSOR_ID_END];
struct mutex update_lock;
struct regulator *regulator;
char valid; /* zero until following fields are valid */
@@ -880,6 +890,24 @@ static ssize_t show_temp11(struct device *dev, struct 
device_attribute *devattr,
return sprintf(buf, "%d\n", read_temp11(dev, attr->index));
 }
 
+static int lm90_read_local_temp(void *dev, long *temp)
+{
+   *temp = read_temp11(dev, LOCAL_TEMP);
+   return 0;
+}
+
+static int lm90_read_remote_temp(void *dev, long *temp)
+{
+   *temp = read_temp11(dev, REMOTE_TEMP);
+   return 0;
+}
+
+static int lm90_read_remote2_temp(void *dev, long *temp)
+{
+   *temp = read_temp11(dev, REMOTE2_TEMP);
+   return 0;
+}
+
 static int write_temp11(struct device *dev, int nr, int index, long val)
 {
struct {
@@ -1659,6 +1687,33 @@ static int lm90_probe(struct i2c_client *client,
}
}
 
+   data->tz[LOCAL] = thermal_zone_of_sensor_register(>dev,
+   LOCAL,
+   >dev,
+   lm90_read_local_temp,
+   NULL);
+   if (IS_ERR(data->tz[LOCAL]))
+   data->tz[LOCAL] = NULL;
+
+   data->tz[REMOTE] = thermal_zone_of_sensor_register(>dev,
+   REMOTE,
+   >dev,
+   lm90_read_remote_temp,
+   NULL);
+   if (IS_ERR(data->tz[REMOTE]))
+   data->tz[REMOTE] = NULL;
+
+   if (data->flags & LM90_HAVE_TEMP3) {
+   data->tz[REMOTE2] = thermal_zone_of_sensor_register(
+   >dev,
+   REMOTE2,
+   >dev,
+   lm90_read_remote2_temp,
+   NULL);
+   if (IS_ERR(data->tz[REMOTE2]))
+   data->tz[REMOTE2] = NULL;
+   }
+
return 0;
 
 exit_unregister:
@@ -1674,8 +1729,11 @@ exit_restore:
 
 static int lm90_remove(struct i2c_client *client)
 {
+   int i;
struct lm90_data *data = i2c_get_clientdata(client);
 
+   for (i = 0; i < SENSOR_ID_END; i++)
+   thermal_zone_of_sensor_unregister(>dev, data->tz[i]);
hwmon_device_unregister(data->hwmon_dev);
device_remove_file(>dev, _attr_pec);
lm90_restore_conf(client, data);
-- 
1.7.9.5

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

[PATCH RESEND v10 1/4] PHY: Add function set_speed to generic PHY framework

This patch adds function set_speed to the generic PHY framework operation
structure. This function can be called to instruct the PHY underlying layer
at specified lane to configure for specified speed in hertz.

Signed-off-by: Loc Ho 
---
 drivers/phy/phy-core.c  |   21 +
 include/linux/phy/phy.h |8 
 2 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 645c867..44f2f63 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -257,6 +257,27 @@ int phy_power_off(struct phy *phy)
 }
 EXPORT_SYMBOL_GPL(phy_power_off);
 
+int phy_set_speed(struct phy *phy, int lane, u64 speed)
+{
+int ret = -ENOTSUPP;
+
+mutex_lock(>mutex);
+if (phy->ops->set_speed) {
+ret =  phy->ops->set_speed(phy, lane, speed);
+if (ret < 0) {
+dev_err(>dev, "phy set speed failed --> %d\n",
+ret);
+goto out;
+}
+}
+
+out:
+mutex_unlock(>mutex);
+
+return ret;
+}
+EXPORT_SYMBOL_GPL(phy_set_speed);
+
 /**
  * of_phy_get() - lookup and obtain a reference to a phy by phandle
  * @dev: device that requests this phy
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index e273e5a..4eb589c 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -27,6 +27,7 @@ struct phy;
  * @exit: operation to be performed while exiting
  * @power_on: powering on the phy
  * @power_off: powering off the phy
+ * @set_speed: set operation speed in hz
  * @owner: the module owner containing the ops
  */
 struct phy_ops {
@@ -34,6 +35,7 @@ struct phy_ops {
int (*exit)(struct phy *phy);
int (*power_on)(struct phy *phy);
int (*power_off)(struct phy *phy);
+   int (*set_speed)(struct phy *phy, int lane, u64 speed);
struct module *owner;
 };
 
@@ -145,6 +147,7 @@ static inline void phy_set_bus_width(struct phy *phy, int 
bus_width)
 {
phy->attrs.bus_width = bus_width;
 }
+int phy_set_speed(struct phy *phy, int lane, u64 speed);
 struct phy *phy_get(struct device *dev, const char *string);
 struct phy *devm_phy_get(struct device *dev, const char *string);
 void phy_put(struct phy *phy);
@@ -227,6 +230,11 @@ static inline void phy_set_bus_width(struct phy *phy, int 
bus_width)
return;
 }
 
+static inline int phy_set_speed(struct phy *phy, int lane, u64 speed)
+{
+   return -ENOSYS;
+}
+
 static inline struct phy *phy_get(struct device *dev, const char *string)
 {
return ERR_PTR(-ENOSYS);
-- 
1.5.5

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

[PATCH 0/2] expose lm90 to thermal fw

2014-02-24 Thread Wei Ni

Expose lm90 to thermal framework via DT nodes.

The [PATCH 1/2] had reviewed in:
http://www.spinics.net/lists/linux-tegra/msg14108.html

Wei Ni (2):
  hwmon: (lm90) split set temp as common codes
  hwmon: lm90: expose to thermal fw via DT nodes

 drivers/hwmon/lm90.c |  228 ++
 1 file changed, 173 insertions(+), 55 deletions(-)

-- 
1.7.9.5

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

[PATCH RESEND v10 0/4] PHY: Add APM X-Gene SoC 15Gbps Multi-purpose PHY support

This patch adds support for APM X-Gene SoC 15Gbps Multi-purpose PHY. This
is the physical layer interface for the corresponding host controller. This
driver uses the PHY generic framework. In addition, the PHY generic
framework is patched to provide an function to set the speed of the PHY.

v10
* Update comment for function xgene_phy_force_lat_summer_cal and
  xgene_phy_sata_force_gen with function style fully-winged style

v9
* Update CMU parameter setting for register 13
* Add required delay when configure CMU PLL, Manual Calibration PLL, and VCO
  PLL
* Add comment for CMU PLL calibration loop delay of 10us
* Add required delay for stopping and starting summer calibrations
* Update comment for summer and latch calibration delays
* Update comment for PHY reset Rx delay and decrease max sleep time from 500
  to 150us
* Always program the DFE (equalizer) setting to 0x7e00 as with original version
* Fix Tx speed selection to always using Gen3 setting when force to an
  specified generation speed

v8
* Update binding documentation
* Remove XGENE_PHY_DTS and XGENE_PHY_EXT_DTS defines
* Remove support for internal clock
* Remove support for external reference CMU
* Remove the need for external reference resource DTS entry and its related
  code

v7
* Add/Update PHY CMU/lane parameters and its default values
* Rename variable enable_manual_cal to preA3Chip
* Remove function phy_rd, phy_wr, and phy_wr_flush
* Change function cmu_wr, cmu_rd, cmu_toggle1to0, cmu_clrbits, cmu_setbits,
  serdes_wr, serdes_rd, serdes_clrbits, and serdes_setbits to take context
  instead void *
* Remove function serdes_toggle1to0
* Decrease the polling time from 10ms to 1ms on CMU calibration complete
  detection
* Move all SATA specify code in function xgene_phy_hw_initialize into
  function xgene_phy_hw_init_sata
* Add usleep_range after starting summer/latch calibrations
* Add usleep_range between receiver reset (function xgene_phy_reset_rxd)
* Save and restore PHY register 31 instead writing 0 in function
  xgene_phy_gen_avg_val
* Update function xgene_phy_sata_force_gen programming sequences
* Add support to reset the receiver lane in function xgene_phy_set_speed
  if speed is 0
* Update PHY parameters in DTS per controller
* Some minor code clean up

v6
* Move PHY document to Documentation/devicetree/binding/phy
* Remove _ADDR from all register defines
* Update clock-names property for sataphy1clk, sataphy2clk, and sataphy3clk

v5
* Update DTS binding documentation
* Remove direct clock access and use clock interface instead
* Change override parameters to decimal instead hex values
* Change apm,tx-amplitude, apm,tx-pre-cursor1, apm,tx-pre-cursor2,
  apm,tx-post-cursor to be unit of uV

v4
* Update documentation with 'apm,' instead 'apm-'
* Change DTS override parameter to have 'apm,'
* Add select GENERIC_PHY to Kconfig PHY_XGENE
* Make override parameters to be pair of three values instead one
* Some minor comment and indentation changes
* Remove error register addition offset
* Add ULL to constants
* Use module_init instead subsys_initcall
* Make DTS node based on first register address
* Update override setting values

v3
* Major re-write of the code based on various review comments
* Support external clock only at the moment
* Support SATA mode only at the moment
* No UEFI support at the moment

v2
* Remove port knowledge from functions
* Make all functions static
* Remove ID completely
* Make resource requirement based on compatible type
* Rename override PHY parameters with more descriptive name
* Add override PHY parameter for per controller, per port, and per speed
* Patch the generic PHY frame to expose set_speed operation

v1
* Initial version

Signed-off-by: Loc Ho 
Signed-off-by: Tuan Phan 
Signed-off-by: Suman Tripathi 
---
Loc Ho (4):
  PHY: Add function set_speed to generic PHY framework
  Documentation: Add APM X-Gene SoC 15Gbps Multi-purpose PHY driver
binding documentation
  PHY: add APM X-Gene SoC 15Gbps Multi-purpose PHY driver
  arm64: Add APM X-Gene SoC 15Gbps Multi-purpose PHY DTS entries

 .../devicetree/bindings/phy/apm-xgene-phy.txt  |   79 +
 arch/arm64/boot/dts/apm-storm.dtsi |   75 +
 drivers/phy/Kconfig|7 +
 drivers/phy/Makefile   |2 +
 drivers/phy/phy-core.c |   21 +
 drivers/phy/phy-xgene.c| 1826 
 include/linux/phy/phy.h|8 +
 7 files changed, 2018 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/phy/apm-xgene-phy.txt
 create mode 100644 drivers/phy/phy-xgene.c

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

[PATCH 1/2] hwmon: (lm90) split set temp as common codes

2014-02-24 Thread Wei Ni

Split set temp codes as common functions, so we can use it
directly when implement linux thermal framework.
And handle error return value for the lm90_select_remote_channel
and write_tempx, then set_temp8 and set_temp11 could return it
to user-space.

Signed-off-by: Wei Ni 
Signed-off-by: Jean Delvare 
---
 drivers/hwmon/lm90.c |  170 ++
 1 file changed, 115 insertions(+), 55 deletions(-)

diff --git a/drivers/hwmon/lm90.c b/drivers/hwmon/lm90.c
index c9ff08d..fb9e224 100644
--- a/drivers/hwmon/lm90.c
+++ b/drivers/hwmon/lm90.c
@@ -473,20 +473,29 @@ static int lm90_read16(struct i2c_client *client, u8 
regh, u8 regl, u16 *value)
  * various registers have different meanings as a result of selecting a
  * non-default remote channel.
  */
-static inline void lm90_select_remote_channel(struct i2c_client *client,
- struct lm90_data *data,
- int channel)
+static inline int lm90_select_remote_channel(struct i2c_client *client,
+struct lm90_data *data,
+int channel)
 {
u8 config;
+   int err;
 
if (data->kind == max6696) {
lm90_read_reg(client, LM90_REG_R_CONFIG1, );
config &= ~0x08;
if (channel)
config |= 0x08;
-   i2c_smbus_write_byte_data(client, LM90_REG_W_CONFIG1,
- config);
+   err = i2c_smbus_write_byte_data(client, LM90_REG_W_CONFIG1,
+   config);
+   if (err < 0) {
+   dev_err(>dev,
+   "Failed to select remote channel %d, err %d\n",
+   channel, err);
+   return err;
+   }
}
+
+   return 0;
 }
 
 /*
@@ -759,29 +768,34 @@ static u16 temp_to_u16_adt7461(struct lm90_data *data, 
long val)
  * Sysfs stuff
  */
 
-static ssize_t show_temp8(struct device *dev, struct device_attribute *devattr,
- char *buf)
+static int read_temp8(struct device *dev, int index)
 {
-   struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
struct lm90_data *data = lm90_update_device(dev);
int temp;
 
if (data->kind == adt7461 || data->kind == tmp451)
-   temp = temp_from_u8_adt7461(data, data->temp8[attr->index]);
+   temp = temp_from_u8_adt7461(data, data->temp8[index]);
else if (data->kind == max6646)
-   temp = temp_from_u8(data->temp8[attr->index]);
+   temp = temp_from_u8(data->temp8[index]);
else
-   temp = temp_from_s8(data->temp8[attr->index]);
+   temp = temp_from_s8(data->temp8[index]);
 
/* +16 degrees offset for temp2 for the LM99 */
-   if (data->kind == lm99 && attr->index == 3)
+   if (data->kind == lm99 && index == 3)
temp += 16000;
 
-   return sprintf(buf, "%d\n", temp);
+   return temp;
 }
 
-static ssize_t set_temp8(struct device *dev, struct device_attribute *devattr,
-const char *buf, size_t count)
+static ssize_t show_temp8(struct device *dev, struct device_attribute *devattr,
+ char *buf)
+{
+   struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
+
+   return sprintf(buf, "%d\n", read_temp8(dev, attr->index));
+}
+
+static int write_temp8(struct device *dev, int index, long val)
 {
static const u8 reg[TEMP8_REG_NUM] = {
LM90_REG_W_LOCAL_LOW,
@@ -794,60 +808,79 @@ static ssize_t set_temp8(struct device *dev, struct 
device_attribute *devattr,
MAX6659_REG_W_REMOTE_EMERG,
};
 
-   struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
struct lm90_data *data = dev_get_drvdata(dev);
struct i2c_client *client = data->client;
-   int nr = attr->index;
-   long val;
int err;
 
-   err = kstrtol(buf, 10, );
-   if (err < 0)
-   return err;
-
/* +16 degrees offset for temp2 for the LM99 */
-   if (data->kind == lm99 && attr->index == 3)
+   if (data->kind == lm99 && index == 3)
val -= 16000;
 
mutex_lock(>update_lock);
if (data->kind == adt7461 || data->kind == tmp451)
-   data->temp8[nr] = temp_to_u8_adt7461(data, val);
+   data->temp8[index] = temp_to_u8_adt7461(data, val);
else if (data->kind == max6646)
-   data->temp8[nr] = temp_to_u8(val);
+   data->temp8[index] = temp_to_u8(val);
else
-   data->temp8[nr] = temp_to_s8(val);
-
-   lm90_select_remote_channel(client, data, nr >= 6);
-   i2c_smbus_write_byte_data(client, reg[nr], data->temp8[nr]);
-

Re: [PATCH 0/9 v7] crypto:s5p-sss: Add DT and Exynos support

2014-02-24 Thread Herbert Xu

On Mon, Feb 17, 2014 at 03:14:26PM +0530, Naveen Krishna Chatradhi wrote:
> SSS module on Exynos4210, Exynos5250 and Exynos5420 SoCs has added
> features to the one on S5PV210. However with minor changes the s5p-sss.c
> driver can be reused to support SSS modules on Exynos4 and 5 SoCs.
> 
> This patch set
> 1. Adds device tree support to the s5p-sss.c driver and Documentation
> 2. Adds code to support SSS module on Exynos4 and 5 SoCs
> 3. Adds device tree node to Exynos5250 and Exynos5420
> 4. Adds variant struct to handle the differences in SSS modules
> 5. Adds clk_prepare/clk_unprepare clocks to the s5p-sss.c driver
> 
> Note: Compatible "exynos4210-secss" should work for Exynos4412 and
>   Exynos5260 (Exynos5260, for which ARCH code is under review)
> I couldn't test on Exynos4412 and Exynos4210 boards, Should be able to
> test with addition of DT node and clocks support.
> 
> Naveen Krishna Ch (7): [crypto-2.6.git]
>   crypto:s5p-sss: Use platform_get_irq() instead of _byname()
>   crypto:s5p-sss: Kconfig: Let Exynos SoCs select SSS driver
>   crypto:s5p-sss: Look for the next request in the queue
>   crypto:s5p-sss: Add device tree support
>   crypto:s5p-sss: Add support for SSS module on Exynos
>   crypto:s5p-sss: validate iv before memcpy
>   crypto:s5p-sss: Use clk_prepare/clk_unprepare

FWIW these patches are fine by me.

Acked-by: Herbert Xu 

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH RESEND v10 2/4] Documentation: Add APM X-Gene SoC 15Gbps Multi-purpose PHY driver binding documentation

Signed-off-by: Loc Ho 
Signed-off-by: Tuan Phan 
Signed-off-by: Suman Tripathi 
---
 .../devicetree/bindings/phy/apm-xgene-phy.txt  |   79 
 1 files changed, 79 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/phy/apm-xgene-phy.txt

diff --git a/Documentation/devicetree/bindings/phy/apm-xgene-phy.txt 
b/Documentation/devicetree/bindings/phy/apm-xgene-phy.txt
new file mode 100644
index 000..5f3a65a
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/apm-xgene-phy.txt
@@ -0,0 +1,79 @@
+* APM X-Gene 15Gbps Multi-purpose PHY nodes
+
+PHY nodes are defined to describe on-chip 15Gbps Multi-purpose PHY. Each
+PHY (pair of lanes) has its own node.
+
+Required properties:
+- compatible   : Shall be "apm,xgene-phy".
+- reg  : PHY memory resource is the SDS PHY access resource.
+- #phy-cells   : Shall be 1 as it expects one argument for setting
+ the mode of the PHY. Possible values are 0 (SATA),
+ 1 (SGMII), 2 (PCIe), 3 (USB), and 4 (XFI).
+
+Optional properties:
+- status   : Shall be "ok" if enabled or "disabled" if disabled.
+ Default is "ok".
+- clocks   : Reference to the clock entry.
+- apm,tx-eye-tuning: Manual control to fine tune the capture of the serial
+ bit lines from the automatic calibrated position.
+ Two set of 3-tuple setting for each (up to 3)
+ supported link speed on the host. Range from 0 to
+ 127 in unit of one bit period. Default is 10.
+- apm,tx-eye-direction : Eye tuning manual control direction. 0 means sample
+ data earlier than the nominal sampling point. 1 means
+ sample data later than the nominal sampling point.
+ Two set of 3-tuple setting for each (up to 3)
+ supported link speed on the host. Default is 0.
+- apm,tx-boost-gain: Frequency boost AC (LSB 3-bit) and DC (2-bit)
+ gain control. Two set of 3-tuple setting for each
+ (up to 3) supported link speed on the host. Range is
+ between 0 to 31 in unit of dB. Default is 3.
+- apm,tx-amplitude : Amplitude control. Two set of 3-tuple setting for
+ each (up to 3) supported link speed on the host.
+ Range is between 0 to 199500 in unit of uV.
+ Default is 199500 uV.
+- apm,tx-pre-cursor1   : 1st pre-cursor emphasis taps control. Two set of
+ 3-tuple setting for each (up to 3) supported link
+ speed on the host. Range is 0 to 273000 in unit of
+ uV. Default is 0.
+- apm,tx-pre-cursor2   : 2st pre-cursor emphasis taps control. Two set of
+ 3-tuple setting for each (up to 3) supported link
+ speed on the host. Range is 0 to 127400 in unit uV.
+ Default is 0x0.
+- apm,tx-post-cursor   : Post-cursor emphasis taps control. Two set of
+ 3-tuple setting for Gen1, Gen2, and Gen3. Range is
+ between 0 to 0x1f in unit of 18.2mV. Default is 0xf.
+- apm,tx-speed : Tx operating speed. One set of 3-tuple for each
+ supported link speed on the host.
+  0 = 1-2Gbps
+  1 = 2-4Gbps (1st tuple default)
+  2 = 4-8Gbps
+  3 = 8-15Gbps (2nd tuple default)
+  4 = 2.5-4Gbps
+  5 = 4-5Gbps
+  6 = 5-6Gbps
+  7 = 6-16Gbps (3rd tuple default)
+
+NOTE: PHY override parameters are board specific setting.
+
+Example:
+   phy1: phy@1f21a000 {
+   compatible = "apm,xgene-phy";
+   reg = <0x0 0x1f21a000 0x0 0x100>;
+   #phy-cells = <1>;
+   status = "disabled";
+   };
+
+   phy2: phy@1f22a000 {
+   compatible = "apm,xgene-phy";
+   reg = <0x0 0x1f22a000 0x0 0x100>;
+   #phy-cells = <1>;
+   status = "ok";
+   };
+
+   phy3: phy@1f23a000 {
+   compatible = "apm,xgene-phy";
+   reg = <0x0 0x1f23a000 0x0 0x100>;
+   #phy-cells = <1>;
+   status = "ok";
+   };
-- 
1.5.5

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

linux-next: manual merge of the staging tree with the arm-soc tree

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
arch/arm/boot/dts/imx53-qsb.dts between commit d5eb195f26fa ("ARM: dts:
i.MX53: move common QSB nodes to new file") from the arm-soc tree and
commit 17b5001b5143 ("imx-drm: convert to componentised device support")
from the staging tree.

I fixed it up (see at bottom) and can carry the fix as necessary (no
action is required).  I also added the following fix up patch:

From: Stephen Rothwell 
Date: Tue, 25 Feb 2014 17:07:01 +1100
Subject: [PATCH] ARM: dts: i.MX53: merge fix patch

Signed-off-by: Stephen Rothwell 
---
 arch/arm/boot/dts/imx53-qsb-common.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx53-qsb-common.dtsi 
b/arch/arm/boot/dts/imx53-qsb-common.dtsi
index 2dca98b79f48..5dd37c7c38b8 100644
--- a/arch/arm/boot/dts/imx53-qsb-common.dtsi
+++ b/arch/arm/boot/dts/imx53-qsb-common.dtsi
@@ -17,7 +17,7 @@
reg = <0x7000 0x4000>;
};
 
-   display@di0 {
+   display0: display@di0 {
compatible = "fsl,imx-parallel-display";
crtcs = < 0>;
interface-pix-fmt = "rgb565";
-- 
1.9.0

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

diff --cc arch/arm/boot/dts/imx53-qsb.dts
index dec4b073ceb1,3cb4f7791a91..
--- a/arch/arm/boot/dts/imx53-qsb.dts
+++ b/arch/arm/boot/dts/imx53-qsb.dts
@@@ -16,6 -16,182 +16,11 @@@
  / {
model = "Freescale i.MX53 Quick Start Board";
compatible = "fsl,imx53-qsb", "fsl,imx53";
 -
 -  memory {
 -  reg = <0x7000 0x4000>;
 -  };
 -
 -  display0: display@di0 {
 -  compatible = "fsl,imx-parallel-display";
 -  crtcs = < 0>;
 -  interface-pix-fmt = "rgb565";
 -  pinctrl-names = "default";
 -  pinctrl-0 = <_ipu_disp0_1>;
 -  status = "disabled";
 -  display-timings {
 -  claawvga {
 -  native-mode;
 -  clock-frequency = <2700>;
 -  hactive = <800>;
 -  vactive = <480>;
 -  hback-porch = <40>;
 -  hfront-porch = <60>;
 -  vback-porch = <10>;
 -  vfront-porch = <10>;
 -  hsync-len = <20>;
 -  vsync-len = <10>;
 -  hsync-active = <0>;
 -  vsync-active = <0>;
 -  de-active = <1>;
 -  pixelclk-active = <0>;
 -  };
 -  };
 -  };
 -
 -  gpio-keys {
 -  compatible = "gpio-keys";
 -
 -  power {
 -  label = "Power Button";
 -  gpios = < 8 0>;
 -  linux,code = <116>; /* KEY_POWER */
 -  };
 -
 -  volume-up {
 -  label = "Volume Up";
 -  gpios = < 14 0>;
 -  linux,code = <115>; /* KEY_VOLUMEUP */
 -  gpio-key,wakeup;
 -  };
 -
 -  volume-down {
 -  label = "Volume Down";
 -  gpios = < 15 0>;
 -  linux,code = <114>; /* KEY_VOLUMEDOWN */
 -  gpio-key,wakeup;
 -  };
 -  };
 -
+   imx-drm {
+   compatible = "fsl,imx-drm";
+   crtcs = < 0>;
+   connectors = <>;
+   };
 -
 -  leds {
 -  compatible = "gpio-leds";
 -  pinctrl-names = "default";
 -  pinctrl-0 = <_pin_gpio7_7>;
 -
 -  user {
 -  label = "Heartbeat";
 -  gpios = < 7 0>;
 -  linux,default-trigger = "heartbeat";
 -  };
 -  };
 -
 -  regulators {
 -  compatible = "simple-bus";
 -
 -  reg_3p2v: 3p2v {
 -  compatible = "regulator-fixed";
 -  regulator-name = "3P2V";
 -  regulator-min-microvolt = <320>;
 -  regulator-max-microvolt = <320>;
 -  regulator-always-on;
 -  };
 -
 -  reg_usb_vbus: usb_vbus {
 -  compatible = "regulator-fixed";
 -  regulator-name = "usb_vbus";
 -  regulator-min-microvolt = <500>;
 -  regulator-max-microvolt = <500>;
 -  gpio = < 8 0>;
 -  enable-active-high;
 -  };
 -  };
 -
 -  sound {
 -  compatible = "fsl,imx53-qsb-sgtl5000",
 -   "fsl,imx-audio-sgtl5000";
 -  model = "imx53-qsb-sgtl5000";
 -

linux-next: manual merge of the staging tree with the imx-mxs tree

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
arch/arm/boot/dts/imx51-babbage.dts between commit a198af2322a1 ("ARM:
dts: i.MX51 babbage: Support diagnostic LED") from the imx-mxs tree and
commit 17b5001b5143 ("imx-drm: convert to componentised device support")
from the staging tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

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

diff --cc arch/arm/boot/dts/imx51-babbage.dts
index 121dadd125c0,6ff15a0eacb3..
--- a/arch/arm/boot/dts/imx51-babbage.dts
+++ b/arch/arm/boot/dts/imx51-babbage.dts
@@@ -81,17 -81,12 +81,23 @@@
};
};
  
 +  leds {
 +  compatible = "gpio-leds";
 +  pinctrl-names = "default";
 +  pinctrl-0 = <_gpio_leds>;
 +
 +  led-diagnostic {
 +  label = "diagnostic";
 +  gpios = < 6 GPIO_ACTIVE_HIGH>;
 +  };
 +  };
 +
+   imx-drm {
+   compatible = "fsl,imx-drm";
+   crtcs = < 0>, < 1>;
+   connectors = <>, <>;
+   };
+ 
sound {
compatible = "fsl,imx51-babbage-sgtl5000",
 "fsl,imx-audio-sgtl5000";


pgpdht7VPb23T.pgp
Description: PGP signature

linux-next: manual merge of the staging tree with the arm-soc tree

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
arch/arm/boot/dts/imx53-mba53.dts between commit a4a2aa9b038c ("ARM: dts:
imx53-mba53: create a container for fixed regulators") from the arm-soc
tree and commit 17b5001b5143 ("imx-drm: convert to componentised device
support") from the staging tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

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

diff --cc arch/arm/boot/dts/imx53-mba53.dts
index 55af11037a00,9b6e76980a74..
--- a/arch/arm/boot/dts/imx53-mba53.dts
+++ b/arch/arm/boot/dts/imx53-mba53.dts
@@@ -35,27 -43,18 +35,33 @@@
status = "disabled";
};
  
+   imx-drm {
+   compatible = "fsl,imx-drm";
+   crtcs = < 1>;
+   connectors = <>, <>;
+   };
+ 
 -  reg_3p2v: 3p2v {
 -  compatible = "regulator-fixed";
 -  regulator-name = "3P2V";
 -  regulator-min-microvolt = <320>;
 -  regulator-max-microvolt = <320>;
 -  regulator-always-on;
 +  regulators {
 +  compatible = "simple-bus";
 +  #address-cells = <1>;
 +  #size-cells = <0>;
 +
 +  reg_backlight: regulator@0 {
 +  compatible = "regulator-fixed";
 +  reg = <0>;
 +  regulator-name = "lcd-supply";
 +  gpio = < 5 0>;
 +  startup-delay-us = <5000>;
 +  };
 +
 +  reg_3p2v: regulator@1 {
 +  compatible = "regulator-fixed";
 +  reg = <1>;
 +  regulator-name = "3P2V";
 +  regulator-min-microvolt = <320>;
 +  regulator-max-microvolt = <320>;
 +  regulator-always-on;
 +  };
};
  
sound {


pgpJO6axWg3Pe.pgp
Description: PGP signature

Re: [PATCH] net: kdoc struct net_device flags and priv_flags

2014-02-24 Thread Luis R. Rodriguez

On Mon, Feb 24, 2014 at 09:37:34PM -0800, Florian Fainelli wrote:
> Le lundi 24 février 2014, 23:53:43 David Miller a écrit :
> > From: Ben Hutchings 
> > Date: Tue, 25 Feb 2014 02:11:05 +
> > 
> > > On Mon, 2014-02-24 at 16:14 -0800, Luis R. Rodriguez wrote:
> > >> From: "Luis R. Rodriguez" 
> > >> 
> > >> ---
> > >> 
> > >>  include/uapi/linux/if.h | 201
> > >>  +++- 1 file changed, 149
> > >>  insertions(+), 52 deletions(-)
> > >> 
> > >> diff --git a/include/uapi/linux/if.h b/include/uapi/linux/if.h
> > >> index d758163..1555623 100644
> > >> --- a/include/uapi/linux/if.h
> > >> +++ b/include/uapi/linux/if.h
> > > 
> > > [...]
> > > 
> > >> +/**
> > >> + * enum net_device_priv_flags -  net_device priv_flags
> > >> + *
> > >> + * These are the  net_device, they are only set internally
> > >> + * by drivers and used in the kernel but are invisible to userspace.
> > > 
> > > [...]
> > > 
> > > Indeed, I wonder why they are in the UAPI header.  As userland doesn't
> > > have a legitimate use for them, maybe you could move them back to
> > > include/linux/if.h instead of bothering with adding macros?
> > 
> > They are visible to userspace via sysfs.
> 
> In /sys/class/net/*/flags, although we are lacking quite a lot of 
> documentation 
> for the exported attributes there.
> 
> The only attributes for which there is some sort of documentation are 
> "operstate" and the XPS/RFS/RPS attributes, maybe that could be fixed too as 
> part of this documentation patch?

Sure, but how about we take it one step at a time? I wanted to do this first
so I can extend the documentation of some flags private flags I'm reviewing
right now, so figured we'd start with the basic, non contravertial simple
documentation and then we can start piling up new shiny documentation.

  Luis
--
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] cpufreq: Return error if ->get() failed in cpufreq_update_policy()

2014-02-24 Thread Viresh Kumar

On 25 February 2014 11:23, Srivatsa S. Bhat
 wrote:
> Hmm, that's a good point. However, lets first think about the simple scenario
> that the driver _is_ able to detect the current frequency from the hardware
> (a non-zero, sane value) say X KHz, and that frequency is different from what
> the cpufreq subsystem thinks it is (Y KHz).
>
> In the current code, when we observe this, we send out a notification and try
> to adjust to X KHz. Instead, what I'm suggesting is to invoke the driver to
> set the frequency to Y KHz, since that's what the cpufreq subsystems wants the
> frequency to be at.

Actually we don't know at this point what cpufreq wants :)
Governor will decide what frequency to run CPU at and lets leave it to
that point.
As the transition that we might end up doing here would be simply overridden
very soon. And to be honest this decision must be taken by governor and not
core. We just want to make sure core is in sync with hardware.

> As for the case where the driver reports the frequency to be 0 KHz, we can
> print a WARN() and try to force set the frequency to Y KHz. But if that turns
> out to be too tricky to handle, we can just put a WARN() and error out, as you
> proposed earlier.

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/

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-24 Thread Linus Torvalds

On Mon, Feb 24, 2014 at 3:35 PM, Linus Torvalds
 wrote:
>
> Litmus test 1:
>
> p = atomic_read(pp, consume);
> if (p == )
> return p->val;
>
>is *NOT* ordered

Btw, don't get me wrong. I don't _like_ it not being ordered, and I
actually did spend some time thinking about my earlier proposal on
strengthening the 'consume' ordering.

I have for the last several years been 100% convinced that the Intel
memory ordering is the right thing, and that people who like weak
memory ordering are wrong and should try to avoid reproducing if at
all possible. But given that we have memory orderings like power and
ARM, I don't actually see a sane way to get a good strong ordering.
You can teach compilers about cases like the above when they actually
see all the code and they could poison the value chain etc. But it
would be fairly painful, and once you cross object files (or even just
functions in the same compilation unit, for that matter), it goes from
painful to just "ridiculously not worth it".

So I think the C semantics should mirror what the hardware gives us -
and do so even in the face of reasonable optimizations - not try to do
something else that requires compilers to treat "consume" very
differently.

If people made me king of the world, I'd outlaw weak memory ordering.
You can re-order as much as you want in hardware with speculation etc,
but you should always *check* your speculation and make it *look* like
you did everything in order. Which is pretty much the intel memory
ordering (ignoring the write buffering).

   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/

[PATCH] x86: set Pentium M as PAE capable

2014-02-24 Thread Chris Bainbridge

Pentium M is PAE capable but does not indicate so in the CPUID response.
This is an issue now that some distributions are no longer shipping
non-PAE kernels (those distributions no longer boot on Pentium M). This
small patch fixes the issue by forcing the PAE capability on Pentium M.

For more discussion see https://bugs.launchpad.net/baltix/+bug/930447

Signed-off-by: Chris Bainbridge 

---

diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index bbe1b8b..97996aa 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -226,6 +226,12 @@ static void intel_workarounds(struct cpuinfo_x86 *c)
clear_cpu_cap(c, X86_FEATURE_SEP);
 
/*
+* PAE CPUID bug: Pentium M reports no PAE but has PAE
+*/
+   if ((c->x86 == 6) && ((c->x86_model == 9) || (c->x86_model == 13)))
+   set_cpu_cap(c, X86_FEATURE_PAE);
+
+   /*
 * P4 Xeon errata 037 workaround.
 * Hardware prefetcher may cause stale data to be loaded into the cache.
 */
--
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] [media] davinci: vpfe: remove deprecated IRQF_DISABLED

2014-02-24 Thread Prabhakar Lad

Hi Michael,

On Mon, Feb 24, 2014 at 11:01 AM, Prabhakar Lad
 wrote:
> Hi Michael,
>
> On Thu, Feb 20, 2014 at 6:47 PM, Michael Opdenacker
>  wrote:
>> Hi Laurent,
>>
>> On 02/20/2014 12:36 PM, Laurent Pinchart wrote:
>>> Hi Michael,
>>>
>>> What's the status of this patch ? Do expect Prabhakar to pick it up, or do 
>>> you
>>> plan to push all your IRQF_DISABLED removal patches in one go ?
>> It's true a good number of my patches haven't been picked up yet, even
>> after multiple resends.
>>
>> I was planning to ask the community tomorrow about what to do to finally
>> get rid of IRQF_DISABLED. Effectively, pushing all the remaining changes
>> in one go (or removing the definition of IRQF_DISABLED) may be the final
>> solution.
>>
>> I hope to be able to answer your question by the end of the week.
>>
> gentle ping. should I pick it up ?
>
I've picked it up.

Thanks,
--Prabhakar Lad
--
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 0/6] vhost/scsi: Add T10 PI SGL passthrough support

2014-02-24 Thread Nicholas A. Bellinger

On Mon, 2014-02-24 at 11:23 +0100, Paolo Bonzini wrote:
> Il 24/02/2014 06:32, Nicholas A. Bellinger ha scritto:
> > AFAICT up until this point the ->prio field has been unused, but
> > I'm certainly open to better ways of signaling (to vhost) that some
> > number of metadata iovs are to be expected..  Any thoughts..?
> 
> Hi nab,
> 
> the virtio-scsi side of the patch is nice and readable.  As requested, 
> here are my thoughts on how to add it to the standard.
> 
> The ->prio field is there to mimic SAM's command priority field (8.7 in 
> my copy of the standard).  I'd rather leave it alone; I understand this 
> is the main reason why this patch is RFC.

Yes.  ;)

> 
> Since we have a new feature bit, we can add a new element before the 
> cdb.  It could be a count of scatter/gather list like you did here, or 
> it could be a byte count.  Even better, we can add _two_ new fields, one 
> for protection data out and one for protection data in.
> 

Having two 16-bit fields for data out / data in protection count in the
command header should be fine.

So that said, adding a new virtio_scsi_cmd_req_pi definition per your
recommendation, and will update the series to use this when the
VIRTIO_SCSI_F_T10_PI feature bit has been negotiated on both ends.

> Also, do we need an equivalent of the residual field, but for metadata?
> 

Mmm, at least for PI I don't think a residual field is necessary.

Any time the metadata is not fully read on outgoing WRITEs, or written
on incoming READs the next hop performing a VERIFY operation will end up
failing with a GUARD or REFERENCE TAG failure.

MKP..?

> Finally, any reason why you put the data sg elements before the metadata 
> sg elements?

Nope, no particular reason for this.

>  I would have thought that processing is a bit simpler if 
> either the metadata comes first, or you store in the command header the 
> data count (either sg or byte).  Because the virtio buffers form a 
> linked list, it's a bit backwards to put metadata last, and store 
> metadata count in the command header; it prevents you from processing 
> the buffers online because you don't know when the metadata starts. 
> Even though the Linux virtio layer always gives you a buffer count, this 
> need not be the case in general.
> 

No objection here.  Updating the patch series to place protection
information ahead of the actual data payload.

--nab

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

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-24 Thread Paul E. McKenney

On Mon, Feb 24, 2014 at 03:35:04PM -0800, Linus Torvalds wrote:
> On Mon, Feb 24, 2014 at 2:37 PM, Paul E. McKenney
>  wrote:
> >>
> >> What if the "nothing modifies 'p'" part looks like this:
> >>
> >> if (p != )
> >> return;
> >>
> >> and now any sane compiler will happily optimize "q = *p" into "q =
> >> myvariable", and we're all done - nothing invalid was ever
> >
> > Yes, the compiler could do that.  But it would still be required to
> > carry a dependency from the memory_order_consume read to the "*p",
> 
> But that's *BS*. You didn't actually listen to the main issue.
> 
> Paul, why do you insist on this carries-a-dependency crap?

Sigh.  Read on...

> It's broken. If you don't believe me, then believe the compiler person
> who already piped up and told you so.
> 
> The "carries a dependency" model is broken. Get over it.
> 
> No sane compiler will ever distinguish two different registers that
> have the same value from each other. No sane compiler will ever say
> "ok, register r1 has the exact same value as register r2, but r2
> carries the dependency, so I need to make sure to pass r2 to that
> function or use it as a base pointer".
> 
> And nobody sane should *expect* a compiler to distinguish two
> registers with the same value that way.
> 
> So the whole model is broken.
> 
> I gave an alternate model (the "restrict"), and you didn't seem to
> understand the really fundamental difference. It's not a language
> difference, it's a conceptual difference.
> 
> In the broken "carries a dependency" model, you have fight all those
> aliases that can have the same value, and it is not a fight you can
> win. We've had the "p-p" examples, we've had the "p&0" examples, but
> the fact is, that "p==" example IS EXACTLY THE SAME THING.
> 
> All three of those things: "p-p", "p&0", and "p==" mean
> that any compiler worth its salt now know that "p" carries no
> information, and will optimize it away.
> 
> So please stop arguing against that. Whenever you argue against that
> simple fact, you are arguing against sane compilers.

So let me see if I understand your reasoning.  My best guess is that it
goes something like this:

1.  The Linux kernel contains code that passes pointers from
rcu_dereference() through external functions.

2.  Code in the Linux kernel expects the normal RCU ordering
guarantees to be in effect even when external functions are
involved.

3.  When compiling one of these external functions, the C compiler
has no way of knowing about these RCU ordering guarantees.

4.  The C compiler might therefore apply any and all optimizations
to these external functions.

5.  This in turn implies that we the only way to prohibit any given
optimization from being applied to the results obtained from
rcu_dereference() is to prohibit that optimization globally.

6.  We have to be very careful what optimizations are globally
prohibited, because a poor choice could result in unacceptable
performance degradation.

7.  Therefore, the only operations that can be counted on to
maintain the needed RCU orderings are those where the compiler
really doesn't have any choice, in other words, where any
reasonable way of computing the result will necessarily maintain
the needed ordering.

Did I get this right, or am I confused?

> So *accept* the fact that some operations (and I guarantee that there
> are more of those than you can think of, and you can create them with
> various tricks using pretty much *any* feature in the C language)
> essentially take the data information away. And just accept the fact
> that then the ordering goes away too.

Actually, the fact that there are more potential optimizations than I can
think of is a big reason for my insistence on the carries-a-dependency
crap.  My lack of optimization omniscience makes me very nervous about
relying on there never ever being a reasonable way of computing a given
result without preserving the ordering.

> So give up on "carries a dependency". Because there will be cases
> where that dependency *isn't* carried.
> 
> The language of the standard needs to get *away* from the broken
> model, because otherwise the standard is broken.
> 
> I suggest we instead talk about "litmus tests" and why certain code
> sequences are ordered, and others are not.

OK...

> So the code sequence I already mentioned is *not* ordered:
> 
> Litmus test 1:
> 
> p = atomic_read(pp, consume);
> if (p == )
> return p->val;
> 
>is *NOT* ordered, because the compiler can trivially turn this into
> "return variable.val", and break the data dependency.

Right, given your model, the compiler is free to produce code that
doesn't order the load from pp against the load from p->val.

>This is true *regardless* of any "carries a dependency" language,
> because that language is insane, and doesn't work when the

Re: [PATCH 1/2] cpufreq: Return error if ->get() failed in cpufreq_update_policy()

2014-02-24 Thread Srivatsa S. Bhat

On 02/25/2014 10:11 AM, Viresh Kumar wrote:
> On 18 February 2014 07:49, Viresh Kumar  wrote:
>> On 18 February 2014 03:30, Rafael J. Wysocki  wrote:
>>> On Monday, February 17, 2014 02:25:34 PM Srivatsa S. Bhat wrote:
 Why go to no_policy when we can actually set things right?

 Anyway, I am not arguing against this strongly. I just wanted to share my
 thoughts, since this is the approach that made more sense to me.
>>>
>>> And I agree with that.  In particular, since we're going to set the new
>>> policy *anyway* at this point, we can adjust the current frequency just fine
>>> in the process, can't we?
>>
>> Though I still feel that it wouldn't be the right thing to do as get()
>> just can't
>> return zero. Actually I was planning to place a WARN() over its return value
>> of zero.

A WARN() would definitely be good.

>>
>> Anyway, as two of the three are in favor of this we can get that in.. But how
>> would that work?
>>
>> - What frequency should we call cpufreq_driver_target ?
>> - Remember that it wouldn't do anything if policy->cur is same as new freq.
>> - Also remember that drivers need special attention if new freq is > old
>> freq or vice versa. As they will change voltage before or after change here.
>> And because we actually don't know what frequency we are at currently, how
>> will we decide that?
> 

Hmm, that's a good point. However, lets first think about the simple scenario
that the driver _is_ able to detect the current frequency from the hardware
(a non-zero, sane value) say X KHz, and that frequency is different from what
the cpufreq subsystem thinks it is (Y KHz).

In the current code, when we observe this, we send out a notification and try
to adjust to X KHz. Instead, what I'm suggesting is to invoke the driver to
set the frequency to Y KHz, since that's what the cpufreq subsystems wants the
frequency to be at.

As for the case where the driver reports the frequency to be 0 KHz, we can
print a WARN() and try to force set the frequency to Y KHz. But if that turns
out to be too tricky to handle, we can just put a WARN() and error out, as you
proposed earlier.

Regards,
Srivatsa S. Bhat

--
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 7/7] powerpc: Added PCI MSI support using the HSTA module

2014-02-24 Thread Alistair Popple

On Sat, 22 Feb 2014 07:41:26 Benjamin Herrenschmidt wrote:
> On Fri, 2014-02-21 at 15:33 +0100, Arnd Bergmann wrote:

[...]

> 
> Should we (provided it's possible in HW) create two ranges instead ? One
> covering RAM and one covering MSIs ? To avoid stray DMAs whacking random
> HW registers in the chip ...
> 

The thought occurred to me but I figured if we had stray DMAs then they could 
already whack random bits of system memory which would likely break your 
system anyway so I wasn't sure how much we'd gain. I guess whacking random HW 
registers is arguably a bit worse though.

I did a bit of digging into the HW documentation and it looks like it _may_ be 
possible to create a second range that would limit access to a subset of HW 
registers, although there doesn't seem to be much flexibility. Personally I'm 
not sure it justifies the work, but I'm happy to look into it a bit more if 
you feel it's important?

- Alistair

--
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 1/6] PM / Voltagedomain: Add generic clk notifier handler for regulator based dynamic voltage scaling

2014-02-24 Thread Mike Turquette

Quoting Nishanth Menon (2014-02-18 12:32:18)
> From: Mike Turquette 
> 
> This patch provides helper functions for drivers that wish to scale
> voltage through the clock rate-change notifiers. The approach taken
> is that the user-driver(cpufreq/devfreq) do not care about the
> details of the OPP table, nor does it care about handling the voltage
> regulator directly.
> 
> By using the clk notifier flags, we are able to sequence the operations
> in the right order. The current logic is heavily influenced by
> implementation done in cpufreq-cpu0.
> 
> [n...@ti.com: Fixes in logic, and broken out from clk to allow building
> a generic voltagedomain solution independent of cpufreq]
> Signed-off-by: Nishanth Menon 
> Signed-off-by: Mike Turquette 

Not-signed-off-by: Mike Turquette 

I haven't reviewed this series and it is a pretty big deviation from my
original RFC. You can have authorship of the patches if you want.

I'm not sure about trying to capture the "voltdm" as a core concept. It
feels a bit unwieldy to me. I have wondered about making an abstract
"performance domain" which is the dvfs analogue to generic power
domains. This a reasonable split since gpd are good for idle power
savings (e.g. clock gate, power gate, sleep state, etc) and "perf
domains" would be good for active power savings (dvfs).

Having a generic container for performance domains might make a good
place to stuff all of this glue logic that we keep running into (e.g.
CPU and GPU max frequencies that are related), and it might make another
nice knob for the thermal folks to use.

For the case of the OMAP voltage domains, it would be a place to stuff
all of the VC/VP -> ABB -> Smart Reflex AVS stuff.

Anyways, I don't have a real proposal. I just don't want my name on
these patches since they are really yours now. I might resurrect them
some day in a different context.

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

Re: [PATCH] tools: Unify export.h

2014-02-24 Thread Rusty Russell

Borislav Petkov  writes:
> From: Borislav Petkov 
>
> So tools/ has been growing three, at a different stage of their
> development export.h headers and so we should unite into one. Add
> tools/include/ to the include path of virtio and liblockdep to pick the
> shared header now.

Should we get more ambitious and start a fake-kernel/ directory where
we can put userspace equivs/stubs of kernel functionality?

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

Re: [PATCH] net: kdoc struct net_device flags and priv_flags

2014-02-24 Thread Florian Fainelli

Le lundi 24 février 2014, 23:53:43 David Miller a écrit :
> From: Ben Hutchings 
> Date: Tue, 25 Feb 2014 02:11:05 +
> 
> > On Mon, 2014-02-24 at 16:14 -0800, Luis R. Rodriguez wrote:
> >> From: "Luis R. Rodriguez" 
> >> 
> >> ---
> >> 
> >>  include/uapi/linux/if.h | 201
> >>  +++- 1 file changed, 149
> >>  insertions(+), 52 deletions(-)
> >> 
> >> diff --git a/include/uapi/linux/if.h b/include/uapi/linux/if.h
> >> index d758163..1555623 100644
> >> --- a/include/uapi/linux/if.h
> >> +++ b/include/uapi/linux/if.h
> > 
> > [...]
> > 
> >> +/**
> >> + * enum net_device_priv_flags -  net_device priv_flags
> >> + *
> >> + * These are the  net_device, they are only set internally
> >> + * by drivers and used in the kernel but are invisible to userspace.
> > 
> > [...]
> > 
> > Indeed, I wonder why they are in the UAPI header.  As userland doesn't
> > have a legitimate use for them, maybe you could move them back to
> > include/linux/if.h instead of bothering with adding macros?
> 
> They are visible to userspace via sysfs.

In /sys/class/net/*/flags, although we are lacking quite a lot of documentation 
for the exported attributes there.

The only attributes for which there is some sort of documentation are 
"operstate" and the XPS/RFS/RPS attributes, maybe that could be fixed too as 
part of this documentation patch?

> 
> My memory may be bad, but I believe this has been brought up before.
> --
> 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/

-- 
Florian
--
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 V8 1/2] PHY: Exynos: Add Exynos5250 SATA PHY driver

2014-02-24 Thread Jingoo Han

On Mon, 24 Feb 2014 19:26:44, Kishon Vijay Abraham I wrote: 
> On Monday 24 February 2014 07:02 PM, Yuvaraj Kumar C D wrote:
> > This patch adds the SATA PHY driver for Exynos5250.Exynos5250 SATA
> > PHY comprises of CMU and TRSV blocks which are of I2C register Map.
> > So this patch also adds a i2c client driver, which is used configure
> 
> We no longer have i2c client driver here.

Right.

> > the CMU and TRSV block of exynos5250 SATA PHY.
> > 
> > This patch incorporates the generic PHY framework to deal with SATA
> > PHY.
> 
> It should be rephrased to have *uses* generic PHY framework. However I feel we
> can do away with this line.

Right, "incorporates" is confusing.

> > 
> > This patch depends on the below patch for the sata functionality
> > [1].ata: ahci_platform: Manage SATA PHY
> > by Roger Quadros 
> 
> hasn't this patch merged yet?

Currently, this patch was queued into libata tree, for-next. [1]

[1] 
http://git.kernel.org/cgit/linux/kernel/git/tj/libata.git/commit/?h=for-next=21b5faeec229d4f70a7f60a7b0b065c98198f491

Best regards,
Jingoo 
HanN떑꿩�r툤y鉉싕b쾊Ф푤v�^�)頻{.n�+돴쪐{콗喩zX㎍썳變}찠꼿쟺�:+v돣�쳭喩zZ+�+zf＂톒쉱�~넮녬i鎬z�췿ⅱ�?솳鈺�&�)刪f뷌^j푹y쬶끷@A첺뛴
0띠h��뭝

Re: [PATCH] checkpatch.pl: Add warning for new __packed additions

2014-02-24 Thread Joe Perches

On Mon, 2014-02-24 at 17:43 -0500, Tom Rini wrote:
> My perl is quite limited, so however much effort you're interested in
> putting in here is greatly appreciated (even if it's pointing out
> something else already in the script to copy and modify).  We already
> ship a .checkpatch.conf so having to enable something by default is
> fine.  Thanks!

The U-Boot checkpatch is not the same as the current
linux version and would need updating.

Tell me a little more please about how often or possible
it would be to update the current linux version of
checkpatch to the version used in U-Boot.


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

RE: [PATCH 2/6] usb: gadget: mv_udc: disable HW zlt for ep0



 
> > On Mon, Feb 24, 2014 at 04:03:12PM +0800, Neil Zhang wrote:
> > > Hardware zlt will try to send the zero length packet automatically
> > > when the data transferd is multiple times of max packet, this will
> > > cause issues on Windows.
> > > So let's disable HW zlt by default.
> >
> > Would you have description that what kinds of issue on Windows if zlt
> > is is selected?
> >
> 
> Enumeration will fail.
> 

What causes enumeration fail, why it does not occur before?

Peter
--
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 5/6] USB: gadget: mv_udc: workaroud for missing dTD

On Mon, Feb 24, 2014 at 04:03:15PM +0800, Neil Zhang wrote:
> There is an issue with the add dTD tripwire semaphore (ATDTW bit in
> USBCMD register) that can cause the controller to ignore a dTD that is
> added to a primed endpoint. When this happens, the software can read
> the tripwire bit and the status bit at '1' even though the endpoint
> is unprimed.
> 
> After executing a dTD, the device controller endpoint state machine
> executes a final read of the dTD terminate bit to check if the
> application added a dTD to the linked list at the last moment. This read
> is done in the finpkt_read_latest_next_td (44) state. After the read is
> performed, if the terminate bit is still set, the state machine moves to
> unprime the endpoint. The decision to unprime the endpoint is done in
> the checkqh_decision (59) state, based on the value of the terminate bit.
> 
> Before reaching the checkqh_decision state, the state machine traverses
> the writeqhtd_status (57), writeqh_status (56), and release_prime_mask
> (42) states. As shown in the waveform, the ep_addtd_tripwire_clr signal
> is not set to clear the tripwire bit in these states.
> 
> Signed-off-by: Neil Zhang 
> ---
>  drivers/usb/gadget/mv_udc_core.c |   20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/drivers/usb/gadget/mv_udc_core.c 
> b/drivers/usb/gadget/mv_udc_core.c
> index a620cff..8df8606 100644
> --- a/drivers/usb/gadget/mv_udc_core.c
> +++ b/drivers/usb/gadget/mv_udc_core.c
> @@ -196,7 +196,27 @@ static int process_ep_req(struct mv_udc *udc, int index,
>   while (readl(>op_regs->epstatus) & bit_pos)
>   udelay(1);
>   break;
> + } else {
> + if (!(readl(>op_regs->epstatus) & bit_pos)) {
> + /* The DMA engine thinks there is no more dTD */
> + curr_dqh->next_dtd_ptr = curr_dtd->dtd_next
> + & EP_QUEUE_HEAD_NEXT_POINTER_MASK;
> +
> + /* clear active and halt bit */
> + curr_dqh->size_ioc_int_sts &=
> + ~(DTD_STATUS_ACTIVE
> + | DTD_STATUS_HALTED);
> +
> + /* Do prime again */
> + wmb();
> + writel(bit_pos, >op_regs->epprime);
> + while (readl(>op_regs->epprime) & bit_pos)
> + cpu_relax();
> +
> + break;
> + }
>   }
> +
>   udelay(1);
>   }
>  

Is it a chipidea IP issue? Any errate number for this issue?
Does we need it for chipidea driver?

-- 

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: [PATCH v2] dma: add R-Car Audio DMAC peri peri driver

2014-02-24 Thread Kuninori Morimoto


Hi Vinod, Linux-kernel ML

ping ?

> Can I ask you about current status of this patch ?
> 
> > From: Kuninori Morimoto 
> > 
> > Add support Audio DMAC peri peri driver
> > for Renesas R-Car Gen2 SoC, using 'shdma-base'
> > DMA driver framework.
> > 
> > Signed-off-by: Kuninori Morimoto 
> > ---
> > v1 -> v2
> > 
> >  - run scripts/checkpatch.pl
> >  - ecchange length settings on audmapp_desc_setup()
> >  - exchange slave_id check on audmapp_find_slave()
> > 
> >  drivers/dma/sh/Kconfig |6 +
> >  drivers/dma/sh/Makefile|1 +
> >  drivers/dma/sh/rcar-audmapp.c  |  325 
> > 
> >  include/linux/platform_data/dma-rcar-audmapp.h |   34 +++
> >  4 files changed, 366 insertions(+)
> >  create mode 100644 drivers/dma/sh/rcar-audmapp.c
> >  create mode 100644 include/linux/platform_data/dma-rcar-audmapp.h
> > 
> > diff --git a/drivers/dma/sh/Kconfig b/drivers/dma/sh/Kconfig
> > index dadd9e01..b4c8138 100644
> > --- a/drivers/dma/sh/Kconfig
> > +++ b/drivers/dma/sh/Kconfig
> > @@ -29,6 +29,12 @@ config RCAR_HPB_DMAE
> > help
> >   Enable support for the Renesas R-Car series DMA controllers.
> >  
> > +config RCAR_AUDMAC_PP
> > +   tristate "Renesas R-Car Audio DMAC Peripheral Peripheral support"
> > +   depends on SH_DMAE_BASE
> > +   help
> > + Enable support for the Renesas R-Car Audio DMAC Peripheral Peripheral 
> > controllers.
> > +
> >  config SHDMA_R8A73A4
> > def_bool y
> > depends on ARCH_R8A73A4 && SH_DMAE != n
> > diff --git a/drivers/dma/sh/Makefile b/drivers/dma/sh/Makefile
> > index e856af2..1ce88b2 100644
> > --- a/drivers/dma/sh/Makefile
> > +++ b/drivers/dma/sh/Makefile
> > @@ -7,3 +7,4 @@ endif
> >  shdma-objs := $(shdma-y)
> >  obj-$(CONFIG_SUDMAC) += sudmac.o
> >  obj-$(CONFIG_RCAR_HPB_DMAE) += rcar-hpbdma.o
> > +obj-$(CONFIG_RCAR_AUDMAC_PP) += rcar-audmapp.o
> > diff --git a/drivers/dma/sh/rcar-audmapp.c b/drivers/dma/sh/rcar-audmapp.c
> > new file mode 100644
> > index 000..cd3c237
> > --- /dev/null
> > +++ b/drivers/dma/sh/rcar-audmapp.c
> > @@ -0,0 +1,325 @@
> > +/*
> > + * drivers/dma/sh/rcar-audmapp.c
> > + *
> > + * Copyright (C) 2013 Renesas Electronics Corporation
> > + * Copyright (C) 2013 Kuninori Morimoto 
> > + *
> > + * based on the drivers/dma/sh/shdma.c
> > + *
> > + * Copyright (C) 2011-2012 Guennadi Liakhovetski 
> > + * Copyright (C) 2009 Nobuhiro Iwamatsu 
> > + * Copyright (C) 2009 Renesas Solutions, Inc. All rights reserved.
> > + * Copyright (C) 2007 Freescale Semiconductor, Inc. All rights reserved.
> > + *
> > + * This is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + *
> > + */
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +/*
> > + * DMA register
> > + */
> > +#define PDMASAR0x00
> > +#define PDMADAR0x04
> > +#define PDMACHCR   0x0c
> > +
> > +/* PDMACHCR */
> > +#define PDMACHCR_DE(1 << 0)
> > +
> > +#define AUDMAPP_MAX_CHANNELS   29
> > +
> > +/* Default MEMCPY transfer size = 2^2 = 4 bytes */
> > +#define LOG2_DEFAULT_XFER_SIZE 2
> > +#define AUDMAPP_SLAVE_NUMBER   256
> > +#define AUDMAPP_LEN_MAX(16 * 1024 * 1024)
> > +
> > +struct audmapp_chan {
> > +   struct shdma_chan shdma_chan;
> > +   struct audmapp_slave_config *config;
> > +   void __iomem *base;
> > +};
> > +
> > +struct audmapp_device {
> > +   struct shdma_dev shdma_dev;
> > +   struct audmapp_pdata *pdata;
> > +   struct device *dev;
> > +   void __iomem *chan_reg;
> > +};
> > +
> > +#define to_chan(chan) container_of(chan, struct audmapp_chan, shdma_chan)
> > +#define to_dev(chan) container_of(chan->shdma_chan.dma_chan.device,
> > \
> > + struct audmapp_device, shdma_dev.dma_dev)
> > +
> > +static void audmapp_write(struct audmapp_chan *auchan, u32 data, u32 reg)
> > +{
> > +   struct audmapp_device *audev = to_dev(auchan);
> > +   struct device *dev = audev->dev;
> > +
> > +   dev_dbg(dev, "w %p : %08x\n", auchan->base + reg, data);
> > +
> > +   iowrite32(data, auchan->base + reg);
> > +}
> > +
> > +static u32 audmapp_read(struct audmapp_chan *auchan, u32 reg)
> > +{
> > +   return ioread32(auchan->base + reg);
> > +}
> > +
> > +static void audmapp_halt(struct shdma_chan *schan)
> > +{
> > +   struct audmapp_chan *auchan = to_chan(schan);
> > +   int i;
> > +
> > +   audmapp_write(auchan, 0, PDMACHCR);
> > +
> > +   for (i = 0; i < 1024; i++) {
> > +   if (0 == audmapp_read(auchan, PDMACHCR))
> > +   return;
> > +   udelay(1);
> > +   }
> > +}
> > +
> > +static void audmapp_start_xfer(struct shdma_chan *schan,
> > +  struct shdma_desc *sdecs)

Re: [PATCH 0/6] bug fix for mv_udc_core.c

On Mon, Feb 24, 2014 at 04:42:40AM -0800, Neil Zhang wrote:
> 
> > -Original Message-
> > From: Matthieu CASTET [mailto:matthieu.cas...@parrot.com]
> > Sent: 2014年2月24日 18:32
> > To: Neil Zhang
> > Cc: ba...@ti.com; gre...@linuxfoundation.org; linux-...@vger.kernel.org;
> > linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH 0/6] bug fix for mv_udc_core.c
> > 
> > Le Mon, 24 Feb 2014 16:03:10 +0800,
> > Neil Zhang  a écrit :
> > 
> > > This patch set is mainly for bug fix.
> > >
> > > Neil Zhang (6):
> > >   usb: gadget: mv_udc: remove redundant pull up in udc_start
> > >   usb: gadget: mv_udc: disable HW zlt for ep0
> > >   usb: gadget: mv_udc: clear corresponding interrupt when flush fifo
> > >   usb: gadget: mv_udc: check endpoint before queue dtd
> > >   USB: gadget: mv_udc: workaroud for missing dTD
> > >   USB: gadget: mv_udc: fix corner case for missiong dTD
> > >
> > >  drivers/usb/gadget/mv_udc_core.c |   47
> > ++
> > >  1 file changed, 42 insertions(+), 5 deletions(-)
> > >
> > 
> > Do you have plan to move to the chipidea udc driver ?
> > 
> > You could have some bug fix for free or share your bug fix with others.
> > 
> 
> 
> Not yet.
> Will estimate it later.
> > 

Freescale uses mv udc driver at u-boot, so the chipidea IP should be
compatible for two SoCs , both Intel and msm are using chipidea driver
at linux kernel, it should be not difficult for marvell to use it. 

For this patchset, some of them may already be fixed at chipidea driver
(3/6, 4/6), some of them may not (5/6, 6/6).

-- 

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: [GIT PULL] bcm pinctrl rename

2014-02-24 Thread Christian Daudt

On Fri, Feb 21, 2014 at 2:29 PM, Olof Johansson  wrote:
> (As per irc discussion). The rename isn't the right thing to do at this
> time in the release, but the binding needs to be tweaked before it ships
> in a full release, or we'll always need to live with it.
>
> So, I'll be happy to take the bindings piece and the dtsi piece (and the
> small edit to the driver to change the compatible string match table),
> but the file rename and Kconfig entry edit is 3.15 material.
>
> Please send new pull request with just that (or, if you prefer, just send the
> patches and we can apply them too).
>

Can you please pull the patches below. Note that if you wanto to
absolutely reduce this to the bone, you can drop the last patch in the
series titled "pinctrl: Rename Broadcom Capri pinctrl binding". That
is the documentation fixup, so the binding doc will be wrong until
3.15. But that will reduce the change to just 2 lines :)
 thanks,
   csd


The following changes since commit cfbf8d4857c26a8a307fb7cd258074c9dcd8c691:

  Linux 3.14-rc4 (2014-02-23 17:40:03 -0800)

are available in the git repository at:

  git://github.com/broadcom/bcm11351.git
tags/bcm-for-3.14-pinctrl-reduced-rename

for you to fetch changes up to 735ea23c4868bf3123a4c79184e9206e0cc60211:

  pinctrl: Rename Broadcom Capri pinctrl binding (2014-02-24 20:25:54 -0800)


Rename pinctrl dt binding to restore consistency with
other bcm mobile bindings.


Christian Daudt (1):
  pinctrl: refer to updated dt binding string.

Sherman Yin (2):
  Update dtsi with new pinctrl compatible string
  pinctrl: Rename Broadcom Capri pinctrl binding

 Documentation/devicetree/bindings/pinctrl/{brcm,capri-pinctrl.txt =>
brcm,bcm11351-pinctrl.txt} | 8 
 arch/arm/boot/dts/bcm11351.dtsi
  | 2 +-
 drivers/pinctrl/pinctrl-capri.c
  | 2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)
 rename Documentation/devicetree/bindings/pinctrl/{brcm,capri-pinctrl.txt
=> brcm,bcm11351-pinctrl.txt} (98%)
--
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 v7 2/2] dmaengine: add Qualcomm BAM dma driver

2014-02-24 Thread Felipe Balbi

On Tue, Feb 25, 2014 at 12:05:00PM +0900, Mark Brown wrote:
> On Mon, Feb 24, 2014 at 06:09:13PM -0600, Felipe Balbi wrote:
> 
> > > + depends on ARCH_QCOM || (COMPILE_TEST && OF && ARM)
> 
> > do you really want to make it depend on ARM even when COMPILE_TEST=y ?
> 
> writel_relaxed() is unfortunately not generally available so it'd fail
> to build on platforms like x86.

bummer

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] net: kdoc struct net_device flags and priv_flags

2014-02-24 Thread David Miller

From: Ben Hutchings 
Date: Tue, 25 Feb 2014 02:11:05 +

> On Mon, 2014-02-24 at 16:14 -0800, Luis R. Rodriguez wrote:
>> From: "Luis R. Rodriguez" 
>> 
>> ---
>>  include/uapi/linux/if.h | 201 
>> +++-
>>  1 file changed, 149 insertions(+), 52 deletions(-)
>> 
>> diff --git a/include/uapi/linux/if.h b/include/uapi/linux/if.h
>> index d758163..1555623 100644
>> --- a/include/uapi/linux/if.h
>> +++ b/include/uapi/linux/if.h
> [...]
>> +/**
>> + * enum net_device_priv_flags -  net_device priv_flags
>> + *
>> + * These are the  net_device, they are only set internally
>> + * by drivers and used in the kernel but are invisible to userspace.
> [...]
> 
> Indeed, I wonder why they are in the UAPI header.  As userland doesn't
> have a legitimate use for them, maybe you could move them back to
> include/linux/if.h instead of bothering with adding macros?

They are visible to userspace via sysfs.

My memory may be bad, but I believe this has been brought up before.
--
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: warn users of smt-snooze-delay that the API isn't there anymore

2014-02-24 Thread Madhavan Srinivasan

On Saturday 22 February 2014 05:44 AM, Cody P Schafer wrote:
> /sys/devices/system/cpu/cpu*/smt-snooze-delay was converted into a NOP
> in commit 3fa8cad82b94d0bed002571bd246f2299ffc876b, and now does
> nothing. Add a pr_warn() to convince any users that they should stop
> using it.
> 
> The commit message from the removing commit notes that this
> functionality should move into the cpuidle driver, essentially by

Would prefer to cleanup the code since the functionality is moved,
instead of adding to it.

> adjusting target_residency to the specified value. At the moment,
> target_residency is not exposed by cpuidle's sysfs, so there isn't a
> drop in replacement for this.
> 
> Signed-off-by: Cody P Schafer 
> ---
>  arch/powerpc/kernel/sysfs.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
> index 97e1dc9..84097b4 100644
> --- a/arch/powerpc/kernel/sysfs.c
> +++ b/arch/powerpc/kernel/sysfs.c
> @@ -50,6 +50,9 @@ static ssize_t store_smt_snooze_delay(struct device *dev,
>   if (ret != 1)
>   return -EINVAL;
>  
> + pr_warn_ratelimited("%s (%d): 
> /sys/devices/system/cpu/cpu%d/smt-snooze-delay is deprecated and is a NOP\n",
> +   current->comm, task_pid_nr(current), cpu->dev.id);
> +
>   per_cpu(smt_snooze_delay, cpu->dev.id) = snooze;
>   return count;
>  }
> @@ -60,6 +63,9 @@ static ssize_t show_smt_snooze_delay(struct device *dev,
>  {
>   struct cpu *cpu = container_of(dev, struct cpu, dev);
>  
> + pr_warn_ratelimited("%s (%d): 
> /sys/devices/system/cpu/cpu%d/smt-snooze-delay is deprecated and is a NOP\n",
> +   current->comm, task_pid_nr(current), cpu->dev.id);
> +
>   return sprintf(buf, "%ld\n", per_cpu(smt_snooze_delay, cpu->dev.id));
>  }
>  
> 

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

Re: sched: hang in migrate_swap

2014-02-24 Thread Michael wang

On 02/24/2014 09:10 PM, Peter Zijlstra wrote:
> On Mon, Feb 24, 2014 at 01:12:18PM +0100, Peter Zijlstra wrote:
>> +if (p) {
>> +if (unlikely(p == RETRY_TASK))
>> +goto again;
> 
> We could even make that: unlikely(p & 1), I think most CPUs can encode
> that far better than the full pointer immediate.

Agree, unless odd-align stuff appeared...

Regards,
Michael Wang

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

Re: [PATCH 1/2] cpufreq: Return error if ->get() failed in cpufreq_update_policy()

2014-02-24 Thread Viresh Kumar

On 18 February 2014 07:49, Viresh Kumar  wrote:
> On 18 February 2014 03:30, Rafael J. Wysocki  wrote:
>> On Monday, February 17, 2014 02:25:34 PM Srivatsa S. Bhat wrote:
>>> Why go to no_policy when we can actually set things right?
>>>
>>> Anyway, I am not arguing against this strongly. I just wanted to share my
>>> thoughts, since this is the approach that made more sense to me.
>>
>> And I agree with that.  In particular, since we're going to set the new
>> policy *anyway* at this point, we can adjust the current frequency just fine
>> in the process, can't we?
>
> Though I still feel that it wouldn't be the right thing to do as get()
> just can't
> return zero. Actually I was planning to place a WARN() over its return value
> of zero.
>
> Anyway, as two of the three are in favor of this we can get that in.. But how
> would that work?
>
> - What frequency should we call cpufreq_driver_target ?
> - Remember that it wouldn't do anything if policy->cur is same as new freq.
> - Also remember that drivers need special attention if new freq is > old
> freq or vice versa. As they will change voltage before or after change here.
> And because we actually don't know what frequency we are at currently, how
> will we decide that?

@Rafael/Srivatsa: Ping!!
--
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: [BUG] sched: tip/master show panic while booting/rebooting

2014-02-24 Thread Paul E. McKenney

On Tue, Feb 25, 2014 at 10:45:26AM +0800, Michael wang wrote:
> Hi, Paul
> 
> On 02/25/2014 08:30 AM, Paul E. McKenney wrote:
> [snip]
> > 
> > I don't see an opportunity for load_balance() to loop with interrupts
> > disabled, but maybe I am looking at the wrong code.  The NMI handler
> > looks to me like it is diagnosing rather than being the problem.
> 
> Thanks for the comment :)
> 
> It was a stuck inside pick_next_task_fair(), and we already got one
> solution now ;-)

What I get for too-late reply.  Glad it is fixed!

Thanx, Paul

> Regards,
> Michael Wang
> 
> > 
> > Thanx, Paul
> > 
> >>  [] idle_balance+0x10f/0x1c0
> >>  [] pick_next_task_fair+0x11e/0x2a0
> >>  [] ? dequeue_task+0x73/0x90
> >>  [] __schedule+0x12a/0x670
> >>  [] schedule+0x29/0x70
> >>  [] worker_thread+0x1bf/0x370
> >>  [] ? manage_workers+0x160/0x160
> >>  [] kthread+0xc9/0xe0
> >>  [] ? flush_kthread_worker+0xb0/0xb0
> >>  [] ret_from_fork+0x7c/0xb0
> >>  [] ? flush_kthread_worker+0xb0/0xb0
> >> Kernel Offset: 0x0 from 0x8100 (relocation range: 
> >> 0x8000-0x9fff)
> > 
> > --
> > 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/

Re: [PATCH] xtensa: export ccount_freq

2014-02-24 Thread Max Filippov

On Tue, Feb 25, 2014 at 8:07 AM, Guenter Roeck  wrote:
> xtensa:allmodconfig fails to build with hundreds of messages such as
>
> ERROR: "ccount_freq" [drivers/ata/pata_hpt3x2n.ko] undefined!
>
> Exporting ccount_freq solves the problem.
>
> Signed-off-by: Guenter Roeck 
> ---
>  arch/xtensa/kernel/time.c |1 +
>  1 file changed, 1 insertion(+)

Hi Guenter,

a similar patch is already queued:
http://lists.linux-xtensa.org/pipermail/linux-xtensa/Week-of-Mon-20140113/001500.html

-- 
Thanks.
-- Max
--
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] ASoC: wm8993: Remove unused pointer in wm8993_remove()

2014-02-24 Thread Mark Brown

On Sat, Feb 22, 2014 at 04:00:16PM +0100, Christian Engelmayer wrote:
> Commit 88b5bdfd (ASoC: wm8993: drop regulator_bulk_free of devm_ allocated
> data) eliminated the last user of driver data pointer 'wm8993' in function
> wm8993_remove() - Thus remove it. Detected by Coverity: CID 1186208.

Applied, thanks.


signature.asc
Description: Digital signature

linux-next: manual merge of the watchdog tree with the mvebu tree

Hi Wim,

Today's linux-next merge of the watchdog tree got a conflict in
drivers/watchdog/orion_wdt.c between commit e97662e1e28d ("watchdog:
orion: Handle the interrupt so it's properly acked") from the mvebu tree
and commit 2e9a2ff49520 ("watchdog: delete non-required instances of
include ") from the watchdog tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

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

diff --cc drivers/watchdog/orion_wdt.c
index 15321aa0bb94,498163497c1c..
--- a/drivers/watchdog/orion_wdt.c
+++ b/drivers/watchdog/orion_wdt.c
@@@ -18,9 -18,8 +18,8 @@@
  #include 
  #include 
  #include 
- #include 
 +#include 
  #include 
 -#include 
  #include 
  #include 
  #include 


pgp1FtnC1P6kV.pgp
Description: PGP signature

[PATCH] xtensa: export ccount_freq

2014-02-24 Thread Guenter Roeck

xtensa:allmodconfig fails to build with hundreds of messages such as

ERROR: "ccount_freq" [drivers/ata/pata_hpt3x2n.ko] undefined!

Exporting ccount_freq solves the problem.

Signed-off-by: Guenter Roeck 
---
 arch/xtensa/kernel/time.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/xtensa/kernel/time.c b/arch/xtensa/kernel/time.c
index 08b769d..2a1823d 100644
--- a/arch/xtensa/kernel/time.c
+++ b/arch/xtensa/kernel/time.c
@@ -30,6 +30,7 @@
 #include 
 
 unsigned long ccount_freq; /* ccount Hz */
+EXPORT_SYMBOL(ccount_freq);
 
 static cycle_t ccount_read(struct clocksource *cs)
 {
-- 
1.7.9.7

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

RE: [PATCH 2/6] usb: gadget: mv_udc: disable HW zlt for ep0




> -Original Message-
> From: Peter Chen [mailto:peter.c...@freescale.com]
> Sent: 2014年2月25日 9:19
> To: Neil Zhang
> Cc: ba...@ti.com; gre...@linuxfoundation.org; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 2/6] usb: gadget: mv_udc: disable HW zlt for ep0
> 
> On Mon, Feb 24, 2014 at 04:03:12PM +0800, Neil Zhang wrote:
> > Hardware zlt will try to send the zero length packet automatically
> > when the data transferd is multiple times of max packet, this will
> > cause issues on Windows.
> > So let's disable HW zlt by default.
> 
> Would you have description that what kinds of issue on Windows if zlt is is
> selected?
> 

Enumeration will fail.

> Peter
> 
> >
> > Signed-off-by: Neil Zhang 
> > ---
> >  drivers/usb/gadget/mv_udc_core.c |2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/usb/gadget/mv_udc_core.c
> > b/drivers/usb/gadget/mv_udc_core.c
> > index ebc0dfd..657ac5c 100644
> > --- a/drivers/usb/gadget/mv_udc_core.c
> > +++ b/drivers/usb/gadget/mv_udc_core.c
> > @@ -89,7 +89,7 @@ static void ep0_reset(struct mv_udc *udc)
> > /* configure ep0 endpoint capabilities in dQH */
> > ep->dqh->max_packet_length =
> > (EP0_MAX_PKT_SIZE << EP_QUEUE_HEAD_MAX_PKT_LEN_POS)
> > -   | EP_QUEUE_HEAD_IOS;
> > +   | EP_QUEUE_HEAD_IOS | EP_QUEUE_HEAD_ZLT_SEL;
> >
> > ep->dqh->next_dtd_ptr = EP_QUEUE_HEAD_NEXT_TERMINATE;
> >
> > --
> > 1.7.9.5
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-usb"
> > in the body of a message to majord...@vger.kernel.org More majordomo
> > info at  http://vger.kernel.org/majordomo-info.html
> >
> >
> 
> --
> 
> Best Regards,
> Peter Chen


Best Regards,
Neil Zhang
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 v5 0/10] fs: Introduce new flag(FALLOC_FL_COLLAPSE_RANGE) for fallocate

2014-02-24 Thread Dave Chinner

On Tue, Feb 25, 2014 at 02:16:01PM +1100, Stephen Rothwell wrote:
> Hi Dave,
> 
> On Mon, 24 Feb 2014 11:57:10 +1100 Dave Chinner  wrote:
> >
> > > Namjae Jeon (10):
> > >   fs: Add new flag(FALLOC_FL_COLLAPSE_RANGE) for fallocate
> > >   xfs: Add support FALLOC_FL_COLLAPSE_RANGE for fallocate
> > 
> > I've pushed these to the following branch:
> > 
> > git://oss.sgi.com/xfs/xfs.git xfs-collapse-range
> > 
> > And so they'll be in tomorrow's linux-next tree.
> > 
> > >   ext4: Add support FALLOC_FL_COLLAPSE_RANGE for fallocate
> > 
> > I've left this one alone for the ext4 guys to sort out.
> 
> So presumably that xfs tree branch is now completely stable and so Ted
> could just merge that branch into the ext4 tree as well and put the ext4
> part on top of that in his tree.

Well, for some definition of stable. Right now it's just a topic
branch that is merged into the for-next branch, so in theory it is
still just a set of pending changes in a branch in a repo that has
been pushed to linux-next for testing.

That said, I don't see that branch changing unless we find bugs in
the code or a problem with the API needs fixing, at which point I
would add more commits to it and rebase the for-next branch that you
are pulling into the linux-next tree.

Realistically, I'm waiting for Lukas to repost his other pending
fallocate changes (the zero range changes) so I can pull the VFS and
XFS bits of that into the XFS tree and I can test them together
before I'll call the xfs-collapse-range stable and ready to be
merged into some other tree...

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.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: Commit 597ce1723 (MIPS: Support for 64-bit FP with O32 binaries) causing qemu hang with mips64 kernels

2014-02-24 Thread Guenter Roeck

On 02/07/2014 08:55 PM, Guenter Roeck wrote:

On 02/07/2014 07:57 PM, Huacai Chen wrote:

Hi,

Maybe you can try this:
http://patchwork.linux-mips.org/patch/6506/
http://patchwork.linux-mips.org/patch/6507/

With those two patches applied the problem is gone.

Any idea if and when those patches may find their way upstream ?
3.14-rc4 still has the problem.

Thanks,
Guenter

Thanks a lot!

Guenter

On Sat, Feb 8, 2014 at 11:39 AM, Guenter Roeck wrote:

Hi all,

in 3.14-rc1, my mips64 qemu test fails. The image boots and then hangs.
Bisect points to commit 597ce1723 (MIPS: Support for 64-bit FP with O32
binaries).
Reverting this commit fixes the problem. Disabling MIPS_O32_FP64_SUPPORT
in my test image does _not_ solve the problem. The qemu version does not
seem
to make a difference; I tested with qemu 1.6.0 and 1.7.0.

Console log output is available in
http://server.roeck-us.net:8010/builders/qemu-mips64-master/builds/34/steps/buildcommand/logs/stdio

When the problem is seen, the emulation hangs as can be seen in the log,
and the qemu process consumes 100% CPU until it is killed.

qemu command line is

qemu-system-mips64 -kernel vmlinux -M malta -hda
core-image-minimal-qemumips64.ext3 \
-vga cirrus -usb -usbdevice wacom-tablet -no-reboot -m 128 --append
"root=/dev/hda \
rw mem=128M console=ttyS0 console=tty" -nographic

The same configuration works fine with earlier kernels. I'll be happy to
provide
the detailed configuration as well as the root file system for testing if
needed.

Obviously I have no idea if this is a problem with the patch or with qemu.
If there is anything I can do to help tracking down the problem further,
please let me know.

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: [PATCH 00/13] cross rename v4

2014-02-24 Thread J. R. Okajima


Miklos Szeredi:
> As Linus' suggestion, a whiteout is represented as a dummy char device.
> This patch uses the 0/0 device number, but the actual number doesn't matter
> as long as it doesn't conflict with a real device.

I have no objection about the char device.
But why do we need an inode for every whiteout? I'd suggest making a
hardlink. For some filesystems which don't support hardlinks, we have to
consume an inode per whiteout. But when the fs supports hardlinks, we
can re-use the inode and consume a few inodes only.


J. R. Okajima
--
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: [alsa-devel] [PATCH] ASoC: cs42888: Add codec driver support

On Tue, Feb 25, 2014 at 12:54:04AM -0300, Fabio Estevam wrote:
> Hi Nicolin,
> 
> On Tue, Feb 25, 2014 at 12:46 AM, Nicolin Chen
>  wrote:
> >> So register it from the ESAI driver then.
> >
> > Then I think I need to find a way to pass the clock to CODEC driver...
> 
> Does this example from mxs-saif help?

Absolutely yes! Thank you in advance :)

> 
> commit 7c9e6150f2e7cbd60e0bc9a19118ca1dc97d2780
> Author: Shawn Guo 
> Date:   Mon Jul 1 16:16:10 2013 +0800
> 
> ASoC: mxs: register saif mclk to clock framework
> 
> Mostly the mxs system design uses saif0 mclk output as the clock source
> of codec.  Since the mclk is implemented as a general divider with the
> saif clk as the parent clock, let's register the mclk as a basic
> clk-divider to common clock framework.  Then with it being a clock
> provdier, clk_get() call in codec driver probe function will just work.
> 
> Signed-off-by: Shawn Guo 
> Signed-off-by: Mark Brown 
> 
> 


--
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] ASoC: cs42888: Add codec driver support

On Tue, Feb 25, 2014 at 12:52:32PM +0900, Mark Brown wrote:
> On Tue, Feb 25, 2014 at 11:46:36AM +0800, Nicolin Chen wrote:
> > On Tue, Feb 25, 2014 at 12:39:29PM +0900, Mark Brown wrote:
> 
> > > So register it from the ESAI driver then.
> 
> > Then I think I need to find a way to pass the clock to CODEC driver...
> 
> Won't the normal DT mechanisms work here?  I'd expect them to, you can
> already have multiple clock providers in a system.

My knowledge should be out of date here. It's nicer to do it in that way.

Thank you.


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

Re: [alsa-devel] [PATCH] ASoC: cs42888: Add codec driver support

2014-02-24 Thread Fabio Estevam

Hi Nicolin,

On Tue, Feb 25, 2014 at 12:46 AM, Nicolin Chen
 wrote:
>> So register it from the ESAI driver then.
>
> Then I think I need to find a way to pass the clock to CODEC driver...

Does this example from mxs-saif help?

commit 7c9e6150f2e7cbd60e0bc9a19118ca1dc97d2780
Author: Shawn Guo 
Date:   Mon Jul 1 16:16:10 2013 +0800

ASoC: mxs: register saif mclk to clock framework

Mostly the mxs system design uses saif0 mclk output as the clock source
of codec.  Since the mclk is implemented as a general divider with the
saif clk as the parent clock, let's register the mclk as a basic
clk-divider to common clock framework.  Then with it being a clock
provdier, clk_get() call in codec driver probe function will just work.

Signed-off-by: Shawn Guo 
Signed-off-by: Mark Brown 
--
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] ASoC: cs42888: Add codec driver support

2014-02-24 Thread Mark Brown

On Tue, Feb 25, 2014 at 11:46:36AM +0800, Nicolin Chen wrote:
> On Tue, Feb 25, 2014 at 12:39:29PM +0900, Mark Brown wrote:

> > So register it from the ESAI driver then.

> Then I think I need to find a way to pass the clock to CODEC driver...

Won't the normal DT mechanisms work here?  I'd expect them to, you can
already have multiple clock providers in a system.


signature.asc
Description: Digital signature

Re: [PATCH V2 1/5] idle/cpuidle: Split cpuidle_idle_call main function into smaller functions

2014-02-24 Thread Preeti U Murthy

Hi Daniel,

On 02/24/2014 07:25 PM, Daniel Lezcano wrote:
> ---
>  drivers/cpuidle/cpuidle.c |  114 
> ++
>  include/linux/cpuidle.h   |   19 +++
>  2 files changed, 105 insertions(+), 28 deletions(-)
> 
> Index: cpuidle-next/drivers/cpuidle/cpuidle.c
> ===
> --- cpuidle-next.orig/drivers/cpuidle/cpuidle.c
> +++ cpuidle-next/drivers/cpuidle/cpuidle.c
> @@ -65,6 +65,26 @@ int cpuidle_play_dead(void)
>  }
> 
>  /**
> + * cpuidle_enabled - check if the cpuidle framework is ready
> + * @dev: cpuidle device for this cpu
> + * @drv: cpuidle driver for this cpu
> + *
> + * Return 0 on success, otherwise:
> + * -NODEV : the cpuidle framework is not available
> + * -EBUSY : the cpuidle framework is not initialized
> + */
> +int cpuidle_enabled(struct cpuidle_driver *drv, struct cpuidle_device *dev)
> +{
> + if (off || !initialized)
> + return -ENODEV;
> +
> + if (!drv || !dev || !dev->enabled)
> + return -EBUSY;
> +
> + return 0;
> +}
> +
> +/**
>   * cpuidle_enter_state - enter the state and update stats
>   * @dev: cpuidle device for this cpu
>   * @drv: cpuidle driver for this cpu
> @@ -108,6 +128,63 @@ int cpuidle_enter_state(struct cpuidle_d
>  }
> 
>  /**
> + * cpuidle_select - ask the cpuidle framework to choose an idle state
> + *
> + * @drv: the cpuidle driver
> + * @dev: the cpuidle device
> + *
> + * Returns the index of the idle state.
> + */
> +int cpuidle_select(struct cpuidle_driver *drv, struct cpuidle_device *dev)
> +{
> + return cpuidle_curr_governor->select(drv, dev);
> +}
> +
> +/**
> + * cpuidle_enter - enter into the specified idle state
> + *
> + * @drv:   the cpuidle driver tied with the cpu
> + * @dev:   the cpuidle device
> + * @index: the index in the idle state table
> + *
> + * Returns the index in the idle state, < 0 in case of error.
> + * The error code depends on the backend driver
> + */
> +int cpuidle_enter(struct cpuidle_driver *drv, struct cpuidle_device *dev,
> +   int index)
> +{
> + int entered_state;
> + bool broadcast = !!(drv->states[index].flags & CPUIDLE_FLAG_TIMER_STOP);
> +
> + if (broadcast)
> + clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, >cpu);
> +
> + if (cpuidle_state_is_coupled(dev, drv, index))
> + entered_state = cpuidle_enter_state_coupled(dev, drv, index);
> + else
> + entered_state = cpuidle_enter_state(dev, drv, index);
> +
> + if (broadcast)
> + clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, >cpu);
> +
> + return entered_state;
> +}
> +
> +/**
> + * cpuidle_reflect - tell the underlying governor what was the state
> + * we were in
> + *
> + * @dev  : the cpuidle device
> + * @index: the index in the idle state table
> + *
> + */
> +void cpuidle_reflect(struct cpuidle_device *dev, int index)
> +{
> + if (cpuidle_curr_governor->reflect)
> + cpuidle_curr_governor->reflect(dev, index);
> +}
> +
> +/**
>   * cpuidle_idle_call - the main idle loop
>   *
>   * NOTE: no locks or semaphores should be used here
> @@ -116,51 +193,32 @@ int cpuidle_enter_state(struct cpuidle_d
>  int cpuidle_idle_call(void)
>  {
>   struct cpuidle_device *dev = __this_cpu_read(cpuidle_devices);
> - struct cpuidle_driver *drv;
> + struct cpuidle_driver *drv = cpuidle_get_cpu_driver(dev);
>   int next_state, entered_state;
> - bool broadcast;
> 
> - if (off || !initialized)
> - return -ENODEV;
> -
> - /* check if the device is ready */
> - if (!dev || !dev->enabled)
> - return -EBUSY;
> -
> - drv = cpuidle_get_cpu_driver(dev);
> + next_state = cpuidle_enabled(drv, dev);

Accepting the return of cpuidle_enabled() into a parameter named
"next_state" looks misleading. You are not returning any idle state. You
could use ret/enabled to accept the return value here perhaps?

> + if (next_state < 0)
> + return next_state;
> 
>   /* ask the governor for the next state */
> - next_state = cpuidle_curr_governor->select(drv, dev);
> + next_state = cpuidle_select(drv, dev);
> +
>   if (need_resched()) {
>   dev->last_residency = 0;
>   /* give the governor an opportunity to reflect on the outcome */
> - if (cpuidle_curr_governor->reflect)
> - cpuidle_curr_governor->reflect(dev, next_state);
> + cpuidle_reflect(dev, next_state);
>   local_irq_enable();
>   return 0;
>   }
> 
>   trace_cpu_idle_rcuidle(next_state, dev->cpu);
> 
> - broadcast = !!(drv->states[next_state].flags & CPUIDLE_FLAG_TIMER_STOP);
> -
> - if (broadcast)
> - clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, >cpu);
> -
> - if (cpuidle_state_is_coupled(dev, drv, next_state))
> - entered_state = cpuidle_enter_state_coupled(dev, drv,
> -

Re: perf_fuzzer compiled for x32 causes reboot

2014-02-24 Thread H. Peter Anvin

On 02/24/2014 11:30 AM, Peter Zijlstra wrote:
> On Mon, Feb 24, 2014 at 02:13:29PM -0500, Steven Rostedt wrote:
>> Ah, and x86_64 saves off the cr2 register when entering NMI and restores
>> it before returning. But it seems to be missing from the i386 code.
> 
> arch/x86/kernel/nmi.c:
> 
> #define nmi_nesting_preprocess(regs)  \
>   do {\
>   if (this_cpu_read(nmi_state) != NMI_NOT_RUNNING) {  \
>   this_cpu_write(nmi_state, NMI_LATCHED); \
>   return; \
>   }   \
>   this_cpu_write(nmi_state, NMI_EXECUTING);   \
>   this_cpu_write(nmi_cr2, read_cr2());\
>   } while (0);\
>   nmi_restart:
> 
> #define nmi_nesting_postprocess() \
>   do {\
>   if (unlikely(this_cpu_read(nmi_cr2) != read_cr2())) \
>   write_cr2(this_cpu_read(nmi_cr2));  \
>   if (this_cpu_dec_return(nmi_state)) \
>   goto nmi_restart;   \
>   } while (0)
> 
> That very much looks like saving/restoring CR2 to me.
> 
> FWIW; I hate how the x86_64 and i386 versions of this NMI nesting magic
> are so completely different.

Is there any way that nmi_cr2 can end up getting overwritten by multiple
nestings of some kind?  I would have thought it would have made more
sense to spill cr2 onto the stack after the stack has been properly set up.

-hpa


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

Re: [PATCH] ASoC: cs42888: Add codec driver support

On Tue, Feb 25, 2014 at 12:39:29PM +0900, Mark Brown wrote:
> On Tue, Feb 25, 2014 at 11:13:14AM +0800, Nicolin Chen wrote:
> > On Tue, Feb 25, 2014 at 12:09:47PM +0900, Mark Brown wrote:
> 
> > > We should be able to arrange to have the ESAI be a clock provider
> > > shouldn't we?  If the clocks need to interface to other things (and they
> > > do) then we should be able to use the standard interface we have to
> > > clocks.
> 
> > Excuse me, I think I just don't get the approach how to use clock API to
> > standardize the MCLK derived from ESAI IP: it's surely not a fixed-clock
> > so we couldn't register in DT and it's not SoC internal clock which means
> > we couldn't register it in the SoC clock driver either.
> 
> > Could you please shed me some light on it?
> 
> So register it from the ESAI driver then.

Then I think I need to find a way to pass the clock to CODEC driver...

Anyway, I'll try it first. Thank you.


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

Re: [PATCH] ASoC: cs42888: Add codec driver support

2014-02-24 Thread Mark Brown

On Tue, Feb 25, 2014 at 11:13:14AM +0800, Nicolin Chen wrote:
> On Tue, Feb 25, 2014 at 12:09:47PM +0900, Mark Brown wrote:

> > We should be able to arrange to have the ESAI be a clock provider
> > shouldn't we?  If the clocks need to interface to other things (and they
> > do) then we should be able to use the standard interface we have to
> > clocks.

> Excuse me, I think I just don't get the approach how to use clock API to
> standardize the MCLK derived from ESAI IP: it's surely not a fixed-clock
> so we couldn't register in DT and it's not SoC internal clock which means
> we couldn't register it in the SoC clock driver either.

> Could you please shed me some light on it?

So register it from the ESAI driver then.


signature.asc
Description: Digital signature

Re: [PATCH V2 1/5] idle/cpuidle: Split cpuidle_idle_call main function into smaller functions

2014-02-24 Thread Preeti U Murthy

Hi Peter, Daniel,

On 02/24/2014 08:46 PM, Peter Zijlstra wrote:
> On Mon, Feb 24, 2014 at 04:12:07PM +0100, Daniel Lezcano wrote:
>> On 02/24/2014 04:00 PM, Peter Zijlstra wrote:
>>>
>>>
>>> None of this actually applies :/ I'm having major conflicts in
>>> driveres/cpuidle/cpuidle.c.
>>
>> Ok, except if I am missing something, the patchset is based on top of
>> tip/sched/core (commit 6990566).
> 
> Ah! So the below commit from the timers/core branch is in the way.

I had informed Daniel earlier of a possible conflict here. Anyway, I
think this patch should not move the BROADCAST_ENTER notification
out of the cpuidle_idle_call(). The reasons are:

1. Even if the patch handles the failed call to BROADCAST_ENTER in
cpuidle_enter(), you would have traced an entry into an idle state earlier
to this. If the entry into broadcast fails we should not be tracing either.

2. Moving the trace after the cpuidle_enter() call is wrong.

So I would suggest the patch at the end of this mail as the alternative
to this one so as to get around the patching conflict.

Thanks

Regards
Preeti U Murthy

> 
> Thomas, Ingo, how do we go about solving this sched/core vs timers/core
> conflict?
> 
> ---
> 
> # git log 6990566..tip/master drivers/cpuidle/
> commit 2f60b8ae0b2a006e4d3452e57ea98b59ce985d14
> Merge: 9eaf844efc23 849401b66d30
> Author: Ingo Molnar 
> Date:   Sat Feb 22 18:52:27 2014 +0100
> 
> Merge branch 'timers/core'
> 
> commit ba8f20c2eb4158a443e9d6a909aee5010efa0c69
> Author: Preeti U Murthy 
> Date:   Fri Feb 7 13:36:52 2014 +0530
> 
> cpuidle: Handle clockevents_notify(BROADCAST_ENTER) failure
> 
> Some archs set the CPUIDLE_FLAG_TIMER_STOP flag for idle states in which 
> the
> local timers stop. The cpuidle_idle_call() currently handles such idle 
> states
> by calling into the broadcast framework so as to wakeup CPUs at their next
> wakeup event. With the hrtimer mode of broadcast, the BROADCAST_ENTER call
> into the broadcast frameowork can fail for archs that do not have an 
> external
> clock device to handle wakeups and the CPU in question has thus to be made
> the stand by CPU. This patch handles such cases by failing the call into
> cpuidle so that the arch can take some default action. The arch will 
> certainly
> not enter a similar idle state because a failed cpuidle call will also 
> implicitly
> indicate that the broadcast framework has not registered this CPU to be 
> woken up.
> Hence we are safe if we fail the cpuidle call.
> 
> In the process move the functions that trace idle statistics just before 
> and
> after the entry and exit into idle states respectively. In other
> scenarios where the call to cpuidle fails, we end up not tracing idle
> entry and exit since a decision on an idle state could not be taken. 
> Similarly
> when the call to broadcast framework fails, we skip tracing idle 
> statistics
> because we are in no further position to take a decision on an alternative
> idle state to enter into.
> 
> Signed-off-by: Preeti U Murthy 
> Cc: deep...@linux.vnet.ibm.com
> Cc: paul...@linux.vnet.ibm.com
> Cc: fweis...@gmail.com
> Cc: pau...@samba.org
> Cc: srivatsa.b...@linux.vnet.ibm.com
> Cc: sva...@linux.vnet.ibm.com
> Cc: pet...@infradead.org
> Cc: b...@kernel.crashing.org
> Acked-by: Rafael J. Wysocki 
> Cc: linuxppc-...@lists.ozlabs.org
> Link: 
> http://lkml.kernel.org/r/20140207080652.17187.66344.st...@preeti.in.ibm.com
> Signed-off-by: Thomas Gleixner 
> 

Signed-off-by: Preeti U Murthy 
---
 drivers/cpuidle/cpuidle.c |   98 -
 include/linux/cpuidle.h   |   19 +
 2 files changed, 98 insertions(+), 19 deletions(-)

diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 09d05ab..a58c15b 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -65,6 +65,26 @@ int cpuidle_play_dead(void)
 }
 
 /**
+ * cpuidle_enabled - check if the cpuidle framework is ready
+ * @dev: cpuidle device for this cpu
+ * @drv: cpuidle driver for this cpu
+ *
+ * Return 0 on success, otherwise:
+ * -NODEV : the cpuidle framework is not available
+ * -EBUSY : the cpuidle framework is not initialized
+ */
+int cpuidle_enabled(struct cpuidle_driver *drv, struct cpuidle_device *dev)
+{
+   if (off || !initialized)
+   return -ENODEV;
+
+   if (!drv || !dev || !dev->enabled)
+   return -EBUSY;
+
+   return 0;
+}
+
+/**
  * cpuidle_enter_state - enter the state and update stats
  * @dev: cpuidle device for this cpu
  * @drv: cpuidle driver for this cpu
@@ -108,6 +128,56 @@ int cpuidle_enter_state(struct cpuidle_device *dev, struct 
cpuidle_driver *drv,
 }
 
 /**
+ * cpuidle_select - ask the cpuidle framework to choose an idle state
+ *
+ * @drv: the cpuidle driver
+ * @dev: the cpuidle device
+ *
+ * Returns the index of the idle state.
+ */
+int

Re: [PATCH v4 0/3] qspinlock: Introducing a 4-byte queue spinlock

2014-02-24 Thread Waiman Long


On 02/22/2014 11:56 AM, Ingo Molnar wrote:

* Peter Zijlstra  wrote:


On Mon, Feb 17, 2014 at 02:47:03PM -0800, H. Peter Anvin wrote:

This is starting to look good, so I have pulled it into
tip:x86/spinlocks to start give it some testing mileage.

Its still atrociously ugly code please drop it.

Fair enough - I've excluded it from tip:master for now, until the
uglies get resolved.

Waiman: please address PeterZ's feedback.

Thanks,

Ingo


I am trying to address PeterZ's feedback while adding 
para-virtualization support right now. I will have a new version ready 
sometime this week.


-Longman
--
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 02/11] perf core: export swevent hrtimer helpers

On Fri, 2014-14-02 at 22:02:06 UTC, Cody P Schafer wrote:
> Export the swevent hrtimer helpers currently only used in events/core.c
> to allow the addition of architecture specific sw-like pmus.

Peter, Ingo, can we get your ACK on this please?

cheers


> Signed-off-by: Cody P Schafer 
> ---
>  include/linux/perf_event.h | 5 -
>  kernel/events/core.c   | 8 
>  2 files changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index 2702e91..24378a9 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -559,7 +559,10 @@ extern void perf_pmu_migrate_context(struct pmu *pmu,
>   int src_cpu, int dst_cpu);
>  extern u64 perf_event_read_value(struct perf_event *event,
>u64 *enabled, u64 *running);
> -
> +extern void perf_swevent_init_hrtimer(struct perf_event *event);
> +extern void perf_swevent_start_hrtimer(struct perf_event *event);
> +extern void perf_swevent_cancel_hrtimer(struct perf_event *event);
> +extern int perf_swevent_event_idx(struct perf_event *event);
>  
>  struct perf_sample_data {
>   u64 type;
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 56003c6..feb0347 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -5816,7 +5816,7 @@ static int perf_swevent_init(struct perf_event *event)
>   return 0;
>  }
>  
> -static int perf_swevent_event_idx(struct perf_event *event)
> +int perf_swevent_event_idx(struct perf_event *event)
>  {
>   return 0;
>  }
> @@ -6045,7 +6045,7 @@ static enum hrtimer_restart perf_swevent_hrtimer(struct 
> hrtimer *hrtimer)
>   return ret;
>  }
>  
> -static void perf_swevent_start_hrtimer(struct perf_event *event)
> +void perf_swevent_start_hrtimer(struct perf_event *event)
>  {
>   struct hw_perf_event *hwc = >hw;
>   s64 period;
> @@ -6067,7 +6067,7 @@ static void perf_swevent_start_hrtimer(struct 
> perf_event *event)
>   HRTIMER_MODE_REL_PINNED, 0);
>  }
>  
> -static void perf_swevent_cancel_hrtimer(struct perf_event *event)
> +void perf_swevent_cancel_hrtimer(struct perf_event *event)
>  {
>   struct hw_perf_event *hwc = >hw;
>  
> @@ -6079,7 +6079,7 @@ static void perf_swevent_cancel_hrtimer(struct 
> perf_event *event)
>   }
>  }
>  
> -static void perf_swevent_init_hrtimer(struct perf_event *event)
> +void perf_swevent_init_hrtimer(struct perf_event *event)
>  {
>   struct hw_perf_event *hwc = >hw;
>  
> -- 
> 1.8.5.4
> 
> ___
> Linuxppc-dev mailing list
> linuxppc-...@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
> 
> 
--
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 01/11] perf: add PMU_RANGE_ATTR() helper for use by sw-like pmus

On Fri, 2014-14-02 at 22:02:05 UTC, Cody P Schafer wrote:
> Add PMU_RANGE_ATTR() and PMU_RANGE_RESV() (for reserved areas) which
> generate functions to extract the relevent bits from
> event->attr.config{,1,2} for use by sw-like pmus where the
> 'config{,1,2}' values don't map directly to hardware registers.
> 
> Signed-off-by: Cody P Schafer 
> ---
>  include/linux/perf_event.h | 17 +
>  1 file changed, 17 insertions(+)
> 
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index e56b07f..2702e91 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -871,4 +871,21 @@ _name##_show(struct device *dev, 
> \
>   \
>  static struct device_attribute format_attr_##_name = __ATTR_RO(_name)
>  
> +#define PMU_RANGE_ATTR(name, attr_var, bit_start, bit_end)   \
> +PMU_FORMAT_ATTR(name, #attr_var ":" #bit_start "-" #bit_end);
> \
> +PMU_RANGE_RESV(name, attr_var, bit_start, bit_end)
> +
> +#define PMU_RANGE_RESV(name, attr_var, bit_start, bit_end)   \
> +static u64 event_get_##name##_max(void)  
> \
> +{\
> + int bits = (bit_end) - (bit_start) + 1; \
> + return ((0x1ULL << (bits - 1ULL)) - 1ULL) | \
> + (0xFULL << (bits - 4ULL));  \
> +}\
> +static u64 event_get_##name(struct perf_event *event)
> \
> +{\
> + return (event->attr.attr_var >> (bit_start)) &  \
> + event_get_##name##_max();   \
> +}

I still don't like the names.

EVENT_GETTER_AND_FORMAT()
EVENT_RESERVED()

?

It's not clear to me the max routine is useful in general. Can't we just do:

> +#define EVENT_RESERVED(name, attr_var, bit_start, bit_end)   \
> +static u64 event_get_##name(struct perf_event *event)\
> +{\
> + return (event->attr.attr_var >> (bit_start)) &  \
> + ((0x1ULL << ((bit_end) - (bit_start) + 1)) - 1ULL); \
> +}


cheers
--
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 05/11] powerpc: add hv_gpci interface header

On Fri, 2014-14-02 at 22:02:09 UTC, Cody P Schafer wrote:
> "H_GetPerformanceCounterInfo" (refered to as hv_gpci or just gpci from
> here on) is an interface to retrieve specific performance counters and
> other data from the hypervisor. All outputs have a fixed format (and
> are represented as structs in this patch).

I still see unused stuff in here, can you strip it back to just what we need.
Same goes for the next patch.

cheers
--
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/11] powerpc: add a shared interface to get gpci version and capabilities

[PATCH v2 07/11] powerpc: add a shared interface to get gpci version and 
capabilities

All the patches that touch perf should be "powerpc/perf: foo"

On Fri, 2014-14-02 at 22:02:11 UTC, Cody P Schafer wrote:
> ...

I realise this is a fairly small patch but a changelog is still nice. You could
for example mention that we don't currently use .ga, .expanded or .lab but
we're adding the logic anyway because ...


> Signed-off-by: Cody P Schafer 
> ---
>  arch/powerpc/perf/hv-common.c | 39 +++
>  arch/powerpc/perf/hv-common.h | 17 +
>  2 files changed, 56 insertions(+)
>  create mode 100644 arch/powerpc/perf/hv-common.c
>  create mode 100644 arch/powerpc/perf/hv-common.h
> 
> diff --git a/arch/powerpc/perf/hv-common.c b/arch/powerpc/perf/hv-common.c
> new file mode 100644
> index 000..47e02b3
> --- /dev/null
> +++ b/arch/powerpc/perf/hv-common.c
> @@ -0,0 +1,39 @@
> +#include 
> +#include 
> +
> +#include "hv-gpci.h"
> +#include "hv-common.h"
> +
> +unsigned long hv_perf_caps_get(struct hv_perf_caps *caps)
> +{
> + unsigned long r;
> + struct p {
> + struct hv_get_perf_counter_info_params params;
> + struct cv_system_performance_capabilities caps;
> + } __packed __aligned(sizeof(uint64_t));
> +
> + struct p arg = {
> + .params = {
> + .counter_request = cpu_to_be32(
> + CIR_SYSTEM_PERFORMANCE_CAPABILITIES),
> + .starting_index = cpu_to_be32(-1),
> + .counter_info_version_in = 0,
> + }
> + };
> +
> + r = plpar_hcall_norets(H_GET_PERF_COUNTER_INFO,
> +virt_to_phys(), sizeof(arg));
> +
> + if (r)
> + return r;
> +
> + pr_devel("capability_mask: 0x%x\n", arg.caps.capability_mask);
> +
> + caps->version = arg.params.counter_info_version_out;
> + caps->collect_privileged = !!arg.caps.perf_collect_privileged;
> + caps->ga = !!(arg.caps.capability_mask & CV_CM_GA);
> + caps->expanded = !!(arg.caps.capability_mask & CV_CM_EXPANDED);
> + caps->lab = !!(arg.caps.capability_mask & CV_CM_LAB);
> +
> + return r;
> +}
> diff --git a/arch/powerpc/perf/hv-common.h b/arch/powerpc/perf/hv-common.h
> new file mode 100644
> index 000..7e615bd
> --- /dev/null
> +++ b/arch/powerpc/perf/hv-common.h
> @@ -0,0 +1,17 @@
> +#ifndef LINUX_POWERPC_PERF_HV_COMMON_H_
> +#define LINUX_POWERPC_PERF_HV_COMMON_H_
> +
> +#include 
> +
> +struct hv_perf_caps {
> + u16 version;
> + u16 collect_privileged:1,
> + ga:1,
> + expanded:1,
> + lab:1,
> + unused:12;
> +};
> +
> +unsigned long hv_perf_caps_get(struct hv_perf_caps *caps);
> +
> +#endif
> -- 
> 1.8.5.4
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 08/11] powerpc/perf: add support for the hv gpci (get performance counter info) interface

On Fri, 2014-14-02 at 22:02:12 UTC, Cody P Schafer wrote:
> This provides a basic link between perf and hv_gpci. Notably, it does
> not yet support transactions and does not list any events (they can
> still be manually composed).

Can you explain how the HV_CAPS stuff ends up looking.

I'm not against adding it, but I'd like to understand how we expect it to be
used a bit better.

cheers

> diff --git a/arch/powerpc/perf/hv-gpci.c b/arch/powerpc/perf/hv-gpci.c
> new file mode 100644
> index 000..1f5d96d
> --- /dev/null
> +++ b/arch/powerpc/perf/hv-gpci.c
> +
> +static struct pmu h_gpci_pmu = {
> + .task_ctx_nr = perf_invalid_context,
> +
> + .name = "hv_gpci",
> + .attr_groups = attr_groups,
> + .event_init  = h_gpci_event_init,
> + .add = h_gpci_event_add,
> + .del = h_gpci_event_del,
 = h_gpci_event_stop,

> + .start   = h_gpci_event_start,
> + .stop= h_gpci_event_stop,
> + .read= h_gpci_event_read,
 = h_gpci_event_update

> + .event_idx = perf_swevent_event_idx,
> +};


--
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] ASoC: cs42888: Add codec driver support

On Tue, Feb 25, 2014 at 12:09:47PM +0900, Mark Brown wrote:
> On Tue, Feb 25, 2014 at 10:38:41AM +0800, Nicolin Chen wrote:
> 
> > Hmm...my words might not be so clear last time: we have to handle the 
> > dividers
> > of ESAI in ESAI driver because the dividers is in the ESAI's IP, not in the 
> > SoC
> > clock controlling unit. So it's hard to get them visible in the clock tree.
> 
> We should be able to arrange to have the ESAI be a clock provider
> shouldn't we?  If the clocks need to interface to other things (and they
> do) then we should be able to use the standard interface we have to
> clocks.

Excuse me, I think I just don't get the approach how to use clock API to
standardize the MCLK derived from ESAI IP: it's surely not a fixed-clock
so we couldn't register in DT and it's not SoC internal clock which means
we couldn't register it in the SoC clock driver either.

Could you please shed me some light on it?

Thank you,
Nicolin 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: [PATCH v2 04/11] powerpc: add hvcalls for 24x7 and gpci (get performance counter info)

On Fri, 2014-14-02 at 22:02:08 UTC, Cody P Schafer wrote:
> Signed-off-by: Cody P Schafer 
> ---
>  arch/powerpc/include/asm/hvcall.h | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/powerpc/include/asm/hvcall.h 
> b/arch/powerpc/include/asm/hvcall.h
> index d8b600b..652f7e4 100644
> --- a/arch/powerpc/include/asm/hvcall.h
> +++ b/arch/powerpc/include/asm/hvcall.h
> @@ -274,6 +274,11 @@
>  /* Platform specific hcalls, used by KVM */
>  #define H_RTAS   0xf000
>  
> +/* "Platform specific hcalls", provided by PHYP */
> +#define H_GET_24X7_CATALOG_PAGE 0xF078
> +#define H_GET_24X7_DATA  0xF07C
> +#define H_GET_PERF_COUNTER_INFO 0xF080

Some tabs some spaces, use tabs.

cheers
--
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 10/11] powerpc/perf: add kconfig option for hypervisor provided counters

On Fri, 2014-14-02 at 22:02:14 UTC, Cody P Schafer wrote:
> Signed-off-by: Cody P Schafer 
> ---
>  arch/powerpc/perf/Makefile | 2 ++
>  arch/powerpc/platforms/Kconfig.cputype | 6 ++
>  2 files changed, 8 insertions(+)
> 
> diff --git a/arch/powerpc/perf/Makefile b/arch/powerpc/perf/Makefile
> index 60d71ee..f9c083a 100644
> --- a/arch/powerpc/perf/Makefile
> +++ b/arch/powerpc/perf/Makefile
> @@ -11,5 +11,7 @@ obj32-$(CONFIG_PPC_PERF_CTRS)   += mpc7450-pmu.o
>  obj-$(CONFIG_FSL_EMB_PERF_EVENT) += core-fsl-emb.o
>  obj-$(CONFIG_FSL_EMB_PERF_EVENT_E500) += e500-pmu.o e6500-pmu.o
>  
> +obj-$(CONFIG_HV_PERF_CTRS) += hv-24x7.o hv-gpci.o hv-common.o
> +
>  obj-$(CONFIG_PPC64)  += $(obj64-y)
>  obj-$(CONFIG_PPC32)  += $(obj32-y)
> diff --git a/arch/powerpc/platforms/Kconfig.cputype 
> b/arch/powerpc/platforms/Kconfig.cputype
> index 434fda3..dcc67cd 100644
> --- a/arch/powerpc/platforms/Kconfig.cputype
> +++ b/arch/powerpc/platforms/Kconfig.cputype
> @@ -364,6 +364,12 @@ config PPC_PERF_CTRS
> help
>   This enables the powerpc-specific perf_event back-end.
>  
> +config HV_PERF_CTRS
> +   def_bool y

This was bool, why did you change it?

> +   depends on PERF_EVENTS && PPC_HAVE_PMU_SUPPORT

Should be:

depends on PERF_EVENTS && PPC_PSERIES

> +   help
> + Enable access to perf counters provided by the hypervisor
> +

cheers
--
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 03/11] sysfs: create bin_attributes under the requested group

On Fri, 2014-14-02 at 22:02:07 UTC, Cody P Schafer wrote:
> bin_attributes created/updated in create_files() (such as those listed
> via (struct device).attribute_groups) were not placed under the
> specified group, and instead appeared in the base kobj directory.
> 
> Fix this by making bin_attributes use creating code similar to normal
> attributes.
> 
> A quick grep shows that no one is using bin_attrs in a named attribute
> group yet, so we can do this without breaking anything in usespace.
> 
> Note that I do not add is_visible() support to
> bin_attributes, though that could be done as well.
> 
> Signed-off-by: Cody P Schafer 

Greg has already taken this, so we'll consider that as good as an ack from him,
unless he wants to give us one.

cheers
--
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 09/11] powerpc/perf: add support for the hv 24x7 interface