Re: [PATCH 3/3] Staging: lustre: tracefile: Remove function prototype

[Shivani Bhardwaj]

On Sat, Nov 7, 2015 at 1:02 PM, Dilger, Andreas
 wrote:
> On 2015/11/06, 10:19, "Shivani Bhardwaj"  wrote:
>
>>Remove the prototype of function cfs_trace_free_string_buffer() as it is
>>no longer needed.
>
> These patches would be a lot more useful if the summary contained the name
> of the function being removed, rather than "remove function prototype" and
> variations of that.  Something like:
>
>staging: lustre: remove cfs_trace_free_string_buffer prototype
>staging: lustre: remove ldlm_pool_set_limit wrapper
>staging: lustre: remove ldlm_pool_get_limit wrapper
>
> Not sure if that is grounds for rejection of this patch series (I'll leave
> that up to Dan and Greg), but definitely something for future patches.
>
> Cheers, Andreas
>

I'll definitely take care of this for future patches that I submit.

Thank you
Shivani

>>Signed-off-by: Shivani Bhardwaj 
>>---
>> drivers/staging/lustre/lustre/libcfs/tracefile.h | 1 -
>> 1 file changed, 1 deletion(-)
>>
>>diff --git a/drivers/staging/lustre/lustre/libcfs/tracefile.h
>>b/drivers/staging/lustre/lustre/libcfs/tracefile.h
>>index 73d60e0..ba62005 100644
>>--- a/drivers/staging/lustre/lustre/libcfs/tracefile.h
>>+++ b/drivers/staging/lustre/lustre/libcfs/tracefile.h
>>@@ -70,7 +70,6 @@ int cfs_trace_copyin_string(char *knl_buffer, int
>>knl_buffer_nob,
>> int cfs_trace_copyout_string(char __user *usr_buffer, int usr_buffer_nob,
>>const char *knl_str, char *append);
>> int cfs_trace_allocate_string_buffer(char **str, int nob);
>>-void cfs_trace_free_string_buffer(char *str, int nob);
>> int cfs_trace_dump_debug_buffer_usrstr(void __user *usr_str, int
>>usr_str_nob);
>> int cfs_trace_daemon_command(char *str);
>> int cfs_trace_daemon_command_usrstr(void __user *usr_str, int
>>usr_str_nob);
>>--
>>2.1.0
>>
>>
>
>
> Cheers, Andreas
> --
> Andreas Dilger
>
> Lustre Software Architect
> Intel High Performance Data Division
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 9/9] Staging: lustre: llite_internal: Remove function prototype

[Shivani Bhardwaj]

Remove the prototype of the function ll_finish_md_op_data() as it is no
longer needed.

Signed-off-by: Shivani Bhardwaj 
---
 drivers/staging/lustre/lustre/llite/llite_internal.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/lustre/lustre/llite/llite_internal.h 
b/drivers/staging/lustre/lustre/llite/llite_internal.h
index 157c3284..d12d483 100644
--- a/drivers/staging/lustre/lustre/llite/llite_internal.h
+++ b/drivers/staging/lustre/lustre/llite/llite_internal.h
@@ -792,7 +792,6 @@ struct md_op_data *ll_prep_md_op_data(struct md_op_data 
*op_data,
  struct inode *i1, struct inode *i2,
  const char *name, int namelen,
  int mode, __u32 opc, void *data);
-void ll_finish_md_op_data(struct md_op_data *op_data);
 int ll_get_obd_name(struct inode *inode, unsigned int cmd, unsigned long arg);
 char *ll_get_fsname(struct super_block *sb, char *buf, int buflen);
 void ll_open_cleanup(struct super_block *sb, struct ptlrpc_request *open_req);
-- 
2.1.0

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

[PATCH 7/9] Staging: lustre: llite_close: Substitute function calls

[Shivani Bhardwaj]

Substitute standard function kfree() in place of the function
ll_finish_md_op_data().

Signed-off-by: Shivani Bhardwaj 
---
 drivers/staging/lustre/lustre/llite/llite_close.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/lustre/llite/llite_close.c 
b/drivers/staging/lustre/lustre/llite/llite_close.c
index 3f348a3..c4f22ec 100644
--- a/drivers/staging/lustre/lustre/llite/llite_close.c
+++ b/drivers/staging/lustre/lustre/llite/llite_close.c
@@ -301,7 +301,7 @@ static void ll_done_writing(struct inode *inode)
CERROR("inode %lu mdc done_writing failed: rc = %d\n",
   inode->i_ino, rc);
 out:
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
if (och) {
md_clear_open_replay_data(ll_i2sbi(inode)->ll_md_exp, och);
kfree(och);
-- 
2.1.0

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

[PATCH 8/9] Staging: lustre: llite_lib: Remove wrapper function

[Shivani Bhardwaj]

Remove the function ll_finish_md_op_data() and replace all its calls
with the standrd function ll_finish_md_op_data().

Signed-off-by: Shivani Bhardwaj 
---
 drivers/staging/lustre/lustre/llite/llite_lib.c | 13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/lustre/lustre/llite/llite_lib.c 
b/drivers/staging/lustre/lustre/llite/llite_lib.c
index 4a8c759..143be87 100644
--- a/drivers/staging/lustre/lustre/llite/llite_lib.c
+++ b/drivers/staging/lustre/lustre/llite/llite_lib.c
@@ -1355,7 +1355,7 @@ out:
if (!rc)
rc = rc1;
}
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
 
