Re: [RFC PATCH 5/7] x86/mm/fault: hook up SCI verification

2019-04-27 Thread Mike Rapoport
On Fri, Apr 26, 2019 at 09:42:23AM +0200, Peter Zijlstra wrote:
> On Fri, Apr 26, 2019 at 12:45:52AM +0300, Mike Rapoport wrote:
> > If a system call runs in isolated context, it's accesses to kernel code and
> > data will be verified by SCI susbsytem.
> > 
> > Signed-off-by: Mike Rapoport 
> > ---
> >  arch/x86/mm/fault.c | 28 
> >  1 file changed, 28 insertions(+)
> 
> There's a distinct lack of touching do_double_fault(). It appears to me
> that you'll instantly trigger #DF when you #PF, because the #PF handler
> itself will not be able to run.

The #PF handler is able to run. On interrupt/error entry the cr3 is
switched to the full kernel page tables, pretty much like PTI does for
user <-> kernel transitions. It's in the patch 3.
 
> And then obviously you have to be very careful to make sure #DF can,
> _at_all_times_ run, otherwise you'll tripple-fault and we all know what
> that does.
> 

-- 
Sincerely yours,
Mike.



Re: [RFC PATCH 2/7] x86/sci: add core implementation for system call isolation

2019-04-27 Thread Mike Rapoport
On Fri, Apr 26, 2019 at 09:49:56AM +0200, Peter Zijlstra wrote:
> On Fri, Apr 26, 2019 at 12:45:49AM +0300, Mike Rapoport wrote:
> > The initial SCI implementation allows access to any kernel data, but it
> > limits access to the code in the following way:
> > * calls and jumps to known code symbols without offset are allowed
> > * calls and jumps into a known symbol with offset are allowed only if that
> > symbol was already accessed and the offset is in the next page
> > * all other code access are blocked
> 
> So if you have a large function and an in-function jump skips a page
> you're toast.

Right :(
 
> Why not employ the instruction decoder we have and unconditionally allow
> all direct JMP/CALL but verify indirect JMP/CALL and RET ?

Apparently I didn't dig deep enough to find the instruction decoder :)
Surely I can use it.

> Anyway, I'm fearing the overhead of this one, this cannot be fast.

Well, I think that the verification itself is not what will slow things
down the most. IMHO, the major overhead is coming from cr3 switch.

-- 
Sincerely yours,
Mike.



[PATCH] quota: set init_needed flag only when successfully getting dquot

2019-04-27 Thread Chengguang Xu
Set init_needed flag only when successfully getting dquot,
so that we can skip unnecessary subsequent operation.

Signed-off-by: Chengguang Xu 
---
 fs/quota/dquot.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/fs/quota/dquot.c b/fs/quota/dquot.c
index fc20e06c56ba..8d4ce2a2b5c8 100644
--- a/fs/quota/dquot.c
+++ b/fs/quota/dquot.c
@@ -1449,8 +1449,6 @@ static int __dquot_initialize(struct inode *inode, int 
type)
if (!sb_has_quota_active(sb, cnt))
continue;

-   init_needed = 1;
-
switch (cnt) {
case USRQUOTA:
qid = make_kqid_uid(inode->i_uid);
@@ -1475,6 +1473,9 @@ static int __dquot_initialize(struct inode *inode, int 
type)
dquot = NULL;
}
got[cnt] = dquot;
+
+   if (got[cnt])
+   init_needed = 1;
}

/* All required i_dquot has been initialized */
--
2.20.1



Re: [GIT PULL] Ceph fixes for 5.1-rc7

2019-04-27 Thread Al Viro
On Fri, Apr 26, 2019 at 01:30:53PM -0400, Jeff Layton wrote:

> > I _probably_ would take allocation out of the loop (e.g. make it
> > __getname(), called unconditionally) and turned it into the
> > d_path.c-style read_seqbegin_or_lock()/need_seqretry()/done_seqretry()
> > loop, so that the first pass would go under rcu_read_lock(), while
> > the second (if needed) would just hold rename_lock exclusive (without
> > bumping the refcount).  But that's a matter of (theoretical) livelock
> > avoidance, not the locking correctness for ->d_name accesses.
> > 
> 
> Yeah, that does sound better. I want to think about this code a bit

FWIW, is there any reason to insist that the pathname is put into the
beginning of the buffer?  I mean, instead of path + pathlen we might
return path + offset, with the pathname going from path + offset to
path + PATH_MAX - 1 inclusive, with path being the thing eventually
freed.

It's easier to build the string backwards, seeing that we are walking
from leaf to root...


[PATCH next v2 1/2] dmaengine: bcm-sba-raid: Use dev_get_drvdata()

2019-04-27 Thread Kefeng Wang
Using dev_get_drvdata directly.

Cc: Vinod Koul 
Cc: dmaeng...@vger.kernel.org
Signed-off-by: Kefeng Wang 
---
 drivers/dma/bcm-sba-raid.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/dma/bcm-sba-raid.c b/drivers/dma/bcm-sba-raid.c
index 72878ac5c78d..fa81d0177765 100644
--- a/drivers/dma/bcm-sba-raid.c
+++ b/drivers/dma/bcm-sba-raid.c
@@ -1459,8 +1459,7 @@ static void sba_receive_message(struct mbox_client *cl, 
void *msg)
 
 static int sba_debugfs_stats_show(struct seq_file *file, void *offset)
 {
-   struct platform_device *pdev = to_platform_device(file->private);
-   struct sba_device *sba = platform_get_drvdata(pdev);
+   struct sba_device *sba = dev_get_drvdata(file->private);
 
/* Write stats in file */
sba_write_stats_in_seqfile(sba, file);
-- 
2.20.1



[PATCH next v2 2/2] dmaengine: nbpfaxi: Use dev_get_drvdata()

2019-04-27 Thread Kefeng Wang
Using dev_get_drvdata directly.

Cc: Vinod Koul 
Cc: dmaeng...@vger.kernel.org
Signed-off-by: Kefeng Wang 
---
 drivers/dma/nbpfaxi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/nbpfaxi.c b/drivers/dma/nbpfaxi.c
index a67b292190f4..594409a6e975 100644
--- a/drivers/dma/nbpfaxi.c
+++ b/drivers/dma/nbpfaxi.c
@@ -1491,14 +1491,14 @@ MODULE_DEVICE_TABLE(platform, nbpf_ids);
 #ifdef CONFIG_PM
 static int nbpf_runtime_suspend(struct device *dev)
 {
-   struct nbpf_device *nbpf = 
platform_get_drvdata(to_platform_device(dev));
+   struct nbpf_device *nbpf = dev_get_drvdata(dev);
clk_disable_unprepare(nbpf->clk);
return 0;
 }
 
 static int nbpf_runtime_resume(struct device *dev)
 {
-   struct nbpf_device *nbpf = 
platform_get_drvdata(to_platform_device(dev));
+   struct nbpf_device *nbpf = dev_get_drvdata(dev);
return clk_prepare_enable(nbpf->clk);
 }
 #endif
-- 
2.20.1



[PATCH 3/6] lib/bitmap: make bitmap_parse_user a wrapper on bitmap_parse

2019-04-27 Thread Yury Norov
Currently we parse user data byte after byte which leads to
overcomplicating of parsing algorithm. There are no performance
critical users of bitmap_parse_user(), and so we can duplicate
user data to kernel buffer and simply call bitmap_parselist().
This rework lets us unify and simplify bitmap_parse() and
bitmap_parse_user(), which is done in the following patch.

Signed-off-by: Yury Norov 
---
 lib/bitmap.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/lib/bitmap.c b/lib/bitmap.c
index f235434df87b..300732031fad 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -434,22 +434,22 @@ EXPORT_SYMBOL(__bitmap_parse);
  *then it must be terminated with a \0.
  * @maskp: pointer to bitmap array that will contain result.
  * @nmaskbits: size of bitmap, in bits.
- *
- * Wrapper for __bitmap_parse(), providing it with user buffer.
- *
- * We cannot have this as an inline function in bitmap.h because it needs
- * linux/uaccess.h to get the access_ok() declaration and this causes
- * cyclic dependencies.
  */
 int bitmap_parse_user(const char __user *ubuf,
unsigned int ulen, unsigned long *maskp,
int nmaskbits)
 {
-   if (!access_ok(ubuf, ulen))
-   return -EFAULT;
-   return __bitmap_parse((const char __force *)ubuf,
-   ulen, 1, maskp, nmaskbits);
+   char *buf;
+   int ret;
 
+   buf = memdup_user_nul(ubuf, ulen);
+   if (IS_ERR(buf))
+   return PTR_ERR(buf);
+
+   ret = bitmap_parse(buf, ulen, maskp, nmaskbits);
+
+   kfree(buf);
+   return ret;
 }
 EXPORT_SYMBOL(bitmap_parse_user);
 
-- 
2.17.1



[PATCH 5/6] lib: add test for bitmap_parse()

2019-04-27 Thread Yury Norov
The test is derived from bitmap_parselist()

Signed-off-by: Yury Norov 
---
 lib/test_bitmap.c | 102 +-
 1 file changed, 101 insertions(+), 1 deletion(-)

diff --git a/lib/test_bitmap.c b/lib/test_bitmap.c
index d3a501f2a81a..99ad6c35d038 100644
--- a/lib/test_bitmap.c
+++ b/lib/test_bitmap.c
@@ -205,7 +205,8 @@ static void __init test_copy(void)
expect_eq_pbl("0-108,128-1023", bmap2, 1024);
 }
 
-#define PARSE_TIME 0x1
+#define PARSE_TIME 0x1
+#define NO_LEN 0x2
 
 struct test_bitmap_parselist{
const int errno;
@@ -328,6 +329,93 @@ static void __init __test_bitmap_parselist(int is_user)
}
 }
 
+static const unsigned long parse_test[] __initconst = {
+   BITMAP_FROM_U64(0),
+   BITMAP_FROM_U64(1),
+   BITMAP_FROM_U64(0xdeadbeef),
+   BITMAP_FROM_U64(0x1ULL),
+};
+
+static const unsigned long parse_test2[] __initconst = {
+   BITMAP_FROM_U64(0x1ULL), BITMAP_FROM_U64(0xdeadbeef),
+   BITMAP_FROM_U64(0x1ULL), BITMAP_FROM_U64(0xbaadf00ddeadbeef),
+   BITMAP_FROM_U64(0x1ULL), BITMAP_FROM_U64(0x0badf00ddeadbeef),
+};
+
+static const struct test_bitmap_parselist parse_tests[] __initconst = {
+   {0, "", _test[0 * step], 32, 0},
+   {0, " ",_test[0 * step], 32, 0},
+   {0, "0",_test[0 * step], 32, 0},
+   {0, "0\n",  _test[0 * step], 32, 0},
+   {0, "1",_test[1 * step], 32, 0},
+   {0, "deadbeef", _test[2 * step], 32, 0},
+   {0, "1,0",  _test[3 * step], 33, 0},
+   {0, "deadbeef,\n,0,1",  _test[2 * step], 96, 0},
+
+   {0, "deadbeef,1,0", _test2[0 * 2 * step], 96, 0},
+   {0, "baadf00d,deadbeef,1,0",_test2[1 * 2 * step], 128, 0},
+   {0, "badf00d,deadbeef,1,0", _test2[2 * 2 * step], 124, 0},
+   {0, "badf00d,deadbeef,1,0", _test2[2 * 2 * step], 124, 
NO_LEN},
+   {0, "  badf00d,deadbeef,1,0  ", _test2[2 * 2 * step], 124, 0},
+   {0, " , badf00d,deadbeef,1,0 , ",   _test2[2 * 2 * step], 
124, 0},
+   {0, " , badf00d, ,, ,,deadbeef,1,0 , ", _test2[2 * 2 * step], 
124, 0},
+
+   {-EINVAL,"goodfood,deadbeef,1,0",   NULL, 128, 0},
+   {-EOVERFLOW, "3,0", NULL, 33, 0},
+   {-EOVERFLOW, "123badf00d,deadbeef,1,0", NULL, 128, 0},
+   {-EOVERFLOW, "badf00d,deadbeef,1,0",NULL, 90, 0},
+   {-EOVERFLOW, "fbadf00d,deadbeef,1,0",   NULL, 95, 0},
+   {-EOVERFLOW, "badf00d,deadbeef,1,0",NULL, 100, 0},
+};
+
+static void __init __test_bitmap_parse(int is_user)
+{
+   int i;
+   int err;
+   ktime_t time;
+   DECLARE_BITMAP(bmap, 2048);
+   char *mode = is_user ? "_user"  : "";
+
+   for (i = 0; i < ARRAY_SIZE(parse_tests); i++) {
+   struct test_bitmap_parselist test = parse_tests[i];
+
+   if (is_user) {
+   size_t len = strlen(test.in);
+   mm_segment_t orig_fs = get_fs();
+
+   set_fs(KERNEL_DS);
+   time = ktime_get();
+   err = bitmap_parse_user(test.in, len, bmap, test.nbits);
+   time = ktime_get() - time;
+   set_fs(orig_fs);
+   } else {
+   size_t len = test.flags & NO_LEN ?
+   UINT_MAX : strlen(test.in);
+   time = ktime_get();
+   err = bitmap_parse(test.in, len, bmap, test.nbits);
+   time = ktime_get() - time;
+   }
+
+   if (err != test.errno) {
+   pr_err("parse%s: %d: input is %s, errno is %d, expected 
%d\n",
+   mode, i, test.in, err, test.errno);
+   continue;
+   }
+
+   if (!err && test.expected
+&& !__bitmap_equal(bmap, test.expected, test.nbits)) {
+   pr_err("parse%s: %d: input is %s, result is 0x%lx, 
expected 0x%lx\n",
+   mode, i, test.in, bmap[0],
+   *test.expected);
+   continue;
+   }
+
+   if (test.flags & PARSE_TIME)
+   pr_err("parse%s: %d: input is '%s' OK, Time: %llu\n",
+   mode, i, test.in, time);
+   }
+}
+
 static void __init test_bitmap_parselist(void)
 {
__test_bitmap_parselist(0);
@@ -338,6 +426,16 @@ static void __init test_bitmap_parselist_user(void)
__test_bitmap_parselist(1);
 }
 
+static void __init test_bitmap_parse(void)
+{
+   __test_bitmap_parse(0);
+}
+
+static void __init test_bitmap_parse_user(void)
+{
+   __test_bitmap_parse(1);
+}
+
 #define EXP_BYTES  (sizeof(exp) * 8)

[PATCH 4/6] lib: rework bitmap_parse()

2019-04-27 Thread Yury Norov
bitmap_parse() is ineffective and full of opaque variables and opencoded
parts. It leads to hard understanding of it. This rework includes:
 - remove bitmap_shift_left() call from the cycle. Now it makes the
   complexity of the algorithm as O(nbits^2). In the suggested approach
   the input string is parsed in reverse direction, so no shifts needed;
 - relax requirement on a single comma and no white spaces between chunks.
   It is considered useful in scripting, and it aligns with
   bitmap_parselist();
 - split bitmap_parse() to small readable helpers;
 - make an explicit calculation of the end of input line at the
   beginning, so users of the bitmap_parse() won't bother doing this.

Signed-off-by: Yury Norov 
---
 include/linux/bitmap.h |   8 +-
 lib/bitmap.c   | 179 -
 2 files changed, 88 insertions(+), 99 deletions(-)

diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
index f58e97446abc..c3e84864cc33 100644
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -172,7 +172,7 @@ bitmap_find_next_zero_area(unsigned long *map,
  align_mask, 0);
 }
 
-extern int __bitmap_parse(const char *buf, unsigned int buflen, int is_user,
+extern int bitmap_parse(const char *buf, unsigned int buflen,
unsigned long *dst, int nbits);
 extern int bitmap_parse_user(const char __user *ubuf, unsigned int ulen,
unsigned long *dst, int nbits);
@@ -408,12 +408,6 @@ static inline void bitmap_shift_left(unsigned long *dst, 
const unsigned long *sr
__bitmap_shift_left(dst, src, shift, nbits);
 }
 
-static inline int bitmap_parse(const char *buf, unsigned int buflen,
-   unsigned long *maskp, int nmaskbits)
-{
-   return __bitmap_parse(buf, buflen, 0, maskp, nmaskbits);
-}
-
 /**
  * BITMAP_FROM_U64() - Represent u64 value in the format suitable for bitmap.
  * @n: u64 value
diff --git a/lib/bitmap.c b/lib/bitmap.c
index 300732031fad..c276c7e0bb53 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -335,97 +335,6 @@ EXPORT_SYMBOL(bitmap_find_next_zero_area_off);
  * second version by Paul Jackson, third by Joe Korty.
  */
 
-#define CHUNKSZ32
-#define nbits_to_hold_value(val)   fls(val)
-#define BASEDEC 10 /* fancier cpuset lists input in decimal */
-
-/**
- * __bitmap_parse - convert an ASCII hex string into a bitmap.
- * @buf: pointer to buffer containing string.
- * @buflen: buffer size in bytes.  If string is smaller than this
- *then it must be terminated with a \0.
- * @is_user: location of buffer, 0 indicates kernel space
- * @maskp: pointer to bitmap array that will contain result.
- * @nmaskbits: size of bitmap, in bits.
- *
- * Commas group hex digits into chunks.  Each chunk defines exactly 32
- * bits of the resultant bitmask.  No chunk may specify a value larger
- * than 32 bits (%-EOVERFLOW), and if a chunk specifies a smaller value
- * then leading 0-bits are prepended.  %-EINVAL is returned for illegal
- * characters and for grouping errors such as "1,,5", ",44", "," and "".
- * Leading and trailing whitespace accepted, but not embedded whitespace.
- */
-int __bitmap_parse(const char *buf, unsigned int buflen,
-   int is_user, unsigned long *maskp,
-   int nmaskbits)
-{
-   int c, old_c, totaldigits, ndigits, nchunks, nbits;
-   u32 chunk;
-   const char __user __force *ubuf = (const char __user __force *)buf;
-
-   bitmap_zero(maskp, nmaskbits);
-
-   nchunks = nbits = totaldigits = c = 0;
-   do {
-   chunk = 0;
-   ndigits = totaldigits;
-
-   /* Get the next chunk of the bitmap */
-   while (buflen) {
-   old_c = c;
-   if (is_user) {
-   if (__get_user(c, ubuf++))
-   return -EFAULT;
-   }
-   else
-   c = *buf++;
-   buflen--;
-   if (isspace(c))
-   continue;
-
-   /*
-* If the last character was a space and the current
-* character isn't '\0', we've got embedded whitespace.
-* This is a no-no, so throw an error.
-*/
-   if (totaldigits && c && isspace(old_c))
-   return -EINVAL;
-
-   /* A '\0' or a ',' signal the end of the chunk */
-   if (c == '\0' || c == ',')
-   break;
-
-   if (!isxdigit(c))
-   return -EINVAL;
-
-   /*
-* Make sure there are at least 4 free bits in 'chunk'.
-* If not, 

[PATCH 6/6] cpumask: don't calculate length of the input string

2019-04-27 Thread Yury Norov
New design of inner bitmap_parse() allows to avoid
calculating the size of a null-terminated string.

Signed-off-by: Yury Norov 
---
 include/linux/cpumask.h | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
index 21755471b1c3..d55d015edc58 100644
--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@ -633,9 +633,7 @@ static inline int cpumask_parselist_user(const char __user 
*buf, int len,
  */
 static inline int cpumask_parse(const char *buf, struct cpumask *dstp)
 {
-   unsigned int len = strchrnul(buf, '\n') - buf;
-
-   return bitmap_parse(buf, len, cpumask_bits(dstp), nr_cpumask_bits);
+   return bitmap_parse(buf, UINT_MAX, cpumask_bits(dstp), nr_cpumask_bits);
 }
 
 /**
-- 
2.17.1



[PATCH 0/4] lib: rework bitmap_parse

2019-04-27 Thread Yury Norov
On top of next-20190418.

Similarly to recently revisited bitmap_parselist() [1],
bitmap_parse() is ineffective and overcomplicated.  This
series reworks it, aligns its interface with bitmap_parselist()
and makes usage simpler.

The series also adds a test for the function and fixes usage of it
in cpumask_parse() according to new design - drops the calculating
of length of an input string.

The following users would also consider to drop the length argument,
if possible:
drivers/block/drbd/drbd_main.c:2608
kernel/padata.c:924
net/core/net-sysfs.c:726
net/core/net-sysfs.c:1309
net/core/net-sysfs.c:1391

bitmap_parse() takes the array of numbers to be put into the map in
the BE order which is reversed to the natural LE order for bitmaps.
For example, to construct bitmap containing a bit on the position 42,
we have to put a line '400,0'. Current implementation reads chunk
one by one from the beginning ('400' before '0') and makes bitmap
shift after each successful parse. It makes the complexity of the
whole process as O(n^2). We can do it in reverse direction ('0'
before '400') and avoid shifting, but it requires reverse parsing
helpers.

Tested on arm64 and BE mips.

[1] https://lkml.org/lkml/2019/4/16/66

Yury Norov (6):
  lib/string: add strnchrnul()
  bitops: more BITS_TO_* macros
  lib/bitmap: make bitmap_parse_user a wrapper on bitmap_parse
  lib: rework bitmap_parse()
  lib: add test for bitmap_parse()
  cpumask: don't calculate length of the input string

 include/linux/bitmap.h   |   8 +-
 include/linux/bitops.h   |   3 +
 include/linux/cpumask.h  |   4 +-
 include/linux/string.h   |   3 +
 lib/bitmap.c | 197 +--
 lib/string.c |  20 
 lib/test_bitmap.c| 102 +-
 tools/include/linux/bitops.h |   9 +-
 8 files changed, 230 insertions(+), 116 deletions(-)

-- 
2.17.1



[PATCH 2/6] bitops: more BITS_TO_* macros

2019-04-27 Thread Yury Norov
Introduce BITS_TO_U64, BITS_TO_U32 and BITS_TO_BYTES as they are handy
in the following changes (BITS_TO_U32 specifically). Sync tools/
version of the macros with the kernel implementation.

Signed-off-by: Yury Norov 
---
 include/linux/bitops.h   | 3 +++
 tools/include/linux/bitops.h | 9 +
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/include/linux/bitops.h b/include/linux/bitops.h
index cf074bce3eb3..3477e179dca7 100644
--- a/include/linux/bitops.h
+++ b/include/linux/bitops.h
@@ -6,6 +6,9 @@
 
 #define BITS_PER_TYPE(type) (sizeof(type) * BITS_PER_BYTE)
 #define BITS_TO_LONGS(nr)  DIV_ROUND_UP(nr, BITS_PER_TYPE(long))
+#define BITS_TO_U64(nr)DIV_ROUND_UP(nr, BITS_PER_TYPE(u64))
+#define BITS_TO_U32(nr)DIV_ROUND_UP(nr, BITS_PER_TYPE(u32))
+#define BITS_TO_BYTES(nr)  DIV_ROUND_UP(nr, BITS_PER_TYPE(char))
 
 extern unsigned int __sw_hweight8(unsigned int w);
 extern unsigned int __sw_hweight16(unsigned int w);
diff --git a/tools/include/linux/bitops.h b/tools/include/linux/bitops.h
index 0b0ef3abc966..959dcb8214ba 100644
--- a/tools/include/linux/bitops.h
+++ b/tools/include/linux/bitops.h
@@ -13,10 +13,11 @@
 #include 
 #include 
 
-#define BITS_TO_LONGS(nr)  DIV_ROUND_UP(nr, BITS_PER_BYTE * sizeof(long))
-#define BITS_TO_U64(nr)DIV_ROUND_UP(nr, BITS_PER_BYTE * 
sizeof(u64))
-#define BITS_TO_U32(nr)DIV_ROUND_UP(nr, BITS_PER_BYTE * 
sizeof(u32))
-#define BITS_TO_BYTES(nr)  DIV_ROUND_UP(nr, BITS_PER_BYTE)
+#define BITS_PER_TYPE(type)(sizeof(type) * BITS_PER_BYTE)
+#define BITS_TO_LONGS(nr)  DIV_ROUND_UP(nr, BITS_PER_TYPE(long))
+#define BITS_TO_U64(nr)DIV_ROUND_UP(nr, BITS_PER_TYPE(u64))
+#define BITS_TO_U32(nr)DIV_ROUND_UP(nr, BITS_PER_TYPE(u32))
+#define BITS_TO_BYTES(nr)  DIV_ROUND_UP(nr, BITS_PER_TYPE(char))
 
 extern unsigned int __sw_hweight8(unsigned int w);
 extern unsigned int __sw_hweight16(unsigned int w);
-- 
2.17.1



RE: [PATCH 2/2] watchdog: imx_sc: Add pretimeout support

2019-04-27 Thread Anson Huang
Hi, Shawn
As patch 1/2 is an independent patch to improve the 
imx_scu_irq_group_enable() API, so I sent out V2 independently with some commit 
message improved, please help review, thanks.
Hi, Guenter
I addressed your comments in V2 patch series, please help review, 
thanks.

Anson. 

> -Original Message-
> From: Guenter Roeck [mailto:groe...@gmail.com] On Behalf Of Guenter
> Roeck
> Sent: Saturday, April 27, 2019 4:17 AM
> To: Anson Huang 
> Cc: shawn...@kernel.org; s.ha...@pengutronix.de;
> ker...@pengutronix.de; feste...@gmail.com; w...@linux-watchdog.org;
> Aisheng Dong ; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
> watch...@vger.kernel.org; dl-linux-imx 
> Subject: Re: [PATCH 2/2] watchdog: imx_sc: Add pretimeout support
> 
> On Thu, Apr 25, 2019 at 05:44:45AM +, Anson Huang wrote:
> > Hi, Guenter
> >
> > > -Original Message-
> > > From: Guenter Roeck [mailto:groe...@gmail.com] On Behalf Of Guenter
> > > Roeck
> > > Sent: Thursday, April 25, 2019 12:04 PM
> > > To: Anson Huang ; shawn...@kernel.org;
> > > s.ha...@pengutronix.de; ker...@pengutronix.de; feste...@gmail.com;
> > > w...@linux-watchdog.org; Aisheng Dong ;
> linux-
> > > arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
> > > watch...@vger.kernel.org
> > > Cc: dl-linux-imx 
> > > Subject: Re: [PATCH 2/2] watchdog: imx_sc: Add pretimeout support
> > >
> > > On 4/24/19 6:14 PM, Anson Huang wrote:
> > > > i.MX system controller watchdog can support pretimeout IRQ via
> > > > general SCU MU IRQ, it depends on IMX_SCU and driver MUST be
> > > > probed after SCU IPC ready, then enable corresponding SCU IRQ
> > > > group and register SCU IRQ notifier, when watchdog pretimeout IRQ
> > > > fires, SCU MU IRQ will be handled and watchdog pretimeout notifier
> > > > will be called to handle the event.
> > > >
> > >
> > > Ah, here is the missing patch.
> > >
> > > As mentioned in my other reply, the watchdog driver does now depend
> > > on the SCU IPC handle and should be instantiated accordingly.
> > > Using -EPROBE_DEFER to work around bad dependencies is not a solution.
> >
> > So, I have to move the i.MX system controller watchdog node into the
> > i.MX SCU node in DT file now? As it depends on i.MX SCU firmware. If
> > so, should I remove the
> 
> Yes, that is what I would suggest.
> 
> > previous i.MX system controller binding doc (fsl-imx-sc-wdt.txt) and
> > add binding doc to
> (Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt) ?
> >
> I can't comment on that; I am neutral on how the documentation is handled.
> 
> > >
> > > Additional comment below.
> > >
> > > Guenter
> > >
> > > > Signed-off-by: Anson Huang 
> > > > ---
> > > >   drivers/watchdog/Kconfig  |  1 +
> > > >   drivers/watchdog/imx_sc_wdt.c | 65
> > > +++
> > > >   2 files changed, 61 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> > > > index 44a3158..f2c2c1a 100644
> > > > --- a/drivers/watchdog/Kconfig
> > > > +++ b/drivers/watchdog/Kconfig
> > > > @@ -644,6 +644,7 @@ config IMX2_WDT
> > > >   config IMX_SC_WDT
> > > > tristate "IMX SC Watchdog"
> > > > depends on HAVE_ARM_SMCCC
> > > > +   depends on IMX_SCU
> > > > select WATCHDOG_CORE
> > > > help
> > > >   This is the driver for the system controller watchdog diff
> > > > --git a/drivers/watchdog/imx_sc_wdt.c
> > > > b/drivers/watchdog/imx_sc_wdt.c index
> > > > 49848b6..f45ed10 100644
> > > > --- a/drivers/watchdog/imx_sc_wdt.c
> > > > +++ b/drivers/watchdog/imx_sc_wdt.c
> > > > @@ -4,6 +4,7 @@
> > > >*/
> > > >
> > > >   #include 
> > > > +#include 
> > > >   #include 
> > > >   #include 
> > > >   #include 
> > > > @@ -33,11 +34,16 @@
> > > >
> > > >   #define SC_TIMER_WDOG_ACTION_PARTITION0
> > > >
> > > > +#define SC_IRQ_WDOG1
> > > > +#define SC_IRQ_GROUP_WDOG  1
> > > > +
> > > >   static bool nowayout = WATCHDOG_NOWAYOUT;
> > > >   module_param(nowayout, bool, );
> > > >   MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once
> > > started (default="
> > > >  __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
> > > >
> > > > +struct watchdog_device *imx_sc_wdd;
> > > > +
> > > >   static int imx_sc_wdt_ping(struct watchdog_device *wdog)
> > > >   {
> > > > struct arm_smccc_res res;
> > > > @@ -85,12 +91,42 @@ static int imx_sc_wdt_set_timeout(struct
> > > watchdog_device *wdog,
> > > > return res.a0 ? -EACCES : 0;
> > > >   }
> > > >
> > > > +static int imx_sc_wdt_set_pretimeout(struct watchdog_device *wdog,
> > > > +unsigned int pretimeout) {
> > > > +   struct arm_smccc_res res;
> > > > +
> > > > +   wdog->pretimeout = pretimeout;
> > > > +   arm_smccc_smc(IMX_SIP_TIMER,
> > > IMX_SIP_TIMER_SET_PRETIME_WDOG,
> > > > + 

[PATCH 1/6] lib/string: add strnchrnul()

2019-04-27 Thread Yury Norov
New function works like strchrnul() with a length limited strings.

Signed-off-by: Yury Norov 
---
 include/linux/string.h |  3 +++
 lib/string.c   | 20 
 2 files changed, 23 insertions(+)

diff --git a/include/linux/string.h b/include/linux/string.h
index 4deb11f7976b..69e8df51b630 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -62,6 +62,9 @@ extern char * strchr(const char *,int);
 #ifndef __HAVE_ARCH_STRCHRNUL
 extern char * strchrnul(const char *,int);
 #endif
+#ifndef __HAVE_ARCH_STRNCHRNUL
+extern char * strnchrnul(const char *, int, int);
+#endif
 #ifndef __HAVE_ARCH_STRNCHR
 extern char * strnchr(const char *, size_t, int);
 #endif
diff --git a/lib/string.c b/lib/string.c
index 6016eb3ac73d..dd99e6ac517a 100644
--- a/lib/string.c
+++ b/lib/string.c
@@ -429,6 +429,26 @@ char *strchrnul(const char *s, int c)
 EXPORT_SYMBOL(strchrnul);
 #endif
 
+#ifndef __HAVE_ARCH_STRNCHRNUL
+/**
+ * strnchrnul - Find and return a character in a length limited string,
+ * or end of string
+ * @s: The string to be searched
+ * @count: The number of characters to be searched
+ * @c: The character to search for
+ *
+ * Returns pointer to first occurrence of 'c' in s. If c is not found,
+ * then return a pointer to the null byte at the end of s.
+ */
+char *strnchrnul(const char *s, int count, int c)
+{
+   while (count-- && *s && *s != (char)c)
+   s++;
+   return (char *)s;
+}
+EXPORT_SYMBOL(strnchrnul);
+#endif
+
 #ifndef __HAVE_ARCH_STRRCHR
 /**
  * strrchr - Find the last occurrence of a character in a string
-- 
2.17.1



[PATCH V2 3/4] watchdog: imx_sc: Add pretimeout support

2019-04-27 Thread Anson Huang
i.MX system controller watchdog can support pretimeout IRQ
via general SCU MU IRQ, it depends on IMX_SCU and driver MUST
be probed after SCU IPC ready, then enable corresponding SCU
IRQ group and register SCU IRQ notifier, when watchdog pretimeout
IRQ fires, SCU MU IRQ will be handled and watchdog pretimeout
notifier will be called to handle the event.

Signed-off-by: Anson Huang 
---
Changes since V1:
- improve imx_sc_wdt_set_pretimeout() return value and assignment 
sequence;
- improve coding and logic of imx_sc_wdt_notify() function;
- use devm_add_action() instead of .remove;
- add local data structure to include notifier block;
- remove the defer probe check since the watchdog node is now moved 
into SCU node;
- ONLY enable pretimeout function after everything about IRQ are 
successfully.
---
 drivers/watchdog/Kconfig  |   1 +
 drivers/watchdog/imx_sc_wdt.c | 114 ++
 2 files changed, 95 insertions(+), 20 deletions(-)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 44a3158..f2c2c1a 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -644,6 +644,7 @@ config IMX2_WDT
 config IMX_SC_WDT
tristate "IMX SC Watchdog"
depends on HAVE_ARM_SMCCC
+   depends on IMX_SCU
select WATCHDOG_CORE
help
  This is the driver for the system controller watchdog
diff --git a/drivers/watchdog/imx_sc_wdt.c b/drivers/watchdog/imx_sc_wdt.c
index 49848b6..d8493a3 100644
--- a/drivers/watchdog/imx_sc_wdt.c
+++ b/drivers/watchdog/imx_sc_wdt.c
@@ -4,6 +4,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -33,11 +34,19 @@
 
 #define SC_TIMER_WDOG_ACTION_PARTITION 0
 
+#define SC_IRQ_WDOG1
+#define SC_IRQ_GROUP_WDOG  1
+
 static bool nowayout = WATCHDOG_NOWAYOUT;
 module_param(nowayout, bool, );
 MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started (default="
 __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
 
+struct imx_sc_wdt_device {
+   struct watchdog_device wdd;
+   struct notifier_block wdt_notifier;
+};
+
 static int imx_sc_wdt_ping(struct watchdog_device *wdog)
 {
struct arm_smccc_res res;
@@ -85,24 +94,66 @@ static int imx_sc_wdt_set_timeout(struct watchdog_device 
*wdog,
return res.a0 ? -EACCES : 0;
 }
 
+static int imx_sc_wdt_set_pretimeout(struct watchdog_device *wdog,
+unsigned int pretimeout)
+{
+   struct arm_smccc_res res;
+
+   arm_smccc_smc(IMX_SIP_TIMER, IMX_SIP_TIMER_SET_PRETIME_WDOG,
+ pretimeout * 1000, 0, 0, 0, 0, 0, );
+   if (res.a0)
+   return -EACCES;
+
+   wdog->pretimeout = pretimeout;
+
+   return 0;
+}
+
+static int imx_sc_wdt_notify(struct notifier_block *nb,
+unsigned long event, void *group)
+{
+   struct imx_sc_wdt_device *imx_sc_wdd =
+container_of(nb,
+ struct imx_sc_wdt_device,
+ wdt_notifier);
+
+   if (event & SC_IRQ_WDOG &&
+   *(u8 *)group == SC_IRQ_GROUP_WDOG)
+   watchdog_notify_pretimeout(_sc_wdd->wdd);
+
+   return 0;
+}
+
+static void imx_sc_wdt_action(void *data)
+{
+   struct notifier_block *wdt_notifier = data;
+
+   imx_scu_irq_unregister_notifier(wdt_notifier);
+   imx_scu_irq_group_enable(SC_IRQ_GROUP_WDOG,
+SC_IRQ_WDOG,
+false);
+}
+
 static const struct watchdog_ops imx_sc_wdt_ops = {
.owner = THIS_MODULE,
.start = imx_sc_wdt_start,
.stop  = imx_sc_wdt_stop,
.ping  = imx_sc_wdt_ping,
.set_timeout = imx_sc_wdt_set_timeout,
+   .set_pretimeout = imx_sc_wdt_set_pretimeout,
 };
 
-static const struct watchdog_info imx_sc_wdt_info = {
+static struct watchdog_info imx_sc_wdt_info = {
.identity   = "i.MX SC watchdog timer",
.options= WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING |
- WDIOF_MAGICCLOSE | WDIOF_PRETIMEOUT,
+ WDIOF_MAGICCLOSE,
 };
 
 static int imx_sc_wdt_probe(struct platform_device *pdev)
 {
+   struct imx_sc_wdt_device *imx_sc_wdd;
+   struct watchdog_device *wdog;
struct device *dev = >dev;
-   struct watchdog_device *imx_sc_wdd;
int ret;
 
imx_sc_wdd = devm_kzalloc(dev, sizeof(*imx_sc_wdd), GFP_KERNEL);
@@ -111,42 +162,65 @@ static int imx_sc_wdt_probe(struct platform_device *pdev)
 
platform_set_drvdata(pdev, imx_sc_wdd);
 
-   imx_sc_wdd->info = _sc_wdt_info;
-   imx_sc_wdd->ops = _sc_wdt_ops;
-   imx_sc_wdd->min_timeout = 1;
-   imx_sc_wdd->max_timeout = MAX_TIMEOUT;
-   imx_sc_wdd->parent = dev;
-   imx_sc_wdd->timeout = DEFAULT_TIMEOUT;
+   wdog = _sc_wdd->wdd;
+   

[PATCH V2 4/4] dt-bindings: watchdog: remove i.MX system controller watchdog

2019-04-27 Thread Anson Huang
i.MX system controller watchdog now depends on SCU driver, so it
needs to be subnode of SCU node in DT, binding doc is moved to
fsl,scu.txt as well.

Signed-off-by: Anson Huang 
---
New patch.
---
 .../bindings/watchdog/fsl-imx-sc-wdt.txt   | 24 --
 1 file changed, 24 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/watchdog/fsl-imx-sc-wdt.txt

diff --git a/Documentation/devicetree/bindings/watchdog/fsl-imx-sc-wdt.txt 
b/Documentation/devicetree/bindings/watchdog/fsl-imx-sc-wdt.txt
deleted file mode 100644
index 02b87e9..000
--- a/Documentation/devicetree/bindings/watchdog/fsl-imx-sc-wdt.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-* Freescale i.MX System Controller Watchdog
-
-i.MX system controller watchdog is for i.MX SoCs with system controller inside,
-the watchdog is managed by system controller, users can ONLY communicate with
-system controller from secure mode for watchdog operations, so Linux i.MX 
system
-controller watchdog driver will call ARM SMC API and trap into 
ARM-Trusted-Firmware
-for watchdog operations, ARM-Trusted-Firmware is running at secure EL3 mode and
-it will request system controller to execute the watchdog operation passed from
-Linux kernel.
-
-Required properties:
-- compatible:  Should be :
-   "fsl,imx8qxp-sc-wdt"
-   followed by "fsl,imx-sc-wdt";
-
-Optional properties:
-- timeout-sec : Contains the watchdog timeout in seconds.
-
-Examples:
-
-watchdog {
-   compatible = "fsl,imx8qxp-sc-wdt", "fsl,imx-sc-wdt";
-   timeout-sec = <60>;
-};
-- 
2.7.4



[PATCH V2 2/4] arm64: dts: imx8qxp: Move watchdog node into scu node

2019-04-27 Thread Anson Huang
i.MX system controller watchdog has pretimeout function which
depends on i.MX SCU driver, so it should be a subnode of SCU.

Signed-off-by: Anson Huang 
---
New patch.
---
 arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi 
b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index 0683ee2..b17c22e 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -149,6 +149,11 @@
rtc: rtc {
compatible = "fsl,imx8qxp-sc-rtc";
};
+
+   watchdog {
+   compatible = "fsl,imx8qxp-sc-wdt", "fsl,imx-sc-wdt";
+   timeout-sec = <60>;
+   };
};
 
timer {
@@ -517,9 +522,4 @@
power-domains = < IMX_SC_R_GPIO_7>;
};
};
-
-   watchdog {
-   compatible = "fsl,imx8qxp-sc-wdt", "fsl,imx-sc-wdt";
-   timeout-sec = <60>;
-   };
 };
-- 
2.7.4



[PATCH V2 1/4] dt-bindings: fsl: scu: add watchdog binding

2019-04-27 Thread Anson Huang
i.MX system controller watchdog has pretimeout function which
depends on i.MX SCU driver, so watchdog DT node needs to be
subnode of SCU, this patch adds i.MX system controller watchdog
binding to SCU binding doc.

Signed-off-by: Anson Huang 
---
New patch.
---
 .../devicetree/bindings/arm/freescale/fsl,scu.txt | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt 
b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
index 5d7dbab..1b56557 100644
--- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
@@ -133,6 +133,16 @@ RTC bindings based on SCU Message Protocol
 Required properties:
 - compatible: should be "fsl,imx8qxp-sc-rtc";
 
+Watchdog bindings based on SCU Message Protocol
+
+
+Required properties:
+- compatible: should be:
+  "fsl,imx8qxp-sc-wdt"
+  followed by "fsl,imx-sc-wdt";
+Optional properties:
+- timeout-sec: contains the watchdog timeout in seconds.
+
 Example (imx8qxp):
 -
 aliases {
@@ -185,6 +195,11 @@ firmware {
rtc: rtc {
compatible = "fsl,imx8qxp-sc-rtc";
};
+
+   watchdog {
+   compatible = "fsl,imx8qxp-sc-wdt", "fsl,imx-sc-wdt";
+   timeout-sec = <60>;
+   };
};
 };
 
-- 
2.7.4



Re: [PATCH v2] ipvs:set sock send/receive buffer correctly

2019-04-27 Thread linmiaohe



On 2019/4/22 2:48, Julian Anastasov wrote:
> 
>   Hello,
> 
> On Thu, 18 Apr 2019, linmiaohe wrote:
> 
>> From: Jie Liu 
>>
>> If we set sysctl_wmem_max or sysctl_rmem_max larger than INT_MAX, the
>> send/receive buffer of sock will be an negative value. Same as when
>> the val is larger than INT_MAX/2.
>>
>> Fixes: 1c003b1580e2 ("ipvs: wakeup master thread")
>> Reported-by: Qiang Ning 
>> Reviewed-by: Miaohe Lin 
>> Signed-off-by: Jie Liu 
> 
>   Looks good to me, thanks!
> 
> Acked-by: Julian Anastasov 
> 
>> ---
>>  net/netfilter/ipvs/ip_vs_sync.c | 20 ++--
>>  1 file changed, 14 insertions(+), 6 deletions(-)
>>
>> diff --git a/net/netfilter/ipvs/ip_vs_sync.c 
>> b/net/netfilter/ipvs/ip_vs_sync.c
>> index 2526be6b3d90..760f3364d4a2 100644
>> --- a/net/netfilter/ipvs/ip_vs_sync.c
>> +++ b/net/netfilter/ipvs/ip_vs_sync.c
>> @@ -1278,14 +1278,22 @@ static void set_sock_size(struct sock *sk, int mode, 
>> int val)
>>  /* setsockopt(sock, SOL_SOCKET, SO_RCVBUF, , sizeof(val)); */
>>  lock_sock(sk);
>>  if (mode) {
>> -val = clamp_t(int, val, (SOCK_MIN_SNDBUF + 1) / 2,
>> -  sysctl_wmem_max);
>> -sk->sk_sndbuf = val * 2;
>> +val = min_t(u32, val, sysctl_wmem_max);
>> +
>> +/* Ensure val * 2 fits into an int, to prevent max_t()
>> + * from treating it as a negative value.
>> + */
>> +val = min_t(int, val, INT_MAX / 2);
>> +sk->sk_sndbuf = max_t(int, val * 2, SOCK_MIN_SNDBUF);
>>  sk->sk_userlocks |= SOCK_SNDBUF_LOCK;
>>  } else {
>> -val = clamp_t(int, val, (SOCK_MIN_RCVBUF + 1) / 2,
>> -  sysctl_rmem_max);
>> -sk->sk_rcvbuf = val * 2;
>> +val = min_t(u32, val, sysctl_rmem_max);
>> +
>> +/* Ensure val * 2 fits into an int, to prevent max_t()
>> + * from treating it as a negative value.
>> + */
>> +val = min_t(int, val, INT_MAX / 2);
>> +sk->sk_rcvbuf = max_t(int, val * 2, SOCK_MIN_RCVBUF);
>>  sk->sk_userlocks |= SOCK_RCVBUF_LOCK;
>>  }
>>  release_sock(sk);
>> -- 
> 
> Regards
> 
> --
> Julian Anastasov 
> 
> .
> 

Hi all,
Could you please tell me if there is still any problem?
Many thanks.



[PATCH V2] firmware: imx: SCU irq should ONLY be enabled after SCU IPC is ready

2019-04-27 Thread Anson Huang
The imx_scu_irq_group_enable() is normally called during module driver
probe phase to enable SCU group irq, if SCU IPC is NOT ready, below
dump will show out:

[0.933001] Hardware name: Freescale i.MX8QXP MEK (DT)
[0.938129] pstate: 6005 (nZCv daif -PAN -UAO)
[0.942907] pc : imx_scu_call_rpc+0x114/0x158
[0.947251] lr : imx_scu_irq_group_enable+0x74/0xc4
[0.952113] sp : 1005bae0
[0.955415] x29: 1005bae0 x28: 111bb0a0
[0.960712] x27: 1140b000 x26: 068c
[0.966011] x25: 111bb100 x24: 
[0.971311] x23: 113d9cd8 x22: 0001
[0.976610] x21: 0001 x20: 80083b51a410
[0.981909] x19: 11259000 x18: 0480
[0.987209] x17: 0023ffb8 x16: 0010
[0.992508] x15: 023f x14: 
[0.997807] x13: 0018 x12: 0030
[1.003107] x11: 0003 x10: 0101010101010101
[1.008406] x9 :  x8 : 7f7f7f7f7f7f7f7f
[1.013706] x7 : fefefeff646c606d x6 : 
[1.019005] x5 : 112596c8 x4 : 0008
[1.024304] x3 : 0003 x2 : 0001
[1.029604] x1 : 1005bb58 x0 : 
[1.034905] Call trace:
[1.037341]  imx_scu_call_rpc+0x114/0x158
[1.041334]  imx_scu_irq_group_enable+0x74/0xc4
[1.045856]  imx_sc_wdt_probe+0x24/0x150
[1.049766]  platform_drv_probe+0x4c/0xb0
[1.053762]  really_probe+0x1f8/0x2c8
[1.057407]  driver_probe_device+0x58/0xfc
[1.061490]  device_driver_attach+0x68/0x70
[1.065660]  __driver_attach+0x94/0xdc
[1.069397]  bus_for_each_dev+0x64/0xc0
[1.073220]  driver_attach+0x20/0x28
[1.076782]  bus_add_driver+0x148/0x1fc
[1.080601]  driver_register+0x68/0x120
[1.084424]  __platform_driver_register+0x4c/0x54
[1.089120]  imx_sc_wdt_driver_init+0x18/0x20
[1.093463]  do_one_initcall+0x58/0x1b8
[1.097287]  kernel_init_freeable+0x1cc/0x288
[1.101630]  kernel_init+0x10/0x100
[1.105101]  ret_from_fork+0x10/0x18
[1.108669] ---[ end trace 9e03302114457de9 ]---
[1.113296] enable irq failed, group 1, mask 1, ret -22

To avoid such scenario, return -EPROBE_DEFER in imx_scu_irq_group_enable()
API if SCU IPC is NOT ready, then module driver which calls this API
in probe phase will defer probe after SCU IPC ready.

Fixes: 851826c7566e ("firmware: imx: enable imx scu general irq function")
Signed-off-by: Anson Huang 
---
No code change, just remove the watchdog related words to improve the commit 
message.
---
 drivers/firmware/imx/imx-scu-irq.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/firmware/imx/imx-scu-irq.c 
b/drivers/firmware/imx/imx-scu-irq.c
index 043833a..687121f 100644
--- a/drivers/firmware/imx/imx-scu-irq.c
+++ b/drivers/firmware/imx/imx-scu-irq.c
@@ -100,6 +100,9 @@ int imx_scu_irq_group_enable(u8 group, u32 mask, u8 enable)
struct imx_sc_rpc_msg *hdr = 
int ret;
 
+   if (!imx_sc_irq_ipc_handle)
+   return -EPROBE_DEFER;
+
hdr->ver = IMX_SC_RPC_VERSION;
hdr->svc = IMX_SC_RPC_SVC_IRQ;
hdr->func = IMX_SC_IRQ_FUNC_ENABLE;
-- 
2.7.4



[PATCH V2] staging: fieldbus: anybus-s: consolidate wait_for_completion_timeout return handling

2019-04-27 Thread Nicholas Mc Guire
wait_for_completion_timeout() returns unsigned long (0 on timeout or
remaining jiffies) not int - so rather than introducing an additional
variable simply wrap the completion into an if().

Signed-off-by: Nicholas Mc Guire 
---

Problem located with experimental API conformance checking cocci script

V2: The original patch's logic was wrong as it was skipping the 
fall-through if so using the fix proposed by Sven Van Asbroeck 
 - This solution also eliminates the need
to introduce an additional variable - Thanks !

Patch was compile-tested with. x86_64_defconfig + FIELDBUS_DEV=m,
HMS_ANYBUSS_BUS=m
(with an unrelated sparse warnings (cast to restricted __be16))

Patch is against 5.1-rc6 (localversion-next is next-20190426)

 drivers/staging/fieldbus/anybuss/host.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/fieldbus/anybuss/host.c 
b/drivers/staging/fieldbus/anybuss/host.c
index e34d424..6227daf 100644
--- a/drivers/staging/fieldbus/anybuss/host.c
+++ b/drivers/staging/fieldbus/anybuss/host.c
@@ -1325,11 +1325,11 @@ anybuss_host_common_probe(struct device *dev,
 *   interrupt came in: ready to go !
 */
reset_deassert(cd);
-   ret = wait_for_completion_timeout(>card_boot, TIMEOUT);
-   if (ret == 0)
+   if (!wait_for_completion_timeout(>card_boot, TIMEOUT)) {
ret = -ETIMEDOUT;
-   if (ret < 0)
goto err_reset;
+   }
+
/*
 * according to the anybus docs, we're allowed to read these
 * without handshaking / reserving the area
-- 
2.1.4



[PATCH] staging: fieldbus: anybus-s: force endiannes annotation

2019-04-27 Thread Nicholas Mc Guire
While the endiannes is being handled correctly sparse was unhappy with
the missing annotation as be16_to_cpu() expects a __be16. 

Signed-off-by: Nicholas Mc Guire 
---

Problem reported by sparse

As far as I understand sparse here the __force is actually the only 
solution possible to inform sparse that the endiannes handling is ok

Patch was compile-tested with. x86_64_defconfig + FIELDBUS_DEV=m,
HMS_ANYBUSS_BUS=m

Patch is against 5.1-rc6 (localversion-next is next-20190426)

 drivers/staging/fieldbus/anybuss/host.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/fieldbus/anybuss/host.c 
b/drivers/staging/fieldbus/anybuss/host.c
index 6227daf..278acac 100644
--- a/drivers/staging/fieldbus/anybuss/host.c
+++ b/drivers/staging/fieldbus/anybuss/host.c
@@ -1348,7 +1348,7 @@ anybuss_host_common_probe(struct device *dev,
add_device_randomness(, 4);
regmap_bulk_read(cd->regmap, REG_FIELDBUS_TYPE, _type,
 sizeof(fieldbus_type));
-   fieldbus_type = be16_to_cpu(fieldbus_type);
+   fieldbus_type = be16_to_cpu((__force __be16)fieldbus_type);
dev_info(dev, "Fieldbus type: %04X", fieldbus_type);
regmap_bulk_read(cd->regmap, REG_MODULE_SW_V, val, 2);
dev_info(dev, "Module SW version: %02X%02X",
-- 
2.1.4



Re: [RFC PATCH v5 4/4] x86/acrn: Add hypercall for ACRN guest

2019-04-27 Thread Zhao, Yakui




On 2019年04月27日 16:58, Borislav Petkov wrote:

On Fri, Apr 26, 2019 at 11:18:48AM +0800, Zhao, Yakui wrote:

It seems that it is seldom used in kernel although the explicit register
variable is supported by GCC and makes the code look simpler. And it seems
that the explicit register variable is not suppoorted by CLAG.


The more reason not to do it this way. Also, the "register" variable
specification is not very widespread in x86 when you look at

$ git grep -E "register\s.*asm" arch/x86/

output.


Yes.  The explicit register variable is not very videspread for arch/x86.
So the register variable will be removed for ACRN hypercall.




So the explicit register variable will be removed. I will follow the asm
code from Borislav. Of course one minor change is that the "movq" is used
instead of "mov".


Does that matter if your destination register is 64-bit?


Thanks for the reminder about the access width.
It is 64-bit register. What I said is the "movq", not "movl".
(I understand that movl is incorrect for 64-bit register).


Thanks
Yakui



RE: [EXT] Re: [PATCH] dmaengine: fsl-qdma: fixed the source/destination descriptior format

2019-04-27 Thread Peng Ma
Hi Vinod,

Thanks your comments.
Please see my comments inline.

Best Regards,
Peng

>-Original Message-
>From: Vinod Koul 
>Sent: 2019年4月26日 19:51
>To: Peng Ma 
>Cc: dan.j.willi...@intel.com; Leo Li ;
>dmaeng...@vger.kernel.org; linux-kernel@vger.kernel.org
>Subject: [EXT] Re: [PATCH] dmaengine: fsl-qdma: fixed the source/destination
>descriptior format
>
>Caution: EXT Email
>
>On 19-04-19, 08:46, Peng Ma wrote:
>> CMD of Source/Destination descriptior format should be lower of
>
>s/descriptior/descriptor
>
[Peng Ma] Got it.
>> struct fsl_qdma_engine number data address.
>>
>> Signed-off-by: Peng Ma 
>> ---
>>  drivers/dma/fsl-qdma.c |   29 ++---
>>  1 files changed, 18 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/dma/fsl-qdma.c b/drivers/dma/fsl-qdma.c index
>> aa1d0ae..542765a 100644
>> --- a/drivers/dma/fsl-qdma.c
>> +++ b/drivers/dma/fsl-qdma.c
>> @@ -113,6 +113,7 @@
>>  /* Field definition for Descriptor offset */
>>  #define QDMA_CCDF_STATUS 20
>>  #define QDMA_CCDF_OFFSET 20
>> +#define QDMA_SDDF_CMD(x) (((u64)(x)) << 32)
>>
>>  /* Field definition for safe loop count*/
>>  #define FSL_QDMA_HALT_COUNT  1500
>> @@ -214,6 +215,12 @@ struct fsl_qdma_engine {
>>
>>  };
>>
>> +static inline void
>> +qdma_sddf_set_cmd(struct fsl_qdma_format *sddf, u32 val) {
>> + sddf->data = QDMA_SDDF_CMD(val); }
>> +
>>  static inline u64
>>  qdma_ccdf_addr_get64(const struct fsl_qdma_format *ccdf)  { @@
>-341,6
>> +348,7 @@ static void fsl_qdma_free_chan_resources(struct dma_chan
>> *chan)  static void fsl_qdma_comp_fill_memcpy(struct fsl_qdma_comp
>*fsl_comp,
>> dma_addr_t dst, dma_addr_t
>src,
>> u32 len)  {
>> + u32 cmd;
>>   struct fsl_qdma_format *sdf, *ddf;
>>   struct fsl_qdma_format *ccdf, *csgf_desc, *csgf_src, *csgf_dest;
>>
>> @@ -353,6 +361,7 @@ static void fsl_qdma_comp_fill_memcpy(struct
>> fsl_qdma_comp *fsl_comp,
>>
>>   memset(fsl_comp->virt_addr, 0,
>FSL_QDMA_COMMAND_BUFFER_SIZE);
>>   memset(fsl_comp->desc_virt_addr, 0,
>> FSL_QDMA_DESCRIPTOR_BUFFER_SIZE);
>> +
>>   /* Head Command Descriptor(Frame Descriptor) */
>>   qdma_desc_addr_set64(ccdf, fsl_comp->bus_addr + 16);
>>   qdma_ccdf_set_format(ccdf, qdma_ccdf_get_offset(ccdf)); @@
>> -369,14 +378,14 @@ static void fsl_qdma_comp_fill_memcpy(struct
>fsl_qdma_comp *fsl_comp,
>>   /* This entry is the last entry. */
>>   qdma_csgf_set_f(csgf_dest, len);
>>   /* Descriptor Buffer */
>> - sdf->data =
>> - cpu_to_le64(FSL_QDMA_CMD_RWTTYPE <<
>> - FSL_QDMA_CMD_RWTTYPE_OFFSET);
>> - ddf->data =
>> - cpu_to_le64(FSL_QDMA_CMD_RWTTYPE <<
>> - FSL_QDMA_CMD_RWTTYPE_OFFSET);
>> - ddf->data |=
>> - cpu_to_le64(FSL_QDMA_CMD_LWC <<
>FSL_QDMA_CMD_LWC_OFFSET);
>> + cmd = cpu_to_le32(FSL_QDMA_CMD_RWTTYPE <<
>> +   FSL_QDMA_CMD_RWTTYPE_OFFSET);
>> + qdma_sddf_set_cmd(sdf, cmd);
>> +
>> + cmd = cpu_to_le32(FSL_QDMA_CMD_RWTTYPE <<
>> +   FSL_QDMA_CMD_RWTTYPE_OFFSET);
>> + cmd |= cpu_to_le32(FSL_QDMA_CMD_LWC <<
>FSL_QDMA_CMD_LWC_OFFSET);
>> + qdma_sddf_set_cmd(ddf, cmd);
>>  }
>>
>>  /*
>> @@ -701,10 +710,8 @@ static irqreturn_t fsl_qdma_error_handler(int
>> irq, void *dev_id)
>>
>>   intr = qdma_readl(fsl_qdma, status + FSL_QDMA_DEDR);
>>
>> - if (intr) {
>> + if (intr)
>>   dev_err(fsl_qdma->dma_dev.dev, "DMA transaction
>error!\n");
>> - return IRQ_NONE;
>> - }
>
>this seems unrelated can you explain?
>
[Peng Ma] This is an added improvement. When an error occurs we should clean 
the error reg then to return.
I forgot to explain it on comments. Should I add this changed to the comments?
>>
>>   qdma_writel(fsl_qdma, FSL_QDMA_DEDR_CLEAR, status +
>FSL_QDMA_DEDR);
>>   return IRQ_HANDLED;
>> --
>> 1.7.1
>
>--
>~Vinod


Re: [PATCH v3 3/3] clk: sifive: add a driver for the SiFive FU540 PRCI IP block

2019-04-27 Thread Atish Patra

On 4/11/19 1:28 AM, Paul Walmsley wrote:

Add driver code for the SiFive FU540 PRCI IP block.  This IP block
handles reset and clock control for the SiFive FU540 device and
implements SoC-level clock tree controls and dividers.

Based on code written by Wesley Terpstra :
https://github.com/riscv/riscv-linux/commit/999529edf517ed75b56659d456d221b2ee56bb60

Boot and PLL rate change were tested on a SiFive HiFive Unleashed
board.

This version includes several changes requested by Stephen Boyd
.

Signed-off-by: Paul Walmsley 
Signed-off-by: Paul Walmsley 
Cc: Michael Turquette 
Cc: Stephen Boyd 
Cc: Albert Ou 
Cc: Wesley W. Terpstra 
Cc: Palmer Dabbelt 
Cc: Megan Wachs 
Cc: linux-ri...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
  drivers/clk/Kconfig |   1 +
  drivers/clk/Makefile|   1 +
  drivers/clk/sifive/Kconfig  |  18 +
  drivers/clk/sifive/Makefile |   1 +
  drivers/clk/sifive/fu540-prci.c | 630 
  5 files changed, 651 insertions(+)
  create mode 100644 drivers/clk/sifive/Kconfig
  create mode 100644 drivers/clk/sifive/Makefile
  create mode 100644 drivers/clk/sifive/fu540-prci.c

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 83dc90bd5179..d2f94ff9b0fc 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -310,6 +310,7 @@ source "drivers/clk/mvebu/Kconfig"
  source "drivers/clk/qcom/Kconfig"
  source "drivers/clk/renesas/Kconfig"
  source "drivers/clk/samsung/Kconfig"
+source "drivers/clk/sifive/Kconfig"
  source "drivers/clk/sprd/Kconfig"
  source "drivers/clk/sunxi-ng/Kconfig"
  source "drivers/clk/tegra/Kconfig"
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 091ee1d8af65..5173a5ae1069 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -94,6 +94,7 @@ obj-$(CONFIG_COMMON_CLK_QCOM) += qcom/
  obj-y += renesas/
  obj-$(CONFIG_ARCH_ROCKCHIP)   += rockchip/
  obj-$(CONFIG_COMMON_CLK_SAMSUNG)  += samsung/
+obj-y  += sifive/
  obj-$(CONFIG_ARCH_SIRF)   += sirf/
  obj-$(CONFIG_ARCH_SOCFPGA)+= socfpga/
  obj-$(CONFIG_PLAT_SPEAR)  += spear/
diff --git a/drivers/clk/sifive/Kconfig b/drivers/clk/sifive/Kconfig
new file mode 100644
index ..8db4a3eb4782
--- /dev/null
+++ b/drivers/clk/sifive/Kconfig
@@ -0,0 +1,18 @@
+# SPDX-License-Identifier: GPL-2.0
+
+menuconfig CLK_SIFIVE
+   bool "SiFive SoC driver support"
+   help
+ SoC drivers for SiFive Linux-capable SoCs.
+
+if CLK_SIFIVE
+
+config CLK_SIFIVE_FU540_PRCI
+   bool "PRCI driver for SiFive FU540 SoCs"
+   select CLK_ANALOGBITS_WRPLL_CLN28HPC
+   help
+ Supports the Power Reset Clock interface (PRCI) IP block found in
+ FU540 SoCs.  If this kernel is meant to run on a SiFive FU540 SoC,
+ enable this driver.
+
+endif
diff --git a/drivers/clk/sifive/Makefile b/drivers/clk/sifive/Makefile
new file mode 100644
index ..74d58a4c0756
--- /dev/null
+++ b/drivers/clk/sifive/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_CLK_SIFIVE_FU540_PRCI)+= fu540-prci.o
diff --git a/drivers/clk/sifive/fu540-prci.c b/drivers/clk/sifive/fu540-prci.c
new file mode 100644
index ..ecf1dfbcc645
--- /dev/null
+++ b/drivers/clk/sifive/fu540-prci.c
@@ -0,0 +1,630 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 SiFive, Inc.
+ * Wesley Terpstra
+ * Paul Walmsley
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * The FU540 PRCI implements clock and reset control for the SiFive
+ * FU540-C000 chip.  This driver assumes that it has sole control
+ * over all PRCI resources.
+ *
+ * This driver is based on the PRCI driver written by Wesley Terpstra:
+ * 
https://github.com/riscv/riscv-linux/commit/999529edf517ed75b56659d456d221b2ee56bb60
+ *
+ * References:
+ * - SiFive FU540-C000 manual v1p0, Chapter 7 "Clocking and Reset"
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * EXPECTED_CLK_PARENT_COUNT: how many parent clocks this driver expects:
+ * hfclk and rtcclk
+ */
+#define EXPECTED_CLK_PARENT_COUNT  2
+
+/*
+ * Register offsets and bitmasks
+ */
+
+/* COREPLLCFG0 */
+#define PRCI_COREPLLCFG0_OFFSET0x4
+# define PRCI_COREPLLCFG0_DIVR_SHIFT   0
+# define PRCI_COREPLLCFG0_DIVR_MASK(0x3f << 
PRCI_COREPLLCFG0_DIVR_SHIFT)
+# define PRCI_COREPLLCFG0_DIVF_SHIFT   6
+# 

RE: [PATCH 2/2] clk: imx: disable i.mx7ulp composite clock during initialization

2019-04-27 Thread Anson Huang
Hi, Stephen
For this patch series, I think patch [1/2] can be picked up directly, 
for patch[2/2], it can be fixed from driver level, it means drivers should make 
sure the composite clock is gated before changing parent/rate, so no need to do 
any change to composite-7ulp clk driver or core framework. Then the 
assigned-clock-parents/rates may NOT be available for i.MX7ULP, is this OK? It 
is anyway something special on i.MX7ULP HW design, SW needs to follow it.

> -Original Message-
> From: Anson Huang
> Sent: Friday, April 26, 2019 8:50 AM
> To: Stephen Boyd ; feste...@gmail.com;
> gust...@embeddedor.com; ker...@pengutronix.de; linux-arm-
> ker...@lists.infradead.org; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; mturque...@baylibre.com;
> s.ha...@pengutronix.de; shawn...@kernel.org; Aisheng Dong
> 
> Cc: dl-linux-imx 
> Subject: RE: [PATCH 2/2] clk: imx: disable i.mx7ulp composite clock during
> initialization
> 
> Hi, Stephen
> 
> > -Original Message-
> > From: Stephen Boyd [mailto:sb...@kernel.org]
> > Sent: Friday, April 26, 2019 8:03 AM
> > To: feste...@gmail.com; gust...@embeddedor.com;
> ker...@pengutronix.de;
> > linux-arm-ker...@lists.infradead.org; linux- c...@vger.kernel.org;
> > linux-kernel@vger.kernel.org; mturque...@baylibre.com;
> > s.ha...@pengutronix.de; shawn...@kernel.org; Aisheng Dong
> > ; Anson Huang 
> > Cc: dl-linux-imx 
> > Subject: Re: [PATCH 2/2] clk: imx: disable i.mx7ulp composite clock
> > during initialization
> >
> > Quoting Anson Huang (2019-04-24 22:19:12)
> > > i.MX7ULP peripheral clock ONLY allow parent/rate to be changed with
> > > clock gated, however, during clock tree initialization, the
> > > peripheral clock could be enabled by bootloader, but the prepare
> > > count in clock tree is still zero, so clock core driver will allow
> > > parent/rate changed even with
> CLK_SET_RATE_GATE/CLK_SET_PARENT_GATE
> >
> > That's a bug. Can you send a patch to fix the core framework code to
> > fail an assigned rate or parent change if those flags are set? Or is
> > that because the core doesn't respect these flags when they're buried
> > in the middle of the clk tree and some rate or parent change comes in
> > and affects the middle of the tree that has the flag set on it?
> 
> The reason is the core framework ONLY checks the prepare count  and the
> flags to determine whether the parent/rate change is allowed, during driver
> probe phase, the clk prepare count is 0 by default since no one ever prepare
> it, but the default HW status of the clk is actually prepared/enabled, so HW
> will prevent the parent/rate change, and the register write will fail, but 
> core
> framework does NOT know that, it does NOT read back the register value to
> check.
> 
> If want to fix it from core framework, I think it should check the clk's HW
> status by calling .is_enabled() instead of prepare_count, that can reflect the
> real HW status during driver probe phase. Checking the prepare_count is OK
> for later operations by modules clk parent/rate change after clock being
> prepared/unprepared, but it does NOT cover the case of assigning clock from
> DT during driver probe phase I think.
> So do we need to fix it from clk core framework?
> 
>  /* some clocks must be gated to change parent */
>  if (parent != old_parent &&
>  (core->flags & CLK_SET_PARENT_GATE) && core->prepare_count) {
>  pr_debug("%s: %s not gated but wants to reparent\n",
>   __func__, core->name);
>  return NULL;
>  }
> 
> >
> > > set, but the change will fail due to HW NOT allow parent/rate change
> > > with clock enabled. It will cause clock HW status mismatch with
> > > clock tree info and lead to function issue. Below is an example:
> > >
> > > usdhc0's pcc clock value is 0xC500 during kernel boot up, it
> > > means
> > > usdhc0 clock is enabled, its parent is APLL_PFD1. In DT file, the
> > > usdhc0 clock settings are as below:
> > >
> > > assigned-clocks = < IMX7ULP_CLK_USDHC0>; assigned-clock-parents
> > > =
> > > < IMX7ULP_CLK_NIC1_DIV>;
> > >
> > > when kernel boot up, the clock tree info is as below, but the usdhc0
> > > PCC register is still 0xC500, which means its parent is still
> > > from APLL_PFD1, which is incorrect and cause usdhc0 NOT work.
> > >
> > > nic1_clk   220   17600  0 0  5
> > > usdhc0   000   17600  0 0  5
> > >
> > > After making sure the peripheral clock is disabled during clock tree
> > > initialization, the usdhc0 is working, and this change is necessary
> > > for all i.MX7ULP peripheral clocks.
> > >
> > > Signed-off-by: Anson Huang 
> > > ---
> > >  drivers/clk/imx/clk-composite-7ulp.c | 13 +
> > >  1 file changed, 13 insertions(+)
> > >
> > > diff --git a/drivers/clk/imx/clk-composite-7ulp.c
> > > b/drivers/clk/imx/clk-composite-7ulp.c
> > > index 

Re: memleak around kobject_init_and_add()

2019-04-27 Thread Tobin C. Harding
On Sat, Apr 27, 2019 at 09:28:09PM +0200, Greg Kroah-Hartman wrote:
> On Sat, Apr 27, 2019 at 06:13:30PM +1000, Tobin C. Harding wrote:
> > (Note at bottom on reasons for 'To' list 'Cc' list)
> > 
> > Hi,
> > 
> > kobject_init_and_add() seems to be routinely misused.  A failed call to this
> > function requires a call to kobject_put() otherwise we leak memory.
> > 
> > Examples memleaks can be seen in:
> > 
> > mm/slub.c
> > fs/btrfs/sysfs.c
> > fs/xfs/xfs_sysfs.h: xfs_sysfs_init()
> > 
> >  Question: Do we fix the misuse or fix the API?
> 
> Fix the misuse.

Following on from this.  It seems we often also forget to call
kobject_uevent() after calls to kobject_init_and_add().  Before I make a
goose of myself patching the whole tree is there ever any reason why we
would _not_ want to call kobject_uevent() after successfully calling
kobject_add() (or kobject_init_and_add())?

Cheers,
Tobin.


Re: [PATCH AUTOSEL 5.0 03/79] ASoC: ab8500: Mark expected switch fall-through

2019-04-27 Thread Sasha Levin

On Sun, Apr 28, 2019 at 03:00:29AM +0900, Mark Brown wrote:

On Sat, Apr 27, 2019 at 12:31:22PM -0500, Gustavo A. R. Silva wrote:

On 4/27/19 12:14 PM, Mark Brown wrote:



> Are we *realy* going to enable -Wimplicit-fallthrough in stable kernels
> and both backport all the fixes and add new fixes for the issues which
> don't have backportable fixes?



I don't think so.



There are hundreds of these patches in mainline, and I think this is
the first time I see one of them being backported.


Right, this looked like a super weird thing to backport.


I agree, it's part of my scripts to drop them but somehow this one snuck
through. I'll drop it. Thanks for pointing it out!

--
Thanks,
Sasha


Re: [PATCH] x86/kvm: move kvm_load/put_guest_xcr0 into atomic context

2019-04-27 Thread Wanpeng Li
On Fri, 12 Apr 2019 at 16:09, Paolo Bonzini  wrote:
>
> On 12/04/19 09:55, WANG Chao wrote:
> > guest xcr0 could leak into host when MCE happens in guest mode. Because
> > do_machine_check() could schedule out at a few places.
> >
> > For example:
> >
> > kvm_load_guest_xcr0
> > ...
> > kvm_x86_ops->run(vcpu) {
> >   vmx_vcpu_run
> > vmx_complete_atomic_exit
> >   kvm_machine_check
> > do_machine_check
> >   do_memory_failure
> > memory_failure
> >   lock_page

Maybe this should not be counted to guest time in guest_exit_irqoff()?

Regards,
Wanpeng Li

> >
> > In this case, host_xcr0 is 0x2ff, guest vcpu xcr0 is 0xff. After schedule
> > out, host cpu has guest xcr0 loaded (0xff).
> >
> > In __switch_to {
> >  switch_fpu_finish
> >copy_kernel_to_fpregs
> >  XRSTORS
> >
> > If any bit i in XSTATE_BV[i] == 1 and xcr0[i] == 0, XRSTORS will
> > generate #GP (In this case, bit 9). Then ex_handler_fprestore kicks in
> > and tries to reinitialize fpu by restoring init fpu state. Same story as
> > last #GP, except we get DOUBLE FAULT this time.
> >
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: WANG Chao 
>
> Thanks for the detailed commit message.  Patch queued!.
>
> Paolo
>
> > ---
> >  arch/x86/kvm/svm.c |  2 ++
> >  arch/x86/kvm/vmx/vmx.c |  4 
> >  arch/x86/kvm/x86.c | 10 --
> >  arch/x86/kvm/x86.h |  2 ++
> >  4 files changed, 12 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
> > index e0a791c3d4fc..2bf73076de7f 100644
> > --- a/arch/x86/kvm/svm.c
> > +++ b/arch/x86/kvm/svm.c
> > @@ -5621,6 +5621,7 @@ static void svm_vcpu_run(struct kvm_vcpu *vcpu)
> >   svm->vmcb->save.cr2 = vcpu->arch.cr2;
> >
> >   clgi();
> > + kvm_load_guest_xcr0(vcpu);
> >
> >   /*
> >* If this vCPU has touched SPEC_CTRL, restore the guest's value if
> > @@ -5766,6 +5767,7 @@ static void svm_vcpu_run(struct kvm_vcpu *vcpu)
> >   if (unlikely(svm->vmcb->control.exit_code == SVM_EXIT_NMI))
> >   kvm_before_interrupt(>vcpu);
> >
> > + kvm_put_guest_xcr0(vcpu);
> >   stgi();
> >
> >   /* Any pending NMI will happen here */
> > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> > index ab432a930ae8..3157598c52f1 100644
> > --- a/arch/x86/kvm/vmx/vmx.c
> > +++ b/arch/x86/kvm/vmx/vmx.c
> > @@ -6410,6 +6410,8 @@ static void vmx_vcpu_run(struct kvm_vcpu *vcpu)
> >   if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP)
> >   vmx_set_interrupt_shadow(vcpu, 0);
> >
> > + kvm_load_guest_xcr0(vcpu);
> > +
> >   if (static_cpu_has(X86_FEATURE_PKU) &&
> >   kvm_read_cr4_bits(vcpu, X86_CR4_PKE) &&
> >   vcpu->arch.pkru != vmx->host_pkru)
> > @@ -6506,6 +6508,8 @@ static void vmx_vcpu_run(struct kvm_vcpu *vcpu)
> >   __write_pkru(vmx->host_pkru);
> >   }
> >
> > + kvm_put_guest_xcr0(vcpu);
> > +
> >   vmx->nested.nested_run_pending = 0;
> >   vmx->idt_vectoring_info = 0;
> >
> > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > index 099b851dabaf..22f66e9a7dc5 100644
> > --- a/arch/x86/kvm/x86.c
> > +++ b/arch/x86/kvm/x86.c
> > @@ -800,7 +800,7 @@ void kvm_lmsw(struct kvm_vcpu *vcpu, unsigned long msw)
> >  }
> >  EXPORT_SYMBOL_GPL(kvm_lmsw);
> >
> > -static void kvm_load_guest_xcr0(struct kvm_vcpu *vcpu)
> > +void kvm_load_guest_xcr0(struct kvm_vcpu *vcpu)
> >  {
> >   if (kvm_read_cr4_bits(vcpu, X86_CR4_OSXSAVE) &&
> >   !vcpu->guest_xcr0_loaded) {
> > @@ -810,8 +810,9 @@ static void kvm_load_guest_xcr0(struct kvm_vcpu *vcpu)
> >   vcpu->guest_xcr0_loaded = 1;
> >   }
> >  }
> > +EXPORT_SYMBOL_GPL(kvm_load_guest_xcr0);
> >
> > -static void kvm_put_guest_xcr0(struct kvm_vcpu *vcpu)
> > +void kvm_put_guest_xcr0(struct kvm_vcpu *vcpu)
> >  {
> >   if (vcpu->guest_xcr0_loaded) {
> >   if (vcpu->arch.xcr0 != host_xcr0)
> > @@ -819,6 +820,7 @@ static void kvm_put_guest_xcr0(struct kvm_vcpu *vcpu)
> >   vcpu->guest_xcr0_loaded = 0;
> >   }
> >  }
> > +EXPORT_SYMBOL_GPL(kvm_put_guest_xcr0);
> >
> >  static int __kvm_set_xcr(struct kvm_vcpu *vcpu, u32 index, u64 xcr)
> >  {
> > @@ -7865,8 +7867,6 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
> >   goto cancel_injection;
> >   }
> >
> > - kvm_load_guest_xcr0(vcpu);
> > -
> >   if (req_immediate_exit) {
> >   kvm_make_request(KVM_REQ_EVENT, vcpu);
> >   kvm_x86_ops->request_immediate_exit(vcpu);
> > @@ -7919,8 +7919,6 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
> >   vcpu->mode = OUTSIDE_GUEST_MODE;
> >   smp_wmb();
> >
> > - kvm_put_guest_xcr0(vcpu);
> > -
> >   kvm_before_interrupt(vcpu);
> >   kvm_x86_ops->handle_external_intr(vcpu);
> >   kvm_after_interrupt(vcpu);
> > diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h
> > index 28406aa1136d..aedc5d0d4989 100644
> > --- 

Re: Strange issues with epoll since 5.0

2019-04-27 Thread Eric Wong
Deepa Dinamani  wrote:
> I tried to replicate the failure on qemu.
> I do not see the failure with N=32.

> Does it work for N < 32?

Depends on number of cores you have; I have 4 cores, 8 threads
with HT; so I needed to have a lot of load on the machine to get
it to fail (it takes about 1 minute).

cmogstored is intended to run on machines that were already
saturated in CPU/memory from other processes, but not HDD I/O
bandwidth.

> Does any other signal work?

SIGCONT does, via:

   perl -i -p -e 's/SIGURG/SIGCONT/g' `git ls-files`

> Are there any other architectures that fail?

I don't have other arches (well, 32-bit x86, but I've never
really tried cmogstored on that, even).

> Could you help me figure out how to run just the one test that is failing?

Just running one test won't trigger since it needs a busy
machine; but:

make test/mgmt_auto_adjust.log
(and "rm make test/mgmt_auto_adjust.log" if you want to rerun)

Thanks for looking into this.  Fwiw, cmogstored uses epoll in
strange and uncommon ways which has led to kernel bugfixes
in the past.


[PATCH] kobject: Improve docs for kobject_add/del

2019-04-27 Thread Tobin C. Harding
There is currently some confusion on how to wind back
kobject_init_and_add() during the error paths in code that uses this
function.

Add documentation to kobject_add() and kobject_del() to help clarify the
usage.

Signed-off-by: Tobin C. Harding 
---

The assumption is that this is the correct usage, and that's what I've
tried to document.  Is this correct?

void fn(void)
{
int ret;

ret = kobject_init_and_add(kobj, ktype, NULL, "foo");
if (ret) {
kobject_put(kobj);
return -1;
}

ret = some_init_fn();
if (ret)
goto err;

ret = some_other_init_fn();
if (ret)
goto other_err;

kobject_uevent(kobj, KOBJ_ADD);
return 0;

other_err:
other_clean_up_fn();
err:
kobject_del(kobj);
return ret;
}

thanks,
Tobin.

 lib/kobject.c | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/lib/kobject.c b/lib/kobject.c
index aa89edcd2b63..b2670671977b 100644
--- a/lib/kobject.c
+++ b/lib/kobject.c
@@ -397,15 +397,19 @@ static __printf(3, 0) int kobject_add_varg(struct kobject 
*kobj,
  * is assigned to the kobject, then the kobject will be located in the
  * root of the sysfs tree.
  *
- * If this function returns an error, kobject_put() must be called to
- * properly clean up the memory associated with the object.
- * Under no instance should the kobject that is passed to this function
- * be directly freed with a call to kfree(), that can leak memory.
- *
  * Note, no "add" uevent will be created with this call, the caller should set
  * up all of the necessary sysfs files for the object and then call
  * kobject_uevent() with the UEVENT_ADD parameter to ensure that
  * userspace is properly notified of this kobject's creation.
+ *
+ * Return: If this function returns an error, kobject_put() must be
+ * called to properly clean up the memory associated with the
+ * object.  Under no instance should the kobject that is passed
+ * to this function be directly freed with a call to kfree(),
+ * that can leak memory.
+ *
+ * If this call returns successfully and you later need to unwind
+ * kobject_add() for the error path you should call kobject_del().
  */
 int kobject_add(struct kobject *kobj, struct kobject *parent,
const char *fmt, ...)
@@ -580,6 +584,9 @@ EXPORT_SYMBOL_GPL(kobject_move);
 /**
  * kobject_del - unlink kobject from hierarchy.
  * @kobj: object.
+ *
+ * This is the function that should be called to delete an object
+ * successfully added via kobject_add().
  */
 void kobject_del(struct kobject *kobj)
 {
-- 
2.21.0



[RFT PATCH v4 0/5] Unify CPU topology across ARM & RISC-V

2019-04-27 Thread Atish Patra
The cpu-map DT entry in ARM can describe the CPU topology in much better
way compared to other existing approaches. RISC-V can easily adopt this
binding to represent its own CPU topology. Thus, both cpu-map DT
binding and topology parsing code can be moved to a common location so
that RISC-V or any other architecture can leverage that.

The relevant discussion regarding unifying cpu topology can be found in
[1].

arch_topology seems to be a perfect place to move the common code. I
have not introduced any significant functional changes in the moved code.
The only downside in this approach is that the capacity code will be
executed for RISC-V as well. But, it will exit immediately after not
able to find the appropriate DT node. If the overhead is considered too
much, we can always compile out capacity related functions under a
different config for the architectures that do not support them.

There was an opportunity to unify topology data structure for ARM32 done
by patch 3/4. But, I refrained from making any other changes as I am not
very well versed with original intention for some functions that
are present in arch_topology.c. I hope this patch series can be served
as a baseline for such changes in the future.

The patches have been tested for RISC-V and compile tested for ARM64,
ARM32 & x86.

The socket change[2] is also now part of this series.

[1] https://lkml.org/lkml/2018/11/6/19
[2] https://lkml.org/lkml/2018/11/7/918

QEMU changes for RISC-V topology are available at

https://github.com/atishp04/qemu/tree/riscv_topology_dt

HiFive Unleashed DT with topology node is available here.
https://github.com/atishp04/opensbi/tree/HiFive_unleashed_topology

It can be verified with OpenSBI with following additional compile time
option.

FW_PAYLOAD_FDT="unleashed_topology.dtb"

Changes from v3->v4
1. Get rid of ARM32 specific information in topology strucuture.
2. Remove redundant functions from ARM32 and use common code instead. 

Changes from v2->v3
1. Cover letter update with experiment DT for topology changes.
2. Added the patch for [2].

Changes from v1->v2
1. ARM32 can now use the common code as well.

Atish Patra (4):
dt-binding: cpu-topology: Move cpu-map to a common binding.
cpu-topology: Move cpu topology code to common code.
arm: Use common cpu_topology structure and functions.
RISC-V: Parse cpu topology during boot.

Sudeep Holla (1):
Documentation: DT: arm: add support for sockets defining package
boundaries

.../topology.txt => cpu/cpu-topology.txt} | 134 ++--
arch/arm/include/asm/topology.h   |  20 --
arch/arm/kernel/topology.c|  60 +---
arch/arm64/include/asm/topology.h |  23 --
arch/arm64/kernel/topology.c  | 303 +-
arch/riscv/Kconfig|   1 +
arch/riscv/kernel/smpboot.c   |   3 +
drivers/base/arch_topology.c  | 300 -
drivers/base/topology.c   |   1 +
include/linux/arch_topology.h |  26 ++
10 files changed, 445 insertions(+), 426 deletions(-)
rename Documentation/devicetree/bindings/{arm/topology.txt => 
cpu/cpu-topology.txt} (66%)

--
2.21.0



[RFT PATCH v4 2/5] dt-binding: cpu-topology: Move cpu-map to a common binding.

2019-04-27 Thread Atish Patra
cpu-map binding can be used to described cpu topology for both
RISC-V & ARM. It makes more sense to move the binding to document
to a common place.

The relevant discussion can be found here.
https://lkml.org/lkml/2018/11/6/19

Signed-off-by: Atish Patra 
Reviewed-by: Sudeep Holla 
Reviewed-by: Rob Herring 
---
 .../topology.txt => cpu/cpu-topology.txt} | 82 +++
 1 file changed, 66 insertions(+), 16 deletions(-)
 rename Documentation/devicetree/bindings/{arm/topology.txt => 
cpu/cpu-topology.txt} (86%)

diff --git a/Documentation/devicetree/bindings/arm/topology.txt 
b/Documentation/devicetree/bindings/cpu/cpu-topology.txt
similarity index 86%
rename from Documentation/devicetree/bindings/arm/topology.txt
rename to Documentation/devicetree/bindings/cpu/cpu-topology.txt
index 3b8febb46dad..069addccab14 100644
--- a/Documentation/devicetree/bindings/arm/topology.txt
+++ b/Documentation/devicetree/bindings/cpu/cpu-topology.txt
@@ -1,12 +1,12 @@
 ===
-ARM topology binding description
+CPU topology binding description
 ===
 
 ===
 1 - Introduction
 ===
 
-In an ARM system, the hierarchy of CPUs is defined through three entities that
+In a SMP system, the hierarchy of CPUs is defined through three entities that
 are used to describe the layout of physical CPUs in the system:
 
 - socket
@@ -14,9 +14,6 @@ are used to describe the layout of physical CPUs in the 
system:
 - core
 - thread
 
-The cpu nodes (bindings defined in [1]) represent the devices that
-correspond to physical CPUs and are to be mapped to the hierarchy levels.
-
 The bottom hierarchy level sits at core or thread level depending on whether
 symmetric multi-threading (SMT) is supported or not.
 
@@ -25,33 +22,31 @@ threads existing in the system and map to the hierarchy 
level "thread" above.
 In systems where SMT is not supported "cpu" nodes represent all cores present
 in the system and map to the hierarchy level "core" above.
 
-ARM topology bindings allow one to associate cpu nodes with hierarchical groups
+CPU topology bindings allow one to associate cpu nodes with hierarchical groups
 corresponding to the system hierarchy; syntactically they are defined as device
 tree nodes.
 
-The remainder of this document provides the topology bindings for ARM, based
-on the Devicetree Specification, available from:
+Currently, only ARM/RISC-V intend to use this cpu topology binding but it may 
be
+used for any other architecture as well.
 
-https://www.devicetree.org/specifications/
+The cpu nodes, as per bindings defined in [4], represent the devices that
+correspond to physical CPUs and are to be mapped to the hierarchy levels.
 
-If not stated otherwise, whenever a reference to a cpu node phandle is made its
-value must point to a cpu node compliant with the cpu node bindings as
-documented in [1].
 A topology description containing phandles to cpu nodes that are not compliant
-with bindings standardized in [1] is therefore considered invalid.
+with bindings standardized in [4] is therefore considered invalid.
 
 ===
 2 - cpu-map node
 ===
 
-The ARM CPU topology is defined within the cpu-map node, which is a direct
+The ARM/RISC-V CPU topology is defined within the cpu-map node, which is a 
direct
 child of the cpus node and provides a container where the actual topology
 nodes are listed.
 
 - cpu-map node
 
-   Usage: Optional - On ARM SMP systems provide CPUs topology to the OS.
- ARM uniprocessor systems do not require a topology
+   Usage: Optional - On SMP systems provide CPUs topology to the OS.
+ Uniprocessor systems do not require a topology
  description and therefore should not define a
  cpu-map node.
 
@@ -494,8 +489,63 @@ cpus {
};
 };
 
+Example 3: HiFive Unleashed (RISC-V 64 bit, 4 core system)
+
+{
+   #address-cells = <2>;
+   #size-cells = <2>;
+   compatible = "sifive,fu540g", "sifive,fu500";
+   model = "sifive,hifive-unleashed-a00";
+
+   ...
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   cpu-map {
+   cluster0 {
+   core0 {
+   cpu = <>;
+   };
+   core1 {
+   cpu = <>;
+   };
+   core2 {
+   cpu0 = <>;
+   };
+   core3 {
+   cpu0 = <>;
+   };
+   };
+   };
+
+ 

[RFT PATCH v4 3/5] cpu-topology: Move cpu topology code to common code.

2019-04-27 Thread Atish Patra
Both RISC-V & ARM64 are using cpu-map device tree to describe
their cpu topology. It's better to move the relevant code to
a common place instead of duplicate code.

Signed-off-by: Atish Patra 
Tested-by: Jeffrey Hugo 
---
 arch/arm64/include/asm/topology.h |  23 ---
 arch/arm64/kernel/topology.c  | 303 +-
 drivers/base/arch_topology.c  | 298 -
 drivers/base/topology.c   |   1 +
 include/linux/arch_topology.h |  28 +++
 5 files changed, 330 insertions(+), 323 deletions(-)

diff --git a/arch/arm64/include/asm/topology.h 
b/arch/arm64/include/asm/topology.h
index 0524f2438649..a4d945db95a2 100644
--- a/arch/arm64/include/asm/topology.h
+++ b/arch/arm64/include/asm/topology.h
@@ -4,29 +4,6 @@
 
 #include 
 
-struct cpu_topology {
-   int thread_id;
-   int core_id;
-   int package_id;
-   int llc_id;
-   cpumask_t thread_sibling;
-   cpumask_t core_sibling;
-   cpumask_t llc_sibling;
-};
-
-extern struct cpu_topology cpu_topology[NR_CPUS];
-
-#define topology_physical_package_id(cpu)  (cpu_topology[cpu].package_id)
-#define topology_core_id(cpu)  (cpu_topology[cpu].core_id)
-#define topology_core_cpumask(cpu) (_topology[cpu].core_sibling)
-#define topology_sibling_cpumask(cpu)  (_topology[cpu].thread_sibling)
-#define topology_llc_cpumask(cpu)  (_topology[cpu].llc_sibling)
-
-void init_cpu_topology(void);
-void store_cpu_topology(unsigned int cpuid);
-void remove_cpu_topology(unsigned int cpuid);
-const struct cpumask *cpu_coregroup_mask(int cpu);
-
 #ifdef CONFIG_NUMA
 
 struct pci_bus;
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index 0825c4a856e3..6b95c91e7d67 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -14,250 +14,13 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
 
 #include 
 #include 
 #include 
 
-static int __init get_cpu_for_node(struct device_node *node)
-{
-   struct device_node *cpu_node;
-   int cpu;
-
-   cpu_node = of_parse_phandle(node, "cpu", 0);
-   if (!cpu_node)
-   return -1;
-
-   cpu = of_cpu_node_to_id(cpu_node);
-   if (cpu >= 0)
-   topology_parse_cpu_capacity(cpu_node, cpu);
-   else
-   pr_crit("Unable to find CPU node for %pOF\n", cpu_node);
-
-   of_node_put(cpu_node);
-   return cpu;
-}
-
-static int __init parse_core(struct device_node *core, int package_id,
-int core_id)
-{
-   char name[10];
-   bool leaf = true;
-   int i = 0;
-   int cpu;
-   struct device_node *t;
-
-   do {
-   snprintf(name, sizeof(name), "thread%d", i);
-   t = of_get_child_by_name(core, name);
-   if (t) {
-   leaf = false;
-   cpu = get_cpu_for_node(t);
-   if (cpu >= 0) {
-   cpu_topology[cpu].package_id = package_id;
-   cpu_topology[cpu].core_id = core_id;
-   cpu_topology[cpu].thread_id = i;
-   } else {
-   pr_err("%pOF: Can't get CPU for thread\n",
-  t);
-   of_node_put(t);
-   return -EINVAL;
-   }
-   of_node_put(t);
-   }
-   i++;
-   } while (t);
-
-   cpu = get_cpu_for_node(core);
-   if (cpu >= 0) {
-   if (!leaf) {
-   pr_err("%pOF: Core has both threads and CPU\n",
-  core);
-   return -EINVAL;
-   }
-
-   cpu_topology[cpu].package_id = package_id;
-   cpu_topology[cpu].core_id = core_id;
-   } else if (leaf) {
-   pr_err("%pOF: Can't get CPU for leaf core\n", core);
-   return -EINVAL;
-   }
-
-   return 0;
-}
-
-static int __init parse_cluster(struct device_node *cluster, int depth)
-{
-   char name[10];
-   bool leaf = true;
-   bool has_cores = false;
-   struct device_node *c;
-   static int package_id __initdata;
-   int core_id = 0;
-   int i, ret;
-
-   /*
-* First check for child clusters; we currently ignore any
-* information about the nesting of clusters and present the
-* scheduler with a flat list of them.
-*/
-   i = 0;
-   do {
-   snprintf(name, sizeof(name), "cluster%d", i);
-   c = of_get_child_by_name(cluster, name);
-   if (c) {
-   leaf = false;
-   ret = parse_cluster(c, depth + 1);
-   of_node_put(c);
-   if (ret 

[RFT PATCH v4 4/5] arm: Use common cpu_topology structure and functions.

2019-04-27 Thread Atish Patra
Currently, ARM32 and ARM64 uses different data structures to represent
their cpu toplogies. Since, we are moving the ARM64 topology to common
code to be used by other architectures, we can reuse that for ARM32 as
well.

Take this opprtunity to remove the redundant functions from ARM32 and
reuse the common code instead.

Signed-off-by: Atish Patra 
---
 arch/arm/include/asm/topology.h | 20 ---
 arch/arm/kernel/topology.c  | 60 -
 drivers/base/arch_topology.c|  4 ++-
 include/linux/arch_topology.h   |  6 ++--
 4 files changed, 11 insertions(+), 79 deletions(-)

diff --git a/arch/arm/include/asm/topology.h b/arch/arm/include/asm/topology.h
index 2a786f54d8b8..8a0fae94d45e 100644
--- a/arch/arm/include/asm/topology.h
+++ b/arch/arm/include/asm/topology.h
@@ -5,26 +5,6 @@
 #ifdef CONFIG_ARM_CPU_TOPOLOGY
 
 #include 
-
-struct cputopo_arm {
-   int thread_id;
-   int core_id;
-   int socket_id;
-   cpumask_t thread_sibling;
-   cpumask_t core_sibling;
-};
-
-extern struct cputopo_arm cpu_topology[NR_CPUS];
-
-#define topology_physical_package_id(cpu)  (cpu_topology[cpu].socket_id)
-#define topology_core_id(cpu)  (cpu_topology[cpu].core_id)
-#define topology_core_cpumask(cpu) (_topology[cpu].core_sibling)
-#define topology_sibling_cpumask(cpu)  (_topology[cpu].thread_sibling)
-
-void init_cpu_topology(void);
-void store_cpu_topology(unsigned int cpuid);
-const struct cpumask *cpu_coregroup_mask(int cpu);
-
 #include 
 
 /* Replace task scheduler's default frequency-invariant accounting */
diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
index 60e375ce1ab2..238f1da0219c 100644
--- a/arch/arm/kernel/topology.c
+++ b/arch/arm/kernel/topology.c
@@ -177,17 +177,6 @@ static inline void parse_dt_topology(void) {}
 static inline void update_cpu_capacity(unsigned int cpuid) {}
 #endif
 
- /*
- * cpu topology table
- */
-struct cputopo_arm cpu_topology[NR_CPUS];
-EXPORT_SYMBOL_GPL(cpu_topology);
-
-const struct cpumask *cpu_coregroup_mask(int cpu)
-{
-   return _topology[cpu].core_sibling;
-}
-
 /*
  * The current assumption is that we can power gate each core independently.
  * This will be superseded by DT binding once available.
@@ -197,32 +186,6 @@ const struct cpumask *cpu_corepower_mask(int cpu)
return _topology[cpu].thread_sibling;
 }
 
-static void update_siblings_masks(unsigned int cpuid)
-{
-   struct cputopo_arm *cpu_topo, *cpuid_topo = _topology[cpuid];
-   int cpu;
-
-   /* update core and thread sibling masks */
-   for_each_possible_cpu(cpu) {
-   cpu_topo = _topology[cpu];
-
-   if (cpuid_topo->socket_id != cpu_topo->socket_id)
-   continue;
-
-   cpumask_set_cpu(cpuid, _topo->core_sibling);
-   if (cpu != cpuid)
-   cpumask_set_cpu(cpu, _topo->core_sibling);
-
-   if (cpuid_topo->core_id != cpu_topo->core_id)
-   continue;
-
-   cpumask_set_cpu(cpuid, _topo->thread_sibling);
-   if (cpu != cpuid)
-   cpumask_set_cpu(cpu, _topo->thread_sibling);
-   }
-   smp_wmb();
-}
-
 /*
  * store_cpu_topology is called at boot when only one cpu is running
  * and with the mutex cpu_hotplug.lock locked, when several cpus have booted,
@@ -230,7 +193,7 @@ static void update_siblings_masks(unsigned int cpuid)
  */
 void store_cpu_topology(unsigned int cpuid)
 {
-   struct cputopo_arm *cpuid_topo = _topology[cpuid];
+   struct cpu_topology *cpuid_topo = _topology[cpuid];
unsigned int mpidr;
 
/* If the cpu topology has been already set, just return */
@@ -250,12 +213,12 @@ void store_cpu_topology(unsigned int cpuid)
/* core performance interdependency */
cpuid_topo->thread_id = MPIDR_AFFINITY_LEVEL(mpidr, 0);
cpuid_topo->core_id = MPIDR_AFFINITY_LEVEL(mpidr, 1);
-   cpuid_topo->socket_id = MPIDR_AFFINITY_LEVEL(mpidr, 2);
+   cpuid_topo->package_id = MPIDR_AFFINITY_LEVEL(mpidr, 2);
} else {
/* largely independent cores */
cpuid_topo->thread_id = -1;
cpuid_topo->core_id = MPIDR_AFFINITY_LEVEL(mpidr, 0);
-   cpuid_topo->socket_id = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+   cpuid_topo->package_id = MPIDR_AFFINITY_LEVEL(mpidr, 1);
}
} else {
/*
@@ -265,7 +228,7 @@ void store_cpu_topology(unsigned int cpuid)
 */
cpuid_topo->thread_id = -1;
cpuid_topo->core_id = 0;
-   cpuid_topo->socket_id = -1;
+   cpuid_topo->package_id = -1;
}
 
update_siblings_masks(cpuid);
@@ -275,7 +238,7 @@ void store_cpu_topology(unsigned int cpuid)
pr_info("CPU%u: 

[RFT PATCH v4 5/5] RISC-V: Parse cpu topology during boot.

2019-04-27 Thread Atish Patra
Currently, there are no topology defined for RISC-V.
Parse the cpu-map node from device tree and setup the
cpu topology.

CPU topology after applying the patch.
$cat /sys/devices/system/cpu/cpu2/topology/core_siblings_list
0-3
$cat /sys/devices/system/cpu/cpu3/topology/core_siblings_list
0-3
$cat /sys/devices/system/cpu/cpu3/topology/physical_package_id
0
$cat /sys/devices/system/cpu/cpu3/topology/core_id
3

Signed-off-by: Atish Patra 
---
 arch/riscv/Kconfig  | 1 +
 arch/riscv/kernel/smpboot.c | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index eb56c82d8aa1..ac87a0ec8b5c 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -47,6 +47,7 @@ config RISCV
select PCI_MSI if PCI
select RISCV_TIMER
select GENERIC_IRQ_MULTI_HANDLER
+   select GENERIC_ARCH_TOPOLOGY if SMP
select ARCH_HAS_PTE_SPECIAL
select HAVE_EBPF_JIT if 64BIT
 
diff --git a/arch/riscv/kernel/smpboot.c b/arch/riscv/kernel/smpboot.c
index 7a0b62252524..54f89d5b19ba 100644
--- a/arch/riscv/kernel/smpboot.c
+++ b/arch/riscv/kernel/smpboot.c
@@ -16,6 +16,7 @@
  * GNU General Public License for more details.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -43,6 +44,7 @@ static DECLARE_COMPLETION(cpu_running);
 
 void __init smp_prepare_boot_cpu(void)
 {
+   init_cpu_topology();
 }
 
 void __init smp_prepare_cpus(unsigned int max_cpus)
@@ -146,6 +148,7 @@ asmlinkage void __init smp_callin(void)
 
trap_init();
notify_cpu_starting(smp_processor_id());
+   update_siblings_masks(smp_processor_id());
set_cpu_online(smp_processor_id(), 1);
/*
 * Remote TLB flushes are ignored while the CPU is offline, so emit
-- 
2.21.0



[RFT PATCH v4 1/5] Documentation: DT: arm: add support for sockets defining package boundaries

2019-04-27 Thread Atish Patra
From: Sudeep Holla 

The current ARM DT topology description provides the operating system
with a topological view of the system that is based on leaf nodes
representing either cores or threads (in an SMT system) and a
hierarchical set of cluster nodes that creates a hierarchical topology
view of how those cores and threads are grouped.

However this hierarchical representation of clusters does not allow to
describe what topology level actually represents the physical package or
the socket boundary, which is a key piece of information to be used by
an operating system to optimize resource allocation and scheduling.

Lets add a new "socket" node type in the cpu-map node to describe the
same.

Signed-off-by: Sudeep Holla 
Reviewed-by: Rob Herring 
---
 .../devicetree/bindings/arm/topology.txt  | 52 ++-
 1 file changed, 39 insertions(+), 13 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/topology.txt 
b/Documentation/devicetree/bindings/arm/topology.txt
index b0d80c0fb265..3b8febb46dad 100644
--- a/Documentation/devicetree/bindings/arm/topology.txt
+++ b/Documentation/devicetree/bindings/arm/topology.txt
@@ -9,6 +9,7 @@ ARM topology binding description
 In an ARM system, the hierarchy of CPUs is defined through three entities that
 are used to describe the layout of physical CPUs in the system:
 
+- socket
 - cluster
 - core
 - thread
@@ -63,21 +64,23 @@ nodes are listed.
 
The cpu-map node's child nodes can be:
 
-   - one or more cluster nodes
+   - one or more cluster nodes or
+   - one or more socket nodes in a multi-socket system
 
Any other configuration is considered invalid.
 
-The cpu-map node can only contain three types of child nodes:
+The cpu-map node can only contain 4 types of child nodes:
 
+- socket node
 - cluster node
 - core node
 - thread node
 
 whose bindings are described in paragraph 3.
 
-The nodes describing the CPU topology (cluster/core/thread) can only
-be defined within the cpu-map node and every core/thread in the system
-must be defined within the topology.  Any other configuration is
+The nodes describing the CPU topology (socket/cluster/core/thread) can
+only be defined within the cpu-map node and every core/thread in the
+system must be defined within the topology.  Any other configuration is
 invalid and therefore must be ignored.
 
 ===
@@ -85,26 +88,44 @@ invalid and therefore must be ignored.
 ===
 
 cpu-map child nodes must follow a naming convention where the node name
-must be "clusterN", "coreN", "threadN" depending on the node type (ie
-cluster/core/thread) (where N = {0, 1, ...} is the node number; nodes which
-are siblings within a single common parent node must be given a unique and
+must be "socketN", "clusterN", "coreN", "threadN" depending on the node type
+(ie socket/cluster/core/thread) (where N = {0, 1, ...} is the node number; 
nodes
+which are siblings within a single common parent node must be given a unique 
and
 sequential N value, starting from 0).
 cpu-map child nodes which do not share a common parent node can have the same
 name (ie same number N as other cpu-map child nodes at different device tree
 levels) since name uniqueness will be guaranteed by the device tree hierarchy.
 
 ===
-3 - cluster/core/thread node bindings
+3 - socket/cluster/core/thread node bindings
 ===
 
-Bindings for cluster/cpu/thread nodes are defined as follows:
+Bindings for socket/cluster/cpu/thread nodes are defined as follows:
+
+- socket node
+
+Description: must be declared within a cpu-map node, one node
+ per physical socket in the system. A system can
+ contain single or multiple physical socket.
+ The association of sockets and NUMA nodes is beyond
+ the scope of this bindings, please refer [2] for
+ NUMA bindings.
+
+   This node is optional for a single socket system.
+
+   The socket node name must be "socketN" as described in 2.1 above.
+   A socket node can not be a leaf node.
+
+   A socket node's child nodes must be one or more cluster nodes.
+
+   Any other configuration is considered invalid.
 
 - cluster node
 
 Description: must be declared within a cpu-map node, one node
  per cluster. A system can contain several layers of
- clustering and cluster nodes can be contained in parent
- cluster nodes.
+ clustering within a single physical socket and cluster
+ nodes can be contained in parent cluster nodes.
 
The cluster node name must be "clusterN" as described in 2.1 above.
A cluster node can not be a leaf node.
@@ -164,13 +185,15 @@ Bindings for cluster/cpu/thread nodes are defined as 

[PATCH] kobject: Improve doc clarity kobject_init_and_add()

2019-04-27 Thread Tobin C. Harding
Function kobject_init_and_add() is currently misused in a number of
places in the kernel.  On error return kobject_put() must be called but
is at times not.

Make the function documentation more explicit about calling
kobject_put() in the error path.

Signed-off-by: Tobin C. Harding 
---
 lib/kobject.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/lib/kobject.c b/lib/kobject.c
index aa89edcd2b63..58d1d7a64203 100644
--- a/lib/kobject.c
+++ b/lib/kobject.c
@@ -437,9 +437,12 @@ EXPORT_SYMBOL(kobject_add);
  * @parent: pointer to the parent of this kobject.
  * @fmt: the name of the kobject.
  *
- * This function combines the call to kobject_init() and
- * kobject_add().  The same type of error handling after a call to
- * kobject_add() and kobject lifetime rules are the same here.
+ * This function combines the call to kobject_init() and kobject_add().
+ *
+ * If this function returns an error, kobject_put() must be called to
+ * properly clean up the memory associated with the object.  This is the
+ * same type of error handling after a call to kobject_add() and kobject
+ * lifetime rules are the same here.
  */
 int kobject_init_and_add(struct kobject *kobj, struct kobj_type *ktype,
 struct kobject *parent, const char *fmt, ...)
-- 
2.21.0



[PATCH] mm: Fix kobject memleak in SLUB

2019-04-27 Thread Tobin C. Harding
Currently error return from kobject_init_and_add() is not followed by a
call to kobject_put().  This means there is a memory leak.

Add call to kobject_put() in error path of kobject_init_and_add().

Signed-off-by: Tobin C. Harding 
---
 mm/slub.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/mm/slub.c b/mm/slub.c
index d30ede89f4a6..84a9d6c06c27 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -5756,8 +5756,10 @@ static int sysfs_slab_add(struct kmem_cache *s)
 
s->kobj.kset = kset;
err = kobject_init_and_add(>kobj, _ktype, NULL, "%s", name);
-   if (err)
+   if (err) {
+   kobject_put(>kobj);
goto out;
+   }
 
err = sysfs_create_group(>kobj, _attr_group);
if (err)
-- 
2.21.0



Re: memleak around kobject_init_and_add()

2019-04-27 Thread Tobin C. Harding
On Sat, Apr 27, 2019 at 09:28:09PM +0200, Greg Kroah-Hartman wrote:
> On Sat, Apr 27, 2019 at 06:13:30PM +1000, Tobin C. Harding wrote:
> > (Note at bottom on reasons for 'To' list 'Cc' list)
> > 
> > Hi,
> > 
> > kobject_init_and_add() seems to be routinely misused.  A failed call to this
> > function requires a call to kobject_put() otherwise we leak memory.
> > 
> > Examples memleaks can be seen in:
> > 
> > mm/slub.c
> > fs/btrfs/sysfs.c
> > fs/xfs/xfs_sysfs.h: xfs_sysfs_init()
> > 
> >  Question: Do we fix the misuse or fix the API?
> 
> Fix the misuse.

Cool, I got it!

> > $ git grep kobject_init_and_add | wc -l
> > 117
> > 
> > Either way, we will have to go through all 117 call sites and check them.
> 
> Yes.  Same for other functions like device_add(), that is the "pattern"
> those users must follow.
> 
> > I
> > don't mind fixing them all but I don't want to do it twice because I chose 
> > the
> > wrong option.  Reaching out to those more experienced for a suggestion 
> > please.
> > 
> > Fix the API
> > ---
> > 
> > Typically init functions do not require cleanup if they fail, this argument
> > leads to this patch
> > 
> > diff --git a/lib/kobject.c b/lib/kobject.c
> > index aa89edcd2b63..62328054bbd0 100644
> > --- a/lib/kobject.c
> > +++ b/lib/kobject.c
> > @@ -453,6 +453,9 @@ int kobject_init_and_add(struct kobject *kobj, struct 
> > kobj_type *ktype,
> > retval = kobject_add_varg(kobj, parent, fmt, args);
> > va_end(args);
> >  
> > +   if (retval)
> > +   kobject_put(kobj);
> > +
> > return retval;
> >  }
> >  EXPORT_SYMBOL_GPL(kobject_init_and_add);
> 
> I would _love_ to do this, but realize what a kobject really is.
> 
> It's just a "base object" that is embedded inside of some other object.
> The kobject core has no idea what is going on outside of itself.  If the
> kobject_init_and_add() function fails, it can NOT drop the last
> reference on itself, as that would cause the memory owned by the _WHOLE_
> structure the kobject is embedded in, to be freed.
> 
> And the kobject core can not "know" that something else needed to be
> done _before_ that memory could be freed.  What if the larger structure
> needs to have some other destructor called on it first?  What if
> some other api initialization needs to be torn down.
> 
> As an example, consider this code:
> 
> struct foo {
>   struct kobject kobj;
>   struct baz *baz;
> };
> 
> void foo_release(struct kobject *kobj)
> {
>   struct foo *foo = container_of(kobj, struct foo, kobj);
>   kfree(foo);
> }
> 
> struct kobj_type foo_ktype = {
>   .release = foo_release,
> };
> 
> struct foo *foo_create(struct foo *parent, char *name)
> {
>   struct *foo;
> 
>   foo = kzalloc(sizeof(*foo), GFP_KERNEL);
>   if (!foo)
>   return NULL;
> 
>   foo->baz = baz_create(name);
>   if (!foo->baz)
>   return NULL;
> 
>   ret = kobject_init_and_add(>kobj, foo_ktype, >kobj, 
> "foo-%s", name);
>   if (ret) {
>   baz_destroy(foo->baz);
>   kobject_put(>kobj);
>   return NULL;
>   }
> 
>   return foo;
> }
> 
> void foo_destroy(struct foo *foo)
> {
>   baz_destroy(foo->baz);
>   kobject_del(>kobj);
> }
> 
> Now if kobject_init_and_add() had failed, and called kobject_put() right
> away, that would have freed the larger "struct foo", but not cleaned up
> the reference to the baz pointer.
> 
> Yes, you can move all of the other destruction logic into the release
> function, to then get rid of baz, but that really doesn't work in the
> real world as there are times you want to drop that when you "know" you
> can drop it, not when the last reference goes away as those are
> different lifecycles.
> 
> Same thing goes for 'struct device'.  It too is a kobject, so think
> about if the driver core's call to initialize the kobject failed, would
> it be ok at that exact moment in time to free everything?
> 
> Look at the "joy" that is device_add().  If kobject_add() fails, we have
> to clean up the glue directory that we had created, _before_ we can then
> call put_device().  Then stack another layer on top of that, look at
> usb_new_device().  If the call to device_add() fails, it needs to do
> some housekeeping before it can drop the last reference to the device to
> free the memory up.

Thanks for the detailed response, unusual objects call for unusual
coding practices eh ;)

> > Fix all the call sites
> > --
> > 
> > Go through all 117 call sites and add kobj_put() in the error path.
> 
> Yes.
> 
> > This example from mm/slub.c
> > 
> > diff --git a/mm/slub.c b/mm/slub.c
> > index d30ede89f4a6..84a9d6c06c27 100644
> > --- a/mm/slub.c
> > +++ b/mm/slub.c
> > @@ -5756,8 +5756,10 @@ static int sysfs_slab_add(struct kmem_cache *s)
> >  
> > s->kobj.kset = kset;
> > err = kobject_init_and_add(>kobj, _ktype, NULL, "%s", name);
> > -   if (err)
> > +   if (err) {
> > +   

Re: Strange issues with epoll since 5.0

2019-04-27 Thread Deepa Dinamani
I tried to replicate the failure on qemu.
I do not see the failure with N=32.

Does it work for N < 32?
Does any other signal work?
Are there any other architectures that fail?

Could you help me figure out how to run just the one test that is failing?

-Deepa


[git pull] Input updates for v5.1-rc6

2019-04-27 Thread Dmitry Torokhov
Hi Linus,

Please pull from:

git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus

to receive updates for the input subsystem. Just a couple of fixups for
Synaptics RMI4 driver and allowing snvs_pwrkey to be selected on more
boards.

Changelog:
-

Jacky Bai (1):
  Input: snvs_pwrkey - make it depend on ARCH_MXC

Lucas Stach (1):
  Input: synaptics-rmi4 - write config register values to the right offset

Pan Bian (1):
  Input: synaptics-rmi4 - fix possible double free

Diffstat:


 drivers/input/keyboard/Kconfig  | 2 +-
 drivers/input/rmi4/rmi_driver.c | 6 +-
 drivers/input/rmi4/rmi_f11.c| 2 +-
 3 files changed, 3 insertions(+), 7 deletions(-)

Thanks.


-- 
Dmitry


Re: Linux 5.0.10

2019-04-27 Thread Bhaskar Chowdhury

Thanks, man!
On 14:44 Sat 27 Apr , Greg KH wrote:

I'm announcing the release of the 5.0.10 kernel.

All users of the 5.0 kernel series must upgrade.

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

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

thanks,

greg k-h



Makefile |5
arch/arm64/include/asm/futex.h   |2
arch/s390/boot/mem_detect.c  |2
arch/x86/crypto/poly1305-avx2-x86_64.S   |   14 +
arch/x86/crypto/poly1305-sse2-x86_64.S   |   22 +-
arch/x86/events/amd/core.c   |   35 +++-
arch/x86/events/intel/core.c |2
arch/x86/events/perf_event.h |   38 ++--
arch/x86/kernel/cpu/bugs.c   |6
arch/x86/kernel/kprobes/core.c   |   48 ++
arch/x86/kernel/process.c|8 -
arch/x86/kvm/emulate.c   |   21 +-
arch/x86/kvm/svm.c   |   24 ++-
arch/x86/kvm/vmx/vmx.c   |4
arch/x86/kvm/x86.c   |   10 -
arch/x86/kvm/x86.h   |2
crypto/testmgr.h |   44 +
drivers/acpi/nfit/core.c |   63 +---
drivers/acpi/nfit/nfit.h |   11 +
drivers/base/memory.c|2
drivers/char/ipmi/ipmi_msghandler.c  |   19 ++
drivers/char/tpm/eventlog/tpm2.c |4
drivers/char/tpm/tpm-dev-common.c|9 +
drivers/char/tpm/tpm_i2c_atmel.c |4
drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c  |1
drivers/gpu/drm/ttm/ttm_page_alloc.c |5
drivers/i3c/master.c |5
drivers/i3c/master/dw-i3c-master.c   |2
drivers/iio/accel/kxcjk-1013.c   |2
drivers/iio/adc/ad_sigma_delta.c |1
drivers/iio/adc/at91_adc.c   |   28 ++-
drivers/iio/chemical/bme680.h|6
drivers/iio/chemical/bme680_core.c   |   54 +--
drivers/iio/chemical/bme680_i2c.c|   21 --
drivers/iio/chemical/bme680_spi.c|  115 ++-
drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c |7
drivers/iio/dac/mcp4725.c|1
drivers/iio/gyro/bmg160_core.c   |6
drivers/iio/gyro/mpu3050-core.c  |8 -
drivers/iio/industrialio-buffer.c|5
drivers/iio/industrialio-core.c  |4
drivers/infiniband/core/uverbs_main.c|3
drivers/input/mouse/elan_i2c_core.c  |   25 +++
drivers/net/bonding/bond_main.c  |6
drivers/net/ethernet/cavium/thunder/nicvf_main.c |   22 ++
drivers/net/ethernet/freescale/fec_main.c|   30 ++-
drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.c  |4
drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c |3
drivers/net/ethernet/mellanox/mlx5/core/en_main.c|8 -
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c  |   94 +---
drivers/net/ethernet/mellanox/mlx5/core/en_stats.c   |6
drivers/net/ethernet/mellanox/mlx5/core/en_stats.h   |4
drivers/net/ethernet/mellanox/mlx5/core/fpga/tls.c   |   61 +++
drivers/net/ethernet/mellanox/mlxsw/core.c   |6
drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c|2
drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c |2
drivers/net/ethernet/netronome/nfp/flower/action.c   |3
drivers/net/ethernet/netronome/nfp/flower/cmsg.h |3
drivers/net/ethernet/netronome/nfp/flower/match.c|   14 -
drivers/net/team/team.c  |   26 +++
drivers/net/wireless/mediatek/mt76/mt76x02_mac.c |   14 +
drivers/net/wireless/ralink/rt2x00/rt2x00.h  |1
drivers/net/wireless/ralink/rt2x00/rt2x00mac.c   |   10 -
drivers/net/wireless/ralink/rt2x00/rt2x00queue.c |   15 +
drivers/scsi/libfc/fc_rport.c|1
drivers/scsi/scsi_lib.c  |6
drivers/staging/comedi/drivers/ni_usb6501.c  |   10 -
drivers/staging/comedi/drivers/vmk80xx.c |8 -
drivers/staging/iio/adc/ad7192.c  

[PATCH V3 07/12] misc: xilinx_sdfec: Add ability to configure LDPC

2019-04-27 Thread Dragan Cvetic
Add the capability to configure LDPC mode via the ioctl
XSDFEC_ADD_LDPC_CODE_PARAMS.

Tested-by: Dragan Cvetic 
Signed-off-by: Derek Kiernan 
Signed-off-by: Dragan Cvetic 
---
 drivers/misc/xilinx_sdfec.c  | 333 +++
 include/uapi/misc/xilinx_sdfec.h | 119 ++
 2 files changed, 452 insertions(+)

diff --git a/drivers/misc/xilinx_sdfec.c b/drivers/misc/xilinx_sdfec.c
index 19b5f96..18e7ae2 100644
--- a/drivers/misc/xilinx_sdfec.c
+++ b/drivers/misc/xilinx_sdfec.c
@@ -26,6 +26,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 
@@ -122,6 +124,57 @@ static dev_t xsdfec_devt;
 #define XSDFEC_TURBO_SCALE_BIT_POS (8)
 #define XSDFEC_TURBO_SCALE_MAX (15)
 
+/* REG0 Register */
+#define XSDFEC_LDPC_CODE_REG0_ADDR_BASE (0x2000)
+#define XSDFEC_LDPC_CODE_REG0_ADDR_HIGH (0x27F0)
+#define XSDFEC_REG0_N_MIN (4)
+#define XSDFEC_REG0_N_MAX (32768)
+#define XSDFEC_REG0_N_MUL_P (256)
+#define XSDFEC_REG0_N_LSB (0)
+#define XSDFEC_REG0_K_MIN (2)
+#define XSDFEC_REG0_K_MAX (32766)
+#define XSDFEC_REG0_K_MUL_P (256)
+#define XSDFEC_REG0_K_LSB (16)
+
+/* REG1 Register */
+#define XSDFEC_LDPC_CODE_REG1_ADDR_BASE (0x2004)
+#define XSDFEC_LDPC_CODE_REG1_ADDR_HIGH (0x27f4)
+#define XSDFEC_REG1_PSIZE_MIN (2)
+#define XSDFEC_REG1_PSIZE_MAX (512)
+#define XSDFEC_REG1_NO_PACKING_MASK (0x400)
+#define XSDFEC_REG1_NO_PACKING_LSB (10)
+#define XSDFEC_REG1_NM_MASK (0xFF800)
+#define XSDFEC_REG1_NM_LSB (11)
+#define XSDFEC_REG1_BYPASS_MASK (0x10)
+
+/* REG2 Register */
+#define XSDFEC_LDPC_CODE_REG2_ADDR_BASE (0x2008)
+#define XSDFEC_LDPC_CODE_REG2_ADDR_HIGH (0x27f8)
+#define XSDFEC_REG2_NLAYERS_MIN (1)
+#define XSDFEC_REG2_NLAYERS_MAX (256)
+#define XSDFEC_REG2_NNMQC_MASK (0xFFE00)
+#define XSDFEC_REG2_NMQC_LSB (9)
+#define XSDFEC_REG2_NORM_TYPE_MASK (0x10)
+#define XSDFEC_REG2_NORM_TYPE_LSB (20)
+#define XSDFEC_REG2_SPECIAL_QC_MASK (0x20)
+#define XSDFEC_REG2_SPEICAL_QC_LSB (21)
+#define XSDFEC_REG2_NO_FINAL_PARITY_MASK (0x40)
+#define XSDFEC_REG2_NO_FINAL_PARITY_LSB (22)
+#define XSDFEC_REG2_MAX_SCHEDULE_MASK (0x180)
+#define XSDFEC_REG2_MAX_SCHEDULE_LSB (23)
+
+/* REG3 Register */
+#define XSDFEC_LDPC_CODE_REG3_ADDR_BASE (0x200C)
+#define XSDFEC_LDPC_CODE_REG3_ADDR_HIGH (0x27FC)
+#define XSDFEC_REG3_LA_OFF_LSB (8)
+#define XSDFEC_REG3_QC_OFF_LSB (16)
+
+#define XSDFEC_LDPC_REG_JUMP (0x10)
+#define XSDFEC_REG_WIDTH_JUMP (4)
+
+/* The maximum number of pinned pages */
+#define MAX_NUM_PAGES ((XSDFEC_QC_TABLE_DEPTH / PAGE_SIZE) + 1)
+
 /**
  * struct xsdfec_clks - For managing SD-FEC clocks
  * @core_clk: Main processing clock for core
@@ -318,6 +371,283 @@ static int xsdfec_get_turbo(struct xsdfec_dev *xsdfec, 
void __user *arg)
return err;
 }
 
+static int xsdfec_reg0_write(struct xsdfec_dev *xsdfec, u32 n, u32 k, u32 
psize,
+u32 offset)
+{
+   u32 wdata;
+
+   if (n < XSDFEC_REG0_N_MIN || n > XSDFEC_REG0_N_MAX ||
+   (n > XSDFEC_REG0_N_MUL_P * psize) || n <= k || ((n % psize) != 0)) {
+   dev_err(xsdfec->dev, "N value is not in range");
+   return -EINVAL;
+   }
+   n <<= XSDFEC_REG0_N_LSB;
+
+   if (k < XSDFEC_REG0_K_MIN || k > XSDFEC_REG0_K_MAX ||
+   (k > XSDFEC_REG0_K_MUL_P * psize) || ((k % psize) != 0)) {
+   dev_err(xsdfec->dev, "K value is not in range");
+   return -EINVAL;
+   }
+   k = k << XSDFEC_REG0_K_LSB;
+   wdata = k | n;
+
+   if (XSDFEC_LDPC_CODE_REG0_ADDR_BASE + (offset * XSDFEC_LDPC_REG_JUMP) >
+   XSDFEC_LDPC_CODE_REG0_ADDR_HIGH) {
+   dev_err(xsdfec->dev, "Writing outside of LDPC reg0 space 0x%x",
+   XSDFEC_LDPC_CODE_REG0_ADDR_BASE +
+   (offset * XSDFEC_LDPC_REG_JUMP));
+   return -EINVAL;
+   }
+   xsdfec_regwrite(xsdfec,
+   XSDFEC_LDPC_CODE_REG0_ADDR_BASE +
+   (offset * XSDFEC_LDPC_REG_JUMP),
+   wdata);
+   return 0;
+}
+
+static int xsdfec_reg1_write(struct xsdfec_dev *xsdfec, u32 psize,
+u32 no_packing, u32 nm, u32 offset)
+{
+   u32 wdata;
+
+   if (psize < XSDFEC_REG1_PSIZE_MIN || psize > XSDFEC_REG1_PSIZE_MAX) {
+   dev_err(xsdfec->dev, "Psize is not in range");
+   return -EINVAL;
+   }
+
+   if (no_packing != 0 && no_packing != 1)
+   dev_err(xsdfec->dev, "No-packing bit register invalid");
+   no_packing = ((no_packing << XSDFEC_REG1_NO_PACKING_LSB) &
+ XSDFEC_REG1_NO_PACKING_MASK);
+
+   if (nm & ~(XSDFEC_REG1_NM_MASK >> XSDFEC_REG1_NM_LSB))
+   dev_err(xsdfec->dev, "NM is beyond 10 bits");
+   nm = (nm << XSDFEC_REG1_NM_LSB) & XSDFEC_REG1_NM_MASK;
+
+   wdata = nm | no_packing | psize;
+   if (XSDFEC_LDPC_CODE_REG1_ADDR_BASE + (offset * XSDFEC_LDPC_REG_JUMP) >
+   

[PATCH V3 04/12] misc: xilinx_sdfec: Add open, close and ioctl

2019-04-27 Thread Dragan Cvetic
Add char device interface per DT node present and support
file operations:
- open(),
- close(),
- unlocked_ioctl(),
- compat_ioctl().

Tested-by: Dragan Cvetic 
Signed-off-by: Derek Kiernan 
Signed-off-by: Dragan Cvetic 
---
 drivers/misc/xilinx_sdfec.c  | 78 
 include/uapi/misc/xilinx_sdfec.h |  4 +++
 2 files changed, 82 insertions(+)

diff --git a/drivers/misc/xilinx_sdfec.c b/drivers/misc/xilinx_sdfec.c
index a52a5c6..30879ae 100644
--- a/drivers/misc/xilinx_sdfec.c
+++ b/drivers/misc/xilinx_sdfec.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -81,8 +82,85 @@ struct xsdfec_dev {
struct xsdfec_clks clks;
 };
 
+static int xsdfec_dev_open(struct inode *iptr, struct file *fptr)
+{
+   struct xsdfec_dev *xsdfec;
+
+   xsdfec = container_of(iptr->i_cdev, struct xsdfec_dev, xsdfec_cdev);
+
+   if (!atomic_dec_and_test(>open_count)) {
+   atomic_inc(>open_count);
+   return -EBUSY;
+   }
+
+   fptr->private_data = xsdfec;
+   return 0;
+}
+
+static int xsdfec_dev_release(struct inode *iptr, struct file *fptr)
+{
+   struct xsdfec_dev *xsdfec;
+
+   xsdfec = container_of(iptr->i_cdev, struct xsdfec_dev, xsdfec_cdev);
+
+   atomic_inc(>open_count);
+   return 0;
+}
+
+static long xsdfec_dev_ioctl(struct file *fptr, unsigned int cmd,
+unsigned long data)
+{
+   struct xsdfec_dev *xsdfec = fptr->private_data;
+   void __user *arg = NULL;
+   int rval = -EINVAL;
+   int err = 0;
+
+   if (!xsdfec)
+   return rval;
+
+   if (_IOC_TYPE(cmd) != XSDFEC_MAGIC)
+   return -ENOTTY;
+
+   /* check if ioctl argument is present and valid */
+   if (_IOC_DIR(cmd) != _IOC_NONE) {
+   arg = (void __user *)data;
+   if (!arg) {
+   dev_err(xsdfec->dev,
+   "xilinx sdfec ioctl argument is NULL Pointer");
+   return rval;
+   }
+   }
+
+   if (err) {
+   dev_err(xsdfec->dev, "Invalid xilinx sdfec ioctl argument");
+   return -EFAULT;
+   }
+
+   switch (cmd) {
+   default:
+   /* Should not get here */
+   dev_err(xsdfec->dev, "Undefined SDFEC IOCTL");
+   break;
+   }
+   return rval;
+}
+
+#ifdef CONFIG_COMPAT
+static long xsdfec_dev_compat_ioctl(struct file *file, unsigned int cmd,
+   unsigned long data)
+{
+   return xsdfec_dev_ioctl(file, cmd, (unsigned long)compat_ptr(data));
+}
+#endif
+
 static const struct file_operations xsdfec_fops = {
.owner = THIS_MODULE,
+   .open = xsdfec_dev_open,
+   .release = xsdfec_dev_release,
+   .unlocked_ioctl = xsdfec_dev_ioctl,
+#ifdef CONFIG_COMPAT
+   .compat_ioctl = xsdfec_dev_compat_ioctl,
+#endif
 };
 
 static int xsdfec_clk_init(struct platform_device *pdev,
diff --git a/include/uapi/misc/xilinx_sdfec.h b/include/uapi/misc/xilinx_sdfec.h
index ba577fa..9709759 100644
--- a/include/uapi/misc/xilinx_sdfec.h
+++ b/include/uapi/misc/xilinx_sdfec.h
@@ -39,4 +39,8 @@ struct xsdfec_config {
__s32 fec_id;
 };
 
+/*
+ * XSDFEC IOCTL List
+ */
+#define XSDFEC_MAGIC 'f'
 #endif /* __XILINX_SDFEC_H__ */
-- 
2.7.4



[PATCH V3 11/12] Docs: misc: xilinx_sdfec: Add documentation

2019-04-27 Thread Dragan Cvetic
Add SD-FEC driver documentation.

Signed-off-by: Derek Kiernan 
Signed-off-by: Dragan Cvetic 
---
 Documentation/misc-devices/index.rst|   1 +
 Documentation/misc-devices/xilinx_sdfec.rst | 291 
 2 files changed, 292 insertions(+)
 create mode 100644 Documentation/misc-devices/xilinx_sdfec.rst

diff --git a/Documentation/misc-devices/index.rst 
b/Documentation/misc-devices/index.rst
index dfd1f45..b5b4757 100644
--- a/Documentation/misc-devices/index.rst
+++ b/Documentation/misc-devices/index.rst
@@ -15,3 +15,4 @@ fit into other categories.
:maxdepth: 2
 
ibmvmc
+   xilinx_sdfec
diff --git a/Documentation/misc-devices/xilinx_sdfec.rst 
b/Documentation/misc-devices/xilinx_sdfec.rst
new file mode 100644
index 000..87966e3
--- /dev/null
+++ b/Documentation/misc-devices/xilinx_sdfec.rst
@@ -0,0 +1,291 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Xilinx SD-FEC Driver
+
+
+Overview
+
+
+This driver supports SD-FEC Integrated Block for Zynq |Ultrascale+ (TM)| 
RFSoCs.
+
+.. |Ultrascale+ (TM)| unicode:: Ultrascale+ U+2122
+   .. with trademark sign
+
+For a full description of SD-FEC core features, see the `SD-FEC Product Guide 
(PG256) 
`_
+
+This driver supports the following features:
+
+  - Retrieval of the Integrated Block configuration and status information
+  - Configuration of LDPC codes
+  - Configuration of Turbo decoding
+  - Monitoring errors
+
+Missing features, known issues, and limitations of the SD-FEC driver are as
+follows:
+
+  - Only allows a single open file handler to any instance of the driver at 
any time
+  - Reset of the SD-FEC Integrated Block is not controlled by this driver
+  - Does not support shared LDPC code table wraparound
+
+The device tree entry is described in:
+`linux-xlnx/Documentation/devicetree/bindings/misc/xlnx,sd-fec.txt 
`_
+
+
+Modes of Operation
+--
+
+The driver works with the SD-FEC core in two modes of operation:
+
+  - Run-time configuration
+  - Programmable Logic (PL) initialization
+
+
+Run-time Configuration
+~~
+
+For Run-time configuration the role of driver is to allow the software 
application to do the following:
+
+   - Load the configuration parameters for either Turbo decode or LDPC 
encode or decode
+   - Activate the SD-FEC core
+   - Monitor the SD-FEC core for errors
+   - Retrieve the status and configuration of the SD-FEC core
+
+Programmable Logic (PL) Initialization
+~~
+
+For PL initialization, supporting logic loads configuration parameters for 
either
+the Turbo decode or LDPC encode or decode.  The role of the driver is to allow
+the software application to do the following:
+
+   - Activate the SD-FEC core
+   - Monitor the SD-FEC core for errors
+   - Retrieve the status and configuration of the SD-FEC core
+
+
+Driver Structure
+
+
+The driver provides a platform device where the ``probe`` and ``remove``
+operations are provided.
+
+  - probe: Updates configuration register with device-tree entries plus 
determines the current activate state of the core, for example, is the core 
bypassed or has the core been started.
+
+
+The driver defines the following driver file operations to provide user
+application interfaces:
+
+  - open: Implements restriction that only a single file descriptor can be 
open per SD-FEC instance at any time
+  - release: Allows another file descriptor to be open, that is after current 
file descriptor is closed
+  - poll: Provides a method to monitor for SD-FEC Error events
+  - unlocked_ioctl: Provides the the following ioctl commands that allows the 
application configure the SD-FEC core:
+
+   - :c:macro:`XSDFEC_START_DEV`
+   - :c:macro:`XSDFEC_STOP_DEV`
+   - :c:macro:`XSDFEC_GET_STATUS`
+   - :c:macro:`XSDFEC_SET_IRQ`
+   - :c:macro:`XSDFEC_SET_TURBO`
+   - :c:macro:`XSDFEC_ADD_LDPC_CODE_PARAMS`
+   - :c:macro:`XSDFEC_GET_CONFIG`
+   - :c:macro:`XSDFEC_SET_ORDER`
+   - :c:macro:`XSDFEC_SET_BYPASS`
+   - :c:macro:`XSDFEC_IS_ACTIVE`
+   - :c:macro:`XSDFEC_CLEAR_STATS`
+   - :c:macro:`XSDFEC_SET_DEFAULT_CONFIG`
+
+
+Driver Usage
+
+
+
+Overview
+
+
+After opening the driver, the user should find out what operations need to be
+performed to configure and activate the SD-FEC core and determine the
+configuration of the driver.
+The following outlines the flow the user should perform:
+
+  - Determine Configuration
+  - Set the order, if not already configured as desired
+  - Set Turbo decode, LPDC encode or decode parameters, depending on how 

[PATCH V3 05/12] misc: xilinx_sdfec: Store driver config and state

2019-04-27 Thread Dragan Cvetic
Stores configuration based on parameters from the DT
node and values from the SD-FEC core plus reads
the default state from the SD-FEC core. To obtain
values from the core register read, write capabilities
have been added plus related register map details.

Tested-by: Dragan Cvetic 
Signed-off-by: Derek Kiernan 
Signed-off-by: Dragan Cvetic 
---
 drivers/misc/xilinx_sdfec.c  | 307 +++
 include/uapi/misc/xilinx_sdfec.h |  94 
 2 files changed, 401 insertions(+)

diff --git a/drivers/misc/xilinx_sdfec.c b/drivers/misc/xilinx_sdfec.c
index 30879ae..77ee62d 100644
--- a/drivers/misc/xilinx_sdfec.c
+++ b/drivers/misc/xilinx_sdfec.c
@@ -37,6 +37,85 @@ static struct class *xsdfec_class;
 static atomic_t xsdfec_ndevs = ATOMIC_INIT(0);
 static dev_t xsdfec_devt;
 
+/* Xilinx SDFEC Register Map */
+/* CODE_WRI_PROTECT Register */
+#define XSDFEC_CODE_WR_PROTECT_ADDR (0x4)
+
+/* ACTIVE Register */
+#define XSDFEC_ACTIVE_ADDR (0x8)
+#define XSDFEC_IS_ACTIVITY_SET (0x1)
+
+/* AXIS_WIDTH Register */
+#define XSDFEC_AXIS_WIDTH_ADDR (0xC)
+#define XSDFEC_AXIS_DOUT_WORDS_LSB (5)
+#define XSDFEC_AXIS_DOUT_WIDTH_LSB (3)
+#define XSDFEC_AXIS_DIN_WORDS_LSB (2)
+#define XSDFEC_AXIS_DIN_WIDTH_LSB (0)
+
+/* AXIS_ENABLE Register */
+#define XSDFEC_AXIS_ENABLE_ADDR (0x10)
+#define XSDFEC_AXIS_OUT_ENABLE_MASK (0x38)
+#define XSDFEC_AXIS_IN_ENABLE_MASK (0x7)
+#define XSDFEC_AXIS_ENABLE_MASK
\
+   (XSDFEC_AXIS_OUT_ENABLE_MASK | XSDFEC_AXIS_IN_ENABLE_MASK)
+
+/* FEC_CODE Register */
+#define XSDFEC_FEC_CODE_ADDR (0x14)
+
+/* ORDER Register Map */
+#define XSDFEC_ORDER_ADDR (0x18)
+
+/* Interrupt Status Register */
+#define XSDFEC_ISR_ADDR (0x1C)
+/* Interrupt Status Register Bit Mask */
+#define XSDFEC_ISR_MASK (0x3F)
+
+/* Write Only - Interrupt Enable Register */
+#define XSDFEC_IER_ADDR (0x20)
+/* Write Only - Interrupt Disable Register */
+#define XSDFEC_IDR_ADDR (0x24)
+/* Read Only - Interrupt Mask Register */
+#define XSDFEC_IMR_ADDR (0x28)
+
+/* ECC Interrupt Status Register */
+#define XSDFEC_ECC_ISR_ADDR (0x2C)
+/* Single Bit Errors */
+#define XSDFEC_ECC_ISR_SBE_MASK (0x7FF)
+/* PL Initialize Single Bit Errors */
+#define XSDFEC_PL_INIT_ECC_ISR_SBE_MASK (0x3C0)
+/* Multi Bit Errors */
+#define XSDFEC_ECC_ISR_MBE_MASK (0x3FF800)
+/* PL Initialize Multi Bit Errors */
+#define XSDFEC_PL_INIT_ECC_ISR_MBE_MASK (0x3C00)
+/* Multi Bit Error to Event Shift */
+#define XSDFEC_ECC_ISR_MBE_TO_EVENT_SHIFT (11)
+/* PL Initialize Multi Bit Error to Event Shift */
+#define XSDFEC_PL_INIT_ECC_ISR_MBE_TO_EVENT_SHIFT (4)
+/* ECC Interrupt Status Bit Mask */
+#define XSDFEC_ECC_ISR_MASK (XSDFEC_ECC_ISR_SBE_MASK | XSDFEC_ECC_ISR_MBE_MASK)
+/* ECC Interrupt Status PL Initialize Bit Mask */
+#define XSDFEC_PL_INIT_ECC_ISR_MASK
\
+   (XSDFEC_PL_INIT_ECC_ISR_SBE_MASK | XSDFEC_PL_INIT_ECC_ISR_MBE_MASK)
+/* ECC Interrupt Status All Bit Mask */
+#define XSDFEC_ALL_ECC_ISR_MASK
\
+   (XSDFEC_ECC_ISR_MASK | XSDFEC_PL_INIT_ECC_ISR_MASK)
+/* ECC Interrupt Status Single Bit Errors Mask */
+#define XSDFEC_ALL_ECC_ISR_SBE_MASK
\
+   (XSDFEC_ECC_ISR_SBE_MASK | XSDFEC_PL_INIT_ECC_ISR_SBE_MASK)
+/* ECC Interrupt Status Multi Bit Errors Mask */
+#define XSDFEC_ALL_ECC_ISR_MBE_MASK
\
+   (XSDFEC_ECC_ISR_MBE_MASK | XSDFEC_PL_INIT_ECC_ISR_MBE_MASK)
+
+/* Write Only - ECC Interrupt Enable Register */
+#define XSDFEC_ECC_IER_ADDR (0x30)
+/* Write Only - ECC Interrupt Disable Register */
+#define XSDFEC_ECC_IDR_ADDR (0x34)
+/* Read Only - ECC Interrupt Mask Register */
+#define XSDFEC_ECC_IMR_ADDR (0x38)
+
+/* BYPASS Register */
+#define XSDFEC_BYPASS_ADDR (0x3C)
+
 /**
  * struct xsdfec_clks - For managing SD-FEC clocks
  * @core_clk: Main processing clock for core
@@ -63,6 +142,7 @@ struct xsdfec_clks {
  * struct xsdfec_dev - Driver data for SDFEC
  * @regs: device physical base address
  * @dev: pointer to device struct
+ * @state: State of the SDFEC device
  * @config: Configuration of the SDFEC device
  * @open_count: Count of char device being opened
  * @xsdfec_cdev: Character device handle
@@ -74,6 +154,7 @@ struct xsdfec_clks {
 struct xsdfec_dev {
void __iomem *regs;
struct device *dev;
+   enum xsdfec_state state;
struct xsdfec_config config;
atomic_t open_count;
struct cdev xsdfec_cdev;
@@ -82,6 +163,65 @@ struct xsdfec_dev {
struct xsdfec_clks clks;
 };
 
+static inline void xsdfec_regwrite(struct xsdfec_dev *xsdfec, u32 addr,
+  u32 value)
+{
+   dev_dbg(xsdfec->dev, "Writing 0x%x to offset 0x%x", value, addr);
+   iowrite32(value, xsdfec->regs + addr);
+}
+
+static inline u32 xsdfec_regread(struct xsdfec_dev *xsdfec, u32 addr)
+{
+   u32 rval;
+
+   

[PATCH V3 09/12] misc: xilinx_sdfec: Support poll file operation

2019-04-27 Thread Dragan Cvetic
Support monitoring and detecting the SD-FEC error events
through IRQ and poll file operation.

The SD-FEC device can detect one-error or multi-error events.
An error triggers an interrupt which creates and run the ONE_SHOT
IRQ thread.
The ONE_SHOT IRQ thread detects type of error and pass that
information to the poll function.
The file_operation callback poll(), collects the events and
updates the statistics accordingly.
The function poll blocks() on waiting queue which can be
unblocked by ONE_SHOT IRQ handling thread.

Support SD-FEC interrupt set ioctl callback.
The SD-FEC can detect two type of errors: coding errors (ECC) and
a data interface errors (TLAST).
The errors are  events which can trigger an IRQ if enabled.
The driver can monitor and detect these errors through IRQ.
Also the driver updates the statistical data.

Tested-by: Dragan Cvetic 
Signed-off-by: Derek Kiernan 
Signed-off-by: Dragan Cvetic 
---
 drivers/misc/xilinx_sdfec.c  | 283 +++
 include/uapi/misc/xilinx_sdfec.h |  13 ++
 2 files changed, 296 insertions(+)

diff --git a/drivers/misc/xilinx_sdfec.c b/drivers/misc/xilinx_sdfec.c
index 560a2ed..32b2e2d 100644
--- a/drivers/misc/xilinx_sdfec.c
+++ b/drivers/misc/xilinx_sdfec.c
@@ -203,8 +203,15 @@ struct xsdfec_clks {
  * @dev: pointer to device struct
  * @state: State of the SDFEC device
  * @config: Configuration of the SDFEC device
+ * @state_updated: indicates State updated by interrupt handler
+ * @stats_updated: indicates Stats updated by interrupt handler
+ * @isr_err_count: Count of ISR errors
+ * @cecc_count: Count of Correctable ECC errors (SBE)
+ * @uecc_count: Count of Uncorrectable ECC errors (MBE)
  * @open_count: Count of char device being opened
+ * @irq: IRQ number
  * @xsdfec_cdev: Character device handle
+ * @waitq: Driver wait queue
  * @irq_lock: Driver spinlock
  * @clks: Clocks managed by the SDFEC driver
  *
@@ -215,8 +222,15 @@ struct xsdfec_dev {
struct device *dev;
enum xsdfec_state state;
struct xsdfec_config config;
+   bool state_updated;
+   bool stats_updated;
+   atomic_t isr_err_count;
+   atomic_t cecc_count;
+   atomic_t uecc_count;
atomic_t open_count;
+   int irq;
struct cdev xsdfec_cdev;
+   wait_queue_head_t waitq;
/* Spinlock to protect state_updated and stats_updated */
spinlock_t irq_lock;
struct xsdfec_clks clks;
@@ -317,6 +331,90 @@ static int xsdfec_get_config(struct xsdfec_dev *xsdfec, 
void __user *arg)
return err;
 }
 
+static int xsdfec_isr_enable(struct xsdfec_dev *xsdfec, bool enable)
+{
+   u32 mask_read;
+
+   if (enable) {
+   /* Enable */
+   xsdfec_regwrite(xsdfec, XSDFEC_IER_ADDR, XSDFEC_ISR_MASK);
+   mask_read = xsdfec_regread(xsdfec, XSDFEC_IMR_ADDR);
+   if (mask_read & XSDFEC_ISR_MASK) {
+   dev_err(xsdfec->dev,
+   "SDFEC enabling irq with IER failed");
+   return -EIO;
+   }
+   } else {
+   /* Disable */
+   xsdfec_regwrite(xsdfec, XSDFEC_IDR_ADDR, XSDFEC_ISR_MASK);
+   mask_read = xsdfec_regread(xsdfec, XSDFEC_IMR_ADDR);
+   if ((mask_read & XSDFEC_ISR_MASK) != XSDFEC_ISR_MASK) {
+   dev_err(xsdfec->dev,
+   "SDFEC disabling irq with IDR failed");
+   return -EIO;
+   }
+   }
+   return 0;
+}
+
+static int xsdfec_ecc_isr_enable(struct xsdfec_dev *xsdfec, bool enable)
+{
+   u32 mask_read;
+
+   if (enable) {
+   /* Enable */
+   xsdfec_regwrite(xsdfec, XSDFEC_ECC_IER_ADDR,
+   XSDFEC_ALL_ECC_ISR_MASK);
+   mask_read = xsdfec_regread(xsdfec, XSDFEC_ECC_IMR_ADDR);
+   if (mask_read & XSDFEC_ALL_ECC_ISR_MASK) {
+   dev_err(xsdfec->dev,
+   "SDFEC enabling ECC irq with ECC IER failed");
+   return -EIO;
+   }
+   } else {
+   /* Disable */
+   xsdfec_regwrite(xsdfec, XSDFEC_ECC_IDR_ADDR,
+   XSDFEC_ALL_ECC_ISR_MASK);
+   mask_read = xsdfec_regread(xsdfec, XSDFEC_ECC_IMR_ADDR);
+   if (!(((mask_read & XSDFEC_ALL_ECC_ISR_MASK) ==
+  XSDFEC_ECC_ISR_MASK) ||
+ ((mask_read & XSDFEC_ALL_ECC_ISR_MASK) ==
+  XSDFEC_PL_INIT_ECC_ISR_MASK))) {
+   dev_err(xsdfec->dev,
+   "SDFEC disable ECC irq with ECC IDR failed");
+   return -EIO;
+   }
+   }
+   return 0;
+}
+
+static int xsdfec_set_irq(struct xsdfec_dev *xsdfec, void __user *arg)
+{
+   struct xsdfec_irq irq;
+   int err;
+   int isr_err;
+   int ecc_err;
+
+   err = 

[PATCH V3 02/12] misc: xilinx-sdfec: add core driver

2019-04-27 Thread Dragan Cvetic
Implements an platform driver that matches with xlnx,
sd-fec-1.1 device tree node and registers as a character
device, including:
- SD-FEC driver binds to sdfec DT node.
- creates and initialise an initial driver dev structure.
- add the driver in Linux build and Kconfig.

Tested-by: Dragan Cvetic 
Signed-off-by: Derek Kiernan 
Signed-off-by: Dragan Cvetic 
---
 drivers/misc/Kconfig |  12 +++
 drivers/misc/Makefile|   1 +
 drivers/misc/xilinx_sdfec.c  | 215 +++
 include/uapi/misc/xilinx_sdfec.h |  42 
 4 files changed, 270 insertions(+)
 create mode 100644 drivers/misc/xilinx_sdfec.c
 create mode 100644 include/uapi/misc/xilinx_sdfec.h

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 3209ee0..1a1fe9c 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -528,6 +528,18 @@ config PCI_ENDPOINT_TEST
Enable this configuration option to enable the host side test driver
for PCI Endpoint.
 
+config XILINX_SDFEC
+   tristate "Xilinx SDFEC 16"
+   help
+ This option enables support for the Xilinx SDFEC (Soft Decision
+ Forward Error Correction) driver. This enables a char driver
+ for the SDFEC.
+
+ You may select this driver if your design instantiates the
+ SDFEC(16nm) hardened block. To compile this as a module choose M.
+
+ If unsure, say N.
+
 config MISC_RTSX
tristate
default MISC_RTSX_PCI || MISC_RTSX_USB
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index c362395..ee31140c 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -49,6 +49,7 @@ obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci/
 obj-$(CONFIG_LATTICE_ECP3_CONFIG)  += lattice-ecp3-config.o
 obj-$(CONFIG_SRAM) += sram.o
 obj-$(CONFIG_SRAM_EXEC)+= sram-exec.o
+obj-$(CONFIG_XILINX_SDFEC) += xilinx_sdfec.o
 obj-y  += mic/
 obj-$(CONFIG_GENWQE)   += genwqe/
 obj-$(CONFIG_ECHO) += echo/
diff --git a/drivers/misc/xilinx_sdfec.c b/drivers/misc/xilinx_sdfec.c
new file mode 100644
index 000..278754b
--- /dev/null
+++ b/drivers/misc/xilinx_sdfec.c
@@ -0,0 +1,215 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Xilinx SDFEC
+ *
+ * Copyright (C) 2016 - 2017 Xilinx, Inc.
+ *
+ * Description:
+ * This driver is developed for SDFEC16 (Soft Decision FEC 16nm)
+ * IP. It exposes a char device interface in sysfs and supports file
+ * operations like  open(), close() and ioctl().
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define DRIVER_NAME "xilinx_sdfec"
+#define DRIVER_VERSION "0.3"
+#define DRIVER_MAX_DEV BIT(MINORBITS)
+
+static struct class *xsdfec_class;
+static atomic_t xsdfec_ndevs = ATOMIC_INIT(0);
+static dev_t xsdfec_devt;
+
+/**
+ * struct xsdfec_dev - Driver data for SDFEC
+ * @regs: device physical base address
+ * @dev: pointer to device struct
+ * @config: Configuration of the SDFEC device
+ * @open_count: Count of char device being opened
+ * @xsdfec_cdev: Character device handle
+ * @irq_lock: Driver spinlock
+ *
+ * This structure contains necessary state for SDFEC driver to operate
+ */
+struct xsdfec_dev {
+   void __iomem *regs;
+   struct device *dev;
+   struct xsdfec_config config;
+   atomic_t open_count;
+   struct cdev xsdfec_cdev;
+   /* Spinlock to protect state_updated and stats_updated */
+   spinlock_t irq_lock;
+};
+
+static const struct file_operations xsdfec_fops = {
+   .owner = THIS_MODULE,
+};
+
+static int xsdfec_probe(struct platform_device *pdev)
+{
+   struct xsdfec_dev *xsdfec;
+   struct device *dev;
+   struct device *dev_create;
+   struct resource *res;
+   int err;
+
+   xsdfec = devm_kzalloc(>dev, sizeof(*xsdfec), GFP_KERNEL);
+   if (!xsdfec)
+   return -ENOMEM;
+
+   xsdfec->dev = >dev;
+   xsdfec->config.fec_id = atomic_read(_ndevs);
+   spin_lock_init(>irq_lock);
+
+   dev = xsdfec->dev;
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   xsdfec->regs = devm_ioremap_resource(dev, res);
+   if (IS_ERR(xsdfec->regs)) {
+   dev_err(dev, "Unable to map resource");
+   err = PTR_ERR(xsdfec->regs);
+   goto err_xsdfec_dev;
+   }
+
+   /* Save driver private data */
+   platform_set_drvdata(pdev, xsdfec);
+
+   cdev_init(>xsdfec_cdev, _fops);
+   xsdfec->xsdfec_cdev.owner = THIS_MODULE;
+   err = cdev_add(>xsdfec_cdev,
+  MKDEV(MAJOR(xsdfec_devt), xsdfec->config.fec_id), 1);
+   if (err < 0) {
+   dev_err(dev, "cdev_add failed");
+   err = -EIO;
+   goto err_xsdfec_dev;
+   }
+
+   if (!xsdfec_class) {
+   err = -EIO;
+   

[PATCH V3 06/12] misc: xilinx_sdfec: Add ability to configure turbo

2019-04-27 Thread Dragan Cvetic
mode

Add the capability to configure and retrieve turbo mode
via the ioctls XSDFEC_SET_TURBO and XSDFEC_GET_TURBO.

Tested-by: Dragan Cvetic 
Signed-off-by: Derek Kiernan 
Signed-off-by: Dragan Cvetic 
---
 drivers/misc/xilinx_sdfec.c  | 77 
 include/uapi/misc/xilinx_sdfec.h | 71 
 2 files changed, 148 insertions(+)

diff --git a/drivers/misc/xilinx_sdfec.c b/drivers/misc/xilinx_sdfec.c
index 77ee62d..19b5f96 100644
--- a/drivers/misc/xilinx_sdfec.c
+++ b/drivers/misc/xilinx_sdfec.c
@@ -116,6 +116,12 @@ static dev_t xsdfec_devt;
 /* BYPASS Register */
 #define XSDFEC_BYPASS_ADDR (0x3C)
 
+/* Turbo Code Register */
+#define XSDFEC_TURBO_ADDR (0x100)
+#define XSDFEC_TURBO_SCALE_MASK (0xFFF)
+#define XSDFEC_TURBO_SCALE_BIT_POS (8)
+#define XSDFEC_TURBO_SCALE_MAX (15)
+
 /**
  * struct xsdfec_clks - For managing SD-FEC clocks
  * @core_clk: Main processing clock for core
@@ -247,6 +253,71 @@ static int xsdfec_dev_release(struct inode *iptr, struct 
file *fptr)
return 0;
 }
 
+static int xsdfec_set_turbo(struct xsdfec_dev *xsdfec, void __user *arg)
+{
+   struct xsdfec_turbo turbo;
+   int err;
+   u32 turbo_write;
+
+   err = copy_from_user(, arg, sizeof(turbo));
+   if (err)
+   return -EFAULT;
+
+   if (turbo.alg >= XSDFEC_TURBO_ALG_MAX) {
+   dev_err(xsdfec->dev,
+   "%s invalid turbo alg value %d for SDFEC%d", __func__,
+   turbo.alg, xsdfec->config.fec_id);
+   return -EINVAL;
+   }
+
+   if (turbo.scale > XSDFEC_TURBO_SCALE_MAX) {
+   dev_err(xsdfec->dev,
+   "%s invalid turbo scale value %d for SDFEC%d", __func__,
+   turbo.scale, xsdfec->config.fec_id);
+   return -EINVAL;
+   }
+
+   /* Check to see what device tree says about the FEC codes */
+   if (xsdfec->config.code == XSDFEC_LDPC_CODE) {
+   dev_err(xsdfec->dev,
+   "%s: Unable to write Turbo to SDFEC%d check DT",
+   __func__, xsdfec->config.fec_id);
+   return -EIO;
+   }
+
+   turbo_write = ((turbo.scale & XSDFEC_TURBO_SCALE_MASK)
+  << XSDFEC_TURBO_SCALE_BIT_POS) |
+ turbo.alg;
+   xsdfec_regwrite(xsdfec, XSDFEC_TURBO_ADDR, turbo_write);
+   return err;
+}
+
+static int xsdfec_get_turbo(struct xsdfec_dev *xsdfec, void __user *arg)
+{
+   u32 reg_value;
+   struct xsdfec_turbo turbo_params;
+   int err;
+
+   if (xsdfec->config.code == XSDFEC_LDPC_CODE) {
+   dev_err(xsdfec->dev,
+   "%s: SDFEC%d is configured for LDPC, check DT",
+   __func__, xsdfec->config.fec_id);
+   return -EIO;
+   }
+
+   reg_value = xsdfec_regread(xsdfec, XSDFEC_TURBO_ADDR);
+
+   turbo_params.scale = (reg_value & XSDFEC_TURBO_SCALE_MASK) >>
+XSDFEC_TURBO_SCALE_BIT_POS;
+   turbo_params.alg = reg_value & 0x1;
+
+   err = copy_to_user(arg, _params, sizeof(turbo_params));
+   if (err)
+   err = -EFAULT;
+
+   return err;
+}
+
 static u32
 xsdfec_translate_axis_width_cfg_val(enum xsdfec_axis_width axis_width_cfg)
 {
@@ -340,6 +411,12 @@ static long xsdfec_dev_ioctl(struct file *fptr, unsigned 
int cmd,
}
 
switch (cmd) {
+   case XSDFEC_SET_TURBO:
+   rval = xsdfec_set_turbo(xsdfec, arg);
+   break;
+   case XSDFEC_GET_TURBO:
+   rval = xsdfec_get_turbo(xsdfec, arg);
+   break;
default:
/* Should not get here */
dev_err(xsdfec->dev, "Undefined SDFEC IOCTL");
diff --git a/include/uapi/misc/xilinx_sdfec.h b/include/uapi/misc/xilinx_sdfec.h
index 68eeb94..3dc8c53 100644
--- a/include/uapi/misc/xilinx_sdfec.h
+++ b/include/uapi/misc/xilinx_sdfec.h
@@ -39,6 +39,22 @@ enum xsdfec_order {
 };
 
 /**
+ * enum xsdfec_turbo_alg - Turbo Algorithm Type.
+ * @XSDFEC_MAX_SCALE: Max Log-Map algorithm with extrinsic scaling. When
+ *   scaling is set to this is equivalent to the Max Log-Map
+ *   algorithm.
+ * @XSDFEC_MAX_STAR: Log-Map algorithm.
+ * @XSDFEC_TURBO_ALG_MAX: Used to indicate out of bound Turbo algorithms.
+ *
+ * This enum specifies which Turbo Decode algorithm is in use.
+ */
+enum xsdfec_turbo_alg {
+   XSDFEC_MAX_SCALE = 0,
+   XSDFEC_MAX_STAR,
+   XSDFEC_TURBO_ALG_MAX,
+};
+
+/**
  * enum xsdfec_state - State.
  * @XSDFEC_INIT: Driver is initialized.
  * @XSDFEC_STARTED: Driver is started.
@@ -96,6 +112,33 @@ enum xsdfec_axis_word_include {
 };
 
 /**
+ * struct xsdfec_turbo - User data for Turbo codes.
+ * @alg: Specifies which Turbo decode algorithm to use
+ * @scale: Specifies the extrinsic scaling to apply when the Max Scale 
algorithm
+ *has been selected
+ *
+ * Turbo 

[PATCH V3 01/12] dt-bindings: xilinx-sdfec: Add SDFEC binding

2019-04-27 Thread Dragan Cvetic
Add the Soft Decision Forward Error Correction (SDFEC) Engine
bindings which is available for the Zynq UltraScale+ RFSoC
FPGA's.

Signed-off-by: Dragan Cvetic 
Signed-off-by: Derek Kiernan 
---
 .../devicetree/bindings/misc/xlnx,sd-fec.txt   | 58 ++
 1 file changed, 58 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/misc/xlnx,sd-fec.txt

diff --git a/Documentation/devicetree/bindings/misc/xlnx,sd-fec.txt 
b/Documentation/devicetree/bindings/misc/xlnx,sd-fec.txt
new file mode 100644
index 000..425b6a6
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/xlnx,sd-fec.txt
@@ -0,0 +1,58 @@
+* Xilinx SDFEC(16nm) IP *
+
+The Soft Decision Forward Error Correction (SDFEC) Engine is a Hard IP block
+which provides high-throughput LDPC and Turbo Code implementations.
+The LDPC decode & encode functionality is capable of covering a range of
+customer specified Quasi-cyclic (QC) codes. The Turbo decode functionality
+principally covers codes used by LTE. The FEC Engine offers significant
+power and area savings versus implementations done in the FPGA fabric.
+
+
+Required properties:
+- compatible: Must be "xlnx,sd-fec-1.1"
+- clock-names : List of input clock names from the following:
+- "core_clk", Main processing clock for processing core (required)
+- "s_axi_aclk", AXI4-Lite memory-mapped slave interface clock (required)
+- "s_axis_din_aclk", DIN AXI4-Stream Slave interface clock (optional)
+- "s_axis_din_words-aclk", DIN_WORDS AXI4-Stream Slave interface clock 
(optional)
+- "s_axis_ctrl_aclk",  Control input AXI4-Stream Slave interface clock 
(optional)
+- "m_axis_dout_aclk", DOUT AXI4-Stream Master interface clock (optional)
+- "m_axis_dout_words_aclk", DOUT_WORDS AXI4-Stream Master interface clock 
(optional)
+- "m_axis_status_aclk", Status output AXI4-Stream Master interface clock 
(optional)
+- clocks : Clock phandles (see clock_bindings.txt for details).
+- reg: Should contain Xilinx SDFEC 16nm Hardened IP block registers
+  location and length.
+- xlnx,sdfec-code : Should contain "ldpc" or "turbo" to describe the codes
+  being used.
+- xlnx,sdfec-din-words : A value 0 indicates that the DIN_WORDS interface is
+  driven with a fixed value and is not present on the device, a value of 1
+  configures the DIN_WORDS to be block based, while a value of 2 configures the
+  DIN_WORDS input to be supplied for each AXI transaction.
+- xlnx,sdfec-din-width : Configures the DIN AXI stream where a value of 1
+  configures a width of "1x128b", 2 a width of "2x128b" and 4 configures a 
width
+  of "4x128b".
+- xlnx,sdfec-dout-words : A value 0 indicates that the DOUT_WORDS interface is
+  driven with a fixed value and is not present on the device, a value of 1
+  configures the DOUT_WORDS to be block based, while a value of 2 configures 
the
+  DOUT_WORDS input to be supplied for each AXI transaction.
+- xlnx,sdfec-dout-width : Configures the DOUT AXI stream where a value of 1
+  configures a width of "1x128b", 2 a width of "2x128b" and 4 configures a 
width
+  of "4x128b".
+Optional properties:
+- interrupts: should contain SDFEC interrupt number
+
+Example
+---
+   sd_fec_0: sd-fec@a004 {
+   compatible = "xlnx,sd-fec-1.1";
+   clock-names = 
"core_clk","s_axi_aclk","s_axis_ctrl_aclk","s_axis_din_aclk","m_axis_status_aclk","m_axis_dout_aclk";
+   clocks = 
<_clk_2>,<_clk_0>,<_clk_1>,<_clk_1>,<_clk_1>, 
<_clk_1>;
+   reg = <0x0 0xa004 0x0 0x4>;
+   interrupt-parent = <>;
+   interrupts = <0 89 4>;
+   xlnx,sdfec-code = "ldpc";
+   xlnx,sdfec-din-words = <0>;
+   xlnx,sdfec-din-width = <2>;
+   xlnx,sdfec-dout-words = <0>;
+   xlnx,sdfec-dout-width = <1>;
+   };
-- 
2.7.4



[PATCH V3 00/12] misc: xilinx sd-fec drive

2019-04-27 Thread Dragan Cvetic
This patchset is adding the full Soft Decision Forward Error
Correction (SD-FEC) driver implementation, driver DT binding and
driver documentation.

Forward Error Correction (FEC) codes such as Low Density Parity
Check (LDPC) and turbo codes provide a means to control errors in
data transmissions over unreliable or noisy communication
channels. The SD-FEC Integrated Block is an optimized block for
soft-decision decoding of these codes. Fixed turbo codes are
supported directly, whereas custom and standardized LDPC codes
are supported through the ability to specify the parity check
matrix through an AXI4-Lite bus or using the optional programmable
(PL)-based support logic. For the further information see
https://www.xilinx.com/support/documentation/ip_documentation/
sd_fec/v1_1/pg256-sdfec-integrated-block.pdf

This driver is a platform device driver which supports SDFEC16
(16nm) IP. SD-FEC driver supports LDPC decoding and encoding and
Turbo code decoding. LDPC codes can be specified on
a codeword-by-codeword basis, also a custom LDPC code can be used.

The SD-FEC driver exposes a char device interface and supports
file operations: open(), close(), poll() and ioctl(). The driver
allows only one usage of the device, open() limits the number of
driver instances. The driver also utilize Common Clock Framework
(CCF).

The control and monitoring is supported over ioctl system call.
The features supported by ioctl():
- enable or disable data pipes to/from device
- configure the FEC algorithm parameters
- set the order of data
- provide a control of a SDFEC bypass option
- activates/deactivates SD-FEC
- collect and provide statistical data
- enable/disable interrupt mode

Poll can be utilized to detect errors on IRQ trigger rather than
using looping status and stats ioctl's.

Tested-by: Santhosh Dyavanapally 
Tested by: Punnaiah Choudary Kalluri 
Tested-by: Dragan Cvetic 
Signed-off-by: Derek Kiernan 
Signed-off-by: Dragan Cvetic 

Changes V1 -> V2:
- Removed unnecesary comenting from the commit messages.
- Removed error log messages which can be triggered from user space.
- Corrected the SDFEC table end addresses.
- Removed casting between user pointer and kernel pointer.
- Corrected definition of ioctl command code, used a corect type for
size parameters.
- Changes to declarations of IOCTL that pass structures, i.e. do not
use pointers for sizeof as prevents compile time checks
- IOCTL size fix, using a paging to manage a memory. Implemented a big
tables transfer from user to kernel with get_user_pages_fast().
- Removed unnecessary check after container_of.
- Removed not needed ioctl code checkes inside ioctl handler.
- Implemented compat_ioctl.
- Updated reviewer and tester lists.
- Updated documentation, added Limitation chapter related to fork()
and dup().

Link to V1 patch series:
https://lore.kernel.org/lkml/1552997064-432700-1-git-send-email-dragan.cve...@xilinx.com/

Changes V2 -> V3:
- Corrected a licence in xilinx_sdfec.h changed to uapi licence format.
- Corrected driver variable data types into user space data types.

Link to V2 patch series:
https://lore.kernel.org/lkml/1554804414-206099-1-git-send-email-dragan.cve...@xilinx.com/

Dragan Cvetic (12):
  dt-bindings: xilinx-sdfec: Add SDFEC binding
  misc: xilinx-sdfec: add core driver
  misc: xilinx_sdfec: Add CCF support
  misc: xilinx_sdfec: Add open, close and ioctl
  misc: xilinx_sdfec: Store driver config and state
  misc: xilinx_sdfec: Add ability to configure turbo
  misc: xilinx_sdfec: Add ability to configure LDPC
  misc: xilinx_sdfec: Add ability to get/set config
  misc: xilinx_sdfec: Support poll file operation
  misc: xilinx_sdfec: Add stats & status ioctls
  Docs: misc: xilinx_sdfec: Add documentation
  MAINTAINERS: add maintainer for SD-FEC

 .../devicetree/bindings/misc/xlnx,sd-fec.txt   |   58 +
 Documentation/misc-devices/index.rst   |1 +
 Documentation/misc-devices/xilinx_sdfec.rst|  291 
 MAINTAINERS|   12 +
 drivers/misc/Kconfig   |   12 +
 drivers/misc/Makefile  |1 +
 drivers/misc/xilinx_sdfec.c| 1669 
 include/uapi/misc/xilinx_sdfec.h   |  475 ++
 8 files changed, 2519 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/misc/xlnx,sd-fec.txt
 create mode 100644 Documentation/misc-devices/xilinx_sdfec.rst
 create mode 100644 drivers/misc/xilinx_sdfec.c
 create mode 100644 include/uapi/misc/xilinx_sdfec.h

-- 
2.7.4



[PATCH V3 08/12] misc: xilinx_sdfec: Add ability to get/set config

2019-04-27 Thread Dragan Cvetic
- Add capability to get SD-FEC config data using ioctl
XSDFEC_GET_CONFIG.

- Add capability to set SD-FEC data order using ioctl
SDFEC_SET_ORDER.

- Add capability to set SD-FEC bypass option using ioctl
XSDFEC_SET_BYPASS.

- Add capability to set SD-FEC active state using ioctl
XSDFEC_IS_ACTIVE.

Tested-by: Dragan Cvetic 
Signed-off-by: Derek Kiernan 
Signed-off-by: Dragan Cvetic 
---
 drivers/misc/xilinx_sdfec.c  | 99 
 include/uapi/misc/xilinx_sdfec.h | 57 +++
 2 files changed, 156 insertions(+)

diff --git a/drivers/misc/xilinx_sdfec.c b/drivers/misc/xilinx_sdfec.c
index 18e7ae2..560a2ed 100644
--- a/drivers/misc/xilinx_sdfec.c
+++ b/drivers/misc/xilinx_sdfec.c
@@ -306,6 +306,17 @@ static int xsdfec_dev_release(struct inode *iptr, struct 
file *fptr)
return 0;
 }
 
+static int xsdfec_get_config(struct xsdfec_dev *xsdfec, void __user *arg)
+{
+   int err;
+
+   err = copy_to_user(arg, >config, sizeof(xsdfec->config));
+   if (err)
+   err = -EFAULT;
+
+   return err;
+}
+
 static int xsdfec_set_turbo(struct xsdfec_dev *xsdfec, void __user *arg)
 {
struct xsdfec_turbo turbo;
@@ -648,6 +659,82 @@ static int xsdfec_add_ldpc(struct xsdfec_dev *xsdfec, void 
__user *arg)
return ret;
 }
 
+static int xsdfec_set_order(struct xsdfec_dev *xsdfec, void __user *arg)
+{
+   bool order_invalid;
+   enum xsdfec_order order;
+   int err;
+
+   err = get_user(order, (enum xsdfec_order *)arg);
+   if (err)
+   return -EFAULT;
+
+   order_invalid = (order != XSDFEC_MAINTAIN_ORDER) &&
+   (order != XSDFEC_OUT_OF_ORDER);
+   if (order_invalid) {
+   dev_err(xsdfec->dev, "%s invalid order value %d for SDFEC%d",
+   __func__, order, xsdfec->config.fec_id);
+   return -EINVAL;
+   }
+
+   /* Verify Device has not started */
+   if (xsdfec->state == XSDFEC_STARTED) {
+   dev_err(xsdfec->dev,
+   "%s attempting to set Order while started for SDFEC%d",
+   __func__, xsdfec->config.fec_id);
+   return -EIO;
+   }
+
+   xsdfec_regwrite(xsdfec, XSDFEC_ORDER_ADDR, order);
+
+   xsdfec->config.order = order;
+
+   return 0;
+}
+
+static int xsdfec_set_bypass(struct xsdfec_dev *xsdfec, bool __user *arg)
+{
+   bool bypass;
+   int err;
+
+   err = get_user(bypass, arg);
+   if (err)
+   return -EFAULT;
+
+   /* Verify Device has not started */
+   if (xsdfec->state == XSDFEC_STARTED) {
+   dev_err(xsdfec->dev,
+   "%s attempting to set bypass while started for SDFEC%d",
+   __func__, xsdfec->config.fec_id);
+   return -EIO;
+   }
+
+   if (bypass)
+   xsdfec_regwrite(xsdfec, XSDFEC_BYPASS_ADDR, 1);
+   else
+   xsdfec_regwrite(xsdfec, XSDFEC_BYPASS_ADDR, 0);
+
+   xsdfec->config.bypass = bypass;
+
+   return 0;
+}
+
+static int xsdfec_is_active(struct xsdfec_dev *xsdfec, bool __user *arg)
+{
+   u32 reg_value;
+   bool is_active;
+   int err;
+
+   reg_value = xsdfec_regread(xsdfec, XSDFEC_ACTIVE_ADDR);
+   /* using a double ! operator instead of casting */
+   is_active = !!(reg_value & XSDFEC_IS_ACTIVITY_SET);
+   err = put_user(is_active, arg);
+   if (err)
+   return -EFAULT;
+
+   return err;
+}
+
 static u32
 xsdfec_translate_axis_width_cfg_val(enum xsdfec_axis_width axis_width_cfg)
 {
@@ -741,6 +828,9 @@ static long xsdfec_dev_ioctl(struct file *fptr, unsigned 
int cmd,
}
 
switch (cmd) {
+   case XSDFEC_GET_CONFIG:
+   rval = xsdfec_get_config(xsdfec, arg);
+   break;
case XSDFEC_SET_TURBO:
rval = xsdfec_set_turbo(xsdfec, arg);
break;
@@ -750,6 +840,15 @@ static long xsdfec_dev_ioctl(struct file *fptr, unsigned 
int cmd,
case XSDFEC_ADD_LDPC_CODE_PARAMS:
rval = xsdfec_add_ldpc(xsdfec, arg);
break;
+   case XSDFEC_SET_ORDER:
+   rval = xsdfec_set_order(xsdfec, arg);
+   break;
+   case XSDFEC_SET_BYPASS:
+   rval = xsdfec_set_bypass(xsdfec, arg);
+   break;
+   case XSDFEC_IS_ACTIVE:
+   rval = xsdfec_is_active(xsdfec, (bool __user *)arg);
+   break;
default:
/* Should not get here */
dev_err(xsdfec->dev, "Undefined SDFEC IOCTL");
diff --git a/include/uapi/misc/xilinx_sdfec.h b/include/uapi/misc/xilinx_sdfec.h
index b6987c5..5532572 100644
--- a/include/uapi/misc/xilinx_sdfec.h
+++ b/include/uapi/misc/xilinx_sdfec.h
@@ -315,6 +315,19 @@ xsdfec_calculate_shared_ldpc_table_entry_size(struct 
xsdfec_ldpc_params *ldpc,
 #define XSDFEC_ADD_LDPC_CODE_PARAMS

[PATCH V3 12/12] MAINTAINERS: add maintainer for SD-FEC

2019-04-27 Thread Dragan Cvetic
support

Add maintainer entry for Xilinx SD-FEC driver support.

Signed-off-by: Derek Kiernan 
Signed-off-by: Dragan Cvetic 
---
 MAINTAINERS | 12 
 1 file changed, 12 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index b8d72ee..14e9335 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17116,6 +17116,18 @@ S: Supported
 F: Documentation/filesystems/xfs.txt
 F: fs/xfs/
 
+XILINX SD-FEC IP CORES
+M: Derek Kiernan 
+M: Dragan Cvetic 
+S: Maintained
+F: Documentation/devicetree/bindings/misc/xlnx,sd-fec.txt
+F: Documentation/misc-devices/xilinx_sdfec.rst
+F: Documentation/misc-devices/index.rst
+F: drivers/misc/xilinx_sdfec.c
+F: drivers/misc/Kconfig
+F: drivers/misc/Makefile
+F: include/uapi/misc/xilinx_sdfec.h
+
 XILINX AXI ETHERNET DRIVER
 M: Anirudha Sarangi 
 M: John Linn 
-- 
2.7.4



[PATCH V3 10/12] misc: xilinx_sdfec: Add stats & status ioctls

2019-04-27 Thread Dragan Cvetic
SD-FEC statistic data are:
- count of data interface errors (isr_err_count)
- count of Correctable ECC errors (cecc_count)
- count of Uncorrectable ECC errors (uecc_count)

Add support:
1. clear stats ioctl callback which clears collected
statistic data,
2. get stats ioctl callback which reads a collected
statistic data,
3. set default configuration ioctl callback,
4. start ioctl callback enables SD-FEC HW,
5. stop ioctl callback disables SD-FEC HW.

In a failed state driver enables the following ioctls:
- get status
- get statistics
- clear stats
- set default SD-FEC device configuration

Tested-by: Santhosh Dyavanapally 
Tested by: Punnaiah Choudary Kalluri 
Tested-by: Derek Kiernan 
Tested-by: Dragan Cvetic 
Signed-off-by: Derek Kiernan 
Signed-off-by: Dragan Cvetic 
---
 drivers/misc/xilinx_sdfec.c  | 123 +++
 include/uapi/misc/xilinx_sdfec.h |  75 
 2 files changed, 198 insertions(+)

diff --git a/drivers/misc/xilinx_sdfec.c b/drivers/misc/xilinx_sdfec.c
index 32b2e2d..317c5c4 100644
--- a/drivers/misc/xilinx_sdfec.c
+++ b/drivers/misc/xilinx_sdfec.c
@@ -203,6 +203,7 @@ struct xsdfec_clks {
  * @dev: pointer to device struct
  * @state: State of the SDFEC device
  * @config: Configuration of the SDFEC device
+ * @intr_enabled: indicates IRQ enabled
  * @state_updated: indicates State updated by interrupt handler
  * @stats_updated: indicates Stats updated by interrupt handler
  * @isr_err_count: Count of ISR errors
@@ -222,6 +223,7 @@ struct xsdfec_dev {
struct device *dev;
enum xsdfec_state state;
struct xsdfec_config config;
+   bool intr_enabled;
bool state_updated;
bool stats_updated;
atomic_t isr_err_count;
@@ -320,6 +322,26 @@ static int xsdfec_dev_release(struct inode *iptr, struct 
file *fptr)
return 0;
 }
 
+static int xsdfec_get_status(struct xsdfec_dev *xsdfec, void __user *arg)
+{
+   struct xsdfec_status status;
+   int err;
+
+   status.fec_id = xsdfec->config.fec_id;
+   spin_lock_irq(>irq_lock);
+   status.state = xsdfec->state;
+   xsdfec->state_updated = false;
+   spin_unlock_irq(>irq_lock);
+   status.activity = (xsdfec_regread(xsdfec, XSDFEC_ACTIVE_ADDR) &
+  XSDFEC_IS_ACTIVITY_SET);
+
+   err = copy_to_user(arg, , sizeof(status));
+   if (err)
+   err = -EFAULT;
+
+   return err;
+}
+
 static int xsdfec_get_config(struct xsdfec_dev *xsdfec, void __user *arg)
 {
int err;
@@ -896,6 +918,80 @@ static int xsdfec_cfg_axi_streams(struct xsdfec_dev 
*xsdfec)
return 0;
 }
 
+static int xsdfec_start(struct xsdfec_dev *xsdfec)
+{
+   u32 regread;
+
+   regread = xsdfec_regread(xsdfec, XSDFEC_FEC_CODE_ADDR);
+   regread &= 0x1;
+   if (regread != xsdfec->config.code) {
+   dev_err(xsdfec->dev,
+   "%s SDFEC HW code does not match driver code, reg %d, 
code %d",
+   __func__, regread, xsdfec->config.code);
+   return -EINVAL;
+   }
+
+   /* Set AXIS enable */
+   xsdfec_regwrite(xsdfec, XSDFEC_AXIS_ENABLE_ADDR,
+   XSDFEC_AXIS_ENABLE_MASK);
+   /* Done */
+   xsdfec->state = XSDFEC_STARTED;
+   return 0;
+}
+
+static int xsdfec_stop(struct xsdfec_dev *xsdfec)
+{
+   u32 regread;
+
+   if (xsdfec->state != XSDFEC_STARTED)
+   dev_err(xsdfec->dev, "Device not started correctly");
+   /* Disable AXIS_ENABLE Input interfaces only */
+   regread = xsdfec_regread(xsdfec, XSDFEC_AXIS_ENABLE_ADDR);
+   regread &= (~XSDFEC_AXIS_IN_ENABLE_MASK);
+   xsdfec_regwrite(xsdfec, XSDFEC_AXIS_ENABLE_ADDR, regread);
+   /* Stop */
+   xsdfec->state = XSDFEC_STOPPED;
+   return 0;
+}
+
+static int xsdfec_clear_stats(struct xsdfec_dev *xsdfec)
+{
+   atomic_set(>isr_err_count, 0);
+   atomic_set(>uecc_count, 0);
+   atomic_set(>cecc_count, 0);
+
+   return 0;
+}
+
+static int xsdfec_get_stats(struct xsdfec_dev *xsdfec, void __user *arg)
+{
+   int err;
+   struct xsdfec_stats user_stats;
+
+   spin_lock_irq(>irq_lock);
+   user_stats.isr_err_count = atomic_read(>isr_err_count);
+   user_stats.cecc_count = atomic_read(>cecc_count);
+   user_stats.uecc_count = atomic_read(>uecc_count);
+   xsdfec->stats_updated = false;
+   spin_unlock_irq(>irq_lock);
+
+   err = copy_to_user(arg, _stats, sizeof(user_stats));
+   if (err)
+   err = -EFAULT;
+
+   return err;
+}
+
+static int xsdfec_set_default_config(struct xsdfec_dev *xsdfec)
+{
+   /* Ensure registers are aligned with core configuration */
+   xsdfec_regwrite(xsdfec, XSDFEC_FEC_CODE_ADDR, xsdfec->config.code);
+   xsdfec_cfg_axi_streams(xsdfec);
+   update_config_from_hw(xsdfec);
+
+   return 0;
+}
+
 static long xsdfec_dev_ioctl(struct file *fptr, unsigned int cmd,
 

[PATCH V3 03/12] misc: xilinx_sdfec: Add CCF support

2019-04-27 Thread Dragan Cvetic
Add the support for Linux Clock Control Framework (CCF).
Registers and enables clocks with the Clock Control
Framework (CCF), to prevent shared clocks from been
disabled.

Tested-by: Dragan Cvetic 
Signed-off-by: Derek Kiernan 
Signed-off-by: Dragan Cvetic 
---
 drivers/misc/xilinx_sdfec.c | 154 
 1 file changed, 154 insertions(+)

diff --git a/drivers/misc/xilinx_sdfec.c b/drivers/misc/xilinx_sdfec.c
index 278754b..a52a5c6 100644
--- a/drivers/misc/xilinx_sdfec.c
+++ b/drivers/misc/xilinx_sdfec.c
@@ -37,6 +37,28 @@ static atomic_t xsdfec_ndevs = ATOMIC_INIT(0);
 static dev_t xsdfec_devt;
 
 /**
+ * struct xsdfec_clks - For managing SD-FEC clocks
+ * @core_clk: Main processing clock for core
+ * @axi_clk: AXI4-Lite memory-mapped clock
+ * @din_words_clk: DIN Words AXI4-Stream Slave clock
+ * @din_clk: DIN AXI4-Stream Slave clock
+ * @dout_clk: DOUT Words AXI4-Stream Slave clock
+ * @dout_words_clk: DOUT AXI4-Stream Slave clock
+ * @ctrl_clk: Control AXI4-Stream Slave clock
+ * @status_clk: Status AXI4-Stream Slave clock
+ */
+struct xsdfec_clks {
+   struct clk *core_clk;
+   struct clk *axi_clk;
+   struct clk *din_words_clk;
+   struct clk *din_clk;
+   struct clk *dout_clk;
+   struct clk *dout_words_clk;
+   struct clk *ctrl_clk;
+   struct clk *status_clk;
+};
+
+/**
  * struct xsdfec_dev - Driver data for SDFEC
  * @regs: device physical base address
  * @dev: pointer to device struct
@@ -44,6 +66,7 @@ static dev_t xsdfec_devt;
  * @open_count: Count of char device being opened
  * @xsdfec_cdev: Character device handle
  * @irq_lock: Driver spinlock
+ * @clks: Clocks managed by the SDFEC driver
  *
  * This structure contains necessary state for SDFEC driver to operate
  */
@@ -55,12 +78,136 @@ struct xsdfec_dev {
struct cdev xsdfec_cdev;
/* Spinlock to protect state_updated and stats_updated */
spinlock_t irq_lock;
+   struct xsdfec_clks clks;
 };
 
 static const struct file_operations xsdfec_fops = {
.owner = THIS_MODULE,
 };
 
+static int xsdfec_clk_init(struct platform_device *pdev,
+  struct xsdfec_clks *clks)
+{
+   int err;
+
+   clks->core_clk = devm_clk_get(>dev, "core_clk");
+   if (IS_ERR(clks->core_clk)) {
+   dev_err(>dev, "failed to get core_clk");
+   return PTR_ERR(clks->core_clk);
+   }
+
+   clks->axi_clk = devm_clk_get(>dev, "s_axi_aclk");
+   if (IS_ERR(clks->axi_clk)) {
+   dev_err(>dev, "failed to get axi_clk");
+   return PTR_ERR(clks->axi_clk);
+   }
+
+   clks->din_words_clk = devm_clk_get(>dev, "s_axis_din_words_aclk");
+   if (IS_ERR(clks->din_words_clk))
+   clks->din_words_clk = NULL;
+
+   clks->din_clk = devm_clk_get(>dev, "s_axis_din_aclk");
+   if (IS_ERR(clks->din_clk))
+   clks->din_clk = NULL;
+
+   clks->dout_clk = devm_clk_get(>dev, "m_axis_dout_aclk");
+   if (IS_ERR(clks->dout_clk))
+   clks->dout_clk = NULL;
+
+   clks->dout_words_clk =
+   devm_clk_get(>dev, "s_axis_dout_words_aclk");
+   if (IS_ERR(clks->dout_words_clk))
+   clks->dout_words_clk = NULL;
+
+   clks->ctrl_clk = devm_clk_get(>dev, "s_axis_ctrl_aclk");
+   if (IS_ERR(clks->ctrl_clk))
+   clks->ctrl_clk = NULL;
+
+   clks->status_clk = devm_clk_get(>dev, "m_axis_status_aclk");
+   if (IS_ERR(clks->status_clk))
+   clks->status_clk = NULL;
+
+   err = clk_prepare_enable(clks->core_clk);
+   if (err) {
+   dev_err(>dev, "failed to enable core_clk (%d)", err);
+   return err;
+   }
+
+   err = clk_prepare_enable(clks->axi_clk);
+   if (err) {
+   dev_err(>dev, "failed to enable axi_clk (%d)", err);
+   goto err_disable_core_clk;
+   }
+
+   err = clk_prepare_enable(clks->din_clk);
+   if (err) {
+   dev_err(>dev, "failed to enable din_clk (%d)", err);
+   goto err_disable_axi_clk;
+   }
+
+   err = clk_prepare_enable(clks->din_words_clk);
+   if (err) {
+   dev_err(>dev, "failed to enable din_words_clk (%d)", err);
+   goto err_disable_din_clk;
+   }
+
+   err = clk_prepare_enable(clks->dout_clk);
+   if (err) {
+   dev_err(>dev, "failed to enable dout_clk (%d)", err);
+   goto err_disable_din_words_clk;
+   }
+
+   err = clk_prepare_enable(clks->dout_words_clk);
+   if (err) {
+   dev_err(>dev, "failed to enable dout_words_clk (%d)",
+   err);
+   goto err_disable_dout_clk;
+   }
+
+   err = clk_prepare_enable(clks->ctrl_clk);
+   if (err) {
+   dev_err(>dev, "failed to enable ctrl_clk (%d)", err);
+   goto err_disable_dout_words_clk;
+   }
+
+   err = clk_prepare_enable(clks->status_clk);

Re: EDAC: Fix memory leak in creating CSROW object

2019-04-27 Thread Greg KH
On Fri, Apr 19, 2019 at 02:45:16AM +0200, Borislav Petkov wrote:
> On Fri, Apr 19, 2019 at 08:35:36AM +0800, PanBian wrote:
> > Yes, I see that. Because the loop start with (--i), there is no put
> > operation for the device that fails to create. So, I think we cannot
> > rule out the possibility of memory leak.
> 
> Ok, so this is not something you trigger - you're basically staring at
> the code?
> 
> Well, there's something else questionable in that code which I asked
> Greg about today but we didn't finish that conversation, let me CC him.
> 
> So AFAIU, devices for which device_add() has returned success,
> should be removed with their counterpart device_del().
> edac_create_csrow_objects(), however, does put_device() on those in the
> "unwinding" loop.
> 
> And for the case where device_add() fails, you should do put_device() to
> it. I.e., what you're saying.
> 
> So I think we need to figure what needs to be done when before fixing
> this properly.
> 
> Greg?

How about this patch, I think it fixes up everything you need to do
here, right?


diff --git a/drivers/edac/edac_mc_sysfs.c b/drivers/edac/edac_mc_sysfs.c
index 464174685589..0fb2d1de6d0e 100644
--- a/drivers/edac/edac_mc_sysfs.c
+++ b/drivers/edac/edac_mc_sysfs.c
@@ -404,6 +404,8 @@ static inline int nr_pages_per_csrow(struct csrow_info 
*csrow)
 static int edac_create_csrow_object(struct mem_ctl_info *mci,
struct csrow_info *csrow, int index)
 {
+   int retval;
+
csrow->dev.type = _attr_type;
csrow->dev.groups = csrow_dev_groups;
device_initialize(>dev);
@@ -415,7 +417,10 @@ static int edac_create_csrow_object(struct mem_ctl_info 
*mci,
edac_dbg(0, "creating (virtual) csrow node %s\n",
 dev_name(>dev));
 
-   return device_add(>dev);
+   retval = device_add(>dev);
+   if (retval)
+   put_device(>dev);
+   return retval;
 }
 
 /* Create a CSROW object under specifed edac_mc_device */
@@ -649,6 +654,8 @@ static int edac_create_dimm_object(struct mem_ctl_info *mci,
 
edac_dbg(0, "creating rank/dimm device %s\n", dev_name(>dev));
 
+   if (err)
+   put_device(>dev);
return err;
 }
 
@@ -928,6 +935,7 @@ int edac_create_sysfs_mci_device(struct mem_ctl_info *mci,
err = device_add(>dev);
if (err < 0) {
edac_dbg(1, "failure: create device %s\n", dev_name(>dev));
+   put_device(mci->dev);
goto out;
}
 


Re: [PATCH v2] fs/proc: add VmTaskSize field to /proc/$$/status

2019-04-27 Thread Alexey Dobriyan
On Fri, Apr 26, 2019 at 03:02:08PM -0400, Joel Savitz wrote:
> In the mainline kernel, there is no quick mechanism to get the virtual
> memory size of the current process from userspace.
> 
> Despite the current state of affairs, this information is available to the
> user through several means, one being a linear search of the entire address
> space. This is an inefficient use of cpu cycles.

You can test only a few known per arch values. Linear search is a self
inflicted wound.

prctl(2) is more natural place and will also be arch neutral.

> A component of the libhugetlb kernel test does exactly this, and as
> systems' address spaces increase beyond 32-bits, this method becomes
> exceedingly tedious.

> For example, on a ppc64le system with a 47-bit address space, the linear
> search causes the test to hang for some unknown amount of time. I
> couldn't give you an exact number because I just ran it for about 10-20
> minutes and went to go do something else, probably to get coffee or
> something, and when I came back, I just killed the test and patched it
> to use this new mechanism. I re-ran my new version of the test using a
> kernel with this patch, and of course it passed through the previously
> bottlenecking codepath nearly instantaneously.
> 
> This patched enabled me to upgrade an O(n) codepath to O(1) in an
> architecture-independent manner.

> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -74,7 +74,10 @@ void task_mem(struct seq_file *m, struct mm_struct *mm)
>   seq_put_decimal_ull_width(m,
>   " kB\nVmPTE:\t", mm_pgtables_bytes(mm) >> 10, 8);
>   SEQ_PUT_DEC(" kB\nVmSwap:\t", swap);
> - seq_puts(m, " kB\n");
> + SEQ_PUT_DEC(" kB\nVmSwap:\t", swap);
> + seq_put_decimal_ull_width(m,
> + " kB\nVmTaskSize:\t", TASK_SIZE >> 10, 8);
> + seq_puts(m, " kB\n");

All fields in this file are related to the task. New field related
to "current" will stick like an eyesore.


Re: [PATCH v6] iio: cros_ec: Add lid angle driver

2019-04-27 Thread Gwendal Grignou
On Sat, Apr 27, 2019 at 6:24 AM Jonathan Cameron
 wrote:
>
> On Sat, 27 Apr 2019 14:21:12 +0100
> Jonathan Cameron  wrote:
>
> > On Wed, 24 Apr 2019 17:29:32 -0700
> > Gwendal Grignou  wrote:
> >
> > > Add a IIO driver that reports the angle between the lid and the base for
> > > ChromeOS convertible device.
> > >
> > Tested on eve with ToT EC firmware.
> > > Check driver is loaded and lid angle is correct.
> > >
> > > Signed-off-by: Gwendal Grignou 
> > I am a little curious... In what way is this a counter driver (comments
> > at the top of the main file)?
It is a mistake, I used another driver .c file as a starting point. I
will fix it.
> >
> > Anyhow, that's no reason not to apply it.  However, it has just missed
> > the coming merge window unless Linus makes 'it is delayed noises' tomorrow.
> >
> > Applied to the togreg branch of iio.git and pushed out as testing
> > for the autobuilders to play with it.
> Ah. Should have waited for my local build test to finish.
>
> I'm guessing this has a dependency I don't know about?
> MOTIONSENSE_CMD_LID_ANGLE isn't defined.
Yes, that constant is part of the cros_ec_commands.h update, in patch
"[PATCH 15/30] mfd: cros_ec: Complete MEMS sensor API"

Gwendal.
>
> Jonathan
>
> >
> > Thanks,
> >
> > Jonathan
> >
> > > ---
> > > Changes in v6:
> > > - Fix lock held in an error path error.
> > >
> > > Changes in v5:
> > > - Remove unnecessary define.
> > > - v4 was the wrong patch file
> > >
> > > Changes in v3:
> > > - Use static channel array, simplify code because index is always 0.
> > >
> > > Changes in v2:
> > > - Fix license, remove driver_module field.
> > >
> > >  drivers/iio/common/cros_ec_sensors/Kconfig|   9 ++
> > >  drivers/iio/common/cros_ec_sensors/Makefile   |   1 +
> > >  .../cros_ec_sensors/cros_ec_lid_angle.c   | 139 ++
> > >  drivers/mfd/cros_ec_dev.c |  13 +-
> > >  4 files changed, 159 insertions(+), 3 deletions(-)
> > >  create mode 100644 drivers/iio/common/cros_ec_sensors/cros_ec_lid_angle.c
> > >
> > > diff --git a/drivers/iio/common/cros_ec_sensors/Kconfig 
> > > b/drivers/iio/common/cros_ec_sensors/Kconfig
> > > index 135f6825903f..aacc2ab9c34f 100644
> > > --- a/drivers/iio/common/cros_ec_sensors/Kconfig
> > > +++ b/drivers/iio/common/cros_ec_sensors/Kconfig
> > > @@ -20,3 +20,12 @@ config IIO_CROS_EC_SENSORS
> > >   Accelerometers, Gyroscope and Magnetometer that are
> > >   presented by the ChromeOS EC Sensor hub.
> > >   Creates an IIO device for each functions.
> > > +
> > > +config IIO_CROS_EC_SENSORS_LID_ANGLE
> > > +   tristate "ChromeOS EC Sensor for lid angle"
> > > +   depends on IIO_CROS_EC_SENSORS_CORE
> > > +   help
> > > + Module to report the angle between lid and base for some
> > > + convertible devices.
> > > + This module is loaded when the EC can calculate the angle between 
> > > the base
> > > + and the lid.
> > > diff --git a/drivers/iio/common/cros_ec_sensors/Makefile 
> > > b/drivers/iio/common/cros_ec_sensors/Makefile
> > > index ec716ff2a775..a35ee232ac07 100644
> > > --- a/drivers/iio/common/cros_ec_sensors/Makefile
> > > +++ b/drivers/iio/common/cros_ec_sensors/Makefile
> > > @@ -4,3 +4,4 @@
> > >
> > >  obj-$(CONFIG_IIO_CROS_EC_SENSORS_CORE) += cros_ec_sensors_core.o
> > >  obj-$(CONFIG_IIO_CROS_EC_SENSORS) += cros_ec_sensors.o
> > > +obj-$(CONFIG_IIO_CROS_EC_SENSORS_LID_ANGLE) += cros_ec_lid_angle.o
> > > diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_lid_angle.c 
> > > b/drivers/iio/common/cros_ec_sensors/cros_ec_lid_angle.c
> > > new file mode 100644
> > > index ..876dfd176b0e
> > > --- /dev/null
> > > +++ b/drivers/iio/common/cros_ec_sensors/cros_ec_lid_angle.c
> > > @@ -0,0 +1,139 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +
> > > +/*
> > > + * cros_ec_lid_angle - Driver for CrOS EC lid angle sensor.
> > > + *
> > > + * Copyright 2018 Google, Inc
> > > + *
> > > + * This driver uses the cros-ec interface to communicate with the Chrome 
> > > OS
> > > + * EC about counter sensors. Counters are presented through
> > > + * iio sysfs.
> > > + */
> > > +
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +
> > > +#define DRV_NAME "cros-ec-lid-angle"
> > > +
> > > +/*
> > > + * One channel for the lid angle, the other for timestamp.
> > > + */
> > > +static const struct iio_chan_spec cros_ec_lid_angle_channels[] = {
> > > +   {
> > > +   .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> > > +   .scan_type.realbits = CROS_EC_SENSOR_BITS,
> > > +   .scan_type.storagebits = CROS_EC_SENSOR_BITS,
> > > +   .scan_type.sign = 'u',
> > > +   .type = IIO_ANGL
> > > +   },
> > > +   IIO_CHAN_SOFT_TIMESTAMP(1)
> > > +};
> > > +
> > > +/* State data for ec_sensors iio driver. */

Re: [PATCH 1/1] rcu/sync: simplify the state machine

2019-04-27 Thread Paul E. McKenney
On Thu, Apr 25, 2019 at 06:50:55PM +0200, Oleg Nesterov wrote:
> With this patch rcu_sync has a single state variable and the transition rules
> become really simple:
> 
>   GP_IDLE   - owned by the first rcu_sync_enter() which moves it to
> 
>   GP_ENTER  - owned by rcu-callback which moves it to
> 
>   GP_PASSED - owned by the last rcu_sync_exit() which moves it to
> 
>   GP_EXIT   - and this is the only "nontrivial" state.
> 
>   rcu-callback moves it back to GP_IDLE unless another enter()
>   comes before a GP pass.
> 
>   If rcu-callback is invoked before the next rcu_sync_exit() it
>   must see gp_count incremented by that enter() and set GP_PASSED.
> 
>   Otherwise, if the next rcu_sync_exit() wins the race, it will
>   move it to
> 
>   GP_REPLAY - owned by rcu-callback which moves it to GP_EXIT
> 
> Signed-off-by: Oleg Nesterov 

Queued and passing initial tests, thank you!  It may be a day or two
before it shows up on -rcu, but it will get there!

Thanx, Paul

> ---
>  include/linux/rcu_sync.h |   2 -
>  kernel/rcu/sync.c| 165 
> +++
>  2 files changed, 95 insertions(+), 72 deletions(-)
> 
> diff --git a/include/linux/rcu_sync.h b/include/linux/rcu_sync.h
> index e7ae221..3156a14 100644
> --- a/include/linux/rcu_sync.h
> +++ b/include/linux/rcu_sync.h
> @@ -19,7 +19,6 @@ struct rcu_sync {
>   int gp_count;
>   wait_queue_head_t   gp_wait;
>  
> - int cb_state;
>   struct rcu_head cb_head;
>  };
>  
> @@ -47,7 +46,6 @@ extern void rcu_sync_dtor(struct rcu_sync *);
>   .gp_state = 0,  \
>   .gp_count = 0,  \
>   .gp_wait = __WAIT_QUEUE_HEAD_INITIALIZER(name.gp_wait), \
> - .cb_state = 0,  \
>   }
>  
>  #define  DEFINE_RCU_SYNC(name)   \
> diff --git a/kernel/rcu/sync.c b/kernel/rcu/sync.c
> index ee427e1..d9f80fc 100644
> --- a/kernel/rcu/sync.c
> +++ b/kernel/rcu/sync.c
> @@ -10,15 +10,13 @@
>  #include 
>  #include 
>  
> -enum { GP_IDLE = 0, GP_PENDING, GP_PASSED };
> -enum { CB_IDLE = 0, CB_PENDING, CB_REPLAY };
> +enum { GP_IDLE = 0, GP_ENTER, GP_PASSED, GP_EXIT, GP_REPLAY };
>  
>  #define  rss_lockgp_wait.lock
>  
>  /**
>   * rcu_sync_init() - Initialize an rcu_sync structure
>   * @rsp: Pointer to rcu_sync structure to be initialized
> - * @type: Flavor of RCU with which to synchronize rcu_sync structure
>   */
>  void rcu_sync_init(struct rcu_sync *rsp)
>  {
> @@ -41,56 +39,26 @@ void rcu_sync_enter_start(struct rcu_sync *rsp)
>   rsp->gp_state = GP_PASSED;
>  }
>  
> -/**
> - * rcu_sync_enter() - Force readers onto slowpath
> - * @rsp: Pointer to rcu_sync structure to use for synchronization
> - *
> - * This function is used by updaters who need readers to make use of
> - * a slowpath during the update.  After this function returns, all
> - * subsequent calls to rcu_sync_is_idle() will return false, which
> - * tells readers to stay off their fastpaths.  A later call to
> - * rcu_sync_exit() re-enables reader slowpaths.
> - *
> - * When called in isolation, rcu_sync_enter() must wait for a grace
> - * period, however, closely spaced calls to rcu_sync_enter() can
> - * optimize away the grace-period wait via a state machine implemented
> - * by rcu_sync_enter(), rcu_sync_exit(), and rcu_sync_func().
> - */
> -void rcu_sync_enter(struct rcu_sync *rsp)
> -{
> - bool need_wait, need_sync;
>  
> - spin_lock_irq(>rss_lock);
> - need_wait = rsp->gp_count++;
> - need_sync = rsp->gp_state == GP_IDLE;
> - if (need_sync)
> - rsp->gp_state = GP_PENDING;
> - spin_unlock_irq(>rss_lock);
> +static void rcu_sync_func(struct rcu_head *rcu);
>  
> - WARN_ON_ONCE(need_wait && need_sync);
> - if (need_sync) {
> - synchronize_rcu();
> - rsp->gp_state = GP_PASSED;
> - wake_up_all(>gp_wait);
> - } else if (need_wait) {
> - wait_event(rsp->gp_wait, rsp->gp_state == GP_PASSED);
> - } else {
> - /*
> -  * Possible when there's a pending CB from a rcu_sync_exit().
> -  * Nobody has yet been allowed the 'fast' path and thus we can
> -  * avoid doing any sync(). The callback will get 'dropped'.
> -  */
> - WARN_ON_ONCE(rsp->gp_state != GP_PASSED);
> - }
> +static void rcu_sync_call(struct rcu_sync *rsp)
> +{
> + call_rcu(>cb_head, rcu_sync_func);
>  }
>  
>  /**
>   * rcu_sync_func() - Callback function managing reader access to fastpath
>   * @rhp: Pointer to rcu_head in rcu_sync structure to use for synchronization
>   *
> - * This function is passed to one of the call_rcu() functions 

Re: [PATCH 1/2] y2038: make CONFIG_64BIT_TIME unconditional

2019-04-27 Thread Arnd Bergmann
On Sat, Apr 27, 2019 at 5:06 PM Lukasz Majewski  wrote:
> > 27.04.2019 в 00:46:53 +0200 Lukasz Majewski написал:
> > (I am wondering whether such trucation is undefined behaviour in C
>
> According to [1] - Chapter 6.3.1.3 - Point 3 it is
> implementation-defined.

The kernel relies on the sane behavior for integer overflow in many
places already, and it is built with -fno-strict-overflow to also make
sure gcc doesn't optimize cases that would be undefined otherwise.

> > and
> > whether there should be sign-extension instead of zeroing-out for the
> > in_compat_syscall() case though.)
>
> What I've found is that "typically" the high order bits are discarded.
>
> However, it is still "implementation dependent".

I think the question was whether we should use

  kts.tv_nsec = (int)kts.tv_nsec;

instead of

  kts.tv_nsec &= 0xul;

Both have a clearly defined meaning in the C dialect we use in the
kernel, but differ in the upper 32 bits for negative input values.

I would say that using sign-extension indeed makes more sense
here, but we don't need to change it for linux-5.1, since none of the
callers of get_timespec64() care -- any negative 32-bit tv_nsec
value results in -EINVAL, including the utimensat() syscall that
has two special cases outside of the 0...9 range.

  Arnd


Re: [PATCH v4 5/5] mtd: hyperbus: Add driver for TI's HyperBus memory controller

2019-04-27 Thread Sergei Shtylyov
On 04/23/2019 01:48 PM, Vignesh Raghavendra wrote:

> Add driver for HyperBus memory controller on TI's AM654 SoC. Programming
> IP is pretty simple and provides direct memory mapped access to
> connected Flash devices.
> 
> Add basic support for the IP without DMA. Second chipSelect is not
> supported for now.
> 
> Signed-off-by: Vignesh Raghavendra 
[...]
> diff --git a/drivers/mtd/hyperbus/hbmc-am654.c 
> b/drivers/mtd/hyperbus/hbmc-am654.c
> new file mode 100644
> index ..f458d7226df9
> --- /dev/null
> +++ b/drivers/mtd/hyperbus/hbmc-am654.c
> @@ -0,0 +1,115 @@
> +// SPDX-License-Identifier: GPL-2.0
> +//
> +// Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
> +// Author: Vignesh Raghavendra 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct am654_hbmc_priv {
> + struct hyperbus_ctlr ctlr;
> + struct hyperbus_device hbdev;
> + void __iomem*regbase;

   You don't seem to use this field.

[...]

MBR, Sergei


Re: [PATCH v2 2/3] pwm: meson: Add clock source configuration for Meson G12A

2019-04-27 Thread Martin Blumenstingl
On Tue, Apr 23, 2019 at 3:37 PM Neil Armstrong  wrote:
>
> For the PWM controller in the Meson G12A SoC, the EE domain and AO domain
> have different clock sources. This patch tries to describe them in the
> DT compatible data. The two AO PWM controller has different clock source,
> but the first AO controller (A & B) can reuse the AXG parents name.
>
> Signed-off-by: Neil Armstrong 
Reviewed-by: Martin Blumenstingl 


Re: [PATCH v2 1/3] dt-bindings: pwm: Update bindings for the Meson G12A Family

2019-04-27 Thread Martin Blumenstingl
On Tue, Apr 23, 2019 at 3:37 PM Neil Armstrong  wrote:
>
> Update the doc to explicitly support Meson G12A Family.
> The 2 first (A & B) AO PWM uses different clock source than the last 2
> (C & D) AO PWM modules, thus we need to differentiate them.
>
> Signed-off-by: Neil Armstrong 
Reviewed-by: Martin Blumenstingl 


Re: [PATCH v2 6/6] arm64: dts: meson: Add minimal support for Odroid-N2

2019-04-27 Thread Martin Blumenstingl
Hi Neil,

On Tue, Apr 23, 2019 at 11:16 AM Neil Armstrong  wrote:
>
> This patch adds basic support for :
> - Amlogic G12B, which is very similar to G12A
> - The HardKernel Odroid-N2 based on the S922X SoC
>
> The Amlogic G12B SoC is very similar with the G12A SoC, sharing
> most of the features and architecture, but with these differences :
> - The first CPU cluster only has 2xCortex-A53 instead of 4
> - G12B has a second cluster of 4xCortex-A73
> - Both cluster can achieve 2GHz instead of 1,8GHz for G12A
> - CPU Clock architecture is difference, thus needing a different
>   compatible to handle this slight difference
> - Supports a MIPI CSI input
> - Embeds a Mali-G52 instead of a Mali-G31, but integration is the same
>
> Actual support is done in the same way as for the GXM support, including
> the G12A dtsi and redefining the CPU clusters.
> Unlike GXM, the first cluster is different, thus needing to remove
> the last 2 cpu nodes of the first cluster.
>
> Signed-off-by: Neil Armstrong 
I don't have the board myself so I can't test it. However, apart from
one comment below this is looking good so:
Reviewed-by: Martin Blumenstingl 

[...]
> + {
> +   status = "okay";
> +};
> +
> +_phy0 {
> +   phy-supply = <_pwr_en>;
> +};
is usb_pwr_en really the phy-supply or is it the vbus-supply of the
USB top control block ( node)?


Martin


Re: [PATCH v2 5/6] dt-bindings: arm: amlogic: add Odroid-N2 binding

2019-04-27 Thread Martin Blumenstingl
On Tue, Apr 23, 2019 at 11:16 AM Neil Armstrong  wrote:
>
> Add compatible for the Amlogic G12B (S922X) SoC based Odroid-N2 SBC
> from HardKernel.
nit-pick: their website mentions "Copyright 2018 Hardkernel co., Ltd. "

> Signed-off-by: Neil Armstrong 
> Reviewed-by: Rob Herring 
Reviewed-by: Martin Blumenstingl 


Re: [PATCH v2 4/6] dt-bindings: arm: amlogic: add G12B bindings

2019-04-27 Thread Martin Blumenstingl
On Tue, Apr 23, 2019 at 11:16 AM Neil Armstrong  wrote:
>
> Add compatible for the Amlogic G12B SoC, sharing most of the
> features and architecture with the G12A SoC.
>
> Signed-off-by: Neil Armstrong 
> Reviewed-by: Rob Herring 
Reviewed-by: Martin Blumenstingl 


Re: [PATCH v2 2/6] clk: meson: g12a: Add support for G12B CPUB clocks

2019-04-27 Thread Martin Blumenstingl
On Tue, Apr 23, 2019 at 11:15 AM Neil Armstrong  wrote:
>
> This patch support for the specific Amlogic G12B clocks.
>
> G12B clock driver is very close, the main differences are :
> - the clock tree is duplicated for the both clusters, and the
>   SYS_PLL are swapped between the clusters
> - G12A has additional clocks like for CSI an other components
>
> Here only the cpu clock tree is handled.
>
> Signed-off-by: Neil Armstrong 
Reviewed-by: Martin Blumenstingl 

while reviewing I used the public S922X datasheet from hardkernel to
verify the implementation.
I noticed that HHI_SYS_PLL_CNTL1  and HHI_SYS1_PLL_CNTL1 seem to have
a 19-bit fractional part for the sys_pll and sys1_pll clocks.
Neil, do you know more about the fractional parts on these clocks?


Regards
Martin


Re: [PATCH v2 1/6] dt-bindings: clk: meson: add g12b periph clock controller bindings

2019-04-27 Thread Martin Blumenstingl
On Tue, Apr 23, 2019 at 11:15 AM Neil Armstrong  wrote:
>
> This patch adds the specific Amlogic G12B clock driver compatible.
>
> G12B clock driver is very close, the main differences are :
> - the clock tree is duplicated for the both clusters, and the
>   SYS_PLL are swapped between the clusters
> - G12A has additional clocks like for CSI an other components
>
> Signed-off-by: Neil Armstrong 
> Reviewed-by: Rob Herring 
Reviewed-by: Martin Blumenstingl 


Re: [PATCH v3] Staging: vc04_services: Cleanup in ctrl_set_bitrate()

2019-04-27 Thread Stefan Wahren
Am 23.04.19 um 16:47 schrieb Madhumitha Prabakaran:
> Remove unnecessary variable from the function and make a corresponding
> change w.r.t the variable. In addition to that align the parameters in
> the parentheses to maintain Linux kernel coding style
>
> Issue suggested by Coccinelle.
>
> Signed-off-by: Madhumitha Prabakaran 
Acked-by: Stefan Wahren 


Re: [PATCH v2 6/7] mmc: meson-gx: remove Rx phase tuning

2019-04-27 Thread Martin Blumenstingl
On Tue, Apr 23, 2019 at 11:03 AM Jerome Brunet  wrote:
>
> This remove all the code related to phase settings. Using the Rx phase
> for tuning has not been reliable. We had several issues over the past
> months, on both v2 and v3 mmc chips After discussing the issue matter
> with Amlogic, They suggested to set a phase shift of 180 between Core and
> Tx and use signal resampling for the tuning.
>
> Since we won't be playing with the phase anymore, let's remove all the
> clock code related to it and set the appropriate value on init.
>
> Signed-off-by: Jerome Brunet 
[Khadas VIM now shows the HS200 eMMC]
Tested-by: Martin Blumenstingl 


BEFORE (no patches from this series applied):
# dmesg | grep mmc1
(no output)

AFTER (all 7 patches from this series applied):
# dmesg | grep mmc1
[2.945155] mmc1: new HS200 MMC card at address 0001
[2.957737] mmcblk1: mmc1:0001 AWPD3R 14.6 GiB
[2.966278] mmcblk1boot0: mmc1:0001 AWPD3R partition 1 4.00 MiB
[2.976114] mmcblk1boot1: mmc1:0001 AWPD3R partition 2 4.00 MiB
[2.986354] mmcblk1rpmb: mmc1:0001 AWPD3R partition 3 4.00 MiB,
chardev (241:0)


Regards
Martin


Re: [PATCH v2 7/7] mmc: meson-gx: add signal resampling tuning

2019-04-27 Thread Martin Blumenstingl
On Tue, Apr 23, 2019 at 11:03 AM Jerome Brunet  wrote:
>
> Use signal resampling tuning for the UHS and HS200 modes.
> Instead of trying to get the *best* resampling setting with complex
> window calculation, we just stop on the first working setting.
>
> If the tuning setting later proves unstable, we will just continue the
> tuning where we left it.
>
> Signed-off-by: Jerome Brunet 
[Khadas VIM now shows the HS200 eMMC]
Tested-by: Martin Blumenstingl 


BEFORE (no patches from this series applied):
# dmesg | grep mmc1
(no output)

AFTER (all 7 patches from this series applied):
# dmesg | grep mmc1
[2.945155] mmc1: new HS200 MMC card at address 0001
[2.957737] mmcblk1: mmc1:0001 AWPD3R 14.6 GiB
[2.966278] mmcblk1boot0: mmc1:0001 AWPD3R partition 1 4.00 MiB
[2.976114] mmcblk1boot1: mmc1:0001 AWPD3R partition 2 4.00 MiB
[2.986354] mmcblk1rpmb: mmc1:0001 AWPD3R partition 3 4.00 MiB,
chardev (241:0)


Regards
Martin


Re: [PATCH v2 5/7] mmc: meson-gx: avoid clock glitch when switching to DDR modes

2019-04-27 Thread Martin Blumenstingl
On Tue, Apr 23, 2019 at 11:03 AM Jerome Brunet  wrote:
>
> Activating DDR in the Amlogic mmc controller, among other things, will
> divide the output clock by 2. So by activating it with clock on, we are
> creating a glitch on the output.
>
> Instead, let's deal with DDR when the clock output is off, when setting
> the clock.
>
> Signed-off-by: Jerome Brunet 
[boot-tested on Khadas VIM and no obvious regressions could be seen]
Tested-by: Martin Blumenstingl 

thank you for fixing this issue from v1!


Re: [PATCH 2/4] PCI: pciehp: Replace ctrl_*() with pci_*()

2019-04-27 Thread Lukas Wunner
On Sat, Apr 27, 2019 at 02:13:02PM -0500, f...@fredlawl.com wrote:
> Hotplug useses custom ctrl_*() dev_*() printk wrappers for logging
> messages. To make hotplug conform to pci logging, replace uses of these
> wrappers with pci_*() printk wrappers. In addition, replace any
> printk() calls with pr_*() wrappers.

A lot of pciehp's messages are preceded by "Slot(%s): ", where %s is
replaced by the Physical Slot Number in the Slot Capabilities register
(which is cached in struct controller) plus an optional suffix if the
same PSN is used by multiple slots.  For some reason (probably a
historic artefact), this prefix is included only in *some* of the
messages.

I think it would be useful to make the messages consistent by *always*
including the "Slot(%s): " prefix.  However the prefix is unknown until
pci_hp_initialize() has been called.  I'd solve this by keeping the
ctrl_*() wrappers and amending them to print the "Slot(%s): " prefix,
then making sure that ctrl_*() is not called before pci_hp_initialize().
(pci_*() has to be used instead).


> @@ -182,39 +184,39 @@ static int pciehp_probe(struct pcie_device *dev)
>  
>   if (!dev->port->subordinate) {
>   /* Can happen if we run out of bus numbers during probe */
> - dev_err(>device,
> - "Hotplug bridge without secondary bus, ignoring\n");
> + pci_err(dev->port, "Hotplug bridge without secondary bus, 
> ignoring\n");

Hm, the string was likely deliberately put on a new line to avoid
exceeding 80 chars, so I'd keep it that way.

Thanks,

Lukas


Re: [PATCH v2 4/7] mmc: meson-gx: disable HS400

2019-04-27 Thread Martin Blumenstingl
Hi Jerome,

On Tue, Apr 23, 2019 at 11:03 AM Jerome Brunet  wrote:
>
> At the moment, all our attempts to enable HS400 on Amlogic chipsets have
> been unsuccessful or unreliable. Until we can figure out how to enable this
> mode safely and reliably, let's force it off.
last year I have seen issues with HS400 on my Khadas VIM2: [0]
have you tested all other patches from this series and HS400 is still
not working for you?

I'm curious because this patch is early in the series and all the
tuning fixes and improvements are after this patch.


Martin


[0] http://lists.infradead.org/pipermail/linux-amlogic/2018-January/006251.html


Re: [EXT] Re: [RFC 00/19] clk: imx: Switch the imx6 and imx7 to clk_hw based API

2019-04-27 Thread Abel Vesa
On 19-04-25 08:53:33, Stephen Boyd wrote:
> Caution: EXT Email
> 
> Quoting Abel Vesa (2019-04-24 00:13:48)
> >
> > Can you please be more specific and point out exactly which one isn't ?
> 
> Is this a question for me?
> 

Nevermind. I'll send another version in the following days.

> >
> > >
> > > FYI, I'm dropping this from my review queue under the assumption it will
> > > be sent again. Also, it would be nice to not have the wrappers at all in
> > > the next series so that everything is clk_hw based instead of clk based.
> > > Otherwise, it looks good to me and I'd like to see this work completed.
> > > Thanks!
> > >
> >
> > I'll try to resend this before the end of next week.
> >
> > As for the wrappers, they need to stay in until the last user of the clk
> > based API is switched to clk_hw based. That means all the remaining imx
> > platforms (1 through 5, and then 8). I chosed to do the imx6 and imx7
> > first because these are easier to find. Once this is in, I'll move on
> > with the imx8 and then the imx1 through imx5 (which are harder to find
> > nowadays).
> >
> 
> Ok. I'm not thrilled to keep around legacy code because nobody is
> testing out new kernels on these devices. If we can, we should try to
> delete old drivers that don't get used anymore, but if we can't then
> we should be able to modify and compile those drivers and wait for the
> bug reports to come in if something is broken.
> 

Yes, as I said, I'll put together some other patchseries for the older imx
platforms (1 through 5) once this one gets in.

> 

Re: [PATCH] staging: vc04_services: bcm2835-camera: Modify return statement.

2019-04-27 Thread Stefan Wahren
Am 27.04.19 um 18:07 schrieb Vatsala Narang:
> Modify return statement and remove the respective assignment.
>
> Issue found by Coccinelle.
>
> Signed-off-by: Vatsala Narang 
Acked-by: Stefan Wahren 


Re: [PATCH v2 3/7] mmc: meson-gx: correct irq flag

2019-04-27 Thread Martin Blumenstingl
On Tue, Apr 23, 2019 at 11:02 AM Jerome Brunet  wrote:
>
> There is no reason for another device to request the MMC irq. It should
> only be used the MMC device, so remove IRQ_SHARED and replace by
> IRQ_ONESHOT as we don't the irq to fire again until the irq thread is
> done
>
> Signed-off-by: Jerome Brunet 
I'm doing the same thing (for the same purpose) in the meson-mx-sdio driver:
Reviewed-by: Martin Blumenstingl 


Re: [PATCH v2 2/7] mmc: meson-gx: ack only raised irq

2019-04-27 Thread Martin Blumenstingl
On Tue, Apr 23, 2019 at 11:02 AM Jerome Brunet  wrote:
>
> This is merely a clean up. It makes sense to only ack raised irqs
> instead of acking everything all the time.
>
> Signed-off-by: Jerome Brunet 
based on reading (and understanding) the code and a test on my Khadas
VIM this seems fine so:
Acked-by: Martin Blumenstingl 


Re: [PATCH v2 0/4] Add drive-strength in Meson pinctrl driver

2019-04-27 Thread Martin Blumenstingl
Hi Linus,

On Tue, Apr 23, 2019 at 1:13 PM Linus Walleij  wrote:
>
> On Thu, Apr 18, 2019 at 2:48 PM Guillaume La Roque
>  wrote:
>
> > The purpose of this patchset is to add drive-strength support in meson 
> > pinconf
> > driver. This is a new feature that was added on the g12a. It is critical 
> > for us
> > to support this since many functions are failing with default pad 
> > drive-strength.
> >
> > The value achievable by the SoC are 0.5mA, 2.5mA, 3mA and 4mA and the DT 
> > property
> > 'drive-strength' is expressed in mA.
> > So this patch add another generic property "drive-strength-uA". The change 
> > to do so
> > would be minimal and could be benefit to other platforms later on.
> >
> > Cheers
> > Guillaume
>
> This needs to be reviewed by Martin Blumenstigl, Martin can you have a look
> at this patch set? If you don't have the patches I think Guillaume can
> resend them.
thank you for the reminder - I just sent my feedback.
can you please also have a look at patch 4/4? there are two cases
where I'm not sure what the best practice of the pinctrl subsystem is


Regards
Martin


Re: [PATCH v2 4/4] pinctrl: meson: add support of drive-strength-uA

2019-04-27 Thread Martin Blumenstingl
Hi Guillaume,

On Thu, Apr 18, 2019 at 2:48 PM Guillaume La Roque
 wrote:
>
> drive-strength-uA is a new feature needed for G12A SoC.
> the default DS setting after boot is usually 500uA and it is not enough for
> many functions. We need to be able to set the drive strength to reliably
> enable things like MMC, I2C, etc ...
>
> Signed-off-by: Guillaume La Roque 
I gave this a go on Meson8m2 (meaning I applied all four patches from
this series and booted the result on my board):
[Meson8m2 doesn't support drive strength and still boots without any
crashes or obvious regressions]
Tested-by: Martin Blumenstingl 

> ---
>  drivers/pinctrl/meson/pinctrl-meson-g12a.c |  36 ++---
>  drivers/pinctrl/meson/pinctrl-meson.c  | 166 -
>  drivers/pinctrl/meson/pinctrl-meson.h  |  20 ++-
personally I would have split this into two separate patches:
- one for the generic pinctrl-meson part which adds drive-strength-uA support
- another patch for enabling this on G12A

if nobody else wants you to split this then it's fine for me as well

>  3 files changed, 163 insertions(+), 59 deletions(-)
>
> diff --git a/drivers/pinctrl/meson/pinctrl-meson-g12a.c 
> b/drivers/pinctrl/meson/pinctrl-meson-g12a.c
> index d494492e98e9..3475cd7bd2af 100644
> --- a/drivers/pinctrl/meson/pinctrl-meson-g12a.c
> +++ b/drivers/pinctrl/meson/pinctrl-meson-g12a.c
> @@ -1304,28 +1304,28 @@ static struct meson_pmx_func 
> meson_g12a_aobus_functions[] = {
>  };
>
>  static struct meson_bank meson_g12a_periphs_banks[] = {
> -   /* name  first  last  irq  pullen  pull  dir  out  in */
> -   BANK("Z",GPIOZ_0,GPIOZ_15, 12, 27,
> -4,  0,  4,  0,  12,  0,  13, 0,  14, 0),
> -   BANK("H",GPIOH_0,GPIOH_8, 28, 36,
> -3,  0,  3,  0,  9,  0,  10,  0,  11,  0),
> -   BANK("BOOT", BOOT_0, BOOT_15,  37, 52,
> -0,  0,  0,  0,  0, 0,  1, 0,  2, 0),
> -   BANK("C",GPIOC_0,GPIOC_7,  53, 60,
> -1,  0,  1,  0,  3, 0,  4, 0,  5, 0),
> -   BANK("A",GPIOA_0,GPIOA_15,  61, 76,
> -5,  0,  5,  0,  16,  0,  17,  0,  18,  0),
> -   BANK("X",GPIOX_0,GPIOX_19,   77, 96,
> -2,  0,  2,  0,  6,  0,  7,  0,  8,  0),
> +   /* name  first  last  irq  pullen  pull  dir  out  in  ds */
> +   BANK_DS("Z",GPIOZ_0,GPIOZ_15, 12, 27,
> +   4,  0,  4,  0,  12,  0,  13, 0,  14, 0, 5, 0),
> +   BANK_DS("H",GPIOH_0,GPIOH_8, 28, 36,
> +   3,  0,  3,  0,  9,  0,  10,  0,  11,  0, 4, 0),
> +   BANK_DS("BOOT", BOOT_0, BOOT_15,  37, 52,
> +   0,  0,  0,  0,  0, 0,  1, 0,  2, 0, 0, 0),
> +   BANK_DS("C",GPIOC_0,GPIOC_7,  53, 60,
> +   1,  0,  1,  0,  3, 0,  4, 0,  5, 0, 1, 0),
> +   BANK_DS("A",GPIOA_0,GPIOA_15,  61, 76,
> +   5,  0,  5,  0,  16,  0,  17,  0,  18,  0, 6, 0),
> +   BANK_DS("X",GPIOX_0,GPIOX_19,   77, 96,
> +   2,  0,  2,  0,  6,  0,  7,  0,  8,  0, 2, 0),
>  };
>
>  static struct meson_bank meson_g12a_aobus_banks[] = {
> -   /* name  first  last  irq  pullen  pull  dir  out  in  */
> -   BANK("AO",   GPIOAO_0,  GPIOAO_11,  0, 11,
> -3,  0,  2, 0,  0,  0,  4, 0,  1,  0),
> +   /* name  first  last  irq  pullen  pull  dir  out  in  ds */
> +   BANK_DS("AO", GPIOAO_0, GPIOAO_11, 0, 11, 3, 0, 2, 0, 0, 0, 4, 0, 1, 
> 0,
> +   0, 0),
> /* GPIOE actually located in the AO bank */
> -   BANK("E",   GPIOE_0,  GPIOE_2,   97, 99,
> -3,  16,  2, 16,  0,  16,  4, 16,  1,  16),
> +   BANK_DS("E", GPIOE_0, GPIOE_2, 97, 99, 3, 16, 2, 16, 0, 16, 4, 16, 1,
> +   16, 1, 0),
>  };
these definitions are really hard to read, but it's been like this
even before your patch

>  static struct meson_pmx_bank meson_g12a_periphs_pmx_banks[] = {
> diff --git a/drivers/pinctrl/meson/pinctrl-meson.c 
> b/drivers/pinctrl/meson/pinctrl-meson.c
> index 96a4a72708e4..5108e5aa6514 100644
> --- a/drivers/pinctrl/meson/pinctrl-meson.c
> +++ b/drivers/pinctrl/meson/pinctrl-meson.c
> @@ -174,62 +174,106 @@ int meson_pmx_get_groups(struct pinctrl_dev *pcdev, 
> unsigned selector,
> return 0;
>  }
>
> -static int meson_pinconf_set(struct pinctrl_dev *pcdev, unsigned int pin,
> -unsigned long *configs, unsigned num_configs)
> +static int meson_pinconf_set_bias(struct meson_pinctrl *pc, unsigned int pin,
> + enum pin_config_param conf)
can you please confirm that I understood the purpose of this correctly:
I think you introduce this to make setting the bias consistent with
how you set the drive-strength.
if so then it would be great to have a separate patch which describes
that it's only a code-style change and a functional no-op

additionally the function arguments are not consistent with
meson_pinconf_get_drive_strength():
- here you pass the pinctrl subsystem specific 

[PATCH] ASoC: tlv320aic3x: Add support for high power analog output

2019-04-27 Thread Saravanan Sekar
Add support to power and output level control for the analog high power
output drivers HPOUT and HPCOM.

Signed-off-by: Saravanan Sekar 
---
 sound/soc/codecs/tlv320aic3x.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/sound/soc/codecs/tlv320aic3x.c b/sound/soc/codecs/tlv320aic3x.c
index 516d17cb2182..d4bafac802eb 100644
--- a/sound/soc/codecs/tlv320aic3x.c
+++ b/sound/soc/codecs/tlv320aic3x.c
@@ -419,6 +419,12 @@ static const struct snd_kcontrol_new aic3x_snd_controls[] 
= {
/* Pop reduction */
SOC_ENUM("Output Driver Power-On time", aic3x_poweron_time_enum),
SOC_ENUM("Output Driver Ramp-up step", aic3x_rampup_step_enum),
+
+   /* Analog HPOUT, HPCOM power and output level controls */
+   SOC_DOUBLE_R("Analog output power control", HPROUT_CTRL,
+   HPRCOM_CTRL, 0, 1, 0),
+   SOC_DOUBLE_R("Analog output level control", HPROUT_CTRL,
+   HPRCOM_CTRL, 4, 9, 0),
 };
 
 /* For other than tlv320aic3104 */
-- 
2.17.1



Re: memleak around kobject_init_and_add()

2019-04-27 Thread Greg Kroah-Hartman
On Sat, Apr 27, 2019 at 06:13:30PM +1000, Tobin C. Harding wrote:
> (Note at bottom on reasons for 'To' list 'Cc' list)
> 
> Hi,
> 
> kobject_init_and_add() seems to be routinely misused.  A failed call to this
> function requires a call to kobject_put() otherwise we leak memory.
> 
> Examples memleaks can be seen in:
> 
>   mm/slub.c
>   fs/btrfs/sysfs.c
>   fs/xfs/xfs_sysfs.h: xfs_sysfs_init()
> 
>  Question: Do we fix the misuse or fix the API?

Fix the misuse.

> $ git grep kobject_init_and_add | wc -l
> 117
> 
> Either way, we will have to go through all 117 call sites and check them.

Yes.  Same for other functions like device_add(), that is the "pattern"
those users must follow.

> I
> don't mind fixing them all but I don't want to do it twice because I chose the
> wrong option.  Reaching out to those more experienced for a suggestion please.
> 
> Fix the API
> ---
> 
> Typically init functions do not require cleanup if they fail, this argument
> leads to this patch
> 
> diff --git a/lib/kobject.c b/lib/kobject.c
> index aa89edcd2b63..62328054bbd0 100644
> --- a/lib/kobject.c
> +++ b/lib/kobject.c
> @@ -453,6 +453,9 @@ int kobject_init_and_add(struct kobject *kobj, struct 
> kobj_type *ktype,
>   retval = kobject_add_varg(kobj, parent, fmt, args);
>   va_end(args);
>  
> + if (retval)
> + kobject_put(kobj);
> +
>   return retval;
>  }
>  EXPORT_SYMBOL_GPL(kobject_init_and_add);

I would _love_ to do this, but realize what a kobject really is.

It's just a "base object" that is embedded inside of some other object.
The kobject core has no idea what is going on outside of itself.  If the
kobject_init_and_add() function fails, it can NOT drop the last
reference on itself, as that would cause the memory owned by the _WHOLE_
structure the kobject is embedded in, to be freed.

And the kobject core can not "know" that something else needed to be
done _before_ that memory could be freed.  What if the larger structure
needs to have some other destructor called on it first?  What if
some other api initialization needs to be torn down.

As an example, consider this code:

struct foo {
struct kobject kobj;
struct baz *baz;
};

void foo_release(struct kobject *kobj)
{
struct foo *foo = container_of(kobj, struct foo, kobj);
kfree(foo);
}

struct kobj_type foo_ktype = {
.release = foo_release,
};

struct foo *foo_create(struct foo *parent, char *name)
{
struct *foo;

foo = kzalloc(sizeof(*foo), GFP_KERNEL);
if (!foo)
return NULL;

foo->baz = baz_create(name);
if (!foo->baz)
return NULL;

ret = kobject_init_and_add(>kobj, foo_ktype, >kobj, 
"foo-%s", name);
if (ret) {
baz_destroy(foo->baz);
kobject_put(>kobj);
return NULL;
}

return foo;
}

void foo_destroy(struct foo *foo)
{
baz_destroy(foo->baz);
kobject_del(>kobj);
}

Now if kobject_init_and_add() had failed, and called kobject_put() right
away, that would have freed the larger "struct foo", but not cleaned up
the reference to the baz pointer.

Yes, you can move all of the other destruction logic into the release
function, to then get rid of baz, but that really doesn't work in the
real world as there are times you want to drop that when you "know" you
can drop it, not when the last reference goes away as those are
different lifecycles.

Same thing goes for 'struct device'.  It too is a kobject, so think
about if the driver core's call to initialize the kobject failed, would
it be ok at that exact moment in time to free everything?

Look at the "joy" that is device_add().  If kobject_add() fails, we have
to clean up the glue directory that we had created, _before_ we can then
call put_device().  Then stack another layer on top of that, look at
usb_new_device().  If the call to device_add() fails, it needs to do
some housekeeping before it can drop the last reference to the device to
free the memory up.

> Fix all the call sites
> --
> 
> Go through all 117 call sites and add kobj_put() in the error path.

Yes.

> This example from mm/slub.c
> 
> diff --git a/mm/slub.c b/mm/slub.c
> index d30ede89f4a6..84a9d6c06c27 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -5756,8 +5756,10 @@ static int sysfs_slab_add(struct kmem_cache *s)
>  
>   s->kobj.kset = kset;
>   err = kobject_init_and_add(>kobj, _ktype, NULL, "%s", name);
> - if (err)
> + if (err) {
> + kobject_put(>kobj);
>   goto out;
> + }

Yup, it sucks, but unless you can think of a better way to do all of
this, that's the requirement here.  Again, same thing for a call to
device_add().  Another subsystem got burned by this just the other day
and we added yet-another-line in the documentation trying to call it out
explicitly.

Kernel programming is hard, sorry, let's go shopping...

> This is a 

Re: [PATCH v2 3/4] dt-bindings: pinctrl: meson: Add drive-strength-uA property

2019-04-27 Thread Martin Blumenstingl
Hi Guillaume,

On Thu, Apr 18, 2019 at 2:48 PM Guillaume La Roque
 wrote:
>
> Add optional drive-strength-uA property
>
> Signed-off-by: Guillaume La Roque 
> ---
>  Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt 
> b/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt
> index a47dd990a8d3..b3e4be696ddc 100644
> --- a/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt
> +++ b/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt
> @@ -51,6 +51,9 @@ Configuration nodes support the generic properties 
> "bias-disable",
>  "bias-pull-up" and "bias-pull-down", described in file
>  pinctrl-bindings.txt
>
> +Optional properties :
> + - drive-strength-uA: Drive strength for the specified pins in uA.
if you have to re-send this series for whatever reason then please
mention that drive-strength-uA is only valid for G12A and newer

otherwise:
Reviewed-by: Martin Blumenstingl 


Re: [PATCH v2 1/4] dt-bindings: pinctrl: add a 'drive-strength-uA' property

2019-04-27 Thread Martin Blumenstingl
On Thu, Apr 18, 2019 at 2:48 PM Guillaume La Roque
 wrote:
>
> This property allow drive-strength parameter in uA instead of mA.
>
> Signed-off-by: Guillaume La Roque 
personally I'm happy with this if the DT maintainers give their ACK.
based on that:
Acked-by: Martin Blumenstingl 


[PATCH 3/4] PCI: pciehp: Remove unused macro definitions

2019-04-27 Thread fred
From: Frederick Lawler 

Now that all uses for the ctrl_*() printk wrappers are removed from
files and replaces with pci_*() or pr_*() printk wrappers, remove the
unused macro definitions. In addition to that, remove the MY_NAME macro.

Signed-off-by: Frederick Lawler 
---
 drivers/pci/hotplug/pciehp.h | 27 ---
 drivers/pci/hotplug/pciehp_hpc.c |  2 +-
 2 files changed, 1 insertion(+), 28 deletions(-)

diff --git a/drivers/pci/hotplug/pciehp.h b/drivers/pci/hotplug/pciehp.h
index 506e1d923a1f..7d3a32a1504a 100644
--- a/drivers/pci/hotplug/pciehp.h
+++ b/drivers/pci/hotplug/pciehp.h
@@ -25,37 +25,10 @@
 
 #include "../pcie/portdrv.h"
 
-#define MY_NAME"pciehp"
-
 extern bool pciehp_poll_mode;
 extern int pciehp_poll_time;
 extern bool pciehp_debug;
 
-#define dbg(format, arg...)\
-do {   \
-   if (pciehp_debug)   \
-   printk(KERN_DEBUG "%s: " format, MY_NAME, ## arg);  \
-} while (0)
-#define err(format, arg...)\
-   printk(KERN_ERR "%s: " format, MY_NAME, ## arg)
-#define info(format, arg...)   \
-   printk(KERN_INFO "%s: " format, MY_NAME, ## arg)
-#define warn(format, arg...)   \
-   printk(KERN_WARNING "%s: " format, MY_NAME, ## arg)
-
-#define ctrl_dbg(ctrl, format, arg...) \
-   do {\
-   if (pciehp_debug)   \
-   dev_printk(KERN_DEBUG, >pcie->device, \
-   format, ## arg);\
-   } while (0)
-#define ctrl_err(ctrl, format, arg...) \
-   dev_err(>pcie->device, format, ## arg)
-#define ctrl_info(ctrl, format, arg...)
\
-   dev_info(>pcie->device, format, ## arg)
-#define ctrl_warn(ctrl, format, arg...)
\
-   dev_warn(>pcie->device, format, ## arg)
-
 #define SLOT_NAME_SIZE 10
 
 /**
diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c
index 5e5631fd0171..28a132a0d9db 100644
--- a/drivers/pci/hotplug/pciehp_hpc.c
+++ b/drivers/pci/hotplug/pciehp_hpc.c
@@ -47,7 +47,7 @@ static inline int pciehp_request_irq(struct controller *ctrl)
 
/* Installs the interrupt handler */
retval = request_threaded_irq(irq, pciehp_isr, pciehp_ist,
- IRQF_SHARED, MY_NAME, ctrl);
+ IRQF_SHARED, "pciehp", ctrl);
if (retval)
pci_err(pdev, "Cannot get irq %d for the hotplug controller\n",
irq);
-- 
2.17.1



[PATCH 1/4] PCI: Replace dev_*() printk wrappers with pci_*() printk wrappers

2019-04-27 Thread fred
From: Frederick Lawler 

Replace remaining instances of dev_*() printk wrappers with pci_*()
printk wrappers. No functional change intended.

Signed-off-by: Frederick Lawler 
---
 drivers/pci/pcie/aer.c| 13 ++---
 drivers/pci/pcie/aer_inject.c |  4 ++--
 drivers/pci/pcie/dpc.c| 27 ---
 3 files changed, 20 insertions(+), 24 deletions(-)

diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
index f8fc2114ad39..224d878a28b4 100644
--- a/drivers/pci/pcie/aer.c
+++ b/drivers/pci/pcie/aer.c
@@ -964,8 +964,7 @@ static bool find_source_device(struct pci_dev *parent,
pci_walk_bus(parent->subordinate, find_device_iter, e_info);
 
if (!e_info->error_dev_num) {
-   pci_printk(KERN_DEBUG, parent, "can't find device of ID%04x\n",
-  e_info->id);
+   pci_dbg(parent, "can't find device of ID%04x\n", e_info->id);
return false;
}
return true;
@@ -1377,10 +1376,11 @@ static int aer_probe(struct pcie_device *dev)
int status;
struct aer_rpc *rpc;
struct device *device = >device;
+   struct pci_dev *pdev = dev->port;
 
rpc = devm_kzalloc(device, sizeof(struct aer_rpc), GFP_KERNEL);
if (!rpc) {
-   dev_printk(KERN_DEBUG, device, "alloc AER rpc failed\n");
+   pci_dbg(pdev, "alloc AER rpc failed\n");
return -ENOMEM;
}
rpc->rpd = dev->port;
@@ -1389,13 +1389,12 @@ static int aer_probe(struct pcie_device *dev)
status = devm_request_threaded_irq(device, dev->irq, aer_irq, aer_isr,
   IRQF_SHARED, "aerdrv", dev);
if (status) {
-   dev_printk(KERN_DEBUG, device, "request AER IRQ %d failed\n",
-  dev->irq);
+   pci_dbg(pdev, "request AER IRQ %d failed\n", dev->irq);
return status;
}
 
aer_enable_rootport(rpc);
-   dev_info(device, "AER enabled with IRQ %d\n", dev->irq);
+   pci_info(pdev, "AER enabled with IRQ %d\n", dev->irq);
return 0;
 }
 
@@ -1419,7 +1418,7 @@ static pci_ers_result_t aer_root_reset(struct pci_dev 
*dev)
pci_write_config_dword(dev, pos + PCI_ERR_ROOT_COMMAND, reg32);
 
rc = pci_bus_error_reset(dev);
-   pci_printk(KERN_DEBUG, dev, "Root Port link has been reset\n");
+   pci_dbg(dev, "Root Port link has been reset\n");
 
/* Clear Root Error Status */
pci_read_config_dword(dev, pos + PCI_ERR_ROOT_STATUS, );
diff --git a/drivers/pci/pcie/aer_inject.c b/drivers/pci/pcie/aer_inject.c
index 95d4759664b3..610b617ae600 100644
--- a/drivers/pci/pcie/aer_inject.c
+++ b/drivers/pci/pcie/aer_inject.c
@@ -460,12 +460,12 @@ static int aer_inject(struct aer_error_inj *einj)
if (device) {
edev = to_pcie_device(device);
if (!get_service_data(edev)) {
-   dev_warn(>device,
+   pci_warn(edev->port,
 "aer_inject: AER service is not 
initialized\n");
ret = -EPROTONOSUPPORT;
goto out_put;
}
-   dev_info(>device,
+   pci_info(edev->port,
 "aer_inject: Injecting errors %08x/%08x into device 
%s\n",
 einj->cor_status, einj->uncor_status, pci_name(dev));
local_irq_disable();
diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c
index 7b77754a82de..72659286191b 100644
--- a/drivers/pci/pcie/dpc.c
+++ b/drivers/pci/pcie/dpc.c
@@ -100,7 +100,6 @@ static int dpc_wait_rp_inactive(struct dpc_dev *dpc)
 {
unsigned long timeout = jiffies + HZ;
struct pci_dev *pdev = dpc->dev->port;
-   struct device *dev = >dev->device;
u16 cap = dpc->cap_pos, status;
 
pci_read_config_word(pdev, cap + PCI_EXP_DPC_STATUS, );
@@ -110,7 +109,7 @@ static int dpc_wait_rp_inactive(struct dpc_dev *dpc)
pci_read_config_word(pdev, cap + PCI_EXP_DPC_STATUS, );
}
if (status & PCI_EXP_DPC_RP_BUSY) {
-   dev_warn(dev, "DPC root port still busy\n");
+   pci_warn(pdev, "DPC root port still busy\n");
return -EBUSY;
}
return 0;
@@ -148,7 +147,6 @@ static pci_ers_result_t dpc_reset_link(struct pci_dev *pdev)
 
 static void dpc_process_rp_pio_error(struct dpc_dev *dpc)
 {
-   struct device *dev = >dev->device;
struct pci_dev *pdev = dpc->dev->port;
u16 cap = dpc->cap_pos, dpc_status, first_error;
u32 status, mask, sev, syserr, exc, dw0, dw1, dw2, dw3, log, prefix;
@@ -156,13 +154,13 @@ static void dpc_process_rp_pio_error(struct dpc_dev *dpc)
 
pci_read_config_dword(pdev, cap + PCI_EXP_DPC_RP_PIO_STATUS, );
pci_read_config_dword(pdev, cap + PCI_EXP_DPC_RP_PIO_MASK, );
-   dev_err(dev, "rp_pio_status: %#010x, 

[PATCH 4/4] PCI/portdrv: Add dev_fmt() to port drivers

2019-04-27 Thread fred
From: Frederick Lawler 

Add dev_fmt() to port drivers.

Signed-off-by: Frederick Lawler 
---
 drivers/pci/hotplug/pciehp_core.c  | 3 +++
 drivers/pci/hotplug/pciehp_ctrl.c  | 2 ++
 drivers/pci/hotplug/pciehp_hpc.c   | 3 +++
 drivers/pci/hotplug/pciehp_pci.c   | 2 ++
 drivers/pci/pcie/aer.c | 3 +++
 drivers/pci/pcie/aer_inject.c  | 2 ++
 drivers/pci/pcie/bw_notification.c | 2 ++
 drivers/pci/pcie/dpc.c | 2 ++
 drivers/pci/pcie/pme.c | 2 ++
 9 files changed, 21 insertions(+)

diff --git a/drivers/pci/hotplug/pciehp_core.c 
b/drivers/pci/hotplug/pciehp_core.c
index 430a47556813..b07d713fd4bd 100644
--- a/drivers/pci/hotplug/pciehp_core.c
+++ b/drivers/pci/hotplug/pciehp_core.c
@@ -17,6 +17,9 @@
  *   Dely Sy "
  */
 
+#define pr_fmt(fmt) "pciehp: " fmt
+#define dev_fmt(fmt) pr_fmt(fmt)
+
 #include 
 #include 
 #include 
diff --git a/drivers/pci/hotplug/pciehp_ctrl.c 
b/drivers/pci/hotplug/pciehp_ctrl.c
index 345c02b1e8d7..969a9c72f65d 100644
--- a/drivers/pci/hotplug/pciehp_ctrl.c
+++ b/drivers/pci/hotplug/pciehp_ctrl.c
@@ -13,6 +13,8 @@
  *
  */
 
+#define dev_fmt(fmt) "pciehp: " fmt
+
 #include 
 #include 
 #include 
diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c
index 28a132a0d9db..f2a3da105f5b 100644
--- a/drivers/pci/hotplug/pciehp_hpc.c
+++ b/drivers/pci/hotplug/pciehp_hpc.c
@@ -12,6 +12,9 @@
  * Send feedback to ,
  */
 
+#define pr_fmt(fmt) "pciehp: " fmt
+#define dev_fmt(fmt) pr_fmt(fmt)
+
 #include 
 #include 
 #include 
diff --git a/drivers/pci/hotplug/pciehp_pci.c b/drivers/pci/hotplug/pciehp_pci.c
index 55967ce567f6..04ccd535aca7 100644
--- a/drivers/pci/hotplug/pciehp_pci.c
+++ b/drivers/pci/hotplug/pciehp_pci.c
@@ -13,6 +13,8 @@
  *
  */
 
+#define dev_fmt(fmt) "pciehp: " fmt
+
 #include 
 #include 
 #include 
diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
index 224d878a28b4..6fd67285423d 100644
--- a/drivers/pci/pcie/aer.c
+++ b/drivers/pci/pcie/aer.c
@@ -12,6 +12,9 @@
  *Andrew Patterson 
  */
 
+#define pr_fmt(fmt) "AER: " fmt
+#define dev_fmt(fmt) pr_fmt(fmt)
+
 #include 
 #include 
 #include 
diff --git a/drivers/pci/pcie/aer_inject.c b/drivers/pci/pcie/aer_inject.c
index 610b617ae600..d4f6d49acd0c 100644
--- a/drivers/pci/pcie/aer_inject.c
+++ b/drivers/pci/pcie/aer_inject.c
@@ -12,6 +12,8 @@
  * Huang Ying 
  */
 
+#define dev_fmt(fmt) "AER: " fmt
+
 #include 
 #include 
 #include 
diff --git a/drivers/pci/pcie/bw_notification.c 
b/drivers/pci/pcie/bw_notification.c
index d2eae3b7cc0f..a4bb90562cd5 100644
--- a/drivers/pci/pcie/bw_notification.c
+++ b/drivers/pci/pcie/bw_notification.c
@@ -14,6 +14,8 @@
  * and warns when links become degraded in operation.
  */
 
+#define dev_fmt(fmt) "BWN: " fmt
+
 #include "../pci.h"
 #include "portdrv.h"
 
diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c
index 72659286191b..b3c10cdc508a 100644
--- a/drivers/pci/pcie/dpc.c
+++ b/drivers/pci/pcie/dpc.c
@@ -6,6 +6,8 @@
  * Copyright (C) 2016 Intel Corp.
  */
 
+#define dev_fmt(fmt) "DPC: " fmt
+
 #include 
 #include 
 #include 
diff --git a/drivers/pci/pcie/pme.c b/drivers/pci/pcie/pme.c
index 54d593d10396..d6698423a6d6 100644
--- a/drivers/pci/pcie/pme.c
+++ b/drivers/pci/pcie/pme.c
@@ -7,6 +7,8 @@
  * Copyright (C) 2009 Rafael J. Wysocki , Novell Inc.
  */
 
+#define dev_fmt(fmt) "PME: " fmt
+
 #include 
 #include 
 #include 
-- 
2.17.1



[PATCH 0/4] PCI: Use PCIe service name in dmesg logs

2019-04-27 Thread fred
From: Frederick Lawler 

In referrence to [1], PCIe services did not have unifrom logging via pci_*()
printk wrappers. This patch series first replaces left over dev_*() calls
for port services. Then, replaces all hotplug ctrl_*() calls with pci_*() to
bring hotplug in line with the other services, and removes the custom
ctrl_*() definitions. Lastly, to satisfy [1], add in dev_fmt()'s to each of
the services.

1. https://lore.kernel.org/linux-pci/20190308180149.gd214...@google.com/

Frederick Lawler (4):
  PCI: Replace dev_*() printk wrappers with pci_*() printk wrappers
  PCI: pciehp: Replace ctrl_*() with pci_*()
  PCI: pciehp: Remove unused macro definitions
  PCI/portdrv: Add dev_fmt() to port drivers

 drivers/pci/hotplug/pciehp.h   |  27 -
 drivers/pci/hotplug/pciehp_core.c  |  25 +++--
 drivers/pci/hotplug/pciehp_ctrl.c  |  88 +
 drivers/pci/hotplug/pciehp_hpc.c   | 154 -
 drivers/pci/hotplug/pciehp_pci.c   |  12 ++-
 drivers/pci/pcie/aer.c |  16 +--
 drivers/pci/pcie/aer_inject.c  |   6 +-
 drivers/pci/pcie/bw_notification.c |   2 +
 drivers/pci/pcie/dpc.c |  29 +++---
 drivers/pci/pcie/pme.c |   2 +
 10 files changed, 187 insertions(+), 174 deletions(-)

--
2.17.1



[PATCH 2/4] PCI: pciehp: Replace ctrl_*() with pci_*()

2019-04-27 Thread fred
From: Frederick Lawler 

Hotplug useses custom ctrl_*() dev_*() printk wrappers for logging
messages. To make hotplug conform to pci logging, replace uses of these
wrappers with pci_*() printk wrappers. In addition, replace any
printk() calls with pr_*() wrappers.

Signed-off-by: Frederick Lawler 
---
 drivers/pci/hotplug/pciehp_core.c |  22 +++--
 drivers/pci/hotplug/pciehp_ctrl.c |  86 +
 drivers/pci/hotplug/pciehp_hpc.c  | 149 --
 drivers/pci/hotplug/pciehp_pci.c  |  10 +-
 4 files changed, 145 insertions(+), 122 deletions(-)

diff --git a/drivers/pci/hotplug/pciehp_core.c 
b/drivers/pci/hotplug/pciehp_core.c
index fc5366b50e95..430a47556813 100644
--- a/drivers/pci/hotplug/pciehp_core.c
+++ b/drivers/pci/hotplug/pciehp_core.c
@@ -51,6 +51,7 @@ static int get_adapter_status(struct hotplug_slot *slot, u8 
*value);
 
 static int init_slot(struct controller *ctrl)
 {
+   struct pci_dev *pdev = ctrl->pcie->port;
struct hotplug_slot_ops *ops;
char name[SLOT_NAME_SIZE];
int retval;
@@ -82,7 +83,7 @@ static int init_slot(struct controller *ctrl)
retval = pci_hp_initialize(>hotplug_slot,
   ctrl->pcie->port->subordinate, 0, name);
if (retval) {
-   ctrl_err(ctrl, "pci_hp_initialize failed: error %d\n", retval);
+   pci_err(pdev, "pci_hp_initialize failed: error %d\n", retval);
kfree(ops);
}
return retval;
@@ -175,6 +176,7 @@ static int pciehp_probe(struct pcie_device *dev)
 {
int rc;
struct controller *ctrl;
+   struct pci_dev *pdev;
 
/* If this is not a "hotplug" service, we have no business here. */
if (dev->service != PCIE_PORT_SERVICE_HP)
@@ -182,39 +184,39 @@ static int pciehp_probe(struct pcie_device *dev)
 
if (!dev->port->subordinate) {
/* Can happen if we run out of bus numbers during probe */
-   dev_err(>device,
-   "Hotplug bridge without secondary bus, ignoring\n");
+   pci_err(dev->port, "Hotplug bridge without secondary bus, 
ignoring\n");
return -ENODEV;
}
 
ctrl = pcie_init(dev);
if (!ctrl) {
-   dev_err(>device, "Controller initialization failed\n");
+   pci_err(dev->port, "Controller initialization failed\n");
return -ENODEV;
}
set_service_data(dev, ctrl);
+   pdev = ctrl->pcie->port;
 
/* Setup the slot information structures */
rc = init_slot(ctrl);
if (rc) {
if (rc == -EBUSY)
-   ctrl_warn(ctrl, "Slot already registered by another 
hotplug driver\n");
+   pci_warn(pdev, "Slot already registered by another 
hotplug driver\n");
else
-   ctrl_err(ctrl, "Slot initialization failed (%d)\n", rc);
+   pci_err(pdev, "Slot initialization failed (%d)\n", rc);
goto err_out_release_ctlr;
}
 
/* Enable events after we have setup the data structures */
rc = pcie_init_notification(ctrl);
if (rc) {
-   ctrl_err(ctrl, "Notification initialization failed (%d)\n", rc);
+   pci_err(pdev, "Notification initialization failed (%d)\n", rc);
goto err_out_free_ctrl_slot;
}
 
/* Publish to user space */
rc = pci_hp_add(>hotplug_slot);
if (rc) {
-   ctrl_err(ctrl, "Publication to user space failed (%d)\n", rc);
+   pci_err(pdev, "Publication to user space failed (%d)\n", rc);
goto err_out_shutdown_notification;
}
 
@@ -328,9 +330,9 @@ int __init pcie_hp_init(void)
int retval = 0;
 
retval = pcie_port_service_register(_portdrv);
-   dbg("pcie_port_service_register = %d\n", retval);
+   pr_debug("pcie_port_service_register = %d\n", retval);
if (retval)
-   dbg("Failure to register service\n");
+   pr_debug("Failure to register service\n");
 
return retval;
 }
diff --git a/drivers/pci/hotplug/pciehp_ctrl.c 
b/drivers/pci/hotplug/pciehp_ctrl.c
index 3f3df4c29f6e..345c02b1e8d7 100644
--- a/drivers/pci/hotplug/pciehp_ctrl.c
+++ b/drivers/pci/hotplug/pciehp_ctrl.c
@@ -54,6 +54,7 @@ static void set_slot_off(struct controller *ctrl)
 static int board_added(struct controller *ctrl)
 {
int retval = 0;
+   struct pci_dev *pdev = ctrl->pcie->port;
struct pci_bus *parent = ctrl->pcie->port->subordinate;
 
if (POWER_CTRL(ctrl)) {
@@ -68,13 +69,13 @@ static int board_added(struct controller *ctrl)
/* Check link training status */
retval = pciehp_check_link_status(ctrl);
if (retval) {
-   ctrl_err(ctrl, "Failed to check link status\n");
+   pci_err(pdev, "Failed to check link status\n");
goto err_exit;
  

Re: [PATCH v4 1/5] mtd: cfi_cmdset_0002: Add support for polling status register

2019-04-27 Thread Sergei Shtylyov
Hello!

On 04/23/2019 01:48 PM, Vignesh Raghavendra wrote:

> HyperFlash devices are compliant with CFI AMD/Fujitsu Extended Command
> Set(0x0002) for flash operations, therefore 
> drivers/mtd/chips/cfi_cmdset_0002.c
> can be used as is. But these devices do not support DQ polling method of
> determining chip ready/good status. These flashes provide Status
> Register whose bits can be polled to know status of flash operation.
> 
> Cypress HyperFlash datasheet here[1], talks about CFI Amd/Fujitsu
> Extended Query version 1.5. Bit 0 of "Software Features supported" field
> of CFI Primary Vendor-Specific Extended Query table indicates
> presence/absence of status register and Bit 1 indicates whether or not
> DQ polling is supported. Using these bits, its possible to determine
> whether flash supports DQ polling or need to use Status Register.
> 
> Add support for polling Status Register to know device ready/status of
> erase/write operations when DQ polling is not supported.
> Print error messages on erase/program failure by looking at related
> Status Register bits.
> 
> [1] https://www.cypress.com/file/213346/download
> 
> Signed-off-by: Vignesh Raghavendra 

   Sorry, only superficial review, I'm not an MTD expert. :-)

> ---
>  drivers/mtd/chips/cfi_cmdset_0002.c | 90 +
>  include/linux/mtd/cfi.h |  5 ++
>  2 files changed, 95 insertions(+)
> 
> diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c 
> b/drivers/mtd/chips/cfi_cmdset_0002.c
> index 7b7286b4d81e..55c4d81098d5 100644
> --- a/drivers/mtd/chips/cfi_cmdset_0002.c
> +++ b/drivers/mtd/chips/cfi_cmdset_0002.c
> @@ -49,6 +49,16 @@
>  #define SST49LF008A  0x005a
>  #define AT49BV6416   0x00d6
>  
> +/*
> + * Status Register bit description. Used by flash devices that don't
> + * support DQ polling (Eg.: HyperFlash)

   It's "e.g. " :-)

[...]
> @@ -97,6 +107,48 @@ static struct mtd_chip_driver cfi_amdstd_chipdrv = {
>   .module = THIS_MODULE
>  };
>  
> +/*
> + * Use status register to poll for Erase/write completion when DQ is not
> + * supported. This is indicated by Bit[1:0] of SoftwareFeatures field in
> + * CFI Primary Vendor-Specific Extended Query table 1.5
> + */
> +static int cfi_use_status_reg(struct cfi_private *cfi)
> +{
> + struct cfi_pri_amdstd *extp = cfi->cmdset_priv;
> +
> + return (extp->MinorVersion >= '5') &&

   Parens not needed here, especially as the next operator isn't enclosed.

> + (extp->SoftwareFeatures & 0x3) == 0x1;
> +}
[...]

MBR, Sergei


Re: [GIT PULL] perf fix

2019-04-27 Thread pr-tracker-bot
The pull request you sent on Sat, 27 Apr 2019 16:38:18 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
> perf-urgent-for-linus

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/5084991663650a238dd9d1981e09eef00a90594c

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker


Re: [GIT PULL] scheduler fix

2019-04-27 Thread pr-tracker-bot
The pull request you sent on Sat, 27 Apr 2019 16:39:26 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
> sched-urgent-for-linus

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/15d4e26b816a39f2d1ba40bacb8e8ecf8884477c

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker


Re: [GIT PULL] x86 fixes

2019-04-27 Thread pr-tracker-bot
The pull request you sent on Sat, 27 Apr 2019 16:42:56 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-urgent-for-linus

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/037904a22bf8b2c999a6e2a8ba971b549c1e9600

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker


Re: [PATCH 3.16 000/202] 3.16.66-rc1 review

2019-04-27 Thread Guenter Roeck

On 4/27/19 8:13 AM, Ben Hutchings wrote:

This is the start of the stable review cycle for the 3.16.66 release.
There are 202 patches in this series, which will be posted as responses
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Wed May 01 18:00:00 UTC 2019.
Anything received after that time might be too late.



Build results:
total: 137 pass: 136 fail: 1
Failed builds:
i386:tools/perf
Qemu test results:
total: 226 pass: 226 fail: 0

Guenter


[PATCH] dt-bindings: iio: isl29018: convert bindings to YAML format

2019-04-27 Thread Brian Masney
Convert the isl29018 device tree bindings to the new YAML format.

Signed-off-by: Brian Masney 
---
I'm willing to be listed as the maintainer since this is one of the
drivers that I moved out out of staging unless one of the original
authors wants to be listed instead.

I added the BSD-2-Clause to the new binding document. I wrote the
original document and the only commit since then was from Rob in
commit 791d3ef2e111 ("dt-bindings: remove 'interrupt-parent' from
bindings")

 .../bindings/iio/light/isl29018.txt   | 27 -
 .../bindings/iio/light/isl29018.yaml  | 56 +++
 2 files changed, 56 insertions(+), 27 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/iio/light/isl29018.txt
 create mode 100644 Documentation/devicetree/bindings/iio/light/isl29018.yaml

diff --git a/Documentation/devicetree/bindings/iio/light/isl29018.txt 
b/Documentation/devicetree/bindings/iio/light/isl29018.txt
deleted file mode 100644
index b9bbde3e13ed..
--- a/Documentation/devicetree/bindings/iio/light/isl29018.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-* ISL 29018/29023/29035 I2C ALS, Proximity, and Infrared sensor
-
-Required properties:
-
-  - compatible: Should be one of
-   "isil,isl29018"
-   "isil,isl29023"
-   "isil,isl29035"
-  - reg: the I2C address of the device
-
-Optional properties:
-
-  - interrupts: the sole interrupt generated by the device
-
-  Refer to interrupt-controller/interrupts.txt for generic interrupt client
-  node bindings.
-
-  - vcc-supply: phandle to the regulator that provides power to the sensor.
-
-Example:
-
-isl29018@44 {
-   compatible = "isil,isl29018";
-   reg = <0x44>;
-   interrupt-parent = <>;
-   interrupts = ;
-};
diff --git a/Documentation/devicetree/bindings/iio/light/isl29018.yaml 
b/Documentation/devicetree/bindings/iio/light/isl29018.yaml
new file mode 100644
index ..cbb00be8f359
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/isl29018.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/light/isl29018.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: |
+  Intersil 29018/29023/29035 Ambient Light, Infrared Light, and Proximity 
Sensor
+
+maintainers:
+  - Brian Masney 
+
+description: |
+  Ambient and infrared light sensing with proximity detection over an i2c
+  interface.
+
+  https://www.renesas.com/us/en/www/doc/datasheet/isl29018.pdf
+  https://www.renesas.com/us/en/www/doc/datasheet/isl29023.pdf
+  https://www.renesas.com/us/en/www/doc/datasheet/isl29035.pdf
+
+properties:
+  compatible:
+enum:
+  - isil,isl29018
+  - isil,isl29023
+  - isil,isl29035
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  vcc-supply:
+description: Regulator that provides power to the sensor
+
+required:
+  - compatible
+  - reg
+
+examples:
+  - |
+#include 
+
+i2c {
+
+#address-cells = <1>;
+#size-cells = <0>;
+
+sensor@44 {
+compatible = "isil,isl29018";
+reg = <0x44>;
+interrupts-extended = < 61 IRQ_TYPE_LEVEL_HIGH>;
+};
+};
+...
-- 
2.20.1



Re: [PATCH 2/3] drivers: regulator: qcom: add PMS405 SPMI regulator

2019-04-27 Thread Mark Brown
On Thu, Apr 25, 2019 at 09:44:00PM +0200, Jorge Ramirez wrote:

> the way I see it, if I follow your suggestion and since we are not
> allowed to extend spmi_regulator_find_range(), the only options are:

> 1) duplicate verbatim this whole function
> (spmi_regulator_select_voltage_same_range) with a minor change (this
> amount of code duplication in the kernel seems rather unnecessary to me)

> 2) modify the struct spmi_regulator definition with a new operation that
> calls a different implementation of find range (seems a massive overkill)

Since the point of this change is AFAICT that this regulator only has a
single linear range it seems like it should just be able to use the
existing generic functions shouldn't it?  It just needs it's own
set/get_voltage_sel() operations.  As far as I can see the main thing
the driver is doing with the custom stuff is handling the fact that
there's multiple ranges but that's not an issue for this regulator.
It's possible I'm missing something there but that was the main thing
(and we do have some generic support for multiple linear ranges in the
helper code already, can't remember why this driver isn't using that -
the ranges overlap IIRC?).

TBH looking at the uses of find_range() I'm not sure they're 100%
sensible as they are - the existing _time_sel() is assuming we only need
to work out the ramp time between voltages in the same range which is
going to have trouble.


signature.asc
Description: PGP signature


Question about sched_setaffinity()

2019-04-27 Thread Paul E. McKenney
Hello, Peter!

TL;DR: If a normal !PF_NO_SETAFFINITY kthread invokes sched_setaffinity(),
and sched_setaffinity() returns 0, is it expected behavior for that
kthread to be running on some CPU other than one of the ones specified by
the in_mask argument?  All CPUs are online, and there is no CPU-hotplug
activity taking place.

Thanx, Paul

Details:

I have long showed the following "toy" synchronize_rcu() implementation:

void synchronize_rcu(void)
{
int cpu;

for_each_online_cpu(cpu)
run_on(cpu);
}

I decided that if I was going to show it, I should test it.  And it
occurred to me that run_on() can be a call to sched_setaffinity():

void synchronize_rcu(void)
{
int cpu;

for_each_online_cpu(cpu)
sched_setaffinity(current->pid, cpumask_of(cpu));
}

This actually passes rcutorture.  But, as Andrea noted, not klitmus.
After some investigation, it turned out that klitmus was creating kthreads
with PF_NO_SETAFFINITY, hence the failures.  But that prompted me to
put checks into my code: After all, rcutorture can be fooled.

void synchronize_rcu(void)
{
int cpu;

for_each_online_cpu(cpu) {
sched_setaffinity(current->pid, cpumask_of(cpu));
WARN_ON_ONCE(raw_smp_processor_id() != cpu);
}
}

This triggers fairly quickly, usually in less than a minute of rcutorture
testing.  And further investigation shows that sched_setaffinity()
always returned 0.  So I tried this hack:

void synchronize_rcu(void)
{
int cpu;

for_each_online_cpu(cpu) {
while (raw_smp_processor_id() != cpu)
sched_setaffinity(current->pid, 
cpumask_of(cpu));
WARN_ON_ONCE(raw_smp_processor_id() != cpu);
}
}

This never triggers, and rcutorture's grace-period rate is not significantly
affected.

Is this expected behavior?  Is there some configuration or setup that I
might be missing?



Re: [PATCH AUTOSEL 5.0 03/79] ASoC: ab8500: Mark expected switch fall-through

2019-04-27 Thread Mark Brown
On Sat, Apr 27, 2019 at 12:31:22PM -0500, Gustavo A. R. Silva wrote:
> On 4/27/19 12:14 PM, Mark Brown wrote:

> > Are we *realy* going to enable -Wimplicit-fallthrough in stable kernels
> > and both backport all the fixes and add new fixes for the issues which
> > don't have backportable fixes?

> I don't think so.

> There are hundreds of these patches in mainline, and I think this is
> the first time I see one of them being backported.

Right, this looked like a super weird thing to backport.


signature.asc
Description: PGP signature


Re: [PATCH AUTOSEL 5.0 03/79] ASoC: ab8500: Mark expected switch fall-through

2019-04-27 Thread Gustavo A. R. Silva



On 4/27/19 12:14 PM, Mark Brown wrote:
> On Fri, Apr 26, 2019 at 09:37:22PM -0400, Sasha Levin wrote:
>> From: "Gustavo A. R. Silva" 
>>
>> [ Upstream commit 102cefc8e879b707be0024fdc7bce1deeb359a5f ]
>>
>> In preparation to enabling -Wimplicit-fallthrough, mark switch
>> cases where we are expecting to fall through.
> 
> Are we *realy* going to enable -Wimplicit-fallthrough in stable kernels
> and both backport all the fixes and add new fixes for the issues which
> don't have backportable fixes?
> 

I don't think so.

There are hundreds of these patches in mainline, and I think this is
the first time I see one of them being backported.

--
Gustavo


  1   2   3   4   5   >