if (!S_ISDIR(inode->i_mode)) {
mutex_lock(>i_mutex);
@@ -1732,7 +1732,7 @@ int ll_iocontrol(struct inode *inode, struct file *file,
 
op_data->op_valid = OBD_MD_FLFLAGS;
rc = md_getattr(sbi->ll_md_exp, op_data, );
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
if (rc) {
CERROR("failure %d inode %lu\n", rc, inode->i_ino);
return -abs(rc);
@@ -1763,7 +1763,7 @@ int ll_iocontrol(struct inode *inode, struct file *file,
op_data->op_attr.ia_valid |= ATTR_ATTR_FLAG;
rc = md_setattr(sbi->ll_md_exp, op_data,
NULL, 0, NULL, 0, , NULL);
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
ptlrpc_req_finished(req);
if (rc)
return rc;
@@ -1934,7 +1934,7 @@ void ll_open_cleanup(struct super_block *sb, struct 
ptlrpc_request *open_req)
op_data->op_mod_time = get_seconds();
md_close(exp, op_data, NULL, _req);
ptlrpc_req_finished(close_req);
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
 }
 
 int ll_prep_inode(struct inode **inode, struct ptlrpc_request *req,
@@ -2170,11 +2170,6 @@ struct md_op_data *ll_prep_md_op_data(struct md_op_data 
*op_data,
return op_data;
 }
 
-void ll_finish_md_op_data(struct md_op_data *op_data)
-{
-   kfree(op_data);
-}
-
 int ll_show_options(struct seq_file *seq, struct dentry *dentry)
 {
struct ll_sb_info *sbi;
-- 
2.1.0

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

[PATCH 6/9] Staging: lustre: llite_nfs: Replace with standard function

[Shivani Bhardwaj]

Replace the calls of the function ll_finish_md_op_data() with the
standard function kfree().

Signed-off-by: Shivani Bhardwaj 
---
 drivers/staging/lustre/lustre/llite/llite_nfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/lustre/llite/llite_nfs.c 
b/drivers/staging/lustre/lustre/llite/llite_nfs.c
index e578a11..a3a89a7 100644
--- a/drivers/staging/lustre/lustre/llite/llite_nfs.c
+++ b/drivers/staging/lustre/lustre/llite/llite_nfs.c
@@ -306,7 +306,7 @@ static struct dentry *ll_get_parent(struct dentry *dchild)
return (void *)op_data;
 
rc = md_getattr_name(sbi->ll_md_exp, op_data, );
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
if (rc) {
CERROR("failure %d inode %lu get parent\n", rc, dir->i_ino);
return ERR_PTR(rc);
-- 
2.1.0

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

[PATCH 5/9] Staging: lustre: symlink: Substitute standard function

[Shivani Bhardwaj]

Substitute the standard function kfree() for the function
ll_finish_md_op_data().

Signed-off-by: Shivani Bhardwaj 
---
 drivers/staging/lustre/lustre/llite/symlink.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/lustre/llite/symlink.c 
b/drivers/staging/lustre/lustre/llite/symlink.c
index 69b2036..6b0d1cc 100644
--- a/drivers/staging/lustre/lustre/llite/symlink.c
+++ b/drivers/staging/lustre/lustre/llite/symlink.c
@@ -73,7 +73,7 @@ static int ll_readlink_internal(struct inode *inode,
 
op_data->op_valid = OBD_MD_LINKNAME;
rc = md_getattr(sbi->ll_md_exp, op_data, request);
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
if (rc) {
if (rc != -ENOENT)
CERROR("inode %lu: rc = %d\n", inode->i_ino, rc);
-- 
2.1.0

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

[PATCH 4/9] Staging: lustre: xattr_cache: Change function calls

[Shivani Bhardwaj]

Change the calls of the function ll_finish_md_op_data() to the standard
function kfree().

Signed-off-by: Shivani Bhardwaj 
---
 drivers/staging/lustre/lustre/llite/xattr_cache.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/lustre/llite/xattr_cache.c 
b/drivers/staging/lustre/lustre/llite/xattr_cache.c
index e1e599c..b7f3efc 100644
--- a/drivers/staging/lustre/lustre/llite/xattr_cache.c
+++ b/drivers/staging/lustre/lustre/llite/xattr_cache.c
@@ -306,7 +306,7 @@ static int ll_xattr_find_get_lock(struct inode *inode,
op_data->op_valid = OBD_MD_FLXATTR | OBD_MD_FLXATTRLS;
 
rc = md_enqueue(exp, , oit, op_data, , NULL, 0, NULL, 0);
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
 
if (rc < 0) {
CDEBUG(D_CACHE,
-- 
2.1.0

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

Re: [PATCH cgroup/for-4.4-fixes] cgroup: fix cftype->file_offset handling

[Zefan Li]

On 2015/11/5 13:12, Tejun Heo wrote:

6f60eade2433 ("cgroup: generalize obtaining the handles of and
notifying cgroup files") introduced cftype->file_offset so that the
handles for per-css file instances can be recorded.  These handles
then can be used, for example, to generate file modified
notifications.

Unfortunately, it made the wrong assumption that files are created
once for a given css and removed on its destruction.  Due to the
dependencies among subsystems, a css may be hidden from userland and
then later shown again.  This is implemented by removing and
re-creating the affected files, so the associated kernfs_node for a
given cgroup file may change over time.  This incorrect assumption led
to the corruption of css->files lists.

Reimplement cftype->file_offset handling so that cgroup_file->kn is
protected by a lock and updated as files are created and destroyed.
This also makes keeping them on per-cgroup list unnecessary.

Signed-off-by: Tejun Heo 
Reported-by: James Sedgwick 
Fixes: 6f60eade2433 ("cgroup: generalize obtaining the handles of and notifying 
cgroup files")


Acked-by: Zefan Li 

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

[PATCH 3/9] Staging: lustre: namei: Replace calls with kfree

[Shivani Bhardwaj]

Replace the calls of the function ll_finish_md_op_data() with thr
stndard function kfree().

Signed-off-by: Shivani Bhardwaj 
---
 drivers/staging/lustre/lustre/llite/namei.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/lustre/lustre/llite/namei.c 
b/drivers/staging/lustre/lustre/llite/namei.c
index 2ca2200..f058ebe2 100644
--- a/drivers/staging/lustre/lustre/llite/namei.c
+++ b/drivers/staging/lustre/lustre/llite/namei.c
@@ -531,7 +531,7 @@ static struct dentry *ll_lookup_it(struct inode *parent, 
struct dentry *dentry,
 
rc = md_intent_lock(ll_i2mdexp(parent), op_data, NULL, 0, it,
lookup_flags, , ll_md_blocking_ast, 0);
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
if (rc < 0) {
retval = ERR_PTR(rc);
goto out;
@@ -786,7 +786,7 @@ static int ll_new_node(struct inode *dir, struct dentry 
*dentry,
from_kuid(_user_ns, current_fsuid()),
from_kgid(_user_ns, current_fsgid()),
cfs_curproc_cap_pack(), rdev, );
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
if (err)
goto err_exit;
 
@@ -961,7 +961,7 @@ static int ll_unlink(struct inode *dir, struct dentry 
*dentry)
ll_get_child_fid(dentry, _data->op_fid3);
op_data->op_fid2 = op_data->op_fid3;
rc = md_unlink(ll_i2sbi(dir)->ll_md_exp, op_data, );
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
if (rc)
goto out;
 
@@ -1011,7 +1011,7 @@ static int ll_rmdir(struct inode *dir, struct dentry 
*dentry)
ll_get_child_fid(dentry, _data->op_fid3);
op_data->op_fid2 = op_data->op_fid3;
rc = md_unlink(ll_i2sbi(dir)->ll_md_exp, op_data, );
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
if (rc == 0) {
ll_update_times(request, dir);
ll_stats_ops_tally(ll_i2sbi(dir), LPROC_LL_RMDIR, 1);
@@ -1060,7 +1060,7 @@ static int ll_link(struct dentry *old_dentry, struct 
inode *dir,
return PTR_ERR(op_data);
 
err = md_link(sbi->ll_md_exp, op_data, );
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
if (err)
goto out;
 
@@ -1096,7 +1096,7 @@ static int ll_rename(struct inode *old_dir, struct dentry 
*old_dentry,
old_dentry->d_name.len,
new_dentry->d_name.name,
new_dentry->d_name.len, );
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
if (!err) {
ll_update_times(request, old_dir);
ll_update_times(request, new_dir);
-- 
2.1.0

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

[PATCH 2/9] Staging: lustre: file: Replace function calls with standard function

[Shivani Bhardwaj]

Replace the calls of the function ll_finish_md_op_data() with the
standard function kfree().

Signed-off-by: Shivani Bhardwaj 
---
 drivers/staging/lustre/lustre/llite/file.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/lustre/lustre/llite/file.c 
b/drivers/staging/lustre/lustre/llite/file.c
index 02f2759..186b5af 100644
--- a/drivers/staging/lustre/lustre/llite/file.c
+++ b/drivers/staging/lustre/lustre/llite/file.c
@@ -202,7 +202,7 @@ static int ll_close_inode_openhandle(struct obd_export 
*md_exp,
rc = -EBUSY;
}
 
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
 
 out:
if (exp_connect_som(exp) && !epoch_close &&
@@ -420,7 +420,7 @@ static int ll_intent_file_open(struct dentry *dentry, void 
*lmm,
itp->it_flags |= MDS_OPEN_BY_FID;
rc = md_intent_lock(sbi->ll_md_exp, op_data, lmm, lmmsize, itp,
0 /*unused */, , ll_md_blocking_ast, 0);
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
if (rc == -ESTALE) {
/* reason for keep own exit path - don`t flood log
* with messages with -ESTALE errors.
@@ -819,7 +819,7 @@ ll_lease_open(struct inode *inode, struct file *file, 
fmode_t fmode,
 * open in ll_md_blocking_ast(). Otherwise as ll_md_blocking_lease_ast
 * doesn't deal with openhandle, so normal openhandle will be leaked. */
LDLM_FL_NO_LRU | LDLM_FL_EXCL);
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
ptlrpc_req_finished(req);
if (rc < 0)
goto out_release_it;
@@ -1393,7 +1393,7 @@ int ll_lov_getstripe_ea_info(struct inode *inode, const 
char *filename,
 
op_data->op_valid = OBD_MD_FLEASIZE | OBD_MD_FLDIREA;
rc = md_getattr_name(sbi->ll_md_exp, op_data, );
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
if (rc < 0) {
CDEBUG(D_INFO, "md_getattr_name failed on %s: rc %d\n",
   filename, rc);
@@ -2056,7 +2056,7 @@ static int ll_swap_layouts(struct file *file1, struct 
file *file2,
 
rc = obd_iocontrol(LL_IOC_LOV_SWAP_LAYOUTS, ll_i2mdexp(llss->inode1),
   sizeof(*op_data), op_data, NULL);
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
 
 putgl:
if (gid != 0) {
@@ -2131,7 +2131,7 @@ static int ll_hsm_state_set(struct inode *inode, struct 
hsm_state_set *hss)
rc = obd_iocontrol(LL_IOC_HSM_STATE_SET, ll_i2mdexp(inode),
   sizeof(*op_data), op_data, NULL);
 
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
 
return rc;
 }
@@ -2350,7 +2350,7 @@ ll_file_ioctl(struct file *file, unsigned int cmd, 
unsigned long arg)
if (copy_to_user((void *)arg, hus, sizeof(*hus)))
rc = -EFAULT;
 
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
kfree(hus);
return rc;
}
@@ -2389,7 +2389,7 @@ ll_file_ioctl(struct file *file, unsigned int cmd, 
unsigned long arg)
if (copy_to_user((char *)arg, hca, sizeof(*hca)))
rc = -EFAULT;
 
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
kfree(hca);
return rc;
}
@@ -2761,7 +2761,7 @@ ll_file_flock(struct file *file, int cmd, struct 
file_lock *file_lock)
rc = rc2;
}
 
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
 
return rc;
 }
@@ -2896,7 +2896,7 @@ static int __ll_inode_revalidate(struct dentry *dentry, 
__u64 ibits)
   based lookup */
, 0, ,
ll_md_blocking_ast, 0);
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
oit.it_create_mode &= ~M_CHECK_STALE;
if (rc < 0) {
rc = ll_inode_revalidate_fini(inode, rc);
@@ -2938,7 +2938,7 @@ static int __ll_inode_revalidate(struct dentry *dentry, 
__u64 ibits)
 
op_data->op_valid = valid;
rc = md_getattr(sbi->ll_md_exp, op_data, );
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
if (rc) {
rc = ll_inode_revalidate_fini(inode, rc);
return rc;
@@ -3533,7 +3533,7 @@ again:
ptlrpc_req_finished(it.d.lustre.it_data);
it.d.lustre.it_data = NULL;
 
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
 
mode = it.d.lustre.it_lock_mode;
it.d.lustre.it_lock_mode = 0;
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  

[PATCH 1/9] Staging: lustre: dir: Replace function calls

[Shivani Bhardwaj]

Replace the calls of the function ll_finish_md_op_data() with the
standard function kfree().

Signed-off-by: Shivani Bhardwaj 
---
 drivers/staging/lustre/lustre/llite/dir.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/lustre/lustre/llite/dir.c 
b/drivers/staging/lustre/lustre/llite/dir.c
index 5c2ef92..ba3f469 100644
--- a/drivers/staging/lustre/lustre/llite/dir.c
+++ b/drivers/staging/lustre/lustre/llite/dir.c
@@ -182,7 +182,7 @@ static int ll_dir_filler(void *_hash, struct page *page0)
op_data->op_npages = npages;
op_data->op_offset = hash;
rc = md_readpage(exp, op_data, page_pool, );
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
if (rc < 0) {
/* page0 is special, which was added into page cache early */
delete_from_page_cache(page0);
@@ -363,7 +363,7 @@ struct page *ll_get_dir_page(struct inode *dir, __u64 hash,
rc = md_enqueue(ll_i2sbi(dir)->ll_md_exp, , ,
op_data, , NULL, 0, NULL, 0);
 
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
 
request = (struct ptlrpc_request *)it.d.lustre.it_data;
if (request)
@@ -669,7 +669,7 @@ static int ll_dir_setdirstripe(struct inode *dir, struct 
lmv_user_md *lump,
from_kuid(_user_ns, current_fsuid()),
from_kgid(_user_ns, current_fsgid()),
cfs_curproc_cap_pack(), 0, );
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
if (err)
goto err_exit;
 err_exit:
@@ -730,7 +730,7 @@ int ll_dir_setstripe(struct inode *inode, struct 
lov_user_md *lump,
/* swabbing is done in lov_setstripe() on server side */
rc = md_setattr(sbi->ll_md_exp, op_data, lump, lum_size,
NULL, 0, , NULL);
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
ptlrpc_req_finished(req);
if (rc) {
if (rc != -EPERM && rc != -EACCES)
@@ -802,7 +802,7 @@ int ll_dir_getstripe(struct inode *inode, struct lov_mds_md 
**lmmp,
 
op_data->op_valid = OBD_MD_FLEASIZE | OBD_MD_FLDIREA;
rc = md_getattr(sbi->ll_md_exp, op_data, );
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
if (rc < 0) {
CDEBUG(D_INFO, "md_getattr failed on inode %lu/%u: rc %d\n",
   inode->i_ino,
@@ -868,7 +868,7 @@ int ll_get_mdt_idx(struct inode *inode)
op_data->op_flags |= MF_GET_MDT_IDX;
rc = md_getattr(sbi->ll_md_exp, op_data, NULL);
mdtidx = op_data->op_mds;
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
if (rc < 0) {
CDEBUG(D_INFO, "md_getattr_name: %d\n", rc);
return rc;
@@ -1301,7 +1301,7 @@ static long ll_dir_ioctl(struct file *file, unsigned int 
cmd, unsigned long arg)
 
op_data->op_valid = OBD_MD_FLID;
rc = md_getattr_name(sbi->ll_md_exp, op_data, );
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
if (rc < 0) {
CDEBUG(D_INFO, "md_getattr_name: %d\n", rc);
goto out_free;
-- 
2.1.0

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

[PATCH 0/9] Remove wrapper function and tidy up the code

[Shivani Bhardwaj]

This patchset removes an unnecessary wrapper function and replaces all
its calls in different files with the standard function that it wrapped.
Also, one patch removes its prototype.
After applying this patch, code becomes cleaner.

Shivani Bhardwaj (9):
  Staging: lustre: dir: Replace function calls
  Staging: lustre: file: Replace function calls with standard function
  Staging: lustre: namei: Replace calls with kfree
  Staging: lustre: xattr_cache: Change function calls
  Staging: lustre: symlink: Substitute standard function
  Staging: lustre: llite_nfs: Replace with standard function
  Staging: lustre: llite_close: Substitute function calls
  Staging: lustre: llite_lib: Remove wrapper function
  Staging: lustre: llite_internal: Remove function prototype

 drivers/staging/lustre/lustre/llite/dir.c  | 14 ++---
 drivers/staging/lustre/lustre/llite/file.c | 24 +++---
 drivers/staging/lustre/lustre/llite/llite_close.c  |  2 +-
 .../staging/lustre/lustre/llite/llite_internal.h   |  1 -
 drivers/staging/lustre/lustre/llite/llite_lib.c| 13 
 drivers/staging/lustre/lustre/llite/llite_nfs.c|  2 +-
 drivers/staging/lustre/lustre/llite/namei.c| 12 +--
 drivers/staging/lustre/lustre/llite/symlink.c  |  2 +-
 drivers/staging/lustre/lustre/llite/xattr_cache.c  |  2 +-
 9 files changed, 33 insertions(+), 39 deletions(-)

-- 
2.1.0

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

Re: [GIT PULL] x86/mm changes for v4.4

[Ard Biesheuvel]

On 7 November 2015 at 08:09, Ingo Molnar  wrote:
>
> * Matt Fleming  wrote:
>
>> On Fri, 06 Nov, at 07:55:50AM, Ingo Molnar wrote:
>> >
>> >  3) We should fix the EFI permission problem without relying on the 
>> > firmware: it
>> > appears we could just mark everything R-X optimistically, and if a 
>> > write fault
>> > happens (it's pretty rare in fact, only triggers when we write to an 
>> > EFI
>> > variable and so), we can mark the faulting page RW- on the fly, 
>> > because it
>> > appears that writable EFI sections, while not enumerated very well in 
>> > 'old'
>> > firmware, are still supposed to be page granular. (Even 'new' firmware 
>> > I
>> > wouldn't automatically trust to get the enumeration right...)
>>
>> Sorry, this isn't true. I misled you with one of my earlier posts on
>> this topic. Let me try and clear things up...
>>
>> Writing to EFI regions has to do with every invocation of the EFI
>> runtime services - it's not limited to when you read/write/delete EFI
>> variables. In fact, EFI variables really have nothing to do with this
>> discussion, they're a completely opaque concept to the OS, we have no
>> idea how the firmware implements them. Everything is done via the EFI
>> boot/runtime services.
>>
>> The firmware itself will attempt to write to EFI regions when we
>> invoke the EFI services because that's where the PE/COFF ".data" and
>> ".bss" sections live along with the heap. There's even some relocation
>> fixups that occur as SetVirtualAddressMap() time so it'll write to
>> ".text" too.
>>
>> Now, the above PE/COFF sections are usually (always?) contained within
>> EFI regions of type EfiRuntimeServicesCode. We know this is true
>> because the firmware folks have told us so, and because stopping that
>> is the motivation behind the new EFI_PROPERTIES_TABLE feature in UEFI
>> V2.5.
>>
>> The data sections within the region are also *not* guaranteed to be
>> page granular because work was required in Tianocore for emitting
>> sections with 4k alignment as part of the EFI_PROPERTIES_TABLE
>> support.
>>
>> Ultimately, what this means is that if you were to attempt to
>> dynamically fixup those regions that required write permission, you'd
>> have to modify the mappings for the majority of the EFI regions
>> anyway. And if you're blindly allowing write permission as a fixup,
>> there's not much security to be had.
>
> I think you misunderstood my suggestion: the 'fixup' would be changing it 
> from R-X
> to RW-, i.e. it would add 'write' permission but remove 'execute' permission.
>
> Note that there would be no 'RWX' permission at any given moment - which is 
> the
> dangerous combination.
>

The problem with that is that /any/ page in the UEFI runtime region
may intersect with both .text and .data of any of the PE/COFF images
that make up the runtime firmware (since the PE/COFF sections are not
necessarily page aligned). Such pages require RWX permissions. The
UEFI memory map does not provide the information to identify those
pages a priori (the entire region containing several PE/COFF images
could be covered by a single entry) so it is hard to guess which pages
should be allowed these RWX permissions.

>> > If that 'supposed to be' turns out to be 'not true' (not unheard of in
>> > firmware land), then plan B would be to mark pages that generate write 
>> > faults
>> > RWX as well, to not break functionality. (This 'mark it RWX' is not 
>> > something
>> > that exploits would have easy access to, and we could also generate a 
>> > warning
>> > [after the EFI call has finished] if it ever triggers.)
>> >
>> > Admittedly this approach might not be without its own complications, 
>> > but it
>> > looks reasonably simple (I don't think we need per EFI call page 
>> > tables,
>> > etc.), and does not assume much about the firmware being able to 
>> > enumerate its
>> > permissions properly. Were we to merge EFI support today I'd have 
>> > insisted on
>> > trying such an approach from day 1 on.
>>
>> We already have separate EFI page tables, though with the caveat that
>> we share some of swapper_pg_dir's PGD entries. The best solution would
>> be to stop sharing entries and isolate the EFI mappings from every
>> other page table structure, so that they're only used during the EFI
>> service calls.
>
> Absolutely. Can you try to fix this for v4.3?
>
> Thanks,
>
> Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] Staging: lustre: tracefile: Remove function prototype

[Dilger, Andreas]

On 2015/11/06, 10:19, "Shivani Bhardwaj"  wrote:

>Remove the prototype of function cfs_trace_free_string_buffer() as it is
>no longer needed.

These patches would be a lot more useful if the summary contained the name
of the function being removed, rather than "remove function prototype" and
variations of that.  Something like:

   staging: lustre: remove cfs_trace_free_string_buffer prototype
   staging: lustre: remove ldlm_pool_set_limit wrapper
   staging: lustre: remove ldlm_pool_get_limit wrapper

Not sure if that is grounds for rejection of this patch series (I'll leave
that up to Dan and Greg), but definitely something for future patches.

Cheers, Andreas

>Signed-off-by: Shivani Bhardwaj 
>---
> drivers/staging/lustre/lustre/libcfs/tracefile.h | 1 -
> 1 file changed, 1 deletion(-)
>
>diff --git a/drivers/staging/lustre/lustre/libcfs/tracefile.h
>b/drivers/staging/lustre/lustre/libcfs/tracefile.h
>index 73d60e0..ba62005 100644
>--- a/drivers/staging/lustre/lustre/libcfs/tracefile.h
>+++ b/drivers/staging/lustre/lustre/libcfs/tracefile.h
>@@ -70,7 +70,6 @@ int cfs_trace_copyin_string(char *knl_buffer, int
>knl_buffer_nob,
> int cfs_trace_copyout_string(char __user *usr_buffer, int usr_buffer_nob,
>const char *knl_str, char *append);
> int cfs_trace_allocate_string_buffer(char **str, int nob);
>-void cfs_trace_free_string_buffer(char *str, int nob);
> int cfs_trace_dump_debug_buffer_usrstr(void __user *usr_str, int
>usr_str_nob);
> int cfs_trace_daemon_command(char *str);
> int cfs_trace_daemon_command_usrstr(void __user *usr_str, int
>usr_str_nob);
>-- 
>2.1.0
>
>


Cheers, Andreas
-- 
Andreas Dilger

Lustre Software Architect
Intel High Performance Data Division


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

Re: [PATCH] sysfs: add devm_sysfs_create_group() and friends

[Dmitry Torokhov]

On Fri, Nov 06, 2015 at 04:24:07PM -0800, Greg Kroah-Hartman wrote:
> On Fri, Oct 30, 2015 at 08:13:11AM -0700, Dmitry Torokhov wrote:
> > On Fri, Oct 30, 2015 at 07:40:37AM -0700, Greg Kroah-Hartman wrote:
> > > On Fri, Oct 30, 2015 at 04:47:06AM -0700, Dmitry Torokhov wrote:
> > > > Many drivers create additional driver-specific device attributes when
> > > > binding to the device and providing managed version of 
> > > > sysfs_create_group()
> > > > will simplify unbinding and error handling in probe path for such 
> > > > drivers.
> > > 
> > > But they really shouldn't, because if they do this, they have raced
> > > userspace and tools don't know that the files are present.
> > > 
> > > I don't want to encourage drivers to do this at all, so I don't want to
> > > make it easier for them to do things incorrectly.
> > 
> > The solution is not to forbid drivers from establishing attributes but
> > rather notify userspace when device is fully bound to the driver. Then
> > userspace that actually cares about these attributes will listen to
> > proper events.
> > 
> > We can either do KOBJ_BOUND/KOBJ_UNBOUND or reuse
> > KOBJ_ONLINE/KOBJ_OFFLINE. I'd prefer the former (adding new events).
> 
> bound/unbound makes a bit more sense, maybe that would work, haven't
> thought that much about it.  Given that no one in the "real world" seem
> to notice the race condition, that means that people aren't really using
> tools like libudev to read sysfs attributes, so maybe no one even cares
> about the contents of them :)

Could be, or they have workarounds for this scenario.

> 
> > > Yes, I know that input does this for its devices, but I still think it
> > > is wrong and should be changed.  Let's not let this problem spread to
> > > other subsystems please.
> > 
> > Like HID, chargers, hwmon, wireless drivers, leds, backlights, platform
> > drivers and so on? Where are platform devices supposed to create their
> > attributes? There are more than 300 drivers that add new groups and 581
> > instance of device_create_file().
> 
> Platform drivers are the main problem right now, I don't know what to do
> about them.  I hate those things :(
> 
> > Let's be realistic here and see that additional attributes are not going
> > anywhere and adding devm interface just helps getting error handling
> > right.
> 
> But the files are already removed from the system when the device is
> removed,

In this case the device to which we attach attributes is not removed
though, it is still present in the system.

> so with the exception of the odd error path on probe, this
> isn't doing much.  Does it save much code when used?

It basically allows replacing code like:

static void rohm_ts_remove_sysfs_group(void *_dev)
{
struct device *dev = _dev;

sysfs_remove_group(>kobj, _ts_attr_group);
}

static int rohm_bu21023_i2c_probe(struct i2c_client *client, ...)
{
...

error = sysfs_create_group(>kobj, _ts_attr_group);
if (error) {
dev_err(dev, "failed to create sysfs group: %d\n", error);
return error;
}

error = devm_add_action(dev, rohm_ts_remove_sysfs_group, dev);
if (error) {
rohm_ts_remove_sysfs_group(dev);
dev_err(>dev,
"Failed to add sysfs cleanup action: %d\n",
error);
return error;
}

...
}

with:

static int rohm_bu21023_i2c_probe(struct i2c_client *client, ...)
{
...

error = devm_sysfs_create_group(dev, rohm_ts_attr_group);
if (error)
return error;

...
}

which is arguable much more compact.

That assuming that the driver is using devm construct. In case driver
used goto error unwinding it really depends at what point the attributes
were created, but I strongly advise against mixing devm and goto
unwinding in one driver as it leads to confusion as to what strategy a
given resource is using, manual or devm?

Thanks.

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

Re: [RFC PATCH 00/28] Linux Kernel Library

[Richard W.M. Jones]

On Sat, Nov 07, 2015 at 01:35:36AM +0100, Richard Weinberger wrote:
> Am 04.11.2015 um 15:15 schrieb Octavian Purdila:
> > We could redefine the syscalls/libc symbols to call lkl_sys_ functions
> > in launch-lkl, e.g.:
> > 
> > int opendir(const char *path)
> > {
> >return lkl_opendir(new_path)
> > }
> 
> To get a better feeling how LKL behaves I've started with a tool
> to mount any Linux filesystem by FUSE.
> I.e. such that we can finally automount without root and bugs in filesystem
> code won't hurt that much.

guestmount already does this:

http://libguestfs.org/guestmount.1.html

By porting a small amount of code from the daemon/ directory, it could
do it using lkl too.  See:

http://www.gossamer-threads.com/lists/linux/kernel/2296116#2296116

Rich.

> lkl_sys_fstatat64() uses the type struct lkl_stat64. Where is it defined?
> git grep is unable to locate it.
> At least it seems to be incompatible with my local struct stat.
> 
> And why is there no lkl_sys_openat() syscall?
> 
> Thanks,
> //richard

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] smpboot: Add smpboot state variables instead of reusing CPU hotplug states

[Paul E. McKenney]

On Thu, Oct 15, 2015 at 01:32:44PM +0200, Daniel Wagner wrote:
> The cpu hotplug state machine in smpboot.c is reusing the states from
> cpu.h. That is confusing when it comes to the CPU_DEAD_FROZEN usage.
> Paul explained to me that he was in need of an additional state
> for destinguishing between a CPU error states. For this he just
> picked CPU_DEAD_FROZEN.
> 
> 8038dad7e888581266c76df15d70ca457a3c5910 smpboot: Add common code for 
> notification from dying CPU
> 2a442c9c6453d3d043dfd89f2e03a1deff8a6f06 x86: Use common 
> outgoing-CPU-notification code
> 
> Instead of reusing the states, let's add new definition inside
> the smpboot.c file with explenation what those states
> mean. Thanks Paul for providing them.
> 
> Signed-off-by: Daniel Wagner 

Apologies for the delay, I didn't realize that you were waiting on me.

Reviewed-by: Paul E. McKenney 

> Cc: Thomas Gleixner 
> Cc: "Paul E. McKenney" 
> Cc: Peter Zijlstra 
> Cc: xen-de...@lists.xenproject.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  arch/x86/xen/smp.c  |  4 +--
>  include/linux/cpu.h |  3 +-
>  kernel/smpboot.c| 82 
> -
>  3 files changed, 67 insertions(+), 22 deletions(-)
> 
> diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
> index 3f4ebf0..804bf5c 100644
> --- a/arch/x86/xen/smp.c
> +++ b/arch/x86/xen/smp.c
> @@ -495,7 +495,7 @@ static int xen_cpu_up(unsigned int cpu, struct 
> task_struct *idle)
>   rc = HYPERVISOR_vcpu_op(VCPUOP_up, cpu, NULL);
>   BUG_ON(rc);
> 
> - while (cpu_report_state(cpu) != CPU_ONLINE)
> + while (!cpu_check_online(cpu))
>   HYPERVISOR_sched_op(SCHEDOP_yield, NULL);
> 
>   return 0;
> @@ -767,7 +767,7 @@ static int xen_hvm_cpu_up(unsigned int cpu, struct 
> task_struct *tidle)
>* This can happen if CPU was offlined earlier and
>* offlining timed out in common_cpu_die().
>*/
> - if (cpu_report_state(cpu) == CPU_DEAD_FROZEN) {
> + if (cpu_check_timeout(cpu)) {
>   xen_smp_intr_free(cpu);
>   xen_uninit_lock_cpu(cpu);
>   }
> diff --git a/include/linux/cpu.h b/include/linux/cpu.h
> index 23c30bd..f78ab46 100644
> --- a/include/linux/cpu.h
> +++ b/include/linux/cpu.h
> @@ -284,7 +284,8 @@ void arch_cpu_idle_dead(void);
> 
>  DECLARE_PER_CPU(bool, cpu_dead_idle);
> 
> -int cpu_report_state(int cpu);
> +int cpu_check_online(int cpu);
> +int cpu_check_timeout(int cpu);
>  int cpu_check_up_prepare(int cpu);
>  void cpu_set_state_online(int cpu);
>  #ifdef CONFIG_HOTPLUG_CPU
> diff --git a/kernel/smpboot.c b/kernel/smpboot.c
> index a818cbc..75e5724 100644
> --- a/kernel/smpboot.c
> +++ b/kernel/smpboot.c
> @@ -371,19 +371,63 @@ int smpboot_update_cpumask_percpu_thread(struct 
> smp_hotplug_thread *plug_thread,
>  }
>  EXPORT_SYMBOL_GPL(smpboot_update_cpumask_percpu_thread);
> 
> +/* The CPU is offline, and its last offline operation was
> + * successful and proceeded normally.  (Or, alternatively, the
> + * CPU never has come online, as this is the initial state.)
> + */
> +#define CPUHP_POST_DEAD  0x01
> +
> +/* The CPU is in the process of coming online.
> + * Simple architectures can skip this state, and just invoke
> + * cpu_set_state_online() unconditionally instead.
> + */
> +#define CPUHP_UP_PREPARE 0x02
> +
> +/* The CPU is now online.  Simple architectures can skip this
> + * state, and just invoke cpu_wait_death() and cpu_report_death()
> + * unconditionally instead.
> + */
> +#define CPUHP_ONLINE 0x03
> +
> +/* The CPU has gone offline, so that it may now be safely
> + * powered off (or whatever the architecture needs to do to it).
> + */
> +#define CPUHP_DEAD   0x04
> +
> +/* The CPU did not go offline in a timely fashion, if at all,
> + * so it might need special processing at the next online (for
> + * example, simply refusing to bring it online).
> + */
> +#define CPUHP_BROKEN 0x05
> +
> +/* The CPU eventually did go offline, but not in a timely
> + * fashion.  If some sort of reset operation is required before it
> + * can be brought online, that reset operation needs to be carried
> + * out at online time.  (Or, again, the architecture might simply
> + * refuse to bring it online.)
> + */
> +#define CPUHP_TIMEOUT0x06
> +
>  static DEFINE_PER_CPU(atomic_t, cpu_hotplug_state) = 
> ATOMIC_INIT(CPU_POST_DEAD);
> 
>  /*
>   * Called to poll specified CPU's state, for example, when waiting for
>   * a CPU to come online.
>   */
> -int cpu_report_state(int cpu)
> +int cpu_check_online(int cpu)
> +{
> + return atomic_read(_cpu(cpu_hotplug_state, cpu)) ==
> +CPUHP_ONLINE;
> +}
> +
> +int cpu_check_timeout(int cpu)
>  {
> - return atomic_read(_cpu(cpu_hotplug_state, cpu));
> + return atomic_read(_cpu(cpu_hotplug_state, cpu)) ==
> +CPUHP_TIMEOUT;
>  }
> 
>  /*
> - * If CPU has died properly, set its state to CPU_UP_PREPARE and
> + * If CPU has 

Re: + mm-hwpoison-adjust-for-new-thp-refcounting-fix.patch added to -mm tree

[Kirill A. Shutemov]

On Fri, Nov 06, 2015 at 02:46:30PM -0800, a...@linux-foundation.org wrote:
> 
> The patch titled
>  Subject: mm-hwpoison-adjust-for-new-thp-refcounting-fix
> has been added to the -mm tree.  Its filename is
>  mm-hwpoison-adjust-for-new-thp-refcounting-fix.patch
> 
> This patch should soon appear at
> 
> http://ozlabs.org/~akpm/mmots/broken-out/mm-hwpoison-adjust-for-new-thp-refcounting-fix.patch
> and later at
> 
> http://ozlabs.org/~akpm/mmotm/broken-out/mm-hwpoison-adjust-for-new-thp-refcounting-fix.patch
> 
> Before you just go and hit "reply", please:
>a) Consider who else should be cc'ed
>b) Prefer to cc a suitable mailing list as well
>c) Ideally: find the original patch on the mailing list and do a
>   reply-to-all to that, adding suitable additional cc's
> 
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
> 
> The -mm tree is included into linux-next and is updated
> there every 3-4 working days
> 
> --
> From: Andrew Morton 
> Subject: mm-hwpoison-adjust-for-new-thp-refcounting-fix
> 
> remove unnded #define, per Kirill
> 
> Cc: Kirill A. Shutemov 
> Cc: Naoya Horiguchi 
> Signed-off-by: Andrew Morton 
> ---
> 
>  include/linux/mm.h |1 -
>  1 file changed, 1 deletion(-)
> 
> diff -puN include/linux/mm.h~mm-hwpoison-adjust-for-new-thp-refcounting-fix 
> include/linux/mm.h
> --- a/include/linux/mm.h~mm-hwpoison-adjust-for-new-thp-refcounting-fix
> +++ a/include/linux/mm.h
> @@ -2193,7 +2193,6 @@ extern int memory_failure(unsigned long
>  extern void memory_failure_queue(unsigned long pfn, int trapno, int flags);
>  extern int unpoison_memory(unsigned long pfn);
>  extern int get_hwpoison_page(struct page *page);
> -#define put_hwpoison_page(page)  put_page(page)
>  extern void put_hwpoison_page(struct page *page);

Andrew, you've removed the wrong line. The next one should be removed.

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

Re: [GIT PULL] x86/mm changes for v4.4

[Ingo Molnar]

* Matt Fleming  wrote:

> On Fri, 06 Nov, at 07:55:50AM, Ingo Molnar wrote:
> > 
> >  3) We should fix the EFI permission problem without relying on the 
> > firmware: it 
> > appears we could just mark everything R-X optimistically, and if a 
> > write fault 
> > happens (it's pretty rare in fact, only triggers when we write to an 
> > EFI 
> > variable and so), we can mark the faulting page RW- on the fly, because 
> > it 
> > appears that writable EFI sections, while not enumerated very well in 
> > 'old' 
> > firmware, are still supposed to be page granular. (Even 'new' firmware 
> > I 
> > wouldn't automatically trust to get the enumeration right...)
> 
> Sorry, this isn't true. I misled you with one of my earlier posts on
> this topic. Let me try and clear things up...
> 
> Writing to EFI regions has to do with every invocation of the EFI
> runtime services - it's not limited to when you read/write/delete EFI
> variables. In fact, EFI variables really have nothing to do with this
> discussion, they're a completely opaque concept to the OS, we have no
> idea how the firmware implements them. Everything is done via the EFI
> boot/runtime services.
> 
> The firmware itself will attempt to write to EFI regions when we
> invoke the EFI services because that's where the PE/COFF ".data" and
> ".bss" sections live along with the heap. There's even some relocation
> fixups that occur as SetVirtualAddressMap() time so it'll write to
> ".text" too.
> 
> Now, the above PE/COFF sections are usually (always?) contained within
> EFI regions of type EfiRuntimeServicesCode. We know this is true
> because the firmware folks have told us so, and because stopping that
> is the motivation behind the new EFI_PROPERTIES_TABLE feature in UEFI
> V2.5.
> 
> The data sections within the region are also *not* guaranteed to be
> page granular because work was required in Tianocore for emitting
> sections with 4k alignment as part of the EFI_PROPERTIES_TABLE
> support.
> 
> Ultimately, what this means is that if you were to attempt to
> dynamically fixup those regions that required write permission, you'd
> have to modify the mappings for the majority of the EFI regions
> anyway. And if you're blindly allowing write permission as a fixup,
> there's not much security to be had.

I think you misunderstood my suggestion: the 'fixup' would be changing it from 
R-X 
to RW-, i.e. it would add 'write' permission but remove 'execute' permission.

Note that there would be no 'RWX' permission at any given moment - which is the 
dangerous combination.

> > If that 'supposed to be' turns out to be 'not true' (not unheard of in
> > firmware land), then plan B would be to mark pages that generate write 
> > faults 
> > RWX as well, to not break functionality. (This 'mark it RWX' is not 
> > something 
> > that exploits would have easy access to, and we could also generate a 
> > warning
> > [after the EFI call has finished] if it ever triggers.)
> > 
> > Admittedly this approach might not be without its own complications, 
> > but it 
> > looks reasonably simple (I don't think we need per EFI call page 
> > tables, 
> > etc.), and does not assume much about the firmware being able to 
> > enumerate its 
> > permissions properly. Were we to merge EFI support today I'd have 
> > insisted on 
> > trying such an approach from day 1 on.
> 
> We already have separate EFI page tables, though with the caveat that
> we share some of swapper_pg_dir's PGD entries. The best solution would
> be to stop sharing entries and isolate the EFI mappings from every
> other page table structure, so that they're only used during the EFI
> service calls.

Absolutely. Can you try to fix this for v4.3?

Thanks,

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

Re: [GIT PULL] x86/mm changes for v4.4

[Ingo Molnar]

* Matt Fleming  wrote:

> On Thu, 05 Nov, at 01:33:10PM, Linus Torvalds wrote:
> > 
> > And if this turns out to be due to EFI wanting those permissions, what 
> > should 
> > we do? People have talked about running the EFI callbacks in their own 
> > private 
> > page table setup, which sounds like the right idea, but until that actually 
> > *happens*
> 
> We have separate page tables today, for a few reasons, but mainly it's
> so that we can have an identity mapping of memory present in the
> region usually used by user processes - broken firmware still uses
> those identity mappings even after the kernel tells it they're
> invalid.
> 
> Note that when I say "separate" I'm talking about trampoline_pgd[]
> which is also used by the x86 suspend/resume code.
> 
> However, turns out that the issue with the current scheme is the fact
> that trampoline_pgd[] actually shares a couple of PGD entries with
> swapper_pg_dir as can be seen in setup_real_mode(),
> 
> 
> trampoline_pgd = (u64 *)__va(real_mode_header->trampoline_pgd);
> trampoline_pgd[0] = init_level4_pgt[pgd_index(__PAGE_OFFSET)].pgd;
> trampoline_pgd[511] = init_level4_pgt[511].pgd;
> 
> 
> So when we map the EFI regions in efi_map_regions() we're inserting
> them into swapper_pg_dir also, which is why you're seeing the
> warnings.
> 
> If I remember correctly the rationale for using trampoline_pgd[] was
> that it already did what we wanted (provided the identity mapping) and
> would save us the overhead of maintaining more page tables for no good
> reason. Obviously this entire thread is a good reason.
> 
> I suggest we stop using trampoline_pgd[] (since it has a good reason
> for sharing the kernel mapping PGD entries) and create our own so that
> we can isolate EFI completely.

Ok. Could you please make this fix a priority for upcoming EFI changes?

> For the immediate problem of the warnings spewing forth on all UEFI
> machines, at the very least the config options needs to be disabled by
> default, if not the patch reverted.

We'll certainly flip around the default, but reverting would be shooting
the messenger: the EFI code is endangering everyone else today, and for
no good reason as it appears... so the warning very much served its
purpose in pointing out a valid problem.

Thanks,

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

Re: [GIT PULL] x86/mm changes for v4.4

[Ingo Molnar]

* Andy Lutomirski  wrote:

> On Thu, Nov 5, 2015 at 10:55 PM, Ingo Molnar  wrote:
> >
> > * Linus Torvalds  wrote:
> >
> >> On Wed, Nov 4, 2015 at 6:17 PM, Dave Jones  wrote:
> >> > On Wed, Nov 04, 2015 at 05:31:59PM -0800, Linus Torvalds wrote:
> >> >  >
> >> >  > I don't have that later debug output at all. Presumably some config 
> >> > difference.
> >> >
> >> > CONFIG_X86_PTDUMP_CORE iirc.
> >>
> >> No, I have that. I suspect CONFIG_EFI_PGT_DUMP instead.
> >>
> >> Anyway, as it stands now, I think the CONFIG_DEBUG_WX option should
> >> not default to 'y' unless it is made more useful if it actually
> >> triggers. Ingo?
> >
> > Yeah, agreed absolutely.
> >
> > So this is a bit sad because RWX pages are a real problem in practice, 
> > especially
> > since the EFI addresses are well predictable, but generating a warning 
> > without
> > being able to fix it quickly is counterproductive as well, as it only annoys
> > people and makes them turn off the option. (Which we could do as well to 
> > begin
> > with, without the annoyance factor...)
> >
> > So the plan would be:
> >
> >  1) Make it default-n.
> >
> >  2) We should try to further improve the messages to make it easier to 
> > determine
> > what's wrong. We _do_ try to output symbolic information in the 
> > warning, to
> > make it easier to find buggy mappings, but these are not standard kernel
> > mappings. So I think we need an e820 mappings based semi-symbolic 
> > printout of
> > bad addresses - maybe even correlate it with the MMIO resource tree.
> >
> >  3) We should fix the EFI permission problem without relying on the 
> > firmware: it
> > appears we could just mark everything R-X optimistically, and if a 
> > write fault
> > happens (it's pretty rare in fact, only triggers when we write to an EFI
> > variable and so), we can mark the faulting page RW- on the fly, because 
> > it
> > appears that writable EFI sections, while not enumerated very well in 
> > 'old'
> > firmware, are still supposed to be page granular. (Even 'new' firmware I
> > wouldn't automatically trust to get the enumeration right...)
> 
> I think it was Borislav who pointed out that this idea, which might
> have been mine, is a bit silly.  Why not just skip mapping the EFI
> stuff in the init_pgd entirely and only map it in the EFI pgd?
> 
> We'll have RWX stuff in the EFI pgd, but so what?  If we're exposing
> anything that runs with the EFI pgd loaded to untrusted input, I think
> we've already lost.

That's certainly true, I was simply confused about the life time of these 
mappings: I assumed they have to stay around. If they are meant to be and are 
partly temporary today already, we should go the whole mile and make that 
really 
so, because _today_ the mappings are permanent, so this is a real problem ...

Thanks,

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

Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness

[Thomas Gleixner]

On Fri, 6 Nov 2015, H. Peter Anvin wrote:
> On 11/06/15 15:17, Dan Williams wrote:
> >>
> >> Is it really required to do that on all cpus?
> > 
> > I believe it is, but I'll double check.
> > 
> 
> It's required on all CPUs on which the DAX memory may have been dirtied.
>  This is similar to the way we flush TLBs.

Right. And that's exactly the problem: "may have been dirtied"

If DAX is used on 50% of the CPUs and the other 50% are plumming away
happily in user space or run low latency RT tasks w/o ever touching
it, then having an unconditional flush on ALL CPUs is just wrong
because you penalize the uninvolved cores with a completely pointless
SMP function call and drain their caches.

Thanks,

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

Re: [PATCH 09/13] Move bp_type_idx to kernel/event/hw_breakpoint.c

[Palmer Dabbelt]

On Wed, 04 Nov 2015 04:21:51 PST (-0800), pet...@infradead.org wrote:
> On Wed, Nov 04, 2015 at 12:41:06PM +0100, Peter Zijlstra wrote:
>> On Tue, Nov 03, 2015 at 11:46:30AM -0800, Palmer Dabbelt wrote:
>> > This has a "#ifdef CONFIG_*" that used to be exposed to userspace.
>> >
>> > The names in here are so generic that I don't think it's a good idea
>> > to expose them to userspace (or even the rest of the kernel).  Since
>> > there's only one kernel user, it's been moved to that file.
>> >
>> > Signed-off-by: Palmer Dabbelt 
>> > Reviewed-by: Andrew Waterman 
>> > Reviewed-by: Albert Ou 
>>
>> Assuming you want to keep all these patches together in a tree or so.
>> Let me know if you want me to take this patch.

Well, the plan was to try to get the whole patch set all upstream together.
I'd prefer that, because it'll be easier to make sure everything gets in before
the last checker patch.  Since it touches so many different places I'd be OK
with doing it peicemeal.

I'm kind of new to this whole process: do you think someone is likely to take
this patch set all together?

>> Acked-by: Peter Zijlstra (Intel) 
>
> Ah, build-bot finds your change is broken and you didn't grep right. It
> is used in more places.

Sorry about that, I must have mis-grep'd.  I guess that's what the build-bot is
for :).

> How about moving it to include/linux/hw_breakpoint.h, instead of having
> it in the uapi crud?

Yep, that makes sense.

I'm going to re-submit a v5 of this patch set, since there was also a missing
patch for blackfin that the buildbot found.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 2/3] dmaselftest: add memcpy selftest support functions

[Sinan Kaya]

On 11/5/2015 11:17 AM, Sinan Kaya wrote:



On 11/5/2015 7:05 AM, Vinod Koul wrote:

On Wed, Nov 04, 2015 at 09:42:46PM -0500, Sinan Kaya wrote:

Here is what I proposed.

- a common file that gets compiled into a module that wants to use
self-test with a public API. It can be called from driver's probe
routine.
- the test is independent of my implementation. It uses dmaengine
API and should be portable to most drivers.
- there *are* still drivers in the kernel that has selftest code
embedded inside them. I followed the design pattern from other
drivers thinking this must have been a good idea and it paid off for
me.

As far as I understand, there is interest in doing more than this
and reusing the dmatest code for code duplication.


the code that selftest uses to test will be very similar to dmatest code,
both of these _should_ share this common code so that fixes get done for
both!



OK, I can move the code around and try to combine it if possible.



I looked at this. IMO, merging selftest code and dmatest code is not a 
good idea.


Dmatest code has been well written and structured so that multiple DMA 
capabilities (XOR, PQ, MEMCPY) can be tested with the same code.


It supports threads and user space interaction.

The code I want to change (dmatest_func) is 3 levels deep in structure. 
My refactored code looked really ugly compared to the original code.




Facts:
- Dmatest can be actually configured to run during boot.
- Nobody besides the dma driver developer uses dmatest. This leaves
holes for regressions that are really hard to debug due to
interaction with the rest of the system.
- Dmatest doesn't exist in most distribution kernels.


That doesn't mean it is not useful. This line of thought is not quite
right.
You are trying to say dmatest in not important and selftest is. Sorry but
you are wrong, both are equally important and since both try to test
and use
similar routines (dmaengien API) they need to share the code and not
duplicate it


If we want to do something else, I need clear directions. I can
remove the self test code completely from my driver. But, I need an
equivalent functionality.


Add selftest to dmatest, we need both!



OK, do you have any objections to compiling dmatest along with hidma in
the same module and calling a function from there ? or do you have
something else in your mind ?



ping





That part is tricky, you need to do so thru clients,
spi/audio/serial etc



My selftest code actually attaches to all slave devices and issues a
memcpy command and then detaches from the slave devices.


Not everyone supports memcpy!


Right, last time I checked; you can request a DMA channel that supports
MEMCPY specifically.




--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

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

Re: [GIT] Sparc

[Julia Lawall]

On Sat, 7 Nov 2015, Julian Calaby wrote:

> Hi Julia,
> 
> On Fri, Nov 6, 2015 at 5:44 PM, Julia Lawall  wrote:
> > On Fri, 6 Nov 2015, Julian Calaby wrote:
> >
> >> Hi Linus,
> >>
> >> On Fri, Nov 6, 2015 at 11:56 AM, Linus Torvalds
> >>  wrote:
> >> > On Thu, Nov 5, 2015 at 4:43 PM, Linus Torvalds
> >> >  wrote:
> >> >>
> >> >> Not that this *matters*, but it's a bit odd to have to cast constants
> >> >> to perfectly regular C types.
> >> >
> >> > Looking around with "git grep", there's a few more of these.
> >> >
> >> >  - btrfs seems to like "(unsigned long)-1"
> >> >
> >> >There's a few other users of that too, including more sparc uses.
> >> >
> >> >  - scsi/qla seems to like "(unsigned long)"
> >> >
> >> >  - fmdrv_common.h seems to like "((unsigned long)1< >> >
> >> > along with a smattering of random noise all over of "(unsigned long)
> >> > n" where 'n' is some integer.
> >> >
> >> > Apparently people aren't as aware of the normal "ul" postfix syntax as
> >> > I would have expected. That said, it's a hundred-odd cases in all of
> >> > the kernel, so it's still fairly rare.
> >>
> >> Maybe this is something the kernel-janitors team should look at? (CC'd)
> >
> > Do you have some concrete examples of the code that is undesirable?
> 
> Joe Perches produced a patch for checkpatch to check for this [1]
> 
> Linus was complaining [2] about people producing constants with casts
> to basic C types in them. For instance:
> 
> #define IOMMU_ERROR_CODE (~(unsigned long) 0)
> 
> This could be replaced with
> 
> #define IOMMU_ERROR_CODE (~0ul)
> 
> or potentially
> 
> #define IOMMU_ERROR_CODE (-1ul)
> 
> It's not overly common, but it looks wrong.

Thanks.  The checkpatch solution indeed looks fine in this case.

julia

> Thanks,
> 
> Julian Calaby
> 
> [1] https://lkml.org/lkml/2015/11/6/48
> [2] https://lkml.org/lkml/2015/11/5/785
> 
> -- 
> Julian Calaby
> 
> Email: julian.cal...@gmail.com
> Profile: http://www.google.com/profiles/julian.calaby/
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] bpf: doc: correct arch list for supported eBPF JIT

[Yang Shi]

aarch64 and s390x support eBPF JIT too, correct document to reflect this and
avoid any confusion.

Signed-off-by: Yang Shi 
---
 Documentation/networking/filter.txt | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/networking/filter.txt 
b/Documentation/networking/filter.txt
index 135581f..96da119 100644
--- a/Documentation/networking/filter.txt
+++ b/Documentation/networking/filter.txt
@@ -596,9 +596,9 @@ skb pointer). All constraints and restrictions from 
bpf_check_classic() apply
 before a conversion to the new layout is being done behind the scenes!
 
 Currently, the classic BPF format is being used for JITing on most of the
-architectures. Only x86-64 performs JIT compilation from eBPF instruction set,
-however, future work will migrate other JIT compilers as well, so that they
-will profit from the very same benefits.
+architectures. x86-64, aarch64 and s390x perform JIT compilation from eBPF
+instruction set, however, future work will migrate other JIT compilers as well,
+so that they will profit from the very same benefits.
 
 Some core changes of the new internal format:
 
-- 
2.0.2

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

Re: [PATCH] arm64: bpf: fix JIT stack setup

[Shi, Yang]

Please ignore this one, forgot to cc to linux-arm-kernel list.

Sorry for the inconvenience.

Yang


On 11/6/2015 9:34 PM, Yang Shi wrote:

ARM64 JIT used FP (x29) as eBPF fp register, but FP is subjected to
change during function call so it may cause the BPF prog stack base address
change too. Whenever, it pointed to the bottom of BPF prog stack instead of
the top.

So, when copying data via bpf_probe_read, it will be copied to (SP - offset),
then it may overwrite the saved FP/LR.

Use x25 to replace FP as BPF stack base register (fp). Since x25 is callee
saved register, so it will keep intact during function call.
It is initialized in BPF prog prologue when BPF prog is started to run
everytime. When BPF prog exits, it could be just tossed.

Other than this the BPf prog stack base need to be setup before function
call stack.

So, the BPF stack layout looks like:

  high
  original A64_SP =>   0:+-+ BPF prologue
 | | FP/LR and callee saved registers
  BPF fp register => +64:+-+
 | |
 | ... | BPF prog stack
 | |
 | |
  current A64_SP =>  +-+
 | |
 | ... | Function call stack
 | |
 +-+
   low

Signed-off-by: Yang Shi 
CC: Zi Shen Lim 
CC: Xi Wang 
---
  arch/arm64/net/bpf_jit_comp.c | 38 +++---
  1 file changed, 31 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c
index a44e529..6809647 100644
--- a/arch/arm64/net/bpf_jit_comp.c
+++ b/arch/arm64/net/bpf_jit_comp.c
@@ -50,7 +50,7 @@ static const int bpf2a64[] = {
[BPF_REG_8] = A64_R(21),
[BPF_REG_9] = A64_R(22),
/* read-only frame pointer to access stack */
-   [BPF_REG_FP] = A64_FP,
+   [BPF_REG_FP] = A64_R(25),
/* temporary register for internal BPF JIT */
[TMP_REG_1] = A64_R(23),
[TMP_REG_2] = A64_R(24),
@@ -155,18 +155,42 @@ static void build_prologue(struct jit_ctx *ctx)
stack_size += 4; /* extra for skb_copy_bits buffer */
stack_size = STACK_ALIGN(stack_size);

+   /*
+* BPF prog stack layout
+*
+* high
+* original A64_SP =>   0:+-+ BPF prologue
+*| | FP/LR and callee saved registers
+* BPF fp register => +64:+-+
+*| |
+ *| ... | BPF prog stack
+*| |
+*| |
+* current A64_SP =>  +-+
+*| |
+*| ... | Function call stack
+*| |
+*+-+
+*  low
+*
+*/
+
+   /* Save FP and LR registers to stay align with ARM64 AAPCS */
+   emit(A64_PUSH(A64_FP, A64_LR, A64_SP), ctx);
+
/* Save callee-saved register */
emit(A64_PUSH(r6, r7, A64_SP), ctx);
emit(A64_PUSH(r8, r9, A64_SP), ctx);
if (ctx->tmp_used)
emit(A64_PUSH(tmp1, tmp2, A64_SP), ctx);

-   /* Set up BPF stack */
-   emit(A64_SUB_I(1, A64_SP, A64_SP, stack_size), ctx);
-
-   /* Set up frame pointer */
+   /* Set up BPF prog stack base register (x25) */
emit(A64_MOV(1, fp, A64_SP), ctx);

+   /* Set up function call stack */
+   emit(A64_SUB_I(1, A64_SP, A64_SP, stack_size), ctx);
+   emit(A64_MOV(1, A64_FP, A64_SP), ctx);
+
/* Clear registers A and X */
emit_a64_mov_i64(ra, 0, ctx);
emit_a64_mov_i64(rx, 0, ctx);
@@ -196,8 +220,8 @@ static void build_epilogue(struct jit_ctx *ctx)
emit(A64_POP(r8, r9, A64_SP), ctx);
emit(A64_POP(r6, r7, A64_SP), ctx);

-   /* Restore frame pointer */
-   emit(A64_MOV(1, fp, A64_SP), ctx);
+   /* Restore FP/LR registers */
+   emit(A64_POP(A64_FP, A64_LR, A64_SP), ctx);

/* Set return value */
emit(A64_MOV(1, A64_R(0), r0), ctx);



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

[PATCH] arm64: bpf: fix JIT stack setup

[Yang Shi]

ARM64 JIT used FP (x29) as eBPF fp register, but FP is subjected to
change during function call so it may cause the BPF prog stack base address
change too. Whenever, it pointed to the bottom of BPF prog stack instead of
the top.

So, when copying data via bpf_probe_read, it will be copied to (SP - offset),
then it may overwrite the saved FP/LR.

Use x25 to replace FP as BPF stack base register (fp). Since x25 is callee
saved register, so it will keep intact during function call.
It is initialized in BPF prog prologue when BPF prog is started to run
everytime. When BPF prog exits, it could be just tossed.

Other than this the BPf prog stack base need to be setup before function
call stack.

So, the BPF stack layout looks like:

 high
 original A64_SP =>   0:+-+ BPF prologue
| | FP/LR and callee saved registers
 BPF fp register => +64:+-+
| |
| ... | BPF prog stack
| |
| |
 current A64_SP =>  +-+
| |
| ... | Function call stack
| |
+-+
  low

Signed-off-by: Yang Shi 
CC: Zi Shen Lim 
CC: Xi Wang 
---
 arch/arm64/net/bpf_jit_comp.c | 38 +++---
 1 file changed, 31 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c
index a44e529..6809647 100644
--- a/arch/arm64/net/bpf_jit_comp.c
+++ b/arch/arm64/net/bpf_jit_comp.c
@@ -50,7 +50,7 @@ static const int bpf2a64[] = {
[BPF_REG_8] = A64_R(21),
[BPF_REG_9] = A64_R(22),
/* read-only frame pointer to access stack */
-   [BPF_REG_FP] = A64_FP,
+   [BPF_REG_FP] = A64_R(25),
/* temporary register for internal BPF JIT */
[TMP_REG_1] = A64_R(23),
[TMP_REG_2] = A64_R(24),
@@ -155,18 +155,42 @@ static void build_prologue(struct jit_ctx *ctx)
stack_size += 4; /* extra for skb_copy_bits buffer */
stack_size = STACK_ALIGN(stack_size);
 
+   /*
+* BPF prog stack layout
+*
+* high
+* original A64_SP =>   0:+-+ BPF prologue
+*| | FP/LR and callee saved registers
+* BPF fp register => +64:+-+
+*| |
+ *| ... | BPF prog stack
+*| |
+*| |
+* current A64_SP =>  +-+
+*| |
+*| ... | Function call stack
+*| |
+*+-+
+*  low
+*
+*/
+
+   /* Save FP and LR registers to stay align with ARM64 AAPCS */
+   emit(A64_PUSH(A64_FP, A64_LR, A64_SP), ctx);
+
/* Save callee-saved register */
emit(A64_PUSH(r6, r7, A64_SP), ctx);
emit(A64_PUSH(r8, r9, A64_SP), ctx);
if (ctx->tmp_used)
emit(A64_PUSH(tmp1, tmp2, A64_SP), ctx);
 
-   /* Set up BPF stack */
-   emit(A64_SUB_I(1, A64_SP, A64_SP, stack_size), ctx);
-
-   /* Set up frame pointer */
+   /* Set up BPF prog stack base register (x25) */
emit(A64_MOV(1, fp, A64_SP), ctx);
 
+   /* Set up function call stack */
+   emit(A64_SUB_I(1, A64_SP, A64_SP, stack_size), ctx);
+   emit(A64_MOV(1, A64_FP, A64_SP), ctx);
+
/* Clear registers A and X */
emit_a64_mov_i64(ra, 0, ctx);
emit_a64_mov_i64(rx, 0, ctx);
@@ -196,8 +220,8 @@ static void build_epilogue(struct jit_ctx *ctx)
emit(A64_POP(r8, r9, A64_SP), ctx);
emit(A64_POP(r6, r7, A64_SP), ctx);
 
-   /* Restore frame pointer */
-   emit(A64_MOV(1, fp, A64_SP), ctx);
+   /* Restore FP/LR registers */
+   emit(A64_POP(A64_FP, A64_LR, A64_SP), ctx);
 
/* Set return value */
emit(A64_MOV(1, A64_R(0), r0), ctx);
-- 
2.0.2

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

[PATCH] arm64: bpf: fix JIT stack setup

[Yang Shi]

ARM64 JIT used FP (x29) as eBPF fp register, but FP is subjected to
change during function call so it may cause the BPF prog stack base address
change too. Whenever, it pointed to the bottom of BPF prog stack instead of
the top.

So, when copying data via bpf_probe_read, it will be copied to (SP - offset),
then it may overwrite the saved FP/LR.

Use x25 to replace FP as BPF stack base register (fp). Since x25 is callee
saved register, so it will keep intact during function call.
It is initialized in BPF prog prologue when BPF prog is started to run
everytime. When BPF prog exits, it could be just tossed.

Other than this the BPf prog stack base need to be setup before function
call stack.

So, the BPF stack layout looks like:

 high
 original A64_SP =>   0:+-+ BPF prologue
| | FP/LR and callee saved registers
 BPF fp register => +64:+-+
| |
| ... | BPF prog stack
| |
| |
 current A64_SP =>  +-+
| |
| ... | Function call stack
| |
+-+
  low

Signed-off-by: Yang Shi 
CC: Zi Shen Lim 
CC: Xi Wang 
---
 arch/arm64/net/bpf_jit_comp.c | 38 +++---
 1 file changed, 31 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c
index a44e529..6809647 100644
--- a/arch/arm64/net/bpf_jit_comp.c
+++ b/arch/arm64/net/bpf_jit_comp.c
@@ -50,7 +50,7 @@ static const int bpf2a64[] = {
[BPF_REG_8] = A64_R(21),
[BPF_REG_9] = A64_R(22),
/* read-only frame pointer to access stack */
-   [BPF_REG_FP] = A64_FP,
+   [BPF_REG_FP] = A64_R(25),
/* temporary register for internal BPF JIT */
[TMP_REG_1] = A64_R(23),
[TMP_REG_2] = A64_R(24),
@@ -155,18 +155,42 @@ static void build_prologue(struct jit_ctx *ctx)
stack_size += 4; /* extra for skb_copy_bits buffer */
stack_size = STACK_ALIGN(stack_size);
 
+   /*
+* BPF prog stack layout
+*
+* high
+* original A64_SP =>   0:+-+ BPF prologue
+*| | FP/LR and callee saved registers
+* BPF fp register => +64:+-+
+*| |
+ *| ... | BPF prog stack
+*| |
+*| |
+* current A64_SP =>  +-+
+*| |
+*| ... | Function call stack
+*| |
+*+-+
+*  low
+*
+*/
+
+   /* Save FP and LR registers to stay align with ARM64 AAPCS */
+   emit(A64_PUSH(A64_FP, A64_LR, A64_SP), ctx);
+
/* Save callee-saved register */
emit(A64_PUSH(r6, r7, A64_SP), ctx);
emit(A64_PUSH(r8, r9, A64_SP), ctx);
if (ctx->tmp_used)
emit(A64_PUSH(tmp1, tmp2, A64_SP), ctx);
 
-   /* Set up BPF stack */
-   emit(A64_SUB_I(1, A64_SP, A64_SP, stack_size), ctx);
-
-   /* Set up frame pointer */
+   /* Set up BPF prog stack base register (x25) */
emit(A64_MOV(1, fp, A64_SP), ctx);
 
+   /* Set up function call stack */
+   emit(A64_SUB_I(1, A64_SP, A64_SP, stack_size), ctx);
+   emit(A64_MOV(1, A64_FP, A64_SP), ctx);
+
/* Clear registers A and X */
emit_a64_mov_i64(ra, 0, ctx);
emit_a64_mov_i64(rx, 0, ctx);
@@ -196,8 +220,8 @@ static void build_epilogue(struct jit_ctx *ctx)
emit(A64_POP(r8, r9, A64_SP), ctx);
emit(A64_POP(r6, r7, A64_SP), ctx);
 
-   /* Restore frame pointer */
-   emit(A64_MOV(1, fp, A64_SP), ctx);
+   /* Restore FP/LR registers */
+   emit(A64_POP(A64_FP, A64_LR, A64_SP), ctx);
 
/* Set return value */
emit(A64_MOV(1, A64_R(0), r0), ctx);
-- 
2.0.2

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

Re: [RFC] namei: prevent sgid-hardlinks for unmapped gids

[Kees Cook]

On Fri, Nov 6, 2015 at 4:48 PM, Andy Lutomirski  wrote:
> On Fri, Nov 6, 2015 at 4:16 PM, Kees Cook  wrote:
>> On Fri, Nov 6, 2015 at 4:11 PM, Kees Cook  wrote:
>>> On Fri, Nov 6, 2015 at 2:30 PM, Andy Lutomirski  wrote:
 On Fri, Nov 6, 2015 at 1:59 PM, Kees Cook  wrote:
> Adding Ted, who might know how this all hooks together. (The context
> is that a write() or truncate() on a setgid file clears the setgid,
> but mmap writes don't.)
>
> On Wed, Nov 4, 2015 at 9:59 AM, Andy Lutomirski  
> wrote:
>> On Tue, Nov 3, 2015 at 10:58 PM, Willy Tarreau  wrote:
>>> On Tue, Nov 03, 2015 at 03:29:55PM -0800, Kees Cook wrote:
 Using "write" does kill the set-gid bit. I haven't looked at
 why.
 Al or anyone else, is there a meaningful distinction here?
>>>
>>> I remember this one, I got caught once while trying to put a shell into
>>> a suid-writable file to get some privileges someone forgot to offer me 
>>> :-)
>>>
>>> It's done by should_remove_suid() which is called upon write() and 
>>> truncate().
>
> file_remove_privs() seems to be the right entry point.
> __generic_file_write_iter in mm/filemap.c calls it, though. Are these
> callbacks not used for mmap writes?

 They're certainly not used early enough -- we need to remove suid when
 the page becomes writable via mmap (wp_page_shared), not when
 writeback happens, or at least not only when writeback happens.
>>>
>>> Well, I'm shy about the change there. For example, we don't strip in
>>> on open(RDWR), just on write().
>>
>> I take it back. Hooking wp_page_shared looks expensive. :) Maybe we do
>> need to hook the mmap?
>
> But file_update_time already pokes at the same (or nearby) cachelines,
> I think -- why would it be expensive?  The whole thing could be
> guarded by if (unlikely(is setuid)), right?

Yeah, true. I added file_remove_privs calls near all the
file_update_time calls, to no effect. Added to wp_page_shared too,
nothing. Hmmm.

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

[PATCH v2 0/3] pstore: resend three patches

[Geliang Tang]

I sent these patches a few weeks ago. Due to the recent changes in pstore,
these patched might not apply anymore. So I refresh and resend them.

---
Changes in v2:
 - refresh the patches.
---

Geliang Tang (3):
  pstore: check PSTORE_FLAGS_FRAGILE in pstore_unregister
  efi-pstore: implement efivars_pstore_exit()
  pstore: drop file opened reference count

 drivers/firmware/efi/efi-pstore.c | 7 +++
 fs/pstore/inode.c | 1 -
 fs/pstore/platform.c  | 9 ++---
 3 files changed, 13 insertions(+), 4 deletions(-)

-- 
2.5.0


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

[PATCH v2 2/3] efi-pstore: implement efivars_pstore_exit()

[Geliang Tang]

The original efivars_pstore_exit() is empty. I
 1) add a bufsize check statement.
 2) call pstore_unregister as it is defined now.
 3) free the memory and set bufsize to 0.

Signed-off-by: Geliang Tang 
---
 drivers/firmware/efi/efi-pstore.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/firmware/efi/efi-pstore.c 
b/drivers/firmware/efi/efi-pstore.c
index eac76a7..62d57d8 100644
--- a/drivers/firmware/efi/efi-pstore.c
+++ b/drivers/firmware/efi/efi-pstore.c
@@ -393,6 +393,13 @@ static __init int efivars_pstore_init(void)
 
 static __exit void efivars_pstore_exit(void)
 {
+   if (!efi_pstore_info.bufsize)
+   return;
+
+   pstore_unregister(_pstore_info);
+   kfree(efi_pstore_info.buf);
+   efi_pstore_info.buf = NULL;
+   efi_pstore_info.bufsize = 0;
 }
 
 module_init(efivars_pstore_init);
-- 
2.5.0


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

[PATCH v2 1/3] pstore: check PSTORE_FLAGS_FRAGILE in pstore_unregister

[Geliang Tang]

When PSTORE_FLAGS_FRAGILE flag is set, only kmsg is registered in
pstore_register. So, under these circumstances, only kmsg needs to
be unregistered in pstore_unregister.

Signed-off-by: Geliang Tang 
---
 fs/pstore/platform.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
index 588461b..5b8f1eb 100644
--- a/fs/pstore/platform.c
+++ b/fs/pstore/platform.c
@@ -497,9 +497,12 @@ EXPORT_SYMBOL_GPL(pstore_register);
 
 void pstore_unregister(struct pstore_info *psi)
 {
-   pstore_unregister_pmsg();
-   pstore_unregister_ftrace();
-   pstore_unregister_console();
+   if ((psi->flags & PSTORE_FLAGS_FRAGILE) == 0) {
+   pstore_unregister_pmsg();
+   pstore_unregister_ftrace();
+   pstore_unregister_console();
+   }
+
pstore_unregister_kmsg();
 
free_buf_for_compression();
-- 
2.5.0


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

[PATCH v2 3/3] pstore: drop file opened reference count

[Geliang Tang]

In my recent commit, I added '.owner = THIS_MODULE' in both
pstore_fs_type and pstore_file_operations to increase a reference count
when pstore filesystem is mounted and pstore file is opened.[1]

But, it's repetitive. There is no need to increase the opened reference
count. We only need to increase the mounted reference count. When a file
is opened, the filesystem can't be unmounted. Hence the pstore module
can't be unloaded either.

So I drop the opened reference count in this patch.

[1] https://lkml.org/lkml/2015/10/20/84

Signed-off-by: Geliang Tang 
---
Here is the reference count test:

$ sudo /sbin/insmod lib/zlib_deflate/zlib_deflate.ko
$ sudo /sbin/insmod fs/pstore/pstore.ko
$ lsmod
Module  Size  Used by
pstore 13301  0
zlib_deflate   20156  1 pstore

$ sudo mount -t pstore pstore /sys/fs/pstore
$ lsmod
Module  Size  Used by
pstore 13301  1
zlib_deflate   20156  1 pstore

$ sudo /sbin/insmod lib/reed_solomon/reed_solomon.ko
$ sudo /sbin/insmod fs/pstore/ramoops.ko mem_address=0x8000 
mem_size=0x4 ecc=1
$ lsmod
Module  Size  Used by
ramoops11156  0
reed_solomon5878  1 ramoops
pstore 13301  2 ramoops
zlib_deflate   20156  1 pstore

$ sudo rmmod ramoops
$ lsmod
Module  Size  Used by
reed_solomon5878  0
pstore 13301  1
zlib_deflate   20156  1 pstore

$ tail -f /sys/fs/pstore/console-ramoops-0 &
[1] 4479
$ lsmod
Module  Size  Used by
reed_solomon5878  0
pstore 13301  1
zlib_deflate   20156  1 pstore

$ sudo umount /sys/fs/pstore
umount: /sys/fs/pstore: target is busy
(In some cases useful info about processes that
 use the device is found by lsof(8) or fuser(1).)

$ kill -9 4479
[1]+  Killed  tail -f /sys/fs/pstore/console-ramoops-0
$ lsmod
Module  Size  Used by
reed_solomon5878  0
pstore 13301  1
zlib_deflate   20156  1 pstore

$ sudo umount /sys/fs/pstore
$ lsmod
Module  Size  Used by
reed_solomon5878  0
pstore 13301  0
zlib_deflate   20156  1 pstore

$ sudo rmmod pstore
$ lsmod
Module  Size  Used by
reed_solomon5878  0
zlib_deflate   20156  0
---
 fs/pstore/inode.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c
index d8c439d..ac6c78fe 100644
--- a/fs/pstore/inode.c
+++ b/fs/pstore/inode.c
@@ -178,7 +178,6 @@ static loff_t pstore_file_llseek(struct file *file, loff_t 
off, int whence)
 }
 
 static const struct file_operations pstore_file_operations = {
-   .owner  = THIS_MODULE,
.open   = pstore_file_open,
.read   = pstore_file_read,
.llseek = pstore_file_llseek,
-- 
2.5.0


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

Re: [PATCH] DWC Ethernet QoS: Delete an unnecessary check before the function call "of_node_put"

[David Miller]

From: SF Markus Elfring 
Date: Fri, 6 Nov 2015 08:15:30 +0100

> From: Markus Elfring 
> Date: Fri, 6 Nov 2015 08:00:22 +0100
> 
> The of_node_put() function tests whether its argument is NULL and then
> returns immediately. Thus the test around the call is not needed.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 

Please resubmit this with a more appropriate Subject line.

The subsystem prefix should be all lower-case and typically
indicate the most specific subsystem or area being changed.

In this case it's a driver, therefore simply use the driver
name "dwc_eth_qos: ".
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 0/3]perf/core: extend perf_reg and perf_sample_regs_intr

[Madhavan Srinivasan]

On Friday 06 November 2015 03:55 PM, Peter Zijlstra wrote:
> On Fri, Nov 06, 2015 at 09:04:00PM +1100, Michael Ellerman wrote:
>> It's a perrenial request from our hardware PMU folks to be able to see the 
>> raw
>> values of the PMU registers.
>>
>> I think partly it's so that they can verify that perf is doing what they 
>> want,
>> and some of it is that they're interested in some of the more obscure info 
>> that
>> isn't plumbed out through other perf interfaces.
>>
>> We've used various internal hacks over the years to keep them happy. This is 
>> an
>> attempt to use a somewhat standard mechanism.
>>
>> It would also be helpful for those of us working on the perf hardware 
>> backends,
>> to be able to verify that we're programming things correctly, without 
>> resorting
>> to debug printks etc.
>>
>> Basically we want to sample regs at the time of the perf interrupt, so we
>> though PERF_SAMPLE_REGS_INTR made senes :)
>>
>> But if you think this is the wrong mechanism within perf, then please let us
>> know.
>>
>> I know perf's mission is to abstract as much of the arcane hardware details
>> into a generic interface and make PMUs actually useful for normal folks, and 
>> we
>> are committed to that, but it would also be useful to be able to get the raw
>> values for a different type of user.
>>
>> Maddy's patch only exports PMC1-6 and MMCR0/1. I think we also need to export
>> some others, in particular MMCRA has a lot of stuff in it, half of which is 
>> not
>> even architected. So that would have to be exported as "POWER8_MMCRA". And 
>> then
>> there's the SIAR/SDAR/SIER which contain a bunch of info on sampled
>> instructions that is not currently plumbed out.
> OK, no objections then. But this is useful information and should be
> included in the patch set.
>

Sure. Will add the information in the next version.

Maddy


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

Re: [RFC PATCH 0/3]perf/core: extend perf_reg and perf_sample_regs_intr

[Madhavan Srinivasan]

On Friday 06 November 2015 03:34 PM, Michael Ellerman wrote:
> On Fri, 2015-11-06 at 10:24 +0100, Peter Zijlstra wrote:
>> On Fri, Nov 06, 2015 at 12:57:17PM +0530, Madhavan Srinivasan wrote:
>>> On Thursday 05 November 2015 06:37 PM, Peter Zijlstra wrote:
 On Thu, Nov 05, 2015 at 02:16:15AM +0530, Madhavan Srinivasan wrote:
> Second patch updates struct arch_misc_reg for arch/powerpc with pmu 
> registers
> and adds offsetof macro for the same. It extends perf_reg_value()
> to use reg idx to decide on struct to return value from.
 Why; what's in those regs?
>>> Was out and did not have access to mail, so missed to respond in time.
>>>
>>> In current implementation of patch 2, have added 
>>> few pmu control/status and counter registers,
>>> which give additional information about the PMU context
>>> for the sample.
>> Yes, I saw that, you still haven't answered the question though. What is
>> in those regs? Why is exposing that information like this the best
>> option.
> It's a perrenial request from our hardware PMU folks to be able to see the raw
> values of the PMU registers.
>
> I think partly it's so that they can verify that perf is doing what they want,
> and some of it is that they're interested in some of the more obscure info 
> that
> isn't plumbed out through other perf interfaces.
>
> We've used various internal hacks over the years to keep them happy. This is 
> an
> attempt to use a somewhat standard mechanism.
>
> It would also be helpful for those of us working on the perf hardware 
> backends,
> to be able to verify that we're programming things correctly, without 
> resorting
> to debug printks etc.
>
> Basically we want to sample regs at the time of the perf interrupt, so we
> though PERF_SAMPLE_REGS_INTR made senes :)
>
> But if you think this is the wrong mechanism within perf, then please let us
> know.
>
> I know perf's mission is to abstract as much of the arcane hardware details
> into a generic interface and make PMUs actually useful for normal folks, and 
> we
> are committed to that, but it would also be useful to be able to get the raw
> values for a different type of user.
>
> Maddy's patch only exports PMC1-6 and MMCR0/1. I think we also need to export
> some others, in particular MMCRA has a lot of stuff in it, half of which is 
> not
> even architected. So that would have to be exported as "POWER8_MMCRA". And 
> then
> there's the SIAR/SDAR/SIER which contain a bunch of info on sampled
> instructions that is not currently plumbed out.

Sure. I will rework the patch to include the other regs also.

Maddy

>
> cheers
>

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

Re: [ANNOUNCE]: SCST 3.1 pre-release freeze

[Vladislav Bolkhovitin]

Hi,

Bike & Snow wrote on 11/06/2015 10:55 AM:
> Hello Vlad
> 
> Excellent news on all the updates.
> 
> Regarding this:
> - QLogic target driver has been significantly improved.
> 
> Does that mean I should stop building the QLogic target driver from here?
> git://git.qlogic.com/scst-qla2xxx.git 
> 
> Or are you saying the git.qlogic.com  has been 
> improved?

It is saying that qla2x00t was improved.

The ultimate goal is to have the mainstream (git) QLogic target driver to be 
the main
and the only QLogic target driver, but, unfortunately, this driver not yet 
reached
level of quality and maturity of qla2x00t. We with QLogic are working toward it.

> If I stop building the one from git.qlogic.com , does 
> the 3.2.0
> one support NPIV?

Yes, it has full NPIV support.

Vlad

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

Re: [PATCH 1/3] staging: rtl8188eu: goto replaced by 'else' branch

[Ivan Safonov]

On 11/07/2015 10:14 AM, Greg Kroah-Hartman wrote:

On Fri, Nov 06, 2015 at 10:17:29PM +0700, Ivan Safonov wrote:

goto is not needed here.

Signed-off-by: Ivan Safonov 
---
  drivers/staging/rtl8188eu/core/rtw_cmd.c | 25 +++--
  1 file changed, 11 insertions(+), 14 deletions(-)


I've applied most of these patches, but I got a bit confused about what
order for some of these.  Can you please look at what I applied and
resend what I missed, in a single set of patches that are properly
numbered so I have a chance to get it right?

thanks,

greg k-h


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

[PATCH 2/2] rtc: efi: add efi_procfs in efi_rtc_ops

[Geliang Tang]

Add efi_procfs in efi_rtc_ops to show rtc-efi info in /proc/driver/rtc.
Most of the code comes from efi_rtc_proc_show() in efirtc.

Signed-off-by: Geliang Tang 
---
 drivers/rtc/rtc-efi.c | 66 +++
 1 file changed, 62 insertions(+), 4 deletions(-)

diff --git a/drivers/rtc/rtc-efi.c b/drivers/rtc/rtc-efi.c
index 3806961..96d3860 100644
--- a/drivers/rtc/rtc-efi.c
+++ b/drivers/rtc/rtc-efi.c
@@ -191,11 +191,69 @@ static int efi_set_time(struct device *dev, struct 
rtc_time *tm)
return status == EFI_SUCCESS ? 0 : -EINVAL;
 }
 
+static int efi_procfs(struct device *dev, struct seq_file *seq)
+{
+   efi_time_t  eft, alm;
+   efi_time_cap_t  cap;
+   efi_bool_t  enabled, pending;
+
+   memset(, 0, sizeof(eft));
+   memset(, 0, sizeof(alm));
+   memset(, 0, sizeof(cap));
+
+   efi.get_time(, );
+   efi.get_wakeup_time(, , );
+
+   seq_printf(seq,
+  "Time\t\t: %u:%u:%u.%09u\n"
+  "Date\t\t: %u-%u-%u\n"
+  "Daylight\t: %u\n",
+  eft.hour, eft.minute, eft.second, eft.nanosecond,
+  eft.year, eft.month, eft.day,
+  eft.daylight);
+
+   if (eft.timezone == EFI_UNSPECIFIED_TIMEZONE)
+   seq_puts(seq, "Timezone\t: unspecified\n");
+   else
+   /* XXX fixme: convert to string? */
+   seq_printf(seq, "Timezone\t: %u\n", eft.timezone);
+
+   seq_printf(seq,
+  "Alarm Time\t: %u:%u:%u.%09u\n"
+  "Alarm Date\t: %u-%u-%u\n"
+  "Alarm Daylight\t: %u\n"
+  "Enabled\t\t: %s\n"
+  "Pending\t\t: %s\n",
+  alm.hour, alm.minute, alm.second, alm.nanosecond,
+  alm.year, alm.month, alm.day,
+  alm.daylight,
+  enabled == 1 ? "yes" : "no",
+  pending == 1 ? "yes" : "no");
+
+   if (eft.timezone == EFI_UNSPECIFIED_TIMEZONE)
+   seq_puts(seq, "Timezone\t: unspecified\n");
+   else
+   /* XXX fixme: convert to string? */
+   seq_printf(seq, "Timezone\t: %u\n", alm.timezone);
+
+   /*
+* now prints the capabilities
+*/
+   seq_printf(seq,
+  "Resolution\t: %u\n"
+  "Accuracy\t: %u\n"
+  "SetstoZero\t: %u\n",
+  cap.resolution, cap.accuracy, cap.sets_to_zero);
+
+   return 0;
+}
+
 static const struct rtc_class_ops efi_rtc_ops = {
-   .read_time = efi_read_time,
-   .set_time = efi_set_time,
-   .read_alarm = efi_read_alarm,
-   .set_alarm = efi_set_alarm,
+   .read_time  = efi_read_time,
+   .set_time   = efi_set_time,
+   .read_alarm = efi_read_alarm,
+   .set_alarm  = efi_set_alarm,
+   .proc   = efi_procfs,
 };
 
 static int __init efi_rtc_probe(struct platform_device *dev)
-- 
2.5.0


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

[PATCH 1/2] rtc: fix module reference count in rtc-proc

[Geliang Tang]

rtc-proc.c is not built as a module. Thus, rather than dealing with
THIS_MODULE's reference count, we should deal with rtc->owner's
reference count.

Signed-off-by: Geliang Tang 
---
 drivers/rtc/rtc-proc.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/rtc/rtc-proc.c b/drivers/rtc/rtc-proc.c
index ffa69e1..31e7e23 100644
--- a/drivers/rtc/rtc-proc.c
+++ b/drivers/rtc/rtc-proc.c
@@ -112,19 +112,21 @@ static int rtc_proc_open(struct inode *inode, struct file 
*file)
int ret;
struct rtc_device *rtc = PDE_DATA(inode);
 
-   if (!try_module_get(THIS_MODULE))
+   if (!try_module_get(rtc->owner))
return -ENODEV;
 
ret = single_open(file, rtc_proc_show, rtc);
if (ret)
-   module_put(THIS_MODULE);
+   module_put(rtc->owner);
return ret;
 }
 
 static int rtc_proc_release(struct inode *inode, struct file *file)
 {
int res = single_release(inode, file);
-   module_put(THIS_MODULE);
+   struct rtc_device *rtc = PDE_DATA(inode);
+
+   module_put(rtc->owner);
return res;
 }
 
-- 
2.5.0


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

Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy

[David Miller]

From: Michal Hocko 
Date: Fri, 6 Nov 2015 17:46:57 +0100

> On Fri 06-11-15 11:19:53, Johannes Weiner wrote:
>> You might think sending these emails is helpful, but it really
>> isn't. Not only is it not contributing code, insights, or solutions,
>> you're now actively sabotaging someone else's effort to build something.
> 
> Come on! Are you even serious?

He is, and I agree %100 with him FWIW.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT] Sparc

[Julian Calaby]

Hi Julia,

On Fri, Nov 6, 2015 at 5:44 PM, Julia Lawall  wrote:
> On Fri, 6 Nov 2015, Julian Calaby wrote:
>
>> Hi Linus,
>>
>> On Fri, Nov 6, 2015 at 11:56 AM, Linus Torvalds
>>  wrote:
>> > On Thu, Nov 5, 2015 at 4:43 PM, Linus Torvalds
>> >  wrote:
>> >>
>> >> Not that this *matters*, but it's a bit odd to have to cast constants
>> >> to perfectly regular C types.
>> >
>> > Looking around with "git grep", there's a few more of these.
>> >
>> >  - btrfs seems to like "(unsigned long)-1"
>> >
>> >There's a few other users of that too, including more sparc uses.
>> >
>> >  - scsi/qla seems to like "(unsigned long)"
>> >
>> >  - fmdrv_common.h seems to like "((unsigned long)1<> >
>> > along with a smattering of random noise all over of "(unsigned long)
>> > n" where 'n' is some integer.
>> >
>> > Apparently people aren't as aware of the normal "ul" postfix syntax as
>> > I would have expected. That said, it's a hundred-odd cases in all of
>> > the kernel, so it's still fairly rare.
>>
>> Maybe this is something the kernel-janitors team should look at? (CC'd)
>
> Do you have some concrete examples of the code that is undesirable?

Joe Perches produced a patch for checkpatch to check for this [1]

Linus was complaining [2] about people producing constants with casts
to basic C types in them. For instance:

#define IOMMU_ERROR_CODE (~(unsigned long) 0)

This could be replaced with

#define IOMMU_ERROR_CODE (~0ul)

or potentially

#define IOMMU_ERROR_CODE (-1ul)

It's not overly common, but it looks wrong.

Thanks,

Julian Calaby

[1] https://lkml.org/lkml/2015/11/6/48
[2] https://lkml.org/lkml/2015/11/5/785

-- 
Julian Calaby

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

[PATCH] of: Provide static inline function for of_translate_address if needed

[Guenter Roeck]

If OF_ADDRESS is not configured, builds can fail with errors such as

drivers/net/ethernet/hisilicon/hns_mdio.c:
In function 'hns_mdio_bus_name':
drivers/net/ethernet/hisilicon/hns_mdio.c:411:3:
error: implicit declaration of function 'of_translate_address'

as currently seen when building sparc:allmodconfig.

Introduce a static inline function if OF_ADDRESS is not configured to fix
the build failure. Return OF_BAD_ADDR in this case. For this to work, the
definition of OF_BAD_ADDR has to be moved outside CONFIG_OF conditional
code.

Fixes: 876133d3161d ("net: hisilicon: add OF dependency")
Cc: Arnd Bergmann 
Signed-off-by: Guenter Roeck 
---
 include/linux/of.h | 4 ++--
 include/linux/of_address.h | 7 +++
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/include/linux/of.h b/include/linux/of.h
index 2194b8ca41f9..dd10626a615f 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -126,6 +126,8 @@ extern raw_spinlock_t devtree_lock;
 #define OF_POPULATED   3 /* device already created for the node */
 #define OF_POPULATED_BUS   4 /* of_platform_populate recursed to children 
of this node */
 
+#define OF_BAD_ADDR((u64)-1)
+
 #ifdef CONFIG_OF
 void of_core_init(void);
 
@@ -229,8 +231,6 @@ static inline unsigned long of_read_ulong(const __be32 
*cell, int size)
 #define OF_IS_DYNAMIC(x) test_bit(OF_DYNAMIC, >_flags)
 #define OF_MARK_DYNAMIC(x) set_bit(OF_DYNAMIC, >_flags)
 
-#define OF_BAD_ADDR((u64)-1)
-
 static inline const char *of_node_full_name(const struct device_node *np)
 {
return np ? np->full_name : "";
diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index d88e81be6368..507daad0bc8d 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -57,6 +57,13 @@ extern int of_dma_get_range(struct device_node *np, u64 
*dma_addr,
u64 *paddr, u64 *size);
 extern bool of_dma_is_coherent(struct device_node *np);
 #else /* CONFIG_OF_ADDRESS */
+
+static inline u64 of_translate_address(struct device_node *np,
+  const __be32 *addr)
+{
+   return OF_BAD_ADDR;
+}
+
 static inline struct device_node *of_find_matching_node_by_address(
struct device_node *from,
const struct of_device_id *matches,
-- 
2.1.4

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

Re: [PATCH] staging: lustre: remove IOC_LIBCFS_PING_TEST ioctl

[Greg Kroah-Hartman]

On Fri, Nov 06, 2015 at 09:08:03PM -0500, y...@ccs.ornl.gov wrote:
> From: James Simmons 
> 
> The ioctl IOC_LIBCFS_PING_TEST has not been used in
> ages. The recent nidstring changes which moved all
> the nidstring operations from libcfs to the LNet
> layer but this ioctl code was still using an
> nidstring operation that was causing an circular
> dependency loop between libcfs and LNet.
> 
> Signed-off-by: James Simmons 
> ---
>  .../lustre/include/linux/libcfs/libcfs_ioctl.h |1 -
>  drivers/staging/lustre/lustre/libcfs/module.c  |   17 -
>  2 files changed, 0 insertions(+), 18 deletions(-)

You sent me 2 copies of this, which am I supposed to apply?  I've
dropped both, please resend the correct one.

thanks,

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

RE....I need your assistance

[Sgt]

I am desperately in need of your assistance. Please get back to me


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

Re: [PATCH 1/3] staging: rtl8188eu: goto replaced by 'else' branch

[Greg Kroah-Hartman]

On Fri, Nov 06, 2015 at 10:17:29PM +0700, Ivan Safonov wrote:
> goto is not needed here.
> 
> Signed-off-by: Ivan Safonov 
> ---
>  drivers/staging/rtl8188eu/core/rtw_cmd.c | 25 +++--
>  1 file changed, 11 insertions(+), 14 deletions(-)
> 

I've applied most of these patches, but I got a bit confused about what
order for some of these.  Can you please look at what I applied and
resend what I missed, in a single set of patches that are properly
numbered so I have a chance to get it right?

thanks,

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

Re: [rtc-linux] Re: [PATCH v5 1/4] dt-bindings: mfd: s2mps11: add documentation for s2mps15 PMIC

[Krzysztof Kozlowski]

W dniu 07.11.2015 o 07:33, Rob Herring pisze:
> On Fri, Oct 30, 2015 at 11:55:31AM +0530, Alim Akhtar wrote:
>> From: Thomas Abraham 
>>
>> Add dt-binding documentation for s2mps15 PMIC device. The s2mps15 device
>> is similar to s2mps11/14 PMIC device and has 27 LDO and 10 buck regulators.
>> This also supports RTC and three 32.768KHz clock outputs.
>>
>> Cc: devicet...@vger.kernel.org
>> Signed-off-by: Thomas Abraham 
>> Signed-off-by: Alim Akhtar 
>> ---
>>  Documentation/devicetree/bindings/mfd/s2mps11.txt |   21 
>> ++---
>>  1 file changed, 14 insertions(+), 7 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt 
>> b/Documentation/devicetree/bindings/mfd/s2mps11.txt
>> index 890f0b0e1643..4c0543ceec25 100644
>> --- a/Documentation/devicetree/bindings/mfd/s2mps11.txt
>> +++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt
>> @@ -1,5 +1,5 @@
>>  
>> -* Samsung S2MPS11, S2MPS13, S2MPS14 and S2MPU02 Voltage and Current 
>> Regulator
>> +* Samsung S2MPS11/13/14/15 and S2MPU02 Voltage and Current Regulator
>>  
>>  The Samsung S2MPS11 is a multi-function device which includes voltage and
>>  current regulators, RTC, charger controller and other sub-blocks. It is
>> @@ -7,8 +7,12 @@ interfaced to the host controller using an I2C interface. 
>> Each sub-block is
>>  addressed by the host system using different I2C slave addresses.
>>  
>>  Required properties:
>> -- compatible: Should be "samsung,s2mps11-pmic" or "samsung,s2mps13-pmic"
>> -  or "samsung,s2mps14-pmic" or "samsung,s2mpu02-pmic".
>> +- compatible: Should be one of the following
>> +- "samsung,s2mps11-pmic"
>> +- "samsung,s2mps13-pmic"
>> +- "samsung,s2mps14-pmic"
>> +- "samsung,s2mps15-pmic"
>> +- "samsung,s2mpu02-pmic".
>>  - reg: Specifies the I2C slave address of the pmic block. It should be 0x66.
>>  
>>  Optional properties:
>> @@ -24,7 +28,7 @@ Optional properties:
>>unwanted buck warm reset (setting buck voltages to default values).
>>  
>>  Optional nodes:
>> -- clocks: s2mps11, s2mps13 and s5m8767 provide three(AP/CP/BT) buffered 
>> 32.768
>> +- clocks: s2mps11, s2mps13, s2mps15 and s5m8767 provide three(AP/CP/BT) 
>> buffered 32.768
> 
> s5m8767 doesn't seem to be documented. Can you please fix or remove.

What exactly do you have in mind?

The s5m8767-clk is already documented as part of clk-s2mps11.c driver:
Documentation/devicetree/bindings/mfd/s2mps11.txt

The main s5m8767 MFD driver is documented as part of regulator driver:
Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt

Yes, this may be confusing... They S2M and S5M family devices share:
 - main mfd driver,
 - rtc driver,
 - clk driver.

but regulator drivers are separate.

Best regards,
Krzysztof

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

Re: [PATCH 4.2 000/110] 4.2.6-stable review

[Greg Kroah-Hartman]

On Fri, Nov 06, 2015 at 07:53:08PM -0700, Shuah Khan wrote:
> On 11/06/2015 12:18 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.2.6 release.
> > There are 110 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sun Nov  8 19:16:22 UTC 2015.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.2.6-rc1.gz
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> 
> Compiled and booted on my test system. No dmesg regressions.

Thanks for testing all of these and letting me know.

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

Re: [BUG, PATCH 03/10] sysfs: added __compat_only_sysfs_link_entry_to_kobj()

[Jeremiah Mahler]

Jarkko,

On Fri, Oct 16, 2015 at 09:40:22PM +0300, Jarkko Sakkinen wrote:
> Added a new function __compat_only_sysfs_link_group_to_kobj() that adds
> a symlink from attribute or group to a kobject. This needed for
> maintaining backwards compatibility with PPI attributes in the TPM
> driver.
> 
> Signed-off-by: Jarkko Sakkinen 
> ---
>  fs/sysfs/group.c  | 44 
>  include/linux/sysfs.h | 11 +++
>  2 files changed, 55 insertions(+)
> 
> diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
> index 39a0199..e123659 100644
> --- a/fs/sysfs/group.c
> +++ b/fs/sysfs/group.c
> @@ -352,3 +352,47 @@ void sysfs_remove_link_from_group(struct kobject *kobj, 
> const char *group_name,
>   }
>  }
>  EXPORT_SYMBOL_GPL(sysfs_remove_link_from_group);
> +
> +/**
> + * __compat_only_sysfs_link_entry_to_kobj - add a symlink to a kobject 
> pointing
> + * to a group or an attribute
> + * @kobj:The kobject containing the group.
> + * @target_kobj: The target kobject.
> + * @target_name: The name of the target group or attribute.
> + */
> +int __compat_only_sysfs_link_entry_to_kobj(struct kobject *kobj,
> +   struct kobject *target_kobj,
> +   const char *target_name)
> +{
> + struct kernfs_node *target;
> + struct kernfs_node *entry;
> + struct kernfs_node *link;
> +
> + /*
> +  * We don't own @target_kobj and it may be removed at any time.
> +  * Synchronize using sysfs_symlink_target_lock. See sysfs_remove_dir()
> +  * for details.
> +  */
> + spin_lock(_symlink_target_lock);
> + target = target_kobj->sd;
> + if (target)
> + kernfs_get(target);
> + spin_unlock(_symlink_target_lock);
> + if (!target)
> + return -ENOENT;
> +
> + entry = kernfs_find_and_get(target_kobj->sd, target_name);
> + if (!entry) {
> + kernfs_put(target);
> + return -ENOENT;
> + }
> +

On an Acer C720 this call to kernfs_find_and_get fails resulting in
a failed resume after suspend.

Apparently it can't find an object for the name "ppi".

This bug does not appear until the next patch is applied which
calls __compat_only_sysfs_link_entry_to_kobj.

[...]

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

Re: [PATCH 3.10 00/24] 3.10.93-stable review

[Shuah Khan]

On 11/06/2015 12:24 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.10.93 release.
> There are 24 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sun Nov  8 19:23:41 UTC 2015.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.10.93-rc1.gz
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

-- 
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shua...@osg.samsung.com | (970) 217-8978
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4.1 00/86] 4.1.13-stable review

[Shuah Khan]

On 11/06/2015 12:21 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.1.13 release.
> There are 86 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sun Nov  8 19:21:32 UTC 2015.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.1.13-rc1.gz
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah


-- 
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shua...@osg.samsung.com | (970) 217-8978
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3.14 00/37] 3.14.57-stable review

[Shuah Khan]

On 11/06/2015 12:24 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.14.57 release.
> There are 37 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sun Nov  8 19:23:35 UTC 2015.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.14.57-rc1.gz
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah


-- 
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shua...@osg.samsung.com | (970) 217-8978
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG, bisect, PATCH 04/10] tpm: move the PPI attributes to character device directory.

[Jeremiah Mahler]

Jarkko,

On Wed, Nov 04, 2015 at 10:17:05AM -0800, Jeremiah Mahler wrote:
> Jarkko, all,
> 
> On Fri, Oct 16, 2015 at 09:40:23PM +0300, Jarkko Sakkinen wrote:
> > Moved PPI attributes to the character device directory. This aligns with
> > the sysfs guidelines and makes them race free because they are created
> > atomically with the character device as part of device_register().The
> > character device and the sysfs attributes appear at the same time to the
> > user space.
> > 
> > As part of this change we enable PPI attributes also for TPM 2.0
> > devices. In order to retain backwards compatibility with TPM 1.x
> > devices, a symlink is created to the platform device directory.
> > 
> > Signed-off-by: Jarkko Sakkinen 
> > Reviewed-by: Jason Gunthorpe 
> > Tested-by: Mimi Zohar  (on TPM 1.2)
> > Tested-by: Chris J Arges 
> > Tested-by: Colin Ian King 
> > ---
> >  drivers/char/tpm/tpm-chip.c | 24 
> >  drivers/char/tpm/tpm.h  | 17 ++---
> >  drivers/char/tpm/tpm_ppi.c  | 34 +++---
> >  3 files changed, 33 insertions(+), 42 deletions(-)
> > 
[...]
> > @@ -225,10 +220,20 @@ int tpm_chip_register(struct tpm_chip *chip)
> > if (rc)
> > return rc;
> >  
> > +   tpm_add_ppi(chip);
> > +
> > rc = tpm_dev_add_device(chip);
> > if (rc)
> > goto out_err;
> >  
> > +   if (!(chip->flags & TPM_CHIP_FLAG_TPM2)) {
> > +   rc = __compat_only_sysfs_link_entry_to_kobj(>pdev->kobj,
> > +   >dev.kobj,
> > +   "ppi");
> > +   if (rc)
> > +   goto out_err;
> > +   }
> > +

This new call to __compat_only_sysfs_link_entry_to_kobj fails on an Acer
C720 due to a failed call to kernfs_find_and_get (discussed in a second
message).

[...]
> 
> The commit for this patch (9b774d5cf2db4) present in the latest
> linux-next (20151101+) breaks suspend/resume on an Acer C720 Chromebook.
> The computer will successfully suspend but when a resume is attempted
> a blank screen is displayed for a few seconds and then it reboots.
> 
> -- 
> - Jeremiah Mahler

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

Re: [PATCH 4.2 000/110] 4.2.6-stable review

[Shuah Khan]

On 11/06/2015 12:18 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.2.6 release.
> There are 110 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sun Nov  8 19:16:22 UTC 2015.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.2.6-rc1.gz
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah


-- 
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shua...@osg.samsung.com | (970) 217-8978
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4.2 000/110] 4.2.6-stable review

[Greg Kroah-Hartman]

On Fri, Nov 06, 2015 at 05:45:29PM -0800, Guenter Roeck wrote:
> On 11/06/2015 11:18 AM, Greg Kroah-Hartman wrote:
> >This is the start of the stable review cycle for the 4.2.6 release.
> >There are 110 patches in this series, all will be posted as a response
> >to this one.  If anyone has any issues with these being applied, please
> >let me know.
> >
> >Responses should be made by Sun Nov  8 19:16:22 UTC 2015.
> >Anything received after that time might be too late.
> >
> 
> Build results:
>   total: 144 pass: 144 fail: 0
> Qemu test results:
>   total: 94 pass: 94 fail: 0
> 
> Details are available at http://server.roeck-us.net:8010/builders.

Thanks for testing all of these and letting me know.

I'm still working on generating a git tree with these patches, hopefully
that happens in a week or so.

thanks,

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

Re: [PATCH] lustre: obdclass: fix sparse warning

[Greg KH]

On Sun, Nov 01, 2015 at 02:12:29PM +0530, Paul Davies C wrote:
> Fix the following warning given by sparse:
> 
> drivers/staging/lustre/lustre/obdclass/cl_lock.c:690:5: warning: symbol 
> 'cl_lock_mutex_try' was not declared. Should it be static?
> 
> Signed-off-by: Paul Davies C 
> ---
>  drivers/staging/lustre/lustre/obdclass/cl_lock.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/lustre/lustre/obdclass/cl_lock.c 
> b/drivers/staging/lustre/lustre/obdclass/cl_lock.c
> index 5621beb..6f83452 100644
> --- a/drivers/staging/lustre/lustre/obdclass/cl_lock.c
> +++ b/drivers/staging/lustre/lustre/obdclass/cl_lock.c
> @@ -687,7 +687,7 @@ EXPORT_SYMBOL(cl_lock_mutex_get);
>   *
>   * \see cl_lock_mutex_get()
>   */
> -int cl_lock_mutex_try(const struct lu_env *env, struct cl_lock *lock)
> +static int cl_lock_mutex_try(const struct lu_env *env, struct cl_lock *lock)
>  {
>   int result;
>  

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

Re: [PATCH] staging: lustre: lnet: selftest: Move extern declarations to headers

[Greg KH]

On Fri, Nov 06, 2015 at 02:04:21AM +0530, Amitoj Kaur Chawla wrote:
> This patch moves extern declarations to respective header files.
> 
> This patch also removes extern keyword from function declarations
> since functions have the extern specifier by default.
> 
> Signed-off-by: Amitoj Kaur Chawla 

Doesn't apply to my staging-testing branch anymore due to patches send
before yours :(

Please refresh it and resend.

thanks,

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

Re: [PATCH v4] sched: fix incorrect wait time and wait count statistics

[Joonwoo Park]

On Fri, Nov 06, 2015 at 02:57:49PM +0100, Peter Zijlstra wrote:
> On Tue, Oct 27, 2015 at 09:46:53PM -0700, Joonwoo Park wrote:
> > @@ -1272,6 +1272,15 @@ void set_task_cpu(struct task_struct *p, unsigned 
> > int new_cpu)
> > WARN_ON_ONCE(p->state != TASK_RUNNING && p->state != TASK_WAKING &&
> > !p->on_rq);
> >  
> > +   /*
> > +* Migrating fair class task must have p->on_rq = TASK_ON_RQ_MIGRATING,
> > +* because schedstat_wait_{start,end} rebase migrating task's wait_start
> > +* time relying on p->on_rq.
> > +*/
> > +   WARN_ON_ONCE(p->state == TASK_RUNNING &&
> > +p->sched_class == _sched_class &&
> > +(p->on_rq && !task_on_rq_migrating(p)));
> > +
> 
> Why do we have to test p->on_rq? Would not ->state == RUNNING imply
> that?
> 

sched_fork() sets p->state = RUNNING before changing task cpu.
Please let me know if you got better idea.

> > +++ b/kernel/sched/fair.c
> > @@ -737,41 +737,69 @@ static void update_curr_fair(struct rq *rq)
> > update_curr(cfs_rq_of(>curr->se));
> >  }
> >  
> > +#ifdef CONFIG_SCHEDSTATS
> >  static inline void
> >  update_stats_wait_start(struct cfs_rq *cfs_rq, struct sched_entity *se)
> >  {
> > +   u64 wait_start = rq_clock(rq_of(cfs_rq));
> >  
> > +   if (entity_is_task(se) && task_on_rq_migrating(task_of(se)) &&
> > +   likely(wait_start > se->statistics.wait_start))
> > +   wait_start -= se->statistics.wait_start;
> > +
> > +   schedstat_set(se->statistics.wait_start, wait_start);
> >  }
> >  
> >  static void
> >  update_stats_wait_end(struct cfs_rq *cfs_rq, struct sched_entity *se)
> >  {
> 
> Since this is now all under CONFIG_SCHEDSTAT, would it not make sense
> to do something like:
> 
>   u64 now = rq_clock(rq_of(cfs_rq));
> 
> to avoid the endless calling of that function?
> 
> Also, for that very same reason; would it not make sense to drop the
> schedstat_set() usage below, that would greatly enhance readability.
> 

Agreed.

> > +   if (entity_is_task(se) && task_on_rq_migrating(task_of(se))) {
> > +   /*
> > +* Preserve migrating task's wait time so wait_start time stamp
> > +* can be adjusted to accumulate wait time prior to migration.
> > +*/
> > +   schedstat_set(se->statistics.wait_start,
> > + rq_clock(rq_of(cfs_rq)) -
> > + se->statistics.wait_start);
> > +   return;
> > +   }
> > +
> > schedstat_set(se->statistics.wait_max, max(se->statistics.wait_max,
> > rq_clock(rq_of(cfs_rq)) - se->statistics.wait_start));
> > schedstat_set(se->statistics.wait_count, se->statistics.wait_count + 1);
> > schedstat_set(se->statistics.wait_sum, se->statistics.wait_sum +
> > rq_clock(rq_of(cfs_rq)) - se->statistics.wait_start);
> > +
> > if (entity_is_task(se)) {
> > trace_sched_stat_wait(task_of(se),
> > rq_clock(rq_of(cfs_rq)) - se->statistics.wait_start);
> > }
> 
> Is there no means of collapsing the two 'entity_is_task()' branches?
> 

Agreed.  Will spin v5 with these clean up.

Thanks,
Joonwoo

> > schedstat_set(se->statistics.wait_start, 0);
> >  }
> > +#else
> > +static inline void
> > +update_stats_wait_start(struct cfs_rq *cfs_rq, struct sched_entity *se)
> > +{
> > +}
> > +
> > +static inline void
> > +update_stats_wait_end(struct cfs_rq *cfs_rq, struct sched_entity *se)
> > +{
> > +}
> > +#endif

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Staging: wilc1000: Declare *wilc in init_wilc_driver to fix build error

[Greg KH]

On Sat, Nov 07, 2015 at 03:29:23AM +0530, Punit Vara wrote:
> This patch is to the linux_wlan.c file that fixes declaration of *wilc
> to remove following error while building it.
> 
> make drivers/staging/wilc1000/linux_wlan.o
> drivers/staging/wilc1000/linux_wlan.c:1824:24: error: ‘wilc’ undeclared
> 
> Signed-off-by: Punit Vara 
> ---
>  drivers/staging/wilc1000/linux_wlan.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/staging/wilc1000/linux_wlan.c 
> b/drivers/staging/wilc1000/linux_wlan.c
> index 2a5b36f..0805050 100644
> --- a/drivers/staging/wilc1000/linux_wlan.c
> +++ b/drivers/staging/wilc1000/linux_wlan.c
> @@ -1780,6 +1780,7 @@ int wilc_netdev_init(struct wilc **wilc)
>  /*The 1st function called after module inserted*/
>  static int __init init_wilc_driver(void)
>  {
> + struct wilc *wilc;
>  #ifdef WILC_SPI
>   struct wilc *wilc;
>  #endif

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

Re: [lustre-devel] [PATCH 07/10] staging: lustre: Handle nodemask on UMP machines

[Greg Kroah-Hartman]

On Fri, Nov 06, 2015 at 10:18:17PM +, Simmons, James A. wrote:
> >All warnings (new ones prefixed by >>):
> >
> >   In file included from include/linux/bitops.h:36:0,
> >from 
> > drivers/staging/lustre/lustre/libcfs/../../include/linux/libcfs/linux/libcfs.h:44,
> >from 
> > drivers/staging/lustre/lustre/libcfs/../../include/linux/libcfs/libcfs.h:40,
> >from 
> > drivers/staging/lustre/lustre/libcfs/libcfs_cpu.c:38:
> >   drivers/staging/lustre/lustre/libcfs/libcfs_cpu.c: In function 
> > 'cfs_cpt_table_alloc':
> >>> arch/m68k/include/asm/bitops.h:64:5: warning: passing argument 2 of 
> >>> 'bset_mem_set_bit' from incompatible pointer type
> >bset_mem_set_bit(nr, vaddr) : \
> >^
> >>> drivers/staging/lustre/lustre/libcfs/libcfs_cpu.c:61:3: note: in 
> >>> expansion of macro 'set_bit'
> >  set_bit(0, >ctb_nodemask);
> 
> Yep and additional patch exist to fix this. Should I just push the fix for 
> this or drop this patch and create
> a new patch that is combo of both fixes.
> 
> BTW Greg this new batch of patches are order independent. Sorry for not 
> pointing that out. The rest of the
> patch appear to be okay.

Ok, I'll drop this one, and apply the rest, please resend this after you
have fixed it up.

thanks,

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

Re: [PATCH] sysfs: add devm_sysfs_create_group() and friends

[Greg Kroah-Hartman]

On Fri, Oct 30, 2015 at 08:13:11AM -0700, Dmitry Torokhov wrote:
> On Fri, Oct 30, 2015 at 07:40:37AM -0700, Greg Kroah-Hartman wrote:
> > On Fri, Oct 30, 2015 at 04:47:06AM -0700, Dmitry Torokhov wrote:
> > > Many drivers create additional driver-specific device attributes when
> > > binding to the device and providing managed version of 
> > > sysfs_create_group()
> > > will simplify unbinding and error handling in probe path for such drivers.
> > 
> > But they really shouldn't, because if they do this, they have raced
> > userspace and tools don't know that the files are present.
> > 
> > I don't want to encourage drivers to do this at all, so I don't want to
> > make it easier for them to do things incorrectly.
> 
> The solution is not to forbid drivers from establishing attributes but
> rather notify userspace when device is fully bound to the driver. Then
> userspace that actually cares about these attributes will listen to
> proper events.
> 
> We can either do KOBJ_BOUND/KOBJ_UNBOUND or reuse
> KOBJ_ONLINE/KOBJ_OFFLINE. I'd prefer the former (adding new events).

bound/unbound makes a bit more sense, maybe that would work, haven't
thought that much about it.  Given that no one in the "real world" seem
to notice the race condition, that means that people aren't really using
tools like libudev to read sysfs attributes, so maybe no one even cares
about the contents of them :)

> > Yes, I know that input does this for its devices, but I still think it
> > is wrong and should be changed.  Let's not let this problem spread to
> > other subsystems please.
> 
> Like HID, chargers, hwmon, wireless drivers, leds, backlights, platform
> drivers and so on? Where are platform devices supposed to create their
> attributes? There are more than 300 drivers that add new groups and 581
> instance of device_create_file().

Platform drivers are the main problem right now, I don't know what to do
about them.  I hate those things :(

> Let's be realistic here and see that additional attributes are not going
> anywhere and adding devm interface just helps getting error handling
> right.

But the files are already removed from the system when the device is
removed, so with the exception of the odd error path on probe, this
isn't doing much.  Does it save much code when used?

thanks,

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

Re: [PATCH 5/5] comedi: driver: Fix - BIT macro used coding style issue

[Greg KH]

On Fri, Nov 06, 2015 at 07:57:46PM +0530, Ranjith wrote:
> BIT macro is used for defining bit location instead of shifting
> operator - coding style issue
> 
> Signed-off-by: Ranjith T 
> ---
>  drivers/staging/comedi/drivers/ii_pci20kc.c |   70 
> +--
>  1 file changed, 35 insertions(+), 35 deletions(-)

Where is patches 1/5, 2/5, 3/5, and 4/5 of this series?

Please fix up your numbering and resend all of these patches in a proper
series.

thanks,

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

Re: [PATCH v3 01/12] pwm: introduce default period and polarity concepts

[Alexandre Belloni]

On 21/09/2015 at 11:33:18 +0200, Boris Brezillon wrote :
> When requested by a user, the PWM is assigned a default period and polarity
> extracted from the DT, the platform data or statically set by the driver.
> Those default values are currently stored in the period and polarity
> fields of the pwm_device struct, but they will be stored somewhere else
> once we have introduced the architecture allowing for hardware state
> retrieval.
> 
> The pwm_set_default_polarity and pwm_set_default_period should only be
> used by PWM drivers or the PWM core infrastructure to specify the
> default period and polarity values.
> 
> PWM users might call the pwm_get_default_period to query the default
> period value. There is currently no helper to query the default
> polarity, but it might be added later on if there is a need for it.
> 
> This patch also modifies all the places where the default helpers should
> be used in place of the standard ones.
> 
> Signed-off-by: Boris Brezillon 

For pwm-sun4i:
Reviewed-by: Alexandre Belloni 


-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 1/3] dt-bindings: sound: Add DT bindings for Broadcom Cygnus audio

[Simran Rai]

Add bindings for audio driver in Broadcom Cygnus.

Signed-off-by: Lori Hikichi 
Signed-off-by: Simran Rai 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 .../bindings/sound/brcm,cygnus-audio.txt   |   54 
 1 file changed, 54 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/sound/brcm,cygnus-audio.txt

diff --git a/Documentation/devicetree/bindings/sound/brcm,cygnus-audio.txt 
b/Documentation/devicetree/bindings/sound/brcm,cygnus-audio.txt
new file mode 100644
index 000..3c06001
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/brcm,cygnus-audio.txt
@@ -0,0 +1,54 @@
+BROADCOM Cygnus Audio I2S/TDM/SPDIF controller
+
+Required properties:
+   - compatible : "brcm,cygnus-audio"
+   - #address-cells: 32bit valued, 1 cell.
+   - #size-cells:  32bit valued, 0 cell.
+   - reg : Should contain audio registers location and length
+   - reg-names: names of the registers listed in "reg" property
+   Valid names are "aud" and "i2s_in". "aud" contains a
+   set of DMA, I2S_OUT and SPDIF registers. "i2s_in" contains
+   a set of I2S_IN registers.
+   - clocks: PLL and leaf clocks used by audio ports
+   - clock-names: names of 3 leaf clocks used by audio ports
+   Valid names are "ch0_audio", "ch1_audio", "ch2_audio"
+   - interrupts: audio DMA interrupt number
+
+SSP Subnode properties:
+- reg: The index of ssp port interface to use
+   Valid value are 0, 1, 2, or 3 (for spdif)
+
+
+Example:
+   cygnus_audio: audio@180ae000 {
+   compatible = "brcm,cygnus-audio";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x180ae000 0xafd>, <0x180aec00 0x1f8>;
+   reg-names = "aud", "i2s_in";
+   clocks = < BCM_CYGNUS_AUDIOPLL_CH0>,
+   < BCM_CYGNUS_AUDIOPLL_CH1>,
+   < BCM_CYGNUS_AUDIOPLL_CH2>;
+   clock-names = "ch0_audio", "ch1_audio", "ch2_audio";
+   interrupts = ;
+
+   ssp0: ssp_port@0 {
+   reg = <0>;
+   status = "okay";
+   };
+
+   ssp1: ssp_port@1 {
+   reg = <1>;
+   status = "disabled";
+   };
+
+   ssp2: ssp_port@2 {
+   reg = <2>;
+   status = "disabled";
+   };
+
+   spdif: spdif_port@3 {
+   reg = <3>;
+   status = "disabled";
+   };
+   };
-- 
1.7.9.5

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

[PATCH v3 3/3] sound: soc: Add Cygnus audio DMA driver

[Simran Rai]

This patch adds Cygnus audio DMA driver. It supports playback and capture
modes and uses ringbuffers for data transfer.

Signed-off-by: Lori Hikichi 
Signed-off-by: Simran Rai 
Reviewed-by: Ray Jui 
Reviewed-by: Arun Parameswaran 
Reviewed-by: Scott Branden 
---
 sound/soc/bcm/Kconfig  |9 +
 sound/soc/bcm/Makefile |5 +
 sound/soc/bcm/cygnus-pcm.c |  859 
 3 files changed, 873 insertions(+)
 create mode 100644 sound/soc/bcm/cygnus-pcm.c

diff --git a/sound/soc/bcm/Kconfig b/sound/soc/bcm/Kconfig
index 6a834e1..d528aac 100644
--- a/sound/soc/bcm/Kconfig
+++ b/sound/soc/bcm/Kconfig
@@ -7,3 +7,12 @@ config SND_BCM2835_SOC_I2S
  Say Y or M if you want to add support for codecs attached to
  the BCM2835 I2S interface. You will also need
  to select the audio interfaces to support below.
+
+config SND_SOC_CYGNUS
+   tristate "SoC platform audio for Broadcom Cygnus chips"
+   depends on ARCH_BCM_CYGNUS || COMPILE_TEST
+   help
+ Say Y if you want to add support for ASoC audio on Broadcom
+ Cygnus chips (bcm958300, bcm958305, bcm911360)
+
+ If you don't know what to do here, say N.
\ No newline at end of file
diff --git a/sound/soc/bcm/Makefile b/sound/soc/bcm/Makefile
index bc816b7..fc739d0 100644
--- a/sound/soc/bcm/Makefile
+++ b/sound/soc/bcm/Makefile
@@ -3,3 +3,8 @@ snd-soc-bcm2835-i2s-objs := bcm2835-i2s.o
 
 obj-$(CONFIG_SND_BCM2835_SOC_I2S) += snd-soc-bcm2835-i2s.o
 
+# CYGNUS Platform Support
+snd-soc-cygnus-objs := cygnus-pcm.o cygnus-ssp.o
+
+obj-$(CONFIG_SND_SOC_CYGNUS) += snd-soc-cygnus.o
+
diff --git a/sound/soc/bcm/cygnus-pcm.c b/sound/soc/bcm/cygnus-pcm.c
new file mode 100644
index 000..23381306
--- /dev/null
+++ b/sound/soc/bcm/cygnus-pcm.c
@@ -0,0 +1,859 @@
+/*
+ * Copyright (C) 2014-2015 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "cygnus-ssp.h"
+
+/* Register offset needed for ASoC PCM module */
+
+#define INTH_R5F_STATUS_OFFSET 0x040
+#define INTH_R5F_CLEAR_OFFSET  0x048
+#define INTH_R5F_MASK_SET_OFFSET   0x050
+#define INTH_R5F_MASK_CLEAR_OFFSET 0x054
+
+#define BF_REARM_FREE_MARK_OFFSET 0x344
+#define BF_REARM_FULL_MARK_OFFSET 0x348
+
+/* Ring Buffer Ctrl Regs --- Start */
+/* AUD_FMM_BF_CTRL_SOURCECH_RINGBUF_X_RDADDR_REG_BASE */
+#define SRC_RBUF_0_RDADDR_OFFSET 0x500
+#define SRC_RBUF_1_RDADDR_OFFSET 0x518
+#define SRC_RBUF_2_RDADDR_OFFSET 0x530
+#define SRC_RBUF_3_RDADDR_OFFSET 0x548
+#define SRC_RBUF_4_RDADDR_OFFSET 0x560
+#define SRC_RBUF_5_RDADDR_OFFSET 0x578
+#define SRC_RBUF_6_RDADDR_OFFSET 0x590
+
+/* AUD_FMM_BF_CTRL_SOURCECH_RINGBUF_X_WRADDR_REG_BASE */
+#define SRC_RBUF_0_WRADDR_OFFSET 0x504
+#define SRC_RBUF_1_WRADDR_OFFSET 0x51c
+#define SRC_RBUF_2_WRADDR_OFFSET 0x534
+#define SRC_RBUF_3_WRADDR_OFFSET 0x54c
+#define SRC_RBUF_4_WRADDR_OFFSET 0x564
+#define SRC_RBUF_5_WRADDR_OFFSET 0x57c
+#define SRC_RBUF_6_WRADDR_OFFSET 0x594
+
+/* AUD_FMM_BF_CTRL_SOURCECH_RINGBUF_X_BASEADDR_REG_BASE */
+#define SRC_RBUF_0_BASEADDR_OFFSET 0x508
+#define SRC_RBUF_1_BASEADDR_OFFSET 0x520
+#define SRC_RBUF_2_BASEADDR_OFFSET 0x538
+#define SRC_RBUF_3_BASEADDR_OFFSET 0x550
+#define SRC_RBUF_4_BASEADDR_OFFSET 0x568
+#define SRC_RBUF_5_BASEADDR_OFFSET 0x580
+#define SRC_RBUF_6_BASEADDR_OFFSET 0x598
+
+/* AUD_FMM_BF_CTRL_SOURCECH_RINGBUF_X_ENDADDR_REG_BASE */
+#define SRC_RBUF_0_ENDADDR_OFFSET 0x50c
+#define SRC_RBUF_1_ENDADDR_OFFSET 0x524
+#define SRC_RBUF_2_ENDADDR_OFFSET 0x53c
+#define SRC_RBUF_3_ENDADDR_OFFSET 0x554
+#define SRC_RBUF_4_ENDADDR_OFFSET 0x56c
+#define SRC_RBUF_5_ENDADDR_OFFSET 0x584
+#define SRC_RBUF_6_ENDADDR_OFFSET 0x59c
+
+/* AUD_FMM_BF_CTRL_SOURCECH_RINGBUF_X_FREE_MARK_REG_BASE */
+#define SRC_RBUF_0_FREE_MARK_OFFSET 0x510
+#define SRC_RBUF_1_FREE_MARK_OFFSET 0x528
+#define SRC_RBUF_2_FREE_MARK_OFFSET 0x540
+#define SRC_RBUF_3_FREE_MARK_OFFSET 0x558
+#define SRC_RBUF_4_FREE_MARK_OFFSET 0x570
+#define SRC_RBUF_5_FREE_MARK_OFFSET 0x588
+#define SRC_RBUF_6_FREE_MARK_OFFSET 0x5a0
+
+/* AUD_FMM_BF_CTRL_DESTCH_RINGBUF_X_RDADDR_REG_BASE */
+#define DST_RBUF_0_RDADDR_OFFSET 0x5c0
+#define DST_RBUF_1_RDADDR_OFFSET 0x5d8
+#define DST_RBUF_2_RDADDR_OFFSET 0x5f0
+#define DST_RBUF_3_RDADDR_OFFSET 0x608
+#define DST_RBUF_4_RDADDR_OFFSET 0x620
+#define DST_RBUF_5_RDADDR_OFFSET 0x638
+
+/* AUD_FMM_BF_CTRL_DESTCH_RINGBUF_X_WRADDR_REG_BASE */
+#define DST_RBUF_0_WRADDR_OFFSET 0x5c4
+#define 

[PATCH v3 0/3] sound: soc: Add audio support for Broadcom Cygnus SoC

[Simran Rai]

Hi,

This patchset contains audio support for Broadcom's Cygnus SoC. It
contains DT bindings and core audio driver. The audio driver
supports both capture and playback of Audio PCM samples over I2S/TDM
interface and provides playback support over SPDIF interface.

This patchset is derived from a previously submitted patchset:
http://lkml.iu.edu/hypermail/linux/kernel/1503.3/05434.html

This patchset has been tested on Cygnus wireless audio bcm958305K board.
It is based on v4.3-rc5  and is available from github:

repo: https://github.com/Broadcom/cygnus-linux/tree/cygnus-sound-v3

Changes from v2:
 - Split patchset 2/2 from v2 into patchsets 2/3 and 3/3.
 - Remove SND_SOC_CYGNUS_DIAG. Diagnostics can be performed using
   standard kernel trace infrastructure.
 - Fix interrupt handler. Acknowledge only those interrupts that are
   handledby ISR.
 - Modify configure_vco() and the pll_macro_entry() struct to make it
   better readable. The functionality did not change.
 - Remove casts on macros
 - Removed surround sound channel grouping from the driver.

Simran Rai (3):
  dt-bindings: sound: Add DT bindings for Broadcom Cygnus audio
  sound: soc: Add Cygnus audio DAI driver
  sound: soc: Add Cygnus audio DMA driver

 .../bindings/sound/brcm,cygnus-audio.txt   |   54 +
 sound/soc/bcm/Kconfig  |9 +
 sound/soc/bcm/Makefile |5 +
 sound/soc/bcm/cygnus-pcm.c |  859 +++
 sound/soc/bcm/cygnus-ssp.c | 1508 
 sound/soc/bcm/cygnus-ssp.h |  129 ++
 6 files changed, 2564 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/sound/brcm,cygnus-audio.txt
 create mode 100644 sound/soc/bcm/cygnus-pcm.c
 create mode 100644 sound/soc/bcm/cygnus-ssp.c
 create mode 100644 sound/soc/bcm/cygnus-ssp.h

-- 
1.7.9.5

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

[PATCH v3 2/3] sound: soc: Add Cygnus audio DAI driver

[Simran Rai]

This patch adds Cygnus audio DAI driver. It supports I2S, TDM and
SPDIF modes and uses three clocks derived from PLL.

This patchset has been tested on Cygnus wireless audio bcm958305K board.

Signed-off-by: Lori Hikichi 
Signed-off-by: Simran Rai 
Reviewed-by: Ray Jui 
Reviewed-by: Arun Parameswaran 
Reviewed-by: Scott Branden 
---
 sound/soc/bcm/cygnus-ssp.c | 1508 
 sound/soc/bcm/cygnus-ssp.h |  129 
 2 files changed, 1637 insertions(+)
 create mode 100644 sound/soc/bcm/cygnus-ssp.c
 create mode 100644 sound/soc/bcm/cygnus-ssp.h

diff --git a/sound/soc/bcm/cygnus-ssp.c b/sound/soc/bcm/cygnus-ssp.c
new file mode 100644
index 000..f9f321b
--- /dev/null
+++ b/sound/soc/bcm/cygnus-ssp.c
@@ -0,0 +1,1508 @@
+/*
+ * Copyright (C) 2014-2015 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "cygnus-ssp.h"
+
+#define DEFAULT_VCO1354750204
+
+#define CYGNUS_TDM_RATE \
+   (SNDRV_PCM_RATE_8000 | SNDRV_PCM_RATE_16000 | \
+   SNDRV_PCM_RATE_11025 | SNDRV_PCM_RATE_22050 | \
+   SNDRV_PCM_RATE_32000 | SNDRV_PCM_RATE_44100 | \
+   SNDRV_PCM_RATE_48000)
+
+#define CAPTURE_FCI_ID_BASE 0x180
+#define CYGNUS_SSP_TRISTATE_MASK 0x001fff
+
+/* Used with stream_on field to indicate which streams are active */
+#define  PLAYBACK_STREAM_MASK   BIT(0)
+#define  CAPTURE_STREAM_MASKBIT(1)
+
+#define I2S_STREAM_CFG_MASK  0xff003ff
+#define I2S_CAP_STREAM_CFG_MASK  0xf0
+#define SPDIF_STREAM_CFG_MASK0x3ff
+#define CH_GRP_STEREO 0x1
+
+/* Begin register offset defines */
+#define AUD_MISC_SEROUT_OE_REG_BASE  0x01c
+#define AUD_MISC_SEROUT_SPDIF_OE  13
+#define AUD_MISC_SEROUT_MCLK_OE   3
+#define AUD_MISC_SEROUT_LRCK_OE   2
+#define AUD_MISC_SEROUT_SCLK_OE   1
+#define AUD_MISC_SEROUT_SDAT_OE   0
+
+/* AUD_FMM_BF_CTRL_xxx regs */
+#define BF_DST_CFG0_OFFSET  0x100
+#define BF_DST_CFG1_OFFSET  0x104
+#define BF_DST_CFG2_OFFSET  0x108
+
+#define BF_DST_CTRL0_OFFSET 0x130
+#define BF_DST_CTRL1_OFFSET 0x134
+#define BF_DST_CTRL2_OFFSET 0x138
+
+#define BF_SRC_CFG0_OFFSET  0x148
+#define BF_SRC_CFG1_OFFSET  0x14c
+#define BF_SRC_CFG2_OFFSET  0x150
+#define BF_SRC_CFG3_OFFSET  0x154
+
+#define BF_SRC_CTRL0_OFFSET 0x1c0
+#define BF_SRC_CTRL1_OFFSET 0x1c4
+#define BF_SRC_CTRL2_OFFSET 0x1c8
+#define BF_SRC_CTRL3_OFFSET 0x1cc
+
+#define BF_SRC_GRP0_OFFSET  0x1fc
+#define BF_SRC_GRP1_OFFSET  0x200
+#define BF_SRC_GRP2_OFFSET  0x204
+#define BF_SRC_GRP3_OFFSET  0x208
+
+#define BF_SRC_GRP_EN_OFFSET0x320
+#define BF_SRC_GRP_FLOWON_OFFSET0x324
+#define BF_SRC_GRP_SYNC_DIS_OFFSET  0x328
+
+/* AUD_FMM_IOP_OUT_I2S_xxx regs */
+#define OUT_I2S_0_STREAM_CFG_OFFSET 0xa00
+#define OUT_I2S_0_CFG_OFFSET0xa04
+#define OUT_I2S_0_MCLK_CFG_OFFSET   0xa0c
+
+#define OUT_I2S_1_STREAM_CFG_OFFSET 0xa40
+#define OUT_I2S_1_CFG_OFFSET0xa44
+#define OUT_I2S_1_MCLK_CFG_OFFSET   0xa4c
+
+#define OUT_I2S_2_STREAM_CFG_OFFSET 0xa80
+#define OUT_I2S_2_CFG_OFFSET0xa84
+#define OUT_I2S_2_MCLK_CFG_OFFSET   0xa8c
+
+/* AUD_FMM_IOP_OUT_SPDIF_xxx regs */
+#define SPDIF_STREAM_CFG_OFFSET  0xac0
+#define SPDIF_CTRL_OFFSET0xac4
+#define SPDIF_FORMAT_CFG_OFFSET  0xad8
+#define SPDIF_MCLK_CFG_OFFSET0xadc
+
+/* AUD_FMM_IOP_PLL_0_xxx regs */
+#define IOP_PLL_0_MACRO_OFFSET0xb00
+#define IOP_PLL_0_MDIV_Ch0_OFFSET 0xb14
+#define IOP_PLL_0_MDIV_Ch1_OFFSET 0xb18
+#define IOP_PLL_0_MDIV_Ch2_OFFSET 0xb1c
+
+#define IOP_PLL_0_ACTIVE_MDIV_Ch0_OFFSET 0xb30
+#define IOP_PLL_0_ACTIVE_MDIV_Ch1_OFFSET 0xb34
+#define IOP_PLL_0_ACTIVE_MDIV_Ch2_OFFSET 0xb38
+
+/* AUD_FMM_IOP_xxx regs */
+#define IOP_PLL_0_CONTROL_OFFSET 0xb04
+#define IOP_PLL_0_USER_NDIV_OFFSET   0xb08
+#define IOP_PLL_0_ACTIVE_NDIV_OFFSET 0xb20
+#define IOP_PLL_0_RESET_OFFSET   0xb5c
+
+/* AUD_FMM_IOP_IN_I2S_xxx regs */
+#define IN_I2S_0_STREAM_CFG_OFFSET 0x00
+#define IN_I2S_0_CFG_OFFSET0x04
+#define IN_I2S_1_STREAM_CFG_OFFSET 0x40
+#define IN_I2S_1_CFG_OFFSET0x44
+#define IN_I2S_2_STREAM_CFG_OFFSET 0x80
+#define IN_I2S_2_CFG_OFFSET0x84
+
+/* AUD_FMM_IOP_MISC_xxx regs */
+#define IOP_SW_INIT_LOGIC  0x1c0
+
+/* End register offset defines */
+
+
+/* AUD_FMM_IOP_OUT_I2S_x_MCLK_CFG_0_REG */
+#define I2S_OUT_MCLKRATE_SHIFT 16
+
+/* AUD_FMM_IOP_OUT_I2S_x_MCLK_CFG_REG */
+#define I2S_OUT_PLLCLKSEL_SHIFT  0
+
+/* AUD_FMM_IOP_OUT_I2S_x_STREAM_CFG */
+#define 

Re: [PATCH v4 3/4] Add PTP_SYS_OFFSET_PRECISE for driver crosstimestamping

[Christopher Hall]

Richard/Thomas:

On Tue, 13 Oct 2015 06:59:26 -0700, Richard Cochran  
 wrote:

On Mon, Oct 12, 2015 at 11:45:21AM -0700, Christopher S. Hall wrote:


+struct ptp_sys_offset_precise {
+   unsigned int rsv[4];/* Reserved for future use. */
+   struct ptp_clock_time dev;
+   struct ptp_clock_time sys;
+};
+


Please put the reserved field at the bottom.  Also, since we reading
the raw monotonic time under the hood, we might as well return it in
this struct too.  It costs us almost nothing, and having that value
can be useful for characterizing the system oscillator.


Below is my proposal to implement your suggested changes adding monotonic  
raw to the PTP_SYS_OFFSET_PRECISE ioctl:


Move the reserved field to the end and add monotonic raw to
ptp_sys_offset_precise:

struct ptp_sys_offset_precise {
 struct ptp_clock_time dev;
 struct ptp_clock_time sys_real;
 struct ptp_clock_time sys_raw;
 unsigned int rsv[4];/* Reserved for future use. */
};

In my previous patch, the getsynctime() prototype is:

int (*getsynctime64)(struct ptp_clock_info *ptp, struct timespec64 *dev,
struct timespec64 *sys);

To simplify the PTP callback arguments (not add an additional raw
argument), it seems better to replace all of the arguments with a single
argument:

int (*getsynctime)(struct ptp_clock_info *ptp, struct correlated_ts *cts);

This requires adding a device time field to the correlated timestamp
struct:

struct correlated_ts {
 int (*get_ts)(struct correlated_ts *ts);
 u64 system_ts;
 u64 device_ts;
 ktime_t system_real;
 ktime_t system_raw;
+   ktime_t device;
 void*private;
};

The device time field is filled out by the driver "on the way back"
(following completion of get_correlated_timestamp()) to the PTP driver.

The call flow:

PTP driver-> get_synctime() (Ethernet driver)-> get_correlated_timestamp()
(Timekeeping)->get_ts (Ethernet driver)

The timestamp argument is the same (type struct correlated_ts *) for all
of these calls.

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

[PATCH] staging: lustre: remove IOC_LIBCFS_PING_TEST ioctl

[y]

From: James Simmons 

The ioctl IOC_LIBCFS_PING_TEST has not been used in
ages. The recent nidstring changes which moved all
the nidstring operations from libcfs to the LNet
layer but this ioctl code was still using an
nidstring operation that was causing an circular
dependency loop between libcfs and LNet.

Signed-off-by: James Simmons 
---
 .../lustre/include/linux/libcfs/libcfs_ioctl.h |1 -
 drivers/staging/lustre/lustre/libcfs/module.c  |   17 -
 2 files changed, 0 insertions(+), 18 deletions(-)

diff --git a/drivers/staging/lustre/include/linux/libcfs/libcfs_ioctl.h 
b/drivers/staging/lustre/include/linux/libcfs/libcfs_ioctl.h
index f5d741f..485ab26 100644
--- a/drivers/staging/lustre/include/linux/libcfs/libcfs_ioctl.h
+++ b/drivers/staging/lustre/include/linux/libcfs/libcfs_ioctl.h
@@ -110,7 +110,6 @@ struct libcfs_ioctl_handler {
 #define IOC_LIBCFS_CLEAR_DEBUG  _IOWR('e', 31, long)
 #define IOC_LIBCFS_MARK_DEBUG_IOWR('e', 32, long)
 #define IOC_LIBCFS_MEMHOG_IOWR('e', 36, long)
-#define IOC_LIBCFS_PING_TEST  _IOWR('e', 37, long)
 /* lnet ioctls */
 #define IOC_LIBCFS_GET_NI_IOWR('e', 50, long)
 #define IOC_LIBCFS_FAIL_NID_IOWR('e', 51, long)
diff --git a/drivers/staging/lustre/lustre/libcfs/module.c 
b/drivers/staging/lustre/lustre/libcfs/module.c
index 50e8fd2..5e22820 100644
--- a/drivers/staging/lustre/lustre/libcfs/module.c
+++ b/drivers/staging/lustre/lustre/libcfs/module.c
@@ -274,23 +274,6 @@ static int libcfs_ioctl_int(struct cfs_psdev_file *pfile, 
unsigned long cmd,
}
break;
 
-   case IOC_LIBCFS_PING_TEST: {
-   extern void (kping_client)(struct libcfs_ioctl_data *);
-   void (*ping)(struct libcfs_ioctl_data *);
-
-   CDEBUG(D_IOCTL, "doing %d pings to nid %s (%s)\n",
-  data->ioc_count, libcfs_nid2str(data->ioc_nid),
-  libcfs_nid2str(data->ioc_nid));
-   ping = symbol_get(kping_client);
-   if (!ping)
-   CERROR("symbol_get failed\n");
-   else {
-   ping(data);
-   symbol_put(kping_client);
-   }
-   return 0;
-   }
-
default: {
struct libcfs_ioctl_handler *hand;
 
-- 
1.7.1

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

[PATCH v6] arm64: dts: Added syscon-reboot node for FSL's LS2080A SoC

[J. German Rivera]

Added sys-reboot node to the FSL's LS2080A SoC DT to leverage
the ARM-generic reboot mechanism for this SoC. This mechanism
is enabled through CONFIG_POWER_RESET_SYSCON.

Signed-off-by: J. German Rivera 
---
CHANGE HISTORY:

Changes in v6:
- Addressed comment from Javier Martinez Canillas
  * Moved change history out of actual commit message
- Addressed comment from Leo Li
  * Refer to LS2080A in compatible string

Changes in v5:
- Addressed comment from Stuart Yoder
  * Fixed commit message to refer to LS2080A instead of LS2085A.

Changes in v4:
- Addressed comment from Arnd Bergmann:
  * Changed compatible string to be more specific
  * Changed node name to 'syscon' instead of 'rstcr'
  * Changed address to lower case hex
- Addressed comment form Stuart Yoder:
  * Rebase on top of branch arm-soc/for-next

Changes in v3:
- Addressed comment form Stuart Yoder:
  * Expose only the reset register

Changes in v2:
- Addressed comment form Stuart Yoder:
  * Removed "@" from reboot node

 arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
index e81cd48..65ac35f 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
@@ -153,6 +153,18 @@
};
};

+   rstcr: syscon@1e6 {
+   compatible = "fsl,ls2080a-rstcr", "syscon";
+   reg = <0x0 0x1e6 0x0 0x4>;
+   };
+
+   reboot {
+   compatible ="syscon-reboot";
+   regmap = <>;
+   offset = <0x0>;
+   mask = <0x2>;
+   };
+
timer {
compatible = "arm,armv8-timer";
interrupts = <1 13 0x8>, /* Physical Secure PPI, active-low */
--
2.3.3

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

[RFC PATCH] usb: dwc2: host: Rewrite the microframe scheduler

[Douglas Anderson]

The old microframe scheduler was terribly hard to follow and (it seemed
to me) that it had some bugs in it.

Let's re-write it in a simpler, easier-to-read way.  Hopefully this will
work better.

Note: no known problems are fixed by this patch, and in fact I can see
very little impact of the microframe scheduler overall.

Signed-off-by: Douglas Anderson 
---
 drivers/usb/dwc2/hcd_queue.c | 72 
 1 file changed, 32 insertions(+), 40 deletions(-)

diff --git a/drivers/usb/dwc2/hcd_queue.c b/drivers/usb/dwc2/hcd_queue.c
index 7d8d06cfe3c1..d6c24decee08 100644
--- a/drivers/usb/dwc2/hcd_queue.c
+++ b/drivers/usb/dwc2/hcd_queue.c
@@ -359,57 +359,49 @@ static int dwc2_find_single_uframe(struct dwc2_hsotg 
*hsotg, struct dwc2_qh *qh)
  */
 static int dwc2_find_multi_uframe(struct dwc2_hsotg *hsotg, struct dwc2_qh *qh)
 {
-   unsigned short utime = qh->usecs;
-   unsigned short xtime;
-   int t_left;
+   int utime;
int i;
int j;
-   int k;
 
for (i = 0; i < 8; i++) {
if (hsotg->frame_usecs[i] <= 0)
continue;
 
-   /*
-* we need n consecutive slots so use j as a start slot
-* j plus j+1 must be enough time (for now)
-*/
-   xtime = hsotg->frame_usecs[i];
-   for (j = i + 1; j < 8; j++) {
+   for (utime = qh->usecs, j = i; utime > 0 && j < 8; j++) {
+   /* Give the available time from this uframe */
+   utime -= hsotg->frame_usecs[j];
+
/*
-* if we add this frame remaining time to xtime we may
-* be OK, if not we need to test j for a complete frame
+* Except for first frame, we can't continue past this
+* frame if it wasn't full, so bail now.  We might still
+* be successful the above subtract made utime <= 0.
 */
-   if (xtime + hsotg->frame_usecs[j] < utime) {
-   if (hsotg->frame_usecs[j] <
-   max_uframe_usecs[j])
-   continue;
-   }
-   if (xtime >= utime) {
-   t_left = utime;
-   for (k = i; k < 8; k++) {
-   t_left -= hsotg->frame_usecs[k];
-   if (t_left <= 0) {
-   qh->frame_usecs[k] +=
-   hsotg->frame_usecs[k]
-   + t_left;
-   hsotg->frame_usecs[k] = -t_left;
-   return i;
-   } else {
-   qh->frame_usecs[k] +=
-   hsotg->frame_usecs[k];
-   hsotg->frame_usecs[k] = 0;
-   }
-   }
-   }
-   /* add the frame time to x time */
-   xtime += hsotg->frame_usecs[j];
-   /* we must have a fully available next frame or break */
-   if (xtime < utime &&
-  hsotg->frame_usecs[j] == max_uframe_usecs[j])
-   continue;
+   if ((i != j) &&
+   (hsotg->frame_usecs[j] < max_uframe_usecs[j]))
+   break;
+   }
+
+   /* If utime > 0 after above loop, try a different start (i) */
+   if (utime > 0)
+   continue;
+
+   dev_dbg(hsotg->dev, "Assigned %d us starting at i=%d + %d us\n",
+   qh->usecs, i,
+   max_uframe_usecs[i] - hsotg->frame_usecs[i]);
+
+   /* We've got success, so allocate */
+   for (utime = qh->usecs, j = i; utime > 0 && j < 8; j++) {
+   qh->frame_usecs[i] = min_t(u16, utime,
+  hsotg->frame_usecs[j]);
+   utime -= qh->frame_usecs[i];
+   hsotg->frame_usecs[j] -= qh->frame_usecs[i];
}
+
+   return i;
}
+
+   dev_dbg(hsotg->dev, "Failed to assign %d us\n", qh->usecs);
+
return -ENOSPC;
 }
 
-- 
2.6.0.rc2.230.g3dd15c0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  

[PATCH v3 00/11] staging: fsl-mc: MC bus MSI support

[J. German Rivera]

This patch series addresses the following item from the TODO list
for the MC bus driver to exit staging:

* Interrupt support. For meaningful driver support we need
  interrupts, and thus need message interrupt support by the bus
  driver.

MC Bus MSI Support Architecture
===
A new IRQ domain bus token is added for the FSL-MC bus.
An MSI IRQ domain is created for each top-level (root) data-path
resource container (DPRC), based on its msi-parent in the device
tree (which is the GIC-ITS). Child DPRCs inherit the MSI IRQ
domain form their parent DPRC.

MC Bus MSI Allocation
-
Given the way in which the GIC-ITS works, we need to pre-allocate
a block of MSIs in the GIC-ITS for the IRQs of all the DPAA2 objects
in the same data-path resource container (DPRC) and for the IRQ of
the DPRC iself.

This is due to the fact that all the IRQs for DPAA2 objects in the
same DPRC (and the DPRC's own IRQ) must use the same "device Id" in
the GIC-ITS. Thus, all these IRQs must share the same ITT table in
the GIC-ITS, and therefore must be allocated in the GIC-ITS as
a block of MSIs for the same "device Id".

This is because all the DPAA2 objects in the same DPRC (and the
DPRC itself) use the DPRC's SMMU stream ID as their device Id for
the GIC-ITS.
The DPAA2 Management Complex (MC) firmware does not assign a separate
SMMU stream ID to each DPAA2 object. The MC only assigns SMMU stream
IDs to DPRCs. In MC terms, the stream ID assigned to a DPRC is known
as the DPRC's Isolation Context ID (ICID).

As a consequence of having to pre-allocate a block of MSIs in
the GIC-ITS, the object allocator of the MC bus driver needs to be
extended to provide IRQ allocation services to DPAA2 device drivers
and to the DPRC driver. For a given DPAA2 object, MSIs are allocated
from the corresponding DPRC's pool of pre-allocated MSIs. The MSI
for the DPRC itself is also allocated from this pool.

The following are the patches in this series:

Patch 1: Added domain bus token DOMAIN_BUS_FSL_MC_MSI
Patch 2: Added generic MSI support for FSL-MC devices
Patch 3: Added GICv3-ITS support for FSL-MC MSIs
Patch 4: Extended MC bus allocator to include IRQs
Patch 5: Changed DPRC built-in portal's mc_io to be atomic
Patch 6: Populate the IRQ pool for an MC bus instance
Patch 7: Set MSI domain for DPRC objects
Patch 8: Fixed bug in dprc_probe() error path
Patch 9: Added DPRC interrupt handler
Patch 10: Added MSI support to the MC bus driver

CHANGE HISTORY

Changes in v3:
- Addressed comment from Marc Zyngier for patch 3.
  See details in patch 3.

Changes in v2:
- Addressed comment from Jiang Liu in patch 2.
  See details in patch 2.
- Addressed comment from Dan Carpenter in patch 9
  See details in patch 9.

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

[PATCH v3 02/11] fsl-mc: msi: Added FSL-MC-specific member to the msi_desc's union

[J. German Rivera]

FSL-MC is a bus type different from PCI and platform, so it needs
its own member in the msi_desc's union.

Signed-off-by: J. German Rivera 
---
CHANGE HISTORY

Changes in v3: none

Changes in v2:
- Addressed comment from Jiang Liu
  * Added a dedicated structure for FSL-MC in struct msi_desc

 include/linux/msi.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/include/linux/msi.h b/include/linux/msi.h
index f71a25e..152e51a 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -33,6 +33,14 @@ struct platform_msi_desc {
 };

 /**
+ * fsl_mc_msi_desc - FSL-MC device specific msi descriptor data
+ * @msi_index: The index of the MSI descriptor
+ */
+struct fsl_mc_msi_desc {
+   u16 msi_index;
+};
+
+/**
  * struct msi_desc - Descriptor structure for MSI based interrupts
  * @list:  List head for management
  * @irq:   The base interrupt number
@@ -87,6 +95,7 @@ struct msi_desc {
 * tree wide cleanup.
 */
struct platform_msi_desc platform;
+   struct fsl_mc_msi_desc fsl_mc;
};
 };

--
2.3.3

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

[PATCH v3 08/11] staging: fsl-mc: set MSI domain for DPRC objects

[J. German Rivera]

THE MSI domain associated with a root DPRC object is
obtained form the device tree. Child DPRCs inherit
the parent DPRC MSI domain.

Signed-off-by: J. German Rivera 
---
CHANGE HISTORY

Changes in v3: none

Changes in v2: none

 drivers/staging/fsl-mc/bus/dprc-driver.c | 39 
 1 file changed, 39 insertions(+)

diff --git a/drivers/staging/fsl-mc/bus/dprc-driver.c 
b/drivers/staging/fsl-mc/bus/dprc-driver.c
index 3bcd161..455379d 100644
--- a/drivers/staging/fsl-mc/bus/dprc-driver.c
+++ b/drivers/staging/fsl-mc/bus/dprc-driver.c
@@ -13,6 +13,7 @@
 #include "../include/mc-sys.h"
 #include 
 #include 
+#include 
 #include "dprc-cmd.h"

 struct dprc_child_objs {
@@ -398,11 +399,16 @@ static int dprc_probe(struct fsl_mc_device *mc_dev)
 {
int error;
size_t region_size;
+   struct device *parent_dev = mc_dev->dev.parent;
struct fsl_mc_bus *mc_bus = to_fsl_mc_bus(mc_dev);
+   bool msi_domain_set = false;

if (WARN_ON(strcmp(mc_dev->obj_desc.type, "dprc") != 0))
return -EINVAL;

+   if (WARN_ON(dev_get_msi_domain(_dev->dev)))
+   return -EINVAL;
+
if (!mc_dev->mc_io) {
/*
 * This is a child DPRC:
@@ -421,6 +427,30 @@ static int dprc_probe(struct fsl_mc_device *mc_dev)
 _dev->mc_io);
if (error < 0)
return error;
+   /*
+* Inherit parent MSI domain:
+*/
+   dev_set_msi_domain(_dev->dev,
+  dev_get_msi_domain(parent_dev));
+   msi_domain_set = true;
+   } else {
+   /*
+* This is a root DPRC
+*/
+   struct irq_domain *mc_msi_domain;
+
+   if (WARN_ON(parent_dev->bus == _mc_bus_type))
+   return -EINVAL;
+
+   error = fsl_mc_find_msi_domain(parent_dev->of_node,
+  _msi_domain);
+   if (error < 0) {
+   dev_warn(_dev->dev,
+"WARNING: MC bus without interrupt support\n");
+   } else {
+   dev_set_msi_domain(_dev->dev, mc_msi_domain);
+   msi_domain_set = true;
+   }
}

error = dprc_open(mc_dev->mc_io, 0, mc_dev->obj_desc.id,
@@ -446,6 +476,9 @@ error_cleanup_open:
(void)dprc_close(mc_dev->mc_io, 0, mc_dev->mc_handle);

 error_cleanup_mc_io:
+   if (msi_domain_set)
+   dev_set_msi_domain(_dev->dev, NULL);
+
fsl_destroy_mc_io(mc_dev->mc_io);
return error;
 }
@@ -463,6 +496,7 @@ error_cleanup_mc_io:
 static int dprc_remove(struct fsl_mc_device *mc_dev)
 {
int error;
+   struct fsl_mc_bus *mc_bus = to_fsl_mc_bus(mc_dev);

if (WARN_ON(strcmp(mc_dev->obj_desc.type, "dprc") != 0))
return -EINVAL;
@@ -475,6 +509,11 @@ static int dprc_remove(struct fsl_mc_device *mc_dev)
if (error < 0)
dev_err(_dev->dev, "dprc_close() failed: %d\n", error);

+   if (dev_get_msi_domain(_dev->dev)) {
+   fsl_mc_cleanup_irq_pool(mc_bus);
+   dev_set_msi_domain(_dev->dev, NULL);
+   }
+
dev_info(_dev->dev, "DPRC device unbound from driver");
return 0;
 }
--
2.3.3

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

[PATCH v3 10/11] staging: fsl-mc: Added DPRC interrupt handler

[J. German Rivera]

The interrupt handler for DPRC IRQs is added. DPRC IRQs are
generated for hot plug events related to DPAA2 objects in a given
DPRC. These events include, creating/destroying DPAA2 objects in
the DPRC, changing the "plugged" state of DPAA2 objects and moving
objects between DPRCs.

Signed-off-by: J. German Rivera 
---
CHANGE HISTORY

Changes in v3: none

Changes in v2: none

 drivers/staging/fsl-mc/bus/dprc-driver.c | 247 +++
 1 file changed, 247 insertions(+)

diff --git a/drivers/staging/fsl-mc/bus/dprc-driver.c 
b/drivers/staging/fsl-mc/bus/dprc-driver.c
index 7f1ceb5..0bd2e63 100644
--- a/drivers/staging/fsl-mc/bus/dprc-driver.c
+++ b/drivers/staging/fsl-mc/bus/dprc-driver.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "dprc-cmd.h"

 struct dprc_child_objs {
@@ -386,6 +387,230 @@ error:
 EXPORT_SYMBOL_GPL(dprc_scan_container);

 /**
+ * dprc_irq0_handler - Regular ISR for DPRC interrupt 0
+ *
+ * @irq: IRQ number of the interrupt being handled
+ * @arg: Pointer to device structure
+ */
+static irqreturn_t dprc_irq0_handler(int irq_num, void *arg)
+{
+   return IRQ_WAKE_THREAD;
+}
+
+/**
+ * dprc_irq0_handler_thread - Handler thread function for DPRC interrupt 0
+ *
+ * @irq: IRQ number of the interrupt being handled
+ * @arg: Pointer to device structure
+ */
+static irqreturn_t dprc_irq0_handler_thread(int irq_num, void *arg)
+{
+   int error;
+   u32 status;
+   struct device *dev = (struct device *)arg;
+   struct fsl_mc_device *mc_dev = to_fsl_mc_device(dev);
+   struct fsl_mc_bus *mc_bus = to_fsl_mc_bus(mc_dev);
+   struct fsl_mc_io *mc_io = mc_dev->mc_io;
+   struct msi_desc *msi_desc = mc_dev->irqs[0]->msi_desc;
+
+   dev_dbg(dev, "DPRC IRQ %d triggered on CPU %u\n",
+   irq_num, smp_processor_id());
+
+   if (WARN_ON(!(mc_dev->flags & FSL_MC_IS_DPRC)))
+   return IRQ_HANDLED;
+
+   mutex_lock(_bus->scan_mutex);
+   if (WARN_ON(!msi_desc || msi_desc->irq != (u32)irq_num))
+   goto out;
+
+   error = dprc_get_irq_status(mc_io, 0, mc_dev->mc_handle, 0,
+   );
+   if (error < 0) {
+   dev_err(dev,
+   "dprc_get_irq_status() failed: %d\n", error);
+   goto out;
+   }
+
+   error = dprc_clear_irq_status(mc_io, 0, mc_dev->mc_handle, 0,
+ status);
+   if (error < 0) {
+   dev_err(dev,
+   "dprc_clear_irq_status() failed: %d\n", error);
+   goto out;
+   }
+
+   if (status & (DPRC_IRQ_EVENT_OBJ_ADDED |
+ DPRC_IRQ_EVENT_OBJ_REMOVED |
+ DPRC_IRQ_EVENT_CONTAINER_DESTROYED |
+ DPRC_IRQ_EVENT_OBJ_DESTROYED |
+ DPRC_IRQ_EVENT_OBJ_CREATED)) {
+   unsigned int irq_count;
+
+   error = dprc_scan_objects(mc_dev, _count);
+   if (error < 0) {
+   /*
+* If the error is -ENXIO, we ignore it, as it indicates
+* that the object scan was aborted, as we detected that
+* an object was removed from the DPRC in the MC, while
+* we were scanning the DPRC.
+*/
+   if (error != -ENXIO) {
+   dev_err(dev, "dprc_scan_objects() failed: %d\n",
+   error);
+   }
+
+   goto out;
+   }
+
+   if (irq_count > FSL_MC_IRQ_POOL_MAX_TOTAL_IRQS) {
+   dev_warn(dev,
+"IRQs needed (%u) exceed IRQs preallocated 
(%u)\n",
+irq_count, FSL_MC_IRQ_POOL_MAX_TOTAL_IRQS);
+   }
+   }
+
+out:
+   mutex_unlock(_bus->scan_mutex);
+   return IRQ_HANDLED;
+}
+
+/*
+ * Disable and clear interrupt for a given DPRC object
+ */
+static int disable_dprc_irq(struct fsl_mc_device *mc_dev)
+{
+   int error;
+   struct fsl_mc_io *mc_io = mc_dev->mc_io;
+
+   WARN_ON(mc_dev->obj_desc.irq_count != 1);
+
+   /*
+* Disable generation of interrupt, while we configure it:
+*/
+   error = dprc_set_irq_enable(mc_io, 0, mc_dev->mc_handle, 0, 0);
+   if (error < 0) {
+   dev_err(_dev->dev,
+   "Disabling DPRC IRQ failed: dprc_set_irq_enable() 
failed: %d\n",
+   error);
+   return error;
+   }
+
+   /*
+* Disable all interrupt causes for the interrupt:
+*/
+   error = dprc_set_irq_mask(mc_io, 0, mc_dev->mc_handle, 0, 0x0);
+   if (error < 0) {
+   dev_err(_dev->dev,
+   "Disabling DPRC IRQ failed: dprc_set_irq_mask() failed: 
%d\n",
+   error);
+   return 

[PATCH v3 05/11] staging: fsl-mc: Extended MC bus allocator to include IRQs

[J. German Rivera]

All the IRQs for DPAA2 objects in the same DPRC must use
the ICID of that DPRC, as their device Id in the GIC-ITS.
Thus, all these IRQs must share the same ITT table in the GIC.
As a result, a pool of IRQs with the same device Id must be
preallocated per DPRC (fsl-mc bus instance). So, the fsl-mc
bus object allocator is extended to also provide services
to allocate IRQs to DPAA2 devices, from their parent fsl-mc bus
IRQ pool.

Signed-off-by: J. German Rivera 
---
CHANGE HISTORY

Changes in v3: none

Changes in v2: none

 drivers/staging/fsl-mc/bus/mc-allocator.c   | 199 
 drivers/staging/fsl-mc/include/mc-private.h |  15 +++
 drivers/staging/fsl-mc/include/mc.h |   9 ++
 3 files changed, 223 insertions(+)

diff --git a/drivers/staging/fsl-mc/bus/mc-allocator.c 
b/drivers/staging/fsl-mc/bus/mc-allocator.c
index 88d1857..c5fa628 100644
--- a/drivers/staging/fsl-mc/bus/mc-allocator.c
+++ b/drivers/staging/fsl-mc/bus/mc-allocator.c
@@ -15,6 +15,7 @@
 #include "../include/dpcon-cmd.h"
 #include "dpmcp-cmd.h"
 #include "dpmcp.h"
+#include 

 /**
  * fsl_mc_resource_pool_add_device - add allocatable device to a resource
@@ -160,6 +161,7 @@ static const char *const fsl_mc_pool_type_strings[] = {
[FSL_MC_POOL_DPMCP] = "dpmcp",
[FSL_MC_POOL_DPBP] = "dpbp",
[FSL_MC_POOL_DPCON] = "dpcon",
+   [FSL_MC_POOL_IRQ] = "irq",
 };

 static int __must_check object_type_to_pool_type(const char *object_type,
@@ -465,6 +467,203 @@ void fsl_mc_object_free(struct fsl_mc_device *mc_adev)
 }
 EXPORT_SYMBOL_GPL(fsl_mc_object_free);

+/*
+ * Initialize the interrupt pool associated with a MC bus.
+ * It allocates a block of IRQs from the GIC-ITS
+ */
+int fsl_mc_populate_irq_pool(struct fsl_mc_bus *mc_bus,
+unsigned int irq_count)
+{
+   unsigned int i;
+   struct msi_desc *msi_desc;
+   struct fsl_mc_device_irq *irq_resources;
+   struct fsl_mc_device_irq *mc_dev_irq;
+   int error;
+   struct fsl_mc_device *mc_bus_dev = _bus->mc_dev;
+   struct fsl_mc_resource_pool *res_pool =
+   _bus->resource_pools[FSL_MC_POOL_IRQ];
+
+   if (WARN_ON(irq_count == 0 ||
+   irq_count > FSL_MC_IRQ_POOL_MAX_TOTAL_IRQS))
+   return -EINVAL;
+
+   error = fsl_mc_msi_domain_alloc_irqs(_bus_dev->dev, irq_count);
+   if (error < 0)
+   return error;
+
+   irq_resources = devm_kzalloc(_bus_dev->dev,
+sizeof(*irq_resources) * irq_count,
+GFP_KERNEL);
+   if (!irq_resources) {
+   error = -ENOMEM;
+   goto cleanup_msi_irqs;
+   }
+
+   for (i = 0; i < irq_count; i++) {
+   mc_dev_irq = _resources[i];
+
+   /*
+* NOTE: This mc_dev_irq's MSI addr/value pair will be set
+* by the fsl_mc_msi_write_msg() callback
+*/
+   mc_dev_irq->resource.type = res_pool->type;
+   mc_dev_irq->resource.data = mc_dev_irq;
+   mc_dev_irq->resource.parent_pool = res_pool;
+   INIT_LIST_HEAD(_dev_irq->resource.node);
+   list_add_tail(_dev_irq->resource.node, _pool->free_list);
+   }
+
+   for_each_msi_entry(msi_desc, _bus_dev->dev) {
+   mc_dev_irq = _resources[msi_desc->fsl_mc.msi_index];
+   mc_dev_irq->msi_desc = msi_desc;
+   mc_dev_irq->resource.id = msi_desc->irq;
+   }
+
+   res_pool->max_count = irq_count;
+   res_pool->free_count = irq_count;
+   mc_bus->irq_resources = irq_resources;
+   return 0;
+
+cleanup_msi_irqs:
+   fsl_mc_msi_domain_free_irqs(_bus_dev->dev);
+   return error;
+}
+EXPORT_SYMBOL_GPL(fsl_mc_populate_irq_pool);
+
+/**
+ * Teardown the interrupt pool associated with an MC bus.
+ * It frees the IRQs that were allocated to the pool, back to the GIC-ITS.
+ */
+void fsl_mc_cleanup_irq_pool(struct fsl_mc_bus *mc_bus)
+{
+   struct fsl_mc_device *mc_bus_dev = _bus->mc_dev;
+   struct fsl_mc_resource_pool *res_pool =
+   _bus->resource_pools[FSL_MC_POOL_IRQ];
+
+   if (WARN_ON(!mc_bus->irq_resources))
+   return;
+
+   if (WARN_ON(res_pool->max_count == 0))
+   return;
+
+   if (WARN_ON(res_pool->free_count != res_pool->max_count))
+   return;
+
+   INIT_LIST_HEAD(_pool->free_list);
+   res_pool->max_count = 0;
+   res_pool->free_count = 0;
+   mc_bus->irq_resources = NULL;
+   fsl_mc_msi_domain_free_irqs(_bus_dev->dev);
+}
+EXPORT_SYMBOL_GPL(fsl_mc_cleanup_irq_pool);
+
+/**
+ * It allocates the IRQs required by a given MC object device. The
+ * IRQs are allocated from the interrupt pool associated with the
+ * MC bus that contains the device, if the device is not a DPRC device.
+ * Otherwise, the IRQs are allocated from the interrupt pool associated
+ * with the MC 

[PATCH v3 09/11] staging: fsl-mc: Fixed bug in dprc_probe() error path

[J. German Rivera]

Destroy mc_io in error path in dprc_probe() only if the mc_io was
created in this function.

Signed-off-by: J. German Rivera 
---
CHANGE HISTORY

Changes in v3: none

Changes in v2: none
- Addressed comment from Dan Carpenter
  * Renamed goto error labels to indicate what the goto does

 drivers/staging/fsl-mc/bus/dprc-driver.c | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/fsl-mc/bus/dprc-driver.c 
b/drivers/staging/fsl-mc/bus/dprc-driver.c
index 455379d..7f1ceb5 100644
--- a/drivers/staging/fsl-mc/bus/dprc-driver.c
+++ b/drivers/staging/fsl-mc/bus/dprc-driver.c
@@ -401,6 +401,7 @@ static int dprc_probe(struct fsl_mc_device *mc_dev)
size_t region_size;
struct device *parent_dev = mc_dev->dev.parent;
struct fsl_mc_bus *mc_bus = to_fsl_mc_bus(mc_dev);
+   bool mc_io_created = false;
bool msi_domain_set = false;

if (WARN_ON(strcmp(mc_dev->obj_desc.type, "dprc") != 0))
@@ -413,6 +414,9 @@ static int dprc_probe(struct fsl_mc_device *mc_dev)
/*
 * This is a child DPRC:
 */
+   if (WARN_ON(parent_dev->bus != _mc_bus_type))
+   return -EINVAL;
+
if (WARN_ON(mc_dev->obj_desc.region_count == 0))
return -EINVAL;

@@ -427,6 +431,9 @@ static int dprc_probe(struct fsl_mc_device *mc_dev)
 _dev->mc_io);
if (error < 0)
return error;
+
+   mc_io_created = true;
+
/*
 * Inherit parent MSI domain:
 */
@@ -457,7 +464,7 @@ static int dprc_probe(struct fsl_mc_device *mc_dev)
  _dev->mc_handle);
if (error < 0) {
dev_err(_dev->dev, "dprc_open() failed: %d\n", error);
-   goto error_cleanup_mc_io;
+   goto error_cleanup_msi_domain;
}

mutex_init(_bus->scan_mutex);
@@ -475,11 +482,15 @@ static int dprc_probe(struct fsl_mc_device *mc_dev)
 error_cleanup_open:
(void)dprc_close(mc_dev->mc_io, 0, mc_dev->mc_handle);

-error_cleanup_mc_io:
+error_cleanup_msi_domain:
if (msi_domain_set)
dev_set_msi_domain(_dev->dev, NULL);

-   fsl_destroy_mc_io(mc_dev->mc_io);
+   if (mc_io_created) {
+   fsl_destroy_mc_io(mc_dev->mc_io);
+   mc_dev->mc_io = NULL;
+   }
+
return error;
 }

--
2.3.3

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

[PATCH v3 06/11] staging: fsl-mc: Changed DPRC built-in portal's mc_io to be atomic

[J. German Rivera]

The DPRC built-in portal's mc_io is used to send commands to the MC
to program MSIs for MC objects. This is done by the
fsl_mc_msi_write_msg() callback, which is invoked by the generic MSI
layer with interrupts disabled. As a result, the mc_io used in
fsl_mc_msi_write_msg needs to be an atomic mc_io.

Signed-off-by: J. German Rivera 
---
CHANGE HISTORY

Changes in v3: none

Changes in v2: none

 drivers/staging/fsl-mc/bus/dprc-driver.c | 4 +++-
 drivers/staging/fsl-mc/bus/mc-bus.c  | 3 ++-
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/fsl-mc/bus/dprc-driver.c 
b/drivers/staging/fsl-mc/bus/dprc-driver.c
index a9ead0d..7bb30dd 100644
--- a/drivers/staging/fsl-mc/bus/dprc-driver.c
+++ b/drivers/staging/fsl-mc/bus/dprc-driver.c
@@ -396,7 +396,9 @@ static int dprc_probe(struct fsl_mc_device *mc_dev)
error = fsl_create_mc_io(_dev->dev,
 mc_dev->regions[0].start,
 region_size,
-NULL, 0, _dev->mc_io);
+NULL,
+FSL_MC_IO_ATOMIC_CONTEXT_PORTAL,
+_dev->mc_io);
if (error < 0)
return error;
}
diff --git a/drivers/staging/fsl-mc/bus/mc-bus.c 
b/drivers/staging/fsl-mc/bus/mc-bus.c
index 84db55b..d34f1af 100644
--- a/drivers/staging/fsl-mc/bus/mc-bus.c
+++ b/drivers/staging/fsl-mc/bus/mc-bus.c
@@ -702,7 +702,8 @@ static int fsl_mc_bus_probe(struct platform_device *pdev)
mc_portal_phys_addr = res.start;
mc_portal_size = resource_size();
error = fsl_create_mc_io(>dev, mc_portal_phys_addr,
-mc_portal_size, NULL, 0, _io);
+mc_portal_size, NULL,
+FSL_MC_IO_ATOMIC_CONTEXT_PORTAL, _io);
if (error < 0)
return error;

--
2.3.3

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

[PATCH v3 03/11] staging: fsl-mc: Added generic MSI support for FSL-MC devices

[J. German Rivera]

Created an MSI domain for the fsl-mc bus-- including functions
to create a domain, find a domain, alloc/free domain irqs, and
bus specific overrides for domain and irq_chip ops.

Signed-off-by: J. German Rivera 
---
CHANGE HISTORY

Changes in v3: none
- Addressed comments from Marc Zyngier:
  * Added WARN_ON in fsl_mc_msi_set_desc to check that caller does
not set set_desc
  * Changed type of paddr in irq_cfg to be phys_addr_t
  * Added WARN_ON in fsl_mc_msi_update_chip_op() to check that caller
does not set irq_write_msi_msg

Changes in v2: none

 drivers/staging/fsl-mc/bus/Kconfig  |   1 +
 drivers/staging/fsl-mc/bus/Makefile |   1 +
 drivers/staging/fsl-mc/bus/mc-msi.c | 285 
 drivers/staging/fsl-mc/include/dprc.h   |   2 +-
 drivers/staging/fsl-mc/include/mc-private.h |  17 ++
 drivers/staging/fsl-mc/include/mc.h |  17 ++
 6 files changed, 322 insertions(+), 1 deletion(-)
 create mode 100644 drivers/staging/fsl-mc/bus/mc-msi.c

diff --git a/drivers/staging/fsl-mc/bus/Kconfig 
b/drivers/staging/fsl-mc/bus/Kconfig
index 0d779d9..c498ac6 100644
--- a/drivers/staging/fsl-mc/bus/Kconfig
+++ b/drivers/staging/fsl-mc/bus/Kconfig
@@ -9,6 +9,7 @@
 config FSL_MC_BUS
tristate "Freescale Management Complex (MC) bus driver"
depends on OF && ARM64
+   select GENERIC_MSI_IRQ_DOMAIN
help
  Driver to enable the bus infrastructure for the Freescale
   QorIQ Management Complex (fsl-mc). The fsl-mc is a hardware
diff --git a/drivers/staging/fsl-mc/bus/Makefile 
b/drivers/staging/fsl-mc/bus/Makefile
index 25433a9..a5f2ba4 100644
--- a/drivers/staging/fsl-mc/bus/Makefile
+++ b/drivers/staging/fsl-mc/bus/Makefile
@@ -13,5 +13,6 @@ mc-bus-driver-objs := mc-bus.o \
  dpmng.o \
  dprc-driver.o \
  mc-allocator.o \
+ mc-msi.o \
  dpmcp.o \
  dpbp.o
diff --git a/drivers/staging/fsl-mc/bus/mc-msi.c 
b/drivers/staging/fsl-mc/bus/mc-msi.c
new file mode 100644
index 000..d6ac465
--- /dev/null
+++ b/drivers/staging/fsl-mc/bus/mc-msi.c
@@ -0,0 +1,285 @@
+/*
+ * Freescale Management Complex (MC) bus driver MSI support
+ *
+ * Copyright (C) 2015 Freescale Semiconductor, Inc.
+ * Author: German Rivera 
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include "../include/mc-private.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "../include/mc-sys.h"
+#include "dprc-cmd.h"
+
+static void fsl_mc_msi_set_desc(msi_alloc_info_t *arg,
+   struct msi_desc *desc)
+{
+   arg->desc = desc;
+   arg->hwirq = (irq_hw_number_t)desc->fsl_mc.msi_index;
+}
+
+static void fsl_mc_msi_update_dom_ops(struct msi_domain_info *info)
+{
+   struct msi_domain_ops *ops = info->ops;
+
+   if (WARN_ON(!ops))
+   return;
+
+   /*
+* set_desc should not be set by the caller
+*/
+   if (WARN_ON(ops->set_desc))
+   return;
+
+   ops->set_desc = fsl_mc_msi_set_desc;
+}
+
+static void __fsl_mc_msi_write_msg(struct fsl_mc_device *mc_bus_dev,
+  struct fsl_mc_device_irq *mc_dev_irq)
+{
+   int error;
+   struct fsl_mc_device *owner_mc_dev = mc_dev_irq->mc_dev;
+   struct msi_desc *msi_desc = mc_dev_irq->msi_desc;
+   struct dprc_irq_cfg irq_cfg;
+
+   /*
+* msi_desc->msg.address is 0x0 when this function is invoked in
+* the free_irq() code path. In this case, for the MC, we don't
+* really need to "unprogram" the MSI, so we just return.
+*/
+   if (msi_desc->msg.address_lo == 0x0 && msi_desc->msg.address_hi == 0x0)
+   return;
+
+   if (WARN_ON(!owner_mc_dev))
+   return;
+
+   irq_cfg.paddr = ((u64)msi_desc->msg.address_hi << 32) |
+   msi_desc->msg.address_lo;
+   irq_cfg.val = msi_desc->msg.data;
+   irq_cfg.user_irq_id = msi_desc->irq;
+
+   if (owner_mc_dev == mc_bus_dev) {
+   /*
+* IRQ is for the mc_bus_dev's DPRC itself
+*/
+   error = dprc_set_irq(mc_bus_dev->mc_io,
+MC_CMD_FLAG_INTR_DIS | MC_CMD_FLAG_PRI,
+mc_bus_dev->mc_handle,
+mc_dev_irq->dev_irq_index,
+_cfg);
+   if (error < 0) {
+   dev_err(_mc_dev->dev,
+   "dprc_set_irq() failed: %d\n", error);
+   }
+   } else {
+   /*
+* IRQ is for for a child device of mc_bus_dev
+*/
+   error = dprc_set_obj_irq(mc_bus_dev->mc_io,
+  

[PATCH v3 11/11] staging: fsl-mc: Added MSI support to the MC bus driver

[J. German Rivera]

Initialize/Cleanup ITS-MSI support for the MC bus driver at driver
init/exit time. Associate an MSI domain with each DPAA2 child device.

Signed-off-by: J. German Rivera 
---
CHANGE HISTORY

Changes in v3: none

Changes in v2: none

 drivers/staging/fsl-mc/bus/mc-bus.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/staging/fsl-mc/bus/mc-bus.c 
b/drivers/staging/fsl-mc/bus/mc-bus.c
index d34f1af..9317561 100644
--- a/drivers/staging/fsl-mc/bus/mc-bus.c
+++ b/drivers/staging/fsl-mc/bus/mc-bus.c
@@ -16,6 +16,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include "../include/dpmng.h"
 #include "../include/mc-sys.h"
 #include "dprc-cmd.h"
@@ -472,6 +474,8 @@ int fsl_mc_device_add(struct dprc_obj_desc *obj_desc,
mc_dev->icid = parent_mc_dev->icid;
mc_dev->dma_mask = FSL_MC_DEFAULT_DMA_MASK;
mc_dev->dev.dma_mask = _dev->dma_mask;
+   dev_set_msi_domain(_dev->dev,
+  dev_get_msi_domain(_mc_dev->dev));
}

/*
@@ -833,8 +837,15 @@ static int __init fsl_mc_bus_driver_init(void)
if (error < 0)
goto error_cleanup_dprc_driver;

+   error = its_fsl_mc_msi_init();
+   if (error < 0)
+   goto error_cleanup_mc_allocator;
+
return 0;

+error_cleanup_mc_allocator:
+   fsl_mc_allocator_driver_exit();
+
 error_cleanup_dprc_driver:
dprc_driver_exit();

@@ -856,6 +867,7 @@ static void __exit fsl_mc_bus_driver_exit(void)
if (WARN_ON(!mc_dev_cache))
return;

+   its_fsl_mc_msi_cleanup();
fsl_mc_allocator_driver_exit();
dprc_driver_exit();
platform_driver_unregister(_mc_bus_driver);
--
2.3.3

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

[PATCH v3 04/11] staging: fsl-mc: Added GICv3-ITS support for FSL-MC MSIs

[J. German Rivera]

Added platform-specific MSI support layer for FSL-MC devices.

Signed-off-by: J. German Rivera 
---
CHANGE HISTORY

Changes in v3: none

Changes in v2: none

 drivers/staging/fsl-mc/bus/Makefile|   1 +
 .../staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c | 127 +
 drivers/staging/fsl-mc/include/mc-private.h|   4 +
 3 files changed, 132 insertions(+)
 create mode 100644 drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c

diff --git a/drivers/staging/fsl-mc/bus/Makefile 
b/drivers/staging/fsl-mc/bus/Makefile
index a5f2ba4..e731517 100644
--- a/drivers/staging/fsl-mc/bus/Makefile
+++ b/drivers/staging/fsl-mc/bus/Makefile
@@ -14,5 +14,6 @@ mc-bus-driver-objs := mc-bus.o \
  dprc-driver.o \
  mc-allocator.o \
  mc-msi.o \
+ irq-gic-v3-its-fsl-mc-msi.o \
  dpmcp.o \
  dpbp.o
diff --git a/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c 
b/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c
new file mode 100644
index 000..5319afa
--- /dev/null
+++ b/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c
@@ -0,0 +1,127 @@
+/*
+ * Freescale Management Complex (MC) bus driver MSI support
+ *
+ * Copyright (C) 2015 Freescale Semiconductor, Inc.
+ * Author: German Rivera 
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include "../include/mc-private.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "../include/mc-sys.h"
+#include "dprc-cmd.h"
+
+static struct irq_chip its_msi_irq_chip = {
+   .name = "fsl-mc-bus-msi",
+   .irq_mask = irq_chip_mask_parent,
+   .irq_unmask = irq_chip_unmask_parent,
+   .irq_eoi = irq_chip_eoi_parent,
+   .irq_set_affinity = msi_domain_set_affinity
+};
+
+static int its_fsl_mc_msi_prepare(struct irq_domain *msi_domain,
+ struct device *dev,
+ int nvec, msi_alloc_info_t *info)
+{
+   u32 its_dev_id;
+   struct fsl_mc_device *mc_bus_dev = to_fsl_mc_device(dev);
+   struct msi_domain_info *msi_info;
+
+   if (WARN_ON(dev->bus != _mc_bus_type))
+   return -EINVAL;
+
+   if (WARN_ON(!(mc_bus_dev->flags & FSL_MC_IS_DPRC)))
+   return -EINVAL;
+
+   /*
+* Set the device Id to be passed to the GIC-ITS:
+*
+* NOTE: This device id corresponds to the IOMMU stream ID
+* associated with the DPRC object (ICID).
+*/
+   its_dev_id = mc_bus_dev->icid;
+   info->scratchpad[0].ul = its_dev_id;
+   msi_info = msi_get_domain_info(msi_domain->parent);
+   return msi_info->ops->msi_prepare(msi_domain->parent, dev, nvec, info);
+}
+
+static struct msi_domain_ops its_fsl_mc_msi_ops = {
+   .msi_prepare = its_fsl_mc_msi_prepare,
+};
+
+static struct msi_domain_info its_fsl_mc_msi_domain_info = {
+   .flags  = (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS),
+   .ops= _fsl_mc_msi_ops,
+   .chip   = _msi_irq_chip,
+};
+
+static const struct of_device_id its_device_id[] = {
+   {   .compatible = "arm,gic-v3-its", },
+   {},
+};
+
+int __init its_fsl_mc_msi_init(void)
+{
+   struct device_node *np;
+   struct irq_domain *parent;
+   struct irq_domain *mc_msi_domain;
+
+   for (np = of_find_matching_node(NULL, its_device_id); np;
+np = of_find_matching_node(np, its_device_id)) {
+   if (!of_property_read_bool(np, "msi-controller"))
+   continue;
+
+   parent = irq_find_matching_host(np, DOMAIN_BUS_NEXUS);
+   if (!parent || !msi_get_domain_info(parent)) {
+   pr_err("%s: unable to locate ITS domain\n",
+  np->full_name);
+   continue;
+   }
+
+   mc_msi_domain =
+   fsl_mc_msi_create_irq_domain(of_node_to_fwnode(np),
+_fsl_mc_msi_domain_info,
+parent);
+   if (!mc_msi_domain) {
+   pr_err("%s: unable to create fsl-mc domain\n",
+  np->full_name);
+   continue;
+   }
+
+   WARN_ON(mc_msi_domain->host_data !=
+   _fsl_mc_msi_domain_info);
+
+   pr_info("fsl-mc MSI: %s domain created\n", np->full_name);
+   }
+
+   return 0;
+}
+
+void its_fsl_mc_msi_cleanup(void)
+{
+   struct device_node *np;
+
+   for (np = of_find_matching_node(NULL, its_device_id); np;
+np = of_find_matching_node(np, its_device_id)) {
+   struct irq_domain *mc_msi_domain =
+  

[PATCH v3 01/11] irqdomain: Added domain bus token DOMAIN_BUS_FSL_MC_MSI

[J. German Rivera]

Since an FSL-MC bus is a new bus type that is neither PCI nor
PLATFORM, we need a new domain bus token to disambiguate the
IRQ domain for FSL-MC MSIs.

Signed-off-by: J. German Rivera 
---
CHANGE HISTORY

Changes in v3: none

Changes in v2: none

 include/linux/irqdomain.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index d5e5c5b..c0cb5d1 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -73,6 +73,7 @@ enum irq_domain_bus_token {
DOMAIN_BUS_PCI_MSI,
DOMAIN_BUS_PLATFORM_MSI,
DOMAIN_BUS_NEXUS,
+   DOMAIN_BUS_FSL_MC_MSI,
 };

 /**
--
2.3.3

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

[PATCH v3 07/11] staging: fsl-mc: Populate the IRQ pool for an MC bus instance

[J. German Rivera]

Scan the corresponding DPRC container to get total count
of IRQs needed by all its child DPAA2 objects. Then,
preallocate a set of MSI IRQs with the DPRC's ICID
(GIT-ITS device Id) to populate the the DPRC's IRQ pool.
Each child DPAA2 object in the DPRC and the DPRC object itself
will allocate their necessary MSI IRQs from the DPRC's IRQ pool,
in their driver probe function.

Signed-off-by: J. German Rivera 
---
CHANGE HISTORY

Changes in v3: none

Changes in v2: none

 drivers/staging/fsl-mc/bus/dprc-driver.c| 24 ++--
 drivers/staging/fsl-mc/include/mc-private.h |  3 ++-
 2 files changed, 24 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/fsl-mc/bus/dprc-driver.c 
b/drivers/staging/fsl-mc/bus/dprc-driver.c
index 7bb30dd..3bcd161 100644
--- a/drivers/staging/fsl-mc/bus/dprc-driver.c
+++ b/drivers/staging/fsl-mc/bus/dprc-driver.c
@@ -241,6 +241,7 @@ static void dprc_cleanup_all_resource_pools(struct 
fsl_mc_device *mc_bus_dev)
  * dprc_scan_objects - Discover objects in a DPRC
  *
  * @mc_bus_dev: pointer to the fsl-mc device that represents a DPRC object
+ * @total_irq_count: total number of IRQs needed by objects in the DPRC.
  *
  * Detects objects added and removed from a DPRC and synchronizes the
  * state of the Linux bus driver, MC by adding and removing
@@ -254,11 +255,13 @@ static void dprc_cleanup_all_resource_pools(struct 
fsl_mc_device *mc_bus_dev)
  * populated before they can get allocation requests from probe callbacks
  * of the device drivers for the non-allocatable devices.
  */
-int dprc_scan_objects(struct fsl_mc_device *mc_bus_dev)
+int dprc_scan_objects(struct fsl_mc_device *mc_bus_dev,
+ unsigned int *total_irq_count)
 {
int num_child_objects;
int dprc_get_obj_failures;
int error;
+   unsigned int irq_count = mc_bus_dev->obj_desc.irq_count;
struct dprc_obj_desc *child_obj_desc_array = NULL;

error = dprc_get_obj_count(mc_bus_dev->mc_io,
@@ -307,6 +310,7 @@ int dprc_scan_objects(struct fsl_mc_device *mc_bus_dev)
continue;
}

+   irq_count += obj_desc->irq_count;
dev_dbg(_bus_dev->dev,
"Discovered object: type %s, id %d\n",
obj_desc->type, obj_desc->id);
@@ -319,6 +323,7 @@ int dprc_scan_objects(struct fsl_mc_device *mc_bus_dev)
}
}

+   *total_irq_count = irq_count;
dprc_remove_devices(mc_bus_dev, child_obj_desc_array,
num_child_objects);

@@ -344,6 +349,7 @@ EXPORT_SYMBOL_GPL(dprc_scan_objects);
 int dprc_scan_container(struct fsl_mc_device *mc_bus_dev)
 {
int error;
+   unsigned int irq_count;
struct fsl_mc_bus *mc_bus = to_fsl_mc_bus(mc_bus_dev);

dprc_init_all_resource_pools(mc_bus_dev);
@@ -352,11 +358,25 @@ int dprc_scan_container(struct fsl_mc_device *mc_bus_dev)
 * Discover objects in the DPRC:
 */
mutex_lock(_bus->scan_mutex);
-   error = dprc_scan_objects(mc_bus_dev);
+   error = dprc_scan_objects(mc_bus_dev, _count);
mutex_unlock(_bus->scan_mutex);
if (error < 0)
goto error;

+   if (dev_get_msi_domain(_bus_dev->dev) && !mc_bus->irq_resources) {
+   if (irq_count > FSL_MC_IRQ_POOL_MAX_TOTAL_IRQS) {
+   dev_warn(_bus_dev->dev,
+"IRQs needed (%u) exceed IRQs preallocated 
(%u)\n",
+irq_count, FSL_MC_IRQ_POOL_MAX_TOTAL_IRQS);
+   }
+
+   error = fsl_mc_populate_irq_pool(
+   mc_bus,
+   FSL_MC_IRQ_POOL_MAX_TOTAL_IRQS);
+   if (error < 0)
+   goto error;
+   }
+
return 0;
 error:
dprc_cleanup_all_resource_pools(mc_bus_dev);
diff --git a/drivers/staging/fsl-mc/include/mc-private.h 
b/drivers/staging/fsl-mc/include/mc-private.h
index 97295f0..27834ea 100644
--- a/drivers/staging/fsl-mc/include/mc-private.h
+++ b/drivers/staging/fsl-mc/include/mc-private.h
@@ -114,7 +114,8 @@ void fsl_mc_device_remove(struct fsl_mc_device *mc_dev);

 int dprc_scan_container(struct fsl_mc_device *mc_bus_dev);

-int dprc_scan_objects(struct fsl_mc_device *mc_bus_dev);
+int dprc_scan_objects(struct fsl_mc_device *mc_bus_dev,
+ unsigned int *total_irq_count);

 int __init dprc_driver_init(void);

--
2.3.3

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

Re: [PATCH 4.2 000/110] 4.2.6-stable review

[Guenter Roeck]

On 11/06/2015 11:18 AM, Greg Kroah-Hartman wrote:

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

Responses should be made by Sun Nov  8 19:16:22 UTC 2015.
Anything received after that time might be too late.



Build results:
total: 144 pass: 144 fail: 0
Qemu test results:
total: 94 pass: 94 fail: 0

Details are available at http://server.roeck-us.net:8010/builders.

Guenter

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

Re: [PATCH 4.1 00/86] 4.1.13-stable review

[Guenter Roeck]

On 11/06/2015 11:21 AM, Greg Kroah-Hartman wrote:

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

Responses should be made by Sun Nov  8 19:21:32 UTC 2015.
Anything received after that time might be too late.



Build results:
total: 137 pass: 137 fail: 0
Qemu test results:
total: 94 pass: 94 fail: 0

Details are available at http://server.roeck-us.net:8010/builders.

Guenter

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

Re: [PATCH 3.14 00/37] 3.14.57-stable review

[Guenter Roeck]

On 11/06/2015 11:24 AM, Greg Kroah-Hartman wrote:

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

Responses should be made by Sun Nov  8 19:23:35 UTC 2015.
Anything received after that time might be too late.



Build results:
total: 127 pass: 127 fail: 0
Qemu test results:
total: 81 pass: 81 fail: 0

Details are available at http://server.roeck-us.net:8010/builders.

Guenter

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

Re: [PATCH 3.10 00/24] 3.10.93-stable review

[Guenter Roeck]

On 11/06/2015 11:24 AM, Greg Kroah-Hartman wrote:

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

Responses should be made by Sun Nov  8 19:23:41 UTC 2015.
Anything received after that time might be too late.



Build results:
total: 121 pass: 121 fail: 0
Qemu test results:
total: 71 pass: 71 fail: 0

Details are available at http://server.roeck-us.net:8010/builders.

Guenter


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

[RFC] kprobes: Use percpu counter to collect nhit statistics

[Martin KaFai Lau]

When doing ebpf+kprobe on some hot TCP functions (e.g.
tcp_rcv_established), the kprobe_dispatcher shows up in 'perf report'.

In kprobe_dispatcher(), there is a lot of cache bouncing
in 'tk->nhit++'.  'tk->nhit' and 'tk->tp.flags' also share
the same cacheline.

perf report (cycles:pp):
8.30%  ipv4_dst_check
4.74%  copy_user_enhanced_fast_string
3.93%  dst_release
2.80%  tcp_v4_rcv
2.31%  queued_spin_lock_slowpath
2.30%  _raw_spin_lock
1.88%  mlx4_en_process_rx_cq
1.84%  eth_get_headlen
1.81%  ip_rcv_finish

1.71%  kprobe_dispatcher

1.55%  mlx4_en_xmit
1.09%  __probe_kernel_read

perf report after patch:
9.15%  ipv4_dst_check
5.00%  copy_user_enhanced_fast_string
4.12%  dst_release
2.96%  tcp_v4_rcv
2.50%  _raw_spin_lock
2.39%  queued_spin_lock_slowpath
2.11%  eth_get_headlen
2.03%  mlx4_en_process_rx_cq
1.69%  mlx4_en_xmit
1.19%  ip_rcv_finish
1.12%  __probe_kernel_read
1.02%  ehci_hcd_cleanup

Signed-off-by: Martin KaFai Lau 
---
 kernel/trace/trace_kprobe.c | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index c995644..91a441b 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -30,7 +30,7 @@
 struct trace_kprobe {
struct list_headlist;
struct kretproberp; /* Use rp.kp for kprobe use */
-   unsigned long   nhit;
+   unsigned long * __percpu nhit;
const char  *symbol;/* symbol name */
struct trace_probe  tp;
 };
@@ -274,6 +274,10 @@ static struct trace_kprobe *alloc_trace_kprobe(const char 
*group,
if (!tk)
return ERR_PTR(ret);
 
+   tk->nhit = alloc_percpu(unsigned long);
+   if (!tk->nhit)
+   goto error;
+
if (symbol) {
tk->symbol = kstrdup(symbol, GFP_KERNEL);
if (!tk->symbol)
@@ -313,6 +317,7 @@ static struct trace_kprobe *alloc_trace_kprobe(const char 
*group,
 error:
kfree(tk->tp.call.name);
kfree(tk->symbol);
+   free_percpu(tk->nhit);
kfree(tk);
return ERR_PTR(ret);
 }
@@ -327,6 +332,7 @@ static void free_trace_kprobe(struct trace_kprobe *tk)
kfree(tk->tp.call.class->system);
kfree(tk->tp.call.name);
kfree(tk->symbol);
+   free_percpu(tk->nhit);
kfree(tk);
 }
 
@@ -874,9 +880,14 @@ static const struct file_operations kprobe_events_ops = {
 static int probes_profile_seq_show(struct seq_file *m, void *v)
 {
struct trace_kprobe *tk = v;
+   unsigned long nhit = 0;
+   int cpu;
+
+   for_each_possible_cpu(cpu)
+   nhit += *per_cpu_ptr(tk->nhit, cpu);
 
seq_printf(m, "  %-44s %15lu %15lu\n",
-  trace_event_name(>tp.call), tk->nhit,
+  trace_event_name(>tp.call), nhit,
   tk->rp.kp.nmissed);
 
return 0;
@@ -1225,7 +1236,7 @@ static int kprobe_dispatcher(struct kprobe *kp, struct 
pt_regs *regs)
 {
struct trace_kprobe *tk = container_of(kp, struct trace_kprobe, rp.kp);
 
-   tk->nhit++;
+   raw_cpu_inc(*tk->nhit);
 
if (tk->tp.flags & TP_FLAG_TRACE)
kprobe_trace_func(tk, regs);
@@ -1242,7 +1253,7 @@ kretprobe_dispatcher(struct kretprobe_instance *ri, 
struct pt_regs *regs)
 {
struct trace_kprobe *tk = container_of(ri->rp, struct trace_kprobe, rp);
 
-   tk->nhit++;
+   raw_cpu_inc(*tk->nhit);
 
if (tk->tp.flags & TP_FLAG_TRACE)
kretprobe_trace_func(tk, ri, regs);
-- 
2.5.1

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

[RFC] kprobes: Use percpu counter to collect nhit statistics

[Martin KaFai Lau]

When doing ebpf+kprobe on some hot TCP functions (e.g.
tcp_rcv_established), the kprobe_dispatcher shows up in 'perf report'.

In kprobe_dispatcher(), there is a lot of cache bouncing
in 'tk->nhit++'.  'tk->nhit' and 'tk->tp.flags' also share
the same cacheline.

perf report (cycles:pp):
8.30%  ipv4_dst_check
4.74%  copy_user_enhanced_fast_string
3.93%  dst_release
2.80%  tcp_v4_rcv
2.31%  queued_spin_lock_slowpath
2.30%  _raw_spin_lock
1.88%  mlx4_en_process_rx_cq
1.84%  eth_get_headlen
1.81%  ip_rcv_finish

1.71%  kprobe_dispatcher

1.55%  mlx4_en_xmit
1.09%  __probe_kernel_read

perf report after patch:
9.15%  ipv4_dst_check
5.00%  copy_user_enhanced_fast_string
4.12%  dst_release
2.96%  tcp_v4_rcv
2.50%  _raw_spin_lock
2.39%  queued_spin_lock_slowpath
2.11%  eth_get_headlen
2.03%  mlx4_en_process_rx_cq
1.69%  mlx4_en_xmit
1.19%  ip_rcv_finish
1.12%  __probe_kernel_read
1.02%  ehci_hcd_cleanup

Signed-off-by: Martin KaFai Lau 
---
 kernel/trace/trace_kprobe.c | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index c995644..91a441b 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -30,7 +30,7 @@
 struct trace_kprobe {
struct list_headlist;
struct kretproberp; /* Use rp.kp for kprobe use */
-   unsigned long   nhit;
+   unsigned long * __percpu nhit;
const char  *symbol;/* symbol name */
struct trace_probe  tp;
 };
@@ -274,6 +274,10 @@ static struct trace_kprobe *alloc_trace_kprobe(const char 
*group,
if (!tk)
return ERR_PTR(ret);
 
+   tk->nhit = alloc_percpu(unsigned long);
+   if (!tk->nhit)
+   goto error;
+
if (symbol) {
tk->symbol = kstrdup(symbol, GFP_KERNEL);
if (!tk->symbol)
@@ -313,6 +317,7 @@ static struct trace_kprobe *alloc_trace_kprobe(const char 
*group,
 error:
kfree(tk->tp.call.name);
kfree(tk->symbol);
+   free_percpu(tk->nhit);
kfree(tk);
return ERR_PTR(ret);
 }
@@ -327,6 +332,7 @@ static void free_trace_kprobe(struct trace_kprobe *tk)
kfree(tk->tp.call.class->system);
kfree(tk->tp.call.name);
kfree(tk->symbol);
+   free_percpu(tk->nhit);
kfree(tk);
 }
 
@@ -874,9 +880,14 @@ static const struct file_operations kprobe_events_ops = {
 static int probes_profile_seq_show(struct seq_file *m, void *v)
 {
struct trace_kprobe *tk = v;
+   unsigned long nhit = 0;
+   int cpu;
+
+   for_each_possible_cpu(cpu)
+   nhit += *per_cpu_ptr(tk->nhit, cpu);
 
seq_printf(m, "  %-44s %15lu %15lu\n",
-  trace_event_name(>tp.call), tk->nhit,
+  trace_event_name(>tp.call), nhit,
   tk->rp.kp.nmissed);
 
return 0;
@@ -1225,7 +1236,7 @@ static int kprobe_dispatcher(struct kprobe *kp, struct 
pt_regs *regs)
 {
struct trace_kprobe *tk = container_of(kp, struct trace_kprobe, rp.kp);
 
-   tk->nhit++;
+   raw_cpu_inc(*tk->nhit);
 
if (tk->tp.flags & TP_FLAG_TRACE)
kprobe_trace_func(tk, regs);
@@ -1242,7 +1253,7 @@ kretprobe_dispatcher(struct kretprobe_instance *ri, 
struct pt_regs *regs)
 {
struct trace_kprobe *tk = container_of(ri->rp, struct trace_kprobe, rp);
 
-   tk->nhit++;
+   raw_cpu_inc(*tk->nhit);
 
if (tk->tp.flags & TP_FLAG_TRACE)
kretprobe_trace_func(tk, ri, regs);
-- 
2.5.1

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

[PATCH v2 4/4] usb: dwc2: host: Giveback URB in tasklet context

[Douglas Anderson]

In commit 94dfd7edfd5c ("USB: HCD: support giveback of URB in tasklet
context") support was added to give back the URB in tasklet context.
Let's take advantage of this in dwc2.

This speeds up the dwc2 interrupt handler considerably.

Note that this requires the change ("usb: dwc2: host: Add a delay before
releasing periodic bandwidth") to come first.

Signed-off-by: Douglas Anderson 
Tested-by: Heiko Stuebner 
---
Changes in v2:
- Commit message now says that URB giveback change needs delay change.

 drivers/usb/dwc2/hcd.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index 33495b235b3c..b899b06b41cc 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -2266,9 +2266,7 @@ void dwc2_host_complete(struct dwc2_hsotg *hsotg, struct 
dwc2_qtd *qtd,
kfree(qtd->urb);
qtd->urb = NULL;
 
-   spin_unlock(>lock);
usb_hcd_giveback_urb(dwc2_hsotg_to_hcd(hsotg), urb, status);
-   spin_lock(>lock);
 }
 
 /*
@@ -2881,7 +2879,7 @@ static struct hc_driver dwc2_hc_driver = {
.hcd_priv_size = sizeof(struct wrapper_priv_data),
 
.irq = _dwc2_hcd_irq,
-   .flags = HCD_MEMORY | HCD_USB2,
+   .flags = HCD_MEMORY | HCD_USB2 | HCD_BH,
 
.start = _dwc2_hcd_start,
.stop = _dwc2_hcd_stop,
-- 
2.6.0.rc2.230.g3dd15c0

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

[PATCH v2 2/4] usb: dwc2: host: Get aligned DMA in a more supported way

[Douglas Anderson]

All other host controllers who want aligned buffers for DMA do it a
certain way.  Let's do that too instead of working behind the USB core's
back.  This makes our interrupt handler not take forever and also rips
out a lot of code, simplifying things a bunch.

This also has the side effect of removing the 65535 max transfer size
limit.

NOTE: The actual code to allocate the aligned buffers is ripped almost
completely from the tegra EHCI driver.  At some point in the future we
may want to add this functionality to the USB core to share more code
everywhere.

Signed-off-by: Douglas Anderson 
Tested-by: Heiko Stuebner 
---
Changes in v2:
- Add a warn if setup_dma is not aligned (Julius Werner).

 drivers/usb/dwc2/core.c  |  21 +-
 drivers/usb/dwc2/hcd.c   | 170 +--
 drivers/usb/dwc2/hcd.h   |  10 ---
 drivers/usb/dwc2/hcd_intr.c  |  65 -
 drivers/usb/dwc2/hcd_queue.c |   7 +-
 5 files changed, 87 insertions(+), 186 deletions(-)

diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index ef73e498e98f..7e28cfafcfd8 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -1830,19 +1830,11 @@ void dwc2_hc_start_transfer(struct dwc2_hsotg *hsotg,
}
 
if (hsotg->core_params->dma_enable > 0) {
-   dma_addr_t dma_addr;
-
-   if (chan->align_buf) {
-   if (dbg_hc(chan))
-   dev_vdbg(hsotg->dev, "align_buf\n");
-   dma_addr = chan->align_buf;
-   } else {
-   dma_addr = chan->xfer_dma;
-   }
-   dwc2_writel((u32)dma_addr, hsotg->regs + HCDMA(chan->hc_num));
+   dwc2_writel((u32)chan->xfer_dma,
+   hsotg->regs + HCDMA(chan->hc_num));
if (dbg_hc(chan))
dev_vdbg(hsotg->dev, "Wrote %08lx to HCDMA(%d)\n",
-(unsigned long)dma_addr, chan->hc_num);
+(unsigned long)chan->xfer_dma, chan->hc_num);
}
 
/* Start the split */
@@ -3137,13 +3129,6 @@ int dwc2_get_hwparams(struct dwc2_hsotg *hsotg)
width = (hwcfg3 & GHWCFG3_XFER_SIZE_CNTR_WIDTH_MASK) >>
GHWCFG3_XFER_SIZE_CNTR_WIDTH_SHIFT;
hw->max_transfer_size = (1 << (width + 11)) - 1;
-   /*
-* Clip max_transfer_size to 65535. dwc2_hc_setup_align_buf() allocates
-* coherent buffers with this size, and if it's too large we can
-* exhaust the coherent DMA pool.
-*/
-   if (hw->max_transfer_size > 65535)
-   hw->max_transfer_size = 65535;
width = (hwcfg3 & GHWCFG3_PACKET_SIZE_CNTR_WIDTH_MASK) >>
GHWCFG3_PACKET_SIZE_CNTR_WIDTH_SHIFT;
hw->max_packet_count = (1 << (width + 4)) - 1;
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index e79baf73c234..33495b235b3c 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -598,9 +598,9 @@ static void dwc2_hc_init_split(struct dwc2_hsotg *hsotg,
chan->hub_port = (u8)hub_port;
 }
 
-static void *dwc2_hc_init_xfer(struct dwc2_hsotg *hsotg,
-  struct dwc2_host_chan *chan,
-  struct dwc2_qtd *qtd, void *bufptr)
+static void dwc2_hc_init_xfer(struct dwc2_hsotg *hsotg,
+ struct dwc2_host_chan *chan,
+ struct dwc2_qtd *qtd)
 {
struct dwc2_hcd_urb *urb = qtd->urb;
struct dwc2_hcd_iso_packet_desc *frame_desc;
@@ -620,7 +620,6 @@ static void *dwc2_hc_init_xfer(struct dwc2_hsotg *hsotg,
else
chan->xfer_buf = urb->setup_packet;
chan->xfer_len = 8;
-   bufptr = NULL;
break;
 
case DWC2_CONTROL_DATA:
@@ -647,7 +646,6 @@ static void *dwc2_hc_init_xfer(struct dwc2_hsotg *hsotg,
chan->xfer_dma = hsotg->status_buf_dma;
else
chan->xfer_buf = hsotg->status_buf;
-   bufptr = NULL;
break;
}
break;
@@ -680,14 +678,6 @@ static void *dwc2_hc_init_xfer(struct dwc2_hsotg *hsotg,
 
chan->xfer_len = frame_desc->length - qtd->isoc_split_offset;
 
-   /* For non-dword aligned buffers */
-   if (hsotg->core_params->dma_enable > 0 &&
-   (chan->xfer_dma & 0x3))
-   bufptr = (u8 *)urb->buf + frame_desc->offset +
-   qtd->isoc_split_offset;
-   else
-   bufptr = NULL;
-
if (chan->xact_pos == DWC2_HCSPLT_XACTPOS_ALL) {
if (chan->xfer_len <= 188)
chan->xact_pos = DWC2_HCSPLT_XACTPOS_ALL;
@@ 

[PATCH v2 3/4] usb: dwc2: host: Add a delay before releasing periodic bandwidth

[Douglas Anderson]

We'd like to be able to use HCD_BH in order to speed up the dwc2 host
interrupt handler quite a bit.  However, according to the kernel doc for
usb_submit_urb() (specifically the part about "Reserved Bandwidth
Transfers"), we need to keep a reservation active as long as a device
driver keeps submitting.  That was easy to do when we gave back the URB
in the interrupt context: we just looked at when our queue was empty and
released the reserved bandwidth then.  ...but now we need a little more
complexity.

We'll follow EHCI's lead in commit 9118f9eb4f1e ("USB: EHCI: improve
interrupt qh unlink") and add a 5ms delay.  Since we don't have a whole
timer infrastructure in dwc2, we'll just add a timer per QH.  The
overhead for this is very small.

Signed-off-by: Douglas Anderson 
---
Changes in v2:
- Periodic bandwidth release delay new for V2

 drivers/usb/dwc2/hcd.h   |   6 ++
 drivers/usb/dwc2/hcd_queue.c | 232 +--
 2 files changed, 184 insertions(+), 54 deletions(-)

diff --git a/drivers/usb/dwc2/hcd.h b/drivers/usb/dwc2/hcd.h
index 8a4486e1a542..b75a8b116f6e 100644
--- a/drivers/usb/dwc2/hcd.h
+++ b/drivers/usb/dwc2/hcd.h
@@ -211,6 +211,7 @@ enum dwc2_transaction_type {
 /**
  * struct dwc2_qh - Software queue head structure
  *
+ * @hsotg:  The HCD state structure for the DWC OTG controller
  * @ep_type:Endpoint type. One of the following values:
  *   - USB_ENDPOINT_XFER_CONTROL
  *   - USB_ENDPOINT_XFER_BULK
@@ -247,13 +248,16 @@ enum dwc2_transaction_type {
  * @n_bytes:Xfer Bytes array. Each element corresponds to a 
transfer
  *  descriptor and indicates original XferSize value for 
the
  *  descriptor
+ * @unreserve_timer:Timer for releasing periodic reservation.
  * @tt_buffer_dirty True if clear_tt_buffer_complete is pending
+ * @unreserve_pending:  True if we planned to unreserve but haven't yet.
  *
  * A Queue Head (QH) holds the static characteristics of an endpoint and
  * maintains a list of transfers (QTDs) for that endpoint. A QH structure may
  * be entered in either the non-periodic or periodic schedule.
  */
 struct dwc2_qh {
+   struct dwc2_hsotg *hsotg;
u8 ep_type;
u8 ep_is_in;
u16 maxp;
@@ -275,7 +279,9 @@ struct dwc2_qh {
struct dwc2_hcd_dma_desc *desc_list;
dma_addr_t desc_list_dma;
u32 *n_bytes;
+   struct timer_list unreserve_timer;
unsigned tt_buffer_dirty:1;
+   unsigned unreserve_pending:1;
 };
 
 /**
diff --git a/drivers/usb/dwc2/hcd_queue.c b/drivers/usb/dwc2/hcd_queue.c
index 3e1edafc593c..10f27b594e92 100644
--- a/drivers/usb/dwc2/hcd_queue.c
+++ b/drivers/usb/dwc2/hcd_queue.c
@@ -53,6 +53,94 @@
 #include "core.h"
 #include "hcd.h"
 
+/* Wait this long before releasing periodic reservation */
+#define DWC2_UNRESERVE_DELAY (msecs_to_jiffies(5))
+
+/**
+ * dwc2_do_unreserve() - Actually release the periodic reservation
+ *
+ * This function actually releases the periodic bandwidth that was reserved
+ * by the given qh.
+ *
+ * @hsotg: The HCD state structure for the DWC OTG controller
+ * @qh:QH for the periodic transfer.
+ */
+static void dwc2_do_unreserve(struct dwc2_hsotg *hsotg, struct dwc2_qh *qh)
+{
+   assert_spin_locked(>lock);
+
+   WARN_ON(!qh->unreserve_pending);
+
+   if (WARN_ON(!list_empty(>qh_list_entry)))
+   list_del_init(>qh_list_entry);
+
+   /* Update claimed usecs per (micro)frame */
+   hsotg->periodic_usecs -= qh->usecs;
+
+   if (hsotg->core_params->uframe_sched > 0) {
+   int i;
+
+   for (i = 0; i < 8; i++) {
+   hsotg->frame_usecs[i] += qh->frame_usecs[i];
+   qh->frame_usecs[i] = 0;
+   }
+   } else {
+   /* Release periodic channel reservation */
+   hsotg->periodic_channels--;
+   }
+
+   /* No more unreserve pending--we're did it */
+   qh->unreserve_pending = false;
+}
+
+/**
+ * dwc2_unreserve_timer_fn() - Timer function to release periodic reservation
+ *
+ * According to the kernel doc for usb_submit_urb() (specifically the part 
about
+ * "Reserved Bandwidth Transfers"), we need to keep a reservation active as
+ * long as a device driver keeps submitting.  Since we're using HCD_BH to give
+ * back the URB we need to give the driver a little bit of time before we
+ * release the reservation.  This worker is called after the appropriate
+ * delay.
+ *
+ * @work: Pointer to a qh unreserve_work.
+ */
+static void dwc2_unreserve_timer_fn(unsigned long data)
+{
+   struct dwc2_qh *qh = (struct dwc2_qh *)data;
+   struct dwc2_hsotg *hsotg = qh->hsotg;
+   unsigned long flags;
+
+   /*
+* Wait for the lock, or for us to be scheduled again.  We
+* could be scheduled again if:
+* - We started executing but didn't get the lock 

[PATCH v2 0/4] dwc2: Speed up the interrupt handler quite a bit

[Douglas Anderson]

The dwc2 interrupt handler is quite slow.  On rk3288 with a few things
plugged into the ports and with cpufreq locked at 696MHz (to simulate
real world idle system), I can easily observe dwc2_handle_hcd_intr()
taking > 120 us, sometimes > 150 us.  Note that SOF interrupts come
every 125 us with high speed USB, so taking > 120 us in the interrupt
handler is a big deal.

The patches here will speed up the interrupt controller significantly.
After this series, I have a hard time seeing the interrupt controller
taking > 20 us and I don't ever see it taking > 30 us ever in my tests
unless I bring the cpufreq back down.  With the cpufreq at 126 MHz I can
still see the interrupt handler take > 50 us, so I'm sure we could
improve this further.  ...but hey, it's a start.

This series also shows big speed improvements when testing with a USB
Gigabit Ethernet adapter.  Previously the tested adapter would top out
at about 15MB/s.  After these changes it gets about 23MB/s.

In addition to the speedup, this series also has the advantage of
simplifying dwc2 and making it more like everyone else (introducing the
possibility of future simplifications).  Picking this series up will
help your diffstat and likely win you friends.  ;)

===

Steps for gathering data with ftrace:

cd /sys/devices/system/cpu/cpu0/cpufreq/
echo userspace > scaling_governor
echo 696000 > scaling_setspeed

cd /sys/kernel/debug/tracing
echo 0 > tracing_on
echo "" > trace
echo nop > current_tracer
echo function_graph > current_tracer
echo dwc2_handle_hcd_intr > set_graph_function
echo dwc2_handle_common_intr >> set_graph_function
echo dwc2_handle_hcd_intr > set_ftrace_filter
echo dwc2_handle_common_intr >> set_ftrace_filter
echo funcgraph-abstime > trace_options
echo 70 > tracing_thresh
echo 1 > /sys/kernel/debug/tracing/tracing_on

sleep 2
cat trace

===
NOTE: This series doesn't replace any other patches I've submitted
recently, it merely adds another set of changes that upstream could
benefit from.

Changes in v2:
- Add a warn if setup_dma is not aligned (Julius Werner).
- Periodic bandwidth release delay new for V2
- Commit message now says that URB giveback change needs delay change.

Douglas Anderson (4):
  usb: dwc2: rockchip: Make the max_transfer_size automatic
  usb: dwc2: host: Get aligned DMA in a more supported way
  usb: dwc2: host: Add a delay before releasing periodic bandwidth
  usb: dwc2: host: Giveback URB in tasklet context

 drivers/usb/dwc2/core.c  |  21 +---
 drivers/usb/dwc2/hcd.c   | 174 +++
 drivers/usb/dwc2/hcd.h   |  16 ++-
 drivers/usb/dwc2/hcd_intr.c  |  65 
 drivers/usb/dwc2/hcd_queue.c | 239 ---
 drivers/usb/dwc2/platform.c  |   2 +-
 6 files changed, 273 insertions(+), 244 deletions(-)

-- 
2.6.0.rc2.230.g3dd15c0

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

[PATCH v2 1/4] usb: dwc2: rockchip: Make the max_transfer_size automatic

[Douglas Anderson]

Previously we needed to set the max_transfer_size to explicitly be 65535
because the old driver would detect that our hardware could support much
bigger transfers and then would try to do them.  This wouldn't work
since the DMA alignment code couldn't support it.

Later in commit e8f8c14d9da7 ("usb: dwc2: clip max_transfer_size to
65535") upstream added support for clipping this automatically.  Since
that commit it has been OK to just use "-1" (default), but nobody
bothered to change it.

Let's change it to default now for two reasons:
- It's nice to use autodetected params.
- If we can remove the 65535 limit, we can transfer more!

Signed-off-by: Douglas Anderson 
Tested-by: Heiko Stuebner 
---
Changes in v2: None

 drivers/usb/dwc2/platform.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 5859b0fa19ee..f26e0c31c07e 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -95,7 +95,7 @@ static const struct dwc2_core_params params_rk3066 = {
.host_rx_fifo_size  = 520,  /* 520 DWORDs */
.host_nperio_tx_fifo_size   = 128,  /* 128 DWORDs */
.host_perio_tx_fifo_size= 256,  /* 256 DWORDs */
-   .max_transfer_size  = 65535,
+   .max_transfer_size  = -1,
.max_packet_count   = -1,
.host_channels  = -1,
.phy_type   = -1,
-- 
2.6.0.rc2.230.g3dd15c0

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

Re: [PATCH 2/3] usb: dwc2: host: Giveback URB in tasklet context

[Doug Anderson]

Alan,

On Fri, Nov 6, 2015 at 7:40 AM, Alan Stern  wrote:
> On Thu, 5 Nov 2015, Doug Anderson wrote:
>
>> Alan,
>>
>> On Thu, Nov 5, 2015 at 7:19 AM, Alan Stern  wrote:
>> > On Wed, 4 Nov 2015, Doug Anderson wrote:
>> >
>> >> In the ChromeOS gerrit
>> >>  Julius Werner
>> >> points out that for EHCI it was good to take the optimization from
>> >> commit 9118f9eb4f1e ("USB: EHCI: improve interrupt qh unlink") before
>> >> this one.  I'm still trying to learn USB / dwc2 so it's unclear to me
>> >> whether we also need a similar change before landing.
>> >>
>> >> I'll see if I can do some investigation about this and also some
>> >> benchmarking before and after.  Certainly profiling the interrupt
>> >> handler itself showed a huge improvement, but I'd hate to see a
>> >> regression elsewhere.
>> >>
>> >> If anyone else knows better than I, please speak up!  :)
>> >
>> > This is a matter of both efficiency and correctness.  Giving back URBs
>> > in a tasklet is not a simple change.
>> >
>> > Have you read the kerneldoc for usb_submit_urb() in
>> > drivers/usb/core/urb.c?  The portion about "Reserved Bandwidth
>> > Transfers" is highly relevant.  I don't know how dwc2 goes about
>> > reserving bandwidth for periodic transfers, but if it relies on the
>> > endpoint queue being non-empty to maintain a reservation then it will
>> > be affected by this change.
>>
>> It does look as if you are right and the reservation will end up being
>> released.  It looks to me like dwc2_deschedule_periodic() is in charge
>> of releasing the reservation.  I'll work on trying to actually confirm
>> this.  I guess I need to find a USB test setup where there are enough
>> devices that I exceed the available time so I can see the brokenness
>> of my old solution...
>
> You may not need that.  Try a single USB keyboard and see what happens
> when the interrupt URB is given back.

I haven't been able to reproduce any new errors with my patch, but I
have with trace_printk I have proven that it does cause reservations
to be lost and then re-gained, which isn't good.

Note that dwc2 is currently having scheduling problems anyway (even
before my patch).  l...@rock-chips.com posted an RFC patch to fix
problems he was seeing, but I have a setup that has problems too and
his patch doesn't fix it.  :(  ...so possibly if everything was
working then I could see my patch break things, but as it is now it's
hard to say.

In any case, I've finished testing the patch that adds a 5us delay
before releasing the reservation.  I'll post that so we can be on the
same page.


>> I hadn't realized that this was a correctness problem and not just an
>> optimization problem, so thank you very much for the info!  :)  I ran
>> with a bunch of USB devices and it worked fine (and performance
>> improved!) so I figured I was good to go...  Now I've read the
>> kerneldoc you pointed at and it was very helpful.  As I understand it,
>> it's considered OK if I copy what EHCI did and release the reservation
>> if nothing has been scheduled for 5 ms.
>
> You might also look into the issues surrounding isochronous URBs.  In
> particular, when an URB is submitted, which frames or microframes
> should it be scheduled in?  The problem is that when the submission
> occurs, some of the slots following the previous URB may already have
> expired.  The explanations for EXDEV and EFBIG in
> Documentation/usb/error-codes.txt are relevant here, although terse.
>
> The host controller drivers that I maintain work like this:
>
> If the endpoint's queue is empty and none of the endpoint's
> URBs are still being given back by the tasklet, pretend that
> the URB_ISO_ASAP flag is set.  Note that this involves
> testing hcd_periodic_completion_in_progress() -- that's
> where switching over to tasklets makes a difference.
>
> If the URB_ISO_ASAP flag is set, the URB is scheduled for
> the first unallocated slot that hasn't already expired.
>
> If the flag isn't set, try to schedule the URB for the first
> unallocated slot.  If that means all the isoc packets in the
> URB would be assigned to expired slots, return -EXDEV.  If
> some but not all of the packets would be assigned to expired
> slots, skip them -- only schedule the packets whose slots
> haven't expired yet.

You're talking to someone who has only been looking at the details of
USB for about 2 days now.  :-P  ...I'm trying to grok all of that, but
I'm not sure I got it all...

I will say that "URB_ISO_ASAP" is not referenced anywhere in dwc2.
Presumably that's a bug (or missing feature).  Would it be terrible if
I just ignored that for now and said that if you try to add something
to the queue and we're currently in the process of waiting for our
timer to expire then you'll just get back -ENOSPC?  dwc2 won't deal
perfectly well if you've very close to exhausting the 

Re: [PATCH -next] net: hisilicon: Never build on SPARC

[Guenter Roeck]

On 11/06/2015 12:30 PM, Arnd Bergmann wrote:

On Friday 06 November 2015 11:16:52 Guenter Roeck wrote:

On Wed, Oct 21, 2015 at 02:53:20PM -0700, Guenter Roeck wrote:

On Wed, Oct 21, 2015 at 09:11:53PM +0200, Arnd Bergmann wrote:

On Wednesday 21 October 2015 10:03:05 Guenter Roeck wrote:

Anyway, if it gets that complicated, I think we should stick with
just returning OF_BAD_ADDR. The above really suggests the need for
an architecture specific solution.


Probably no harm in this really: the far more common
of_address_to_resource() and of_iomap() helpers are equally
broken on SPARC and we just return a runtime error for those
as well without CONFIG_OF_ADDRESS rather than breaking the build.


Agreed. Given this, returning OF_BAD_ADDR sounds like a better choice.


Arnd,

do you know if a fix for this problem is pending in some branch ?
Mainline sparc builds are now affected.



I don't think anyone wrote the patch to do this. Can you send one?



I'll see what I can do.

Guenter


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

Re: [PATCH] jbd2: get rid of superfluous __GFP_REPEAT

[Tetsuo Handa]

On 2015/11/07 1:17, mho...@kernel.org wrote:
> From: Michal Hocko 
>
> jbd2_alloc is explicit about its allocation preferences wrt. the
> allocation size. Sub page allocations go to the slab allocator
> and larger are using either the page allocator or vmalloc. This
> is all good but the logic is unnecessarily complex. Requests larger
> than order-3 are doing the vmalloc directly while smaller go to the
> page allocator with __GFP_REPEAT. The flag doesn't do anything useful
> for those because they are smaller than PAGE_ALLOC_COSTLY_ORDER.
>
> Let's simplify the code flow and use kmalloc for sub-page requests
> and the page allocator for others with fallback to vmalloc if the
> allocation fails.
>
> Cc: "Theodore Ts'o" 
> Signed-off-by: Michal Hocko 
> ---
>   fs/jbd2/journal.c | 35 ---
>   1 file changed, 12 insertions(+), 23 deletions(-)
>
> diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c
> index 81e622681c82..2945c96f171f 100644
> --- a/fs/jbd2/journal.c
> +++ b/fs/jbd2/journal.c
> @@ -2299,18 +2299,15 @@ void *jbd2_alloc(size_t size, gfp_t flags)
>
>   BUG_ON(size & (size-1)); /* Must be a power of 2 */
>
> - flags |= __GFP_REPEAT;
> - if (size == PAGE_SIZE)
> - ptr = (void *)__get_free_pages(flags, 0);
> - else if (size > PAGE_SIZE) {
> + if (size < PAGE_SIZE)
> + ptr = kmem_cache_alloc(get_slab(size), flags);
> + else {
>   int order = get_order(size);
>
> - if (order < 3)
> - ptr = (void *)__get_free_pages(flags, order);
> - else
> + ptr = (void *)__get_free_pages(flags, order);

I thought that we can add __GFP_NOWARN for this __get_free_pages() call.
But I noticed more important problem. See below.

> + if (!ptr)
>   ptr = vmalloc(size);
> - } else
> - ptr = kmem_cache_alloc(get_slab(size), flags);
> + }
>
>   /* Check alignment; SLUB has gotten this wrong in the past,
>* and this can lead to user data corruption! */
> @@ -2321,20 +2318,12 @@ void *jbd2_alloc(size_t size, gfp_t flags)
>
>   void jbd2_free(void *ptr, size_t size)
>   {
> - if (size == PAGE_SIZE) {
> - free_pages((unsigned long)ptr, 0);
> - return;
> - }
> - if (size > PAGE_SIZE) {
> - int order = get_order(size);
> -
> - if (order < 3)
> - free_pages((unsigned long)ptr, order);
> - else
> - vfree(ptr);
> - return;
> - }
> - kmem_cache_free(get_slab(size), ptr);
> + if (size < PAGE_SIZE)
> + kmem_cache_free(get_slab(size), ptr);
> + else if (is_vmalloc_addr(ptr))
> + vfree(ptr);
> + else
> + free_pages((unsigned long)ptr, get_order(size));
>   };
>
>   /*
>

All jbd2_alloc() callers seem to pass GFP_NOFS. Therefore, use of
vmalloc() which implicitly passes GFP_KERNEL | __GFP_HIGHMEM can cause
deadlock, can't it? This vmalloc(size) call needs to be replaced with
__vmalloc(size, flags).

We need to check all vmalloc() callers in case they are calling vmalloc()
under GFP_KERNEL-unsafe context. For example, I think that __aa_kvmalloc()
needs to use __vmalloc() too.

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

Re: [PATCH v5 1/4] dt-bindings: mfd: s2mps11: add documentation for s2mps15 PMIC

[Alim Akhtar]

Hi Rob,

On Sat, Nov 7, 2015 at 4:03 AM, Rob Herring  wrote:
> On Fri, Oct 30, 2015 at 11:55:31AM +0530, Alim Akhtar wrote:
>> From: Thomas Abraham 
>>
>> Add dt-binding documentation for s2mps15 PMIC device. The s2mps15 device
>> is similar to s2mps11/14 PMIC device and has 27 LDO and 10 buck regulators.
>> This also supports RTC and three 32.768KHz clock outputs.
>>
>> Cc: devicet...@vger.kernel.org
>> Signed-off-by: Thomas Abraham 
>> Signed-off-by: Alim Akhtar 
>> ---
>>  Documentation/devicetree/bindings/mfd/s2mps11.txt |   21 
>> ++---
>>  1 file changed, 14 insertions(+), 7 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt 
>> b/Documentation/devicetree/bindings/mfd/s2mps11.txt
>> index 890f0b0e1643..4c0543ceec25 100644
>> --- a/Documentation/devicetree/bindings/mfd/s2mps11.txt
>> +++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt
>> @@ -1,5 +1,5 @@
>>
>> -* Samsung S2MPS11, S2MPS13, S2MPS14 and S2MPU02 Voltage and Current 
>> Regulator
>> +* Samsung S2MPS11/13/14/15 and S2MPU02 Voltage and Current Regulator
>>
>>  The Samsung S2MPS11 is a multi-function device which includes voltage and
>>  current regulators, RTC, charger controller and other sub-blocks. It is
>> @@ -7,8 +7,12 @@ interfaced to the host controller using an I2C interface. 
>> Each sub-block is
>>  addressed by the host system using different I2C slave addresses.
>>
>>  Required properties:
>> -- compatible: Should be "samsung,s2mps11-pmic" or "samsung,s2mps13-pmic"
>> -   or "samsung,s2mps14-pmic" or "samsung,s2mpu02-pmic".
>> +- compatible: Should be one of the following
>> + - "samsung,s2mps11-pmic"
>> + - "samsung,s2mps13-pmic"
>> + - "samsung,s2mps14-pmic"
>> + - "samsung,s2mps15-pmic"
>> + - "samsung,s2mpu02-pmic".
>>  - reg: Specifies the I2C slave address of the pmic block. It should be 0x66.
>>
>>  Optional properties:
>> @@ -24,7 +28,7 @@ Optional properties:
>>unwanted buck warm reset (setting buck voltages to default values).
>>
>>  Optional nodes:
>> -- clocks: s2mps11, s2mps13 and s5m8767 provide three(AP/CP/BT) buffered 
>> 32.768
>> +- clocks: s2mps11, s2mps13, s2mps15 and s5m8767 provide three(AP/CP/BT) 
>> buffered 32.768
>
> s5m8767 doesn't seem to be documented. Can you please fix or remove.
>
Ok, will take a look.

> Rob
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



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

Re: [PATCH 4/5] NVMe: add blk polling support

[Keith Busch]

On Fri, Nov 06, 2015 at 03:46:07PM -0800, Elliott, Robert (Persistent Memory) 
wrote:
> > -Original Message-
> > From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> > ow...@vger.kernel.org] On Behalf Of Jens Axboe
> > Sent: Friday, November 6, 2015 11:20 AM
> ...
> > Subject: [PATCH 4/5] NVMe: add blk polling support
> >
> > Add nvme_poll(), which will check a specific completion queue for
> > command completions. Wire that up to the new block layer poll
> > mechanism.
> >
> > Later on we'll setup specific sq/cq pairs that don't have interrups
> > enabled, so we can do more efficient polling. As of this patch, an
> > IRQ will still trigger on command completion.
> ...
> > -static int nvme_process_cq(struct nvme_queue *nvmeq)
> > +static void __nvme_process_cq(struct nvme_queue *nvmeq, unsigned int
> > *tag)
> >  {
> >   u16 head, phase;
> >
> > @@ -953,6 +953,8 @@ static int nvme_process_cq(struct nvme_queue *nvmeq)
> >   head = 0;
> >   phase = !phase;
> >   }
> > + if (tag && *tag == cqe.command_id)
> > + *tag = -1;
> >   ctx = nvme_finish_cmd(nvmeq, cqe.command_id, );
> >   fn(nvmeq, ctx, );
> >   }
> 
> The NVMe completion queue entries are 16 bytes long.  Although it's
> most likely to write them from 0..15 in one PCIe Memory Write
> transaction, the NVMe device could write those bytes in any order.
> It could thus update the command identifier before the other bytes,
> causing this code to process invalid stale values in the other
> fields.

That's a very interesting point. We are okay if we can rely on the phase
bit, which we can by my reading of the spec. Coalescing would not work
if the driver can observe a new phase in a partially written CQE.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/