[for-next][PATCH 1/2] tracing: Remove {start,stop}_branch_trace

[Steven Rostedt]

From: Dmitry Safonov <0x7f454...@gmail.com>

Both start_branch_trace() and stop_branch_trace() are used in only one
location, and are both static. As they are small functions there is no
need to keep them separated out.

Link: 
http://lkml.kernel.org/r/1445000689-32596-1-git-send-email-0x7f454...@gmail.com

Signed-off-by: Dmitry Safonov <0x7f454...@gmail.com>
Signed-off-by: Steven Rostedt 
---
 kernel/trace/trace_branch.c | 15 ++-
 1 file changed, 2 insertions(+), 13 deletions(-)

diff --git a/kernel/trace/trace_branch.c b/kernel/trace/trace_branch.c
index e2e12ad3186f..3a2a73716a5b 100644
--- a/kernel/trace/trace_branch.c
+++ b/kernel/trace/trace_branch.c
@@ -125,25 +125,14 @@ void disable_branch_tracing(void)
mutex_unlock(_tracing_mutex);
 }
 
-static void start_branch_trace(struct trace_array *tr)
-{
-   enable_branch_tracing(tr);
-}
-
-static void stop_branch_trace(struct trace_array *tr)
-{
-   disable_branch_tracing();
-}
-
 static int branch_trace_init(struct trace_array *tr)
 {
-   start_branch_trace(tr);
-   return 0;
+   return enable_branch_tracing(tr);
 }
 
 static void branch_trace_reset(struct trace_array *tr)
 {
-   stop_branch_trace(tr);
+   disable_branch_tracing();
 }
 
 static enum print_line_t trace_branch_print(struct trace_iterator *iter,
-- 
2.6.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/

[for-next][PATCH 2/2] ftrace: Calculate the correct dyn_ftrace number to report to the userspace

[Steven Rostedt]

From: Minfei Huang 

Now, ftrace only calculate the dyn_ftrace number in the adding
breakpoint loop, not in adding update and finish update loop.

Calculate the correct dyn_ftrace, once ftrace reports the failure message
to the userspace.

Link: 
http://lkml.kernel.org/r/1442420382-13130-1-git-send-email-mnfhu...@gmail.com

Signed-off-by: Minfei Huang 
Signed-off-by: Steven Rostedt 
---
 arch/x86/kernel/ftrace.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
index 8b7b0a51e742..311bcf338f07 100644
--- a/arch/x86/kernel/ftrace.c
+++ b/arch/x86/kernel/ftrace.c
@@ -556,6 +556,7 @@ void ftrace_replace_code(int enable)
run_sync();
 
report = "updating code";
+   count = 0;
 
for_ftrace_rec_iter(iter) {
rec = ftrace_rec_iter_record(iter);
@@ -563,11 +564,13 @@ void ftrace_replace_code(int enable)
ret = add_update(rec, enable);
if (ret)
goto remove_breakpoints;
+   count++;
}
 
run_sync();
 
report = "removing breakpoints";
+   count = 0;
 
for_ftrace_rec_iter(iter) {
rec = ftrace_rec_iter_record(iter);
@@ -575,6 +578,7 @@ void ftrace_replace_code(int enable)
ret = finish_update(rec, enable);
if (ret)
goto remove_breakpoints;
+   count++;
}
 
run_sync();
-- 
2.6.1


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

Re: [PATCH 09/11] net: ipv6: hlen could be set as size_t

[kbuild test robot]

Hi LABBE,

[auto build test WARNING on net/master -- if it's inappropriate base, please 
suggest rules for selecting the more suitable base]

url:
https://github.com/0day-ci/linux/commits/LABBE-Corentin/net-change-len-parameter-type-for-memcpy_-to-from-_msg/20151023-201642
config: xtensa-allyesconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa 

All warnings (new ones prefixed by >>):

   In file included from include/linux/uio.h:12:0,
from include/linux/socket.h:7,
from net/ipv6/raw.c:23:
   net/ipv6/raw.c: In function 'raw6_getfrag':
   include/linux/kernel.h:722:17: warning: comparison of distinct pointer types 
lacks a cast
 (void) (&_min1 == &_min2);  \
^
>> net/ipv6/raw.c:708:14: note: in expansion of macro 'min'
  int copy = min(rfv->hlen - offset, len);
 ^

vim +/min +708 net/ipv6/raw.c

^1da177e Linus Torvalds2005-04-16  692  break;
6e8f4d48 Masahide NAKAMURA 2006-08-23  693  case IPPROTO_MH:
19e3c66b Al Viro   2014-11-24  694  rfv->hlen = 4;
19e3c66b Al Viro   2014-11-24  695  err = 
memcpy_from_msg(rfv->c, rfv->msg, rfv->hlen);
19e3c66b Al Viro   2014-11-24  696  if (!err)
19e3c66b Al Viro   2014-11-24  697  
fl6->fl6_mh_type = rfv->c[2];
^1da177e Linus Torvalds2005-04-16  698  }
19e3c66b Al Viro   2014-11-24  699  return err;
^1da177e Linus Torvalds2005-04-16  700  }
19e3c66b Al Viro   2014-11-24  701  
19e3c66b Al Viro   2014-11-24  702  static int raw6_getfrag(void *from, 
char *to, int offset, int len, int odd,
19e3c66b Al Viro   2014-11-24  703 struct sk_buff 
*skb)
19e3c66b Al Viro   2014-11-24  704  {
19e3c66b Al Viro   2014-11-24  705  struct raw6_frag_vec *rfv = 
from;
19e3c66b Al Viro   2014-11-24  706  
19e3c66b Al Viro   2014-11-24  707  if (offset < rfv->hlen) {
19e3c66b Al Viro   2014-11-24 @708  int copy = 
min(rfv->hlen - offset, len);
19e3c66b Al Viro   2014-11-24  709  
19e3c66b Al Viro   2014-11-24  710  if (skb->ip_summed == 
CHECKSUM_PARTIAL)
19e3c66b Al Viro   2014-11-24  711  memcpy(to, 
rfv->c + offset, copy);
19e3c66b Al Viro   2014-11-24  712  else
19e3c66b Al Viro   2014-11-24  713  skb->csum = 
csum_block_add(
19e3c66b Al Viro   2014-11-24  714  
skb->csum,
19e3c66b Al Viro   2014-11-24  715  
csum_partial_copy_nocheck(rfv->c + offset,
19e3c66b Al Viro   2014-11-24  716  
  to, copy, 0),

:: The code at line 708 was first introduced by commit
:: 19e3c66b52caf20a9a1119dc847b6abae4c03f4f ipv6 equivalent of "ipv4: Avoid 
reading user iov twice after raw_probe_proto_opt"

:: TO: Al Viro 
:: CC: Al Viro 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCH v2 00/12] KVM: x86: add support for VMX TSC scaling

[Haozhong Zhang]

On Fri, Oct 23, 2015 at 12:06:50PM +0200, Joerg Roedel wrote:
> On Tue, Oct 20, 2015 at 03:39:00PM +0800, Haozhong Zhang wrote:
> > VMX TSC scaling shares some common logics with SVM TSC ratio which
> > is already supported by KVM. Patch 1 ~ 8 move those common logics from
> > SVM code to the common code. Upon them, patch 9 ~ 12 add VMX-specific
> > support for VMX TSC scaling.
> 
> Have you tested your changes on an AMD machine too?
> 
> 
>   Joerg
> 

No, since I don't have AMD machines at hand. The modifications to SVM
code are mostly lifting common code with VMX TSC scaling code, so it
should still work on AMD machines.

Haozhong
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [Y2038] [PATCH V2] hil_mlc: convert timeval to ktime_t

[Pingbo Wen]

> 在 2015年10月23日，17:55，Arnd Bergmann  写道：
> 
> On Friday 23 October 2015 17:24:59 WEN Pingbo wrote:
>> Using struct timeval will cause time overflow in 2038, replacing it with
>> ktime_t. And we don't need to handle sec and nsec separately.
>> 
> 
> This part looks good now, but as I commented in version 1, it should
> really be a separate patch rather than combined with the rest that
> is dealing with another use of timeval.

Ok, I will split it in next version.

>> -do_gettimeofday();
>> -tv.tv_usec += USEC_PER_SEC * (tv.tv_sec - mlc->instart.tv_sec);
>> -tv.tv_usec -= mlc->instart.tv_usec;
>> -if (tv.tv_usec >= mlc->intimeout) goto sched;
>> -tv.tv_usec = (mlc->intimeout - tv.tv_usec) * HZ / USEC_PER_SEC;
>> -if (!tv.tv_usec) goto sched;
>> -mod_timer(_mlcs_kicker, jiffies + tv.tv_usec);
>> +if (tmp.tv64 >= (mlc->intimeout * NSEC_PER_USEC))
>> +goto sched;
>> +tmp.tv64 = mlc->intimeout * NSEC_PER_USEC - tmp.tv64;
>> +if (tmp.tv64 < NSEC_PER_USEC)
>> +goto sched;
>> +mod_timer(_mlcs_kicker,
>> +jiffies + nsecs_to_jiffies(tmp.tv64));
>>  break;
>>  sched:
>>  tasklet_schedule(_mlcs_tasklet);
> 
> If I read this right, the code is executed one for each input event such
> as a keypress or mouse movement. In the latter case, doing nsecs_to_jiffies()
> here is actually a bit expensive, and I stil think it can be avoided
> by just using jiffies.
> 
> For the (tmp.tv64 < NSEC_PER_USEC) part, did you just do that because
> I said this, or did you actually prove that it is required? I'm still
> confused about what the driver is trying to achieve here.

More explanation here:)
the judgement here is to prevent mod_timer with zero delta. I can not make sure 
whether the module
have nanosecond precise, so just keep same.

> 
>> diff --git a/drivers/input/serio/hp_sdc_mlc.c 
>> b/drivers/input/serio/hp_sdc_mlc.c
>> index d50f067..0a27b89 100644
>> --- a/drivers/input/serio/hp_sdc_mlc.c
>> +++ b/drivers/input/serio/hp_sdc_mlc.c
>> @@ -149,7 +149,8 @@ static int hp_sdc_mlc_in(hil_mlc *mlc, suseconds_t 
>> timeout)
>> 
>>  /* Try to down the semaphore */
>>  if (down_trylock(>isem)) {
>> -struct timeval tv;
>> +ktime_t tmp = ktime_sub(ktime_get(), mlc->instart);
>> +
>>  if (priv->emtestmode) {
>>  mlc->ipacket[0] =
>>  HIL_ERR_INT | (mlc->opacket &
> 
> Maybe give the variable a more useful name than 'tmp'?
> 
> You could also remove the variable entirely if you slightly restructure
> the condition below.

I see, thanks for point out.

Pingbo

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

Re: [PATCH v5 2/2] lib/test-string_helpers.c: add string_get_size() tests

[Vitaly Kuznetsov]

Rasmus Villemoes  writes:

> On Thu, Sep 17 2015, Vitaly Kuznetsov  wrote:
>
>> +
>> +static __init void test_string_get_size(void)
>> +{
>> +test_string_get_size_one(16384, 512, STRING_UNITS_2, "8.00 MiB");
>> +test_string_get_size_one(8192, 4096, STRING_UNITS_10, "32.7 MB");
>
> This is a little late,

Thanks for the ping, it turns out this patch was never merged (though
the one fixing the issue was), I'll have to resend.

> but I just noticed that string_get_size with
> STRING_UNITS_10, block size >= 1024 and sufficiently large size seems to
> be broken. Yes, 32.7 MB is what it produces, but is it what it should
> give? 8192*4096 = 33554432, so I'd expect "33.5 MB". It does give that
> when we pass size=65536 and block_size=512; a combination with the same
> product.
>
> I think the problem is that the remainder coming out of the while
> (blk_size >= divisor[units]) loop is dropped on the floor in the
> subsequent size > exp case - but I'm too lazy right now to figure out how
> to fix it.

Ok, I'll take a look.

-- 
  Vitaly
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 08/11] net: bluetooth: change the len parameter of sco_send_frame() to size_t

[kbuild test robot]

Hi LABBE,

[auto build test WARNING on net/master -- if it's inappropriate base, please 
suggest rules for selecting the more suitable base]

url:
https://github.com/0day-ci/linux/commits/LABBE-Corentin/net-change-len-parameter-type-for-memcpy_-to-from-_msg/20151023-201642
config: sparc64-allyesconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sparc64 

All warnings (new ones prefixed by >>):

   In file included from include/linux/printk.h:277:0,
from include/linux/kernel.h:13,
from include/linux/list.h:8,
from include/linux/module.h:9,
from net/bluetooth/sco.c:27:
   net/bluetooth/sco.c: In function 'sco_send_frame':
   include/linux/dynamic_debug.h:64:16: warning: format '%d' expects argument 
of type 'int', but argument 4 has type 'size_t' [-Wformat=]
 static struct _ddebug  __aligned(8)   \
   ^
   include/linux/dynamic_debug.h:76:2: note: in expansion of macro 
'DEFINE_DYNAMIC_DEBUG_METADATA'
 DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt);  \
 ^
   include/linux/printk.h:283:2: note: in expansion of macro 'dynamic_pr_debug'
 dynamic_pr_debug(fmt, ##__VA_ARGS__)
 ^
   include/net/bluetooth/bluetooth.h:129:26: note: in expansion of macro 
'pr_debug'
#define BT_DBG(fmt, ...) pr_debug(fmt "\n", ##__VA_ARGS__)
 ^
>> net/bluetooth/sco.c:281:2: note: in expansion of macro 'BT_DBG'
 BT_DBG("sk %p len %d", sk, len);
 ^

vim +/BT_DBG +281 net/bluetooth/sco.c

^1da177e Linus Torvalds  2005-04-16  265  done:
09fd0de5 Gustavo Padovan 2011-06-17  266hci_dev_unlock(hdev);
^1da177e Linus Torvalds  2005-04-16  267hci_dev_put(hdev);
^1da177e Linus Torvalds  2005-04-16  268return err;
^1da177e Linus Torvalds  2005-04-16  269  }
^1da177e Linus Torvalds  2005-04-16  270  
722dd7cd LABBE Corentin  2015-10-23  271  static int sco_send_frame(struct sock 
*sk, struct msghdr *msg, size_t len)
^1da177e Linus Torvalds  2005-04-16  272  {
^1da177e Linus Torvalds  2005-04-16  273struct sco_conn *conn = 
sco_pi(sk)->conn;
^1da177e Linus Torvalds  2005-04-16  274struct sk_buff *skb;
088ce088 Mikel Astiz 2012-04-11  275int err;
^1da177e Linus Torvalds  2005-04-16  276  
^1da177e Linus Torvalds  2005-04-16  277/* Check outgoing MTU */
^1da177e Linus Torvalds  2005-04-16  278if (len > conn->mtu)
^1da177e Linus Torvalds  2005-04-16  279return -EINVAL;
^1da177e Linus Torvalds  2005-04-16  280  
^1da177e Linus Torvalds  2005-04-16 @281BT_DBG("sk %p len %d", sk, len);
^1da177e Linus Torvalds  2005-04-16  282  
088ce088 Mikel Astiz 2012-04-11  283skb = bt_skb_send_alloc(sk, 
len, msg->msg_flags & MSG_DONTWAIT, );
b9dbdbc1 Gustavo Padovan 2010-05-01  284if (!skb)
^1da177e Linus Torvalds  2005-04-16  285return err;
^1da177e Linus Torvalds  2005-04-16  286  
6ce8e9ce Al Viro 2014-04-06  287if 
(memcpy_from_msg(skb_put(skb, len), msg, len)) {
b9dbdbc1 Gustavo Padovan 2010-05-01  288kfree_skb(skb);
b9dbdbc1 Gustavo Padovan 2010-05-01  289return -EFAULT;

:: The code at line 281 was first introduced by commit
:: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Linux-2.6.12-rc2

:: TO: Linus Torvalds 
:: CC: Linus Torvalds 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

[PATCH v9 1/5] configfs: Allow dynamic group creation

[Daniel Baluta]

We don't want to hardcode default groups at subsystem
creation time. We export:
* configfs_register_group
* configfs_unregister_group
to allow drivers to programatically create/destroy groups
later, after module init time.

This is needed for IIO configfs support.

Suggested-by: Lars-Peter Clausen 
Signed-off-by: Daniel Baluta 
---
 fs/configfs/dir.c| 102 +++
 include/linux/configfs.h |   8 
 2 files changed, 110 insertions(+)

diff --git a/fs/configfs/dir.c b/fs/configfs/dir.c
index c81ce7f..bf76795 100644
--- a/fs/configfs/dir.c
+++ b/fs/configfs/dir.c
@@ -1636,6 +1636,108 @@ const struct file_operations configfs_dir_operations = {
.iterate= configfs_readdir,
 };
 
+/**
+ * configfs_alloc_group() - allocate a configfs group
+ * @name:  group name
+ * @item_type: config_item associated with the allocated group
+ *
+ * Dynamically allocates and initialize a group specified by name and
+ * config_item_type. We need kzalloc'ed memory because default_group
+ * is empty.
+ *
+ * Return: allocated config group or ERR_PTR() on error
+ */
+struct config_group *
+configfs_alloc_group(const char *name, struct config_item_type *item_type)
+{
+   struct config_group *group;
+
+   group = kzalloc(sizeof(*group), GFP_KERNEL);
+   if (!group)
+   return ERR_PTR(-ENOMEM);
+   config_group_init_type_name(group, name, item_type);
+
+   return group;
+}
+EXPORT_SYMBOL(configfs_alloc_group);
+
+/**
+ * configfs_free_group() - frees memory for a configfs group
+ * @group: group to be 'eliberated'
+ */
+void configfs_free_group(struct config_group *group)
+{
+   kfree(group);
+}
+EXPORT_SYMBOL(configfs_free_group);
+
+/**
+ * configfs_register_group - creates a parent-child relation between two groups
+ * @parent_group:  parent group
+ * @group: child group
+ *
+ * link groups, creates dentry for the child and attaches it to the
+ * parent dentry.
+ *
+ * Return: 0 on success, negative errno code on error
+ */
+int configfs_register_group(struct config_group *parent_group,
+   struct config_group *group)
+{
+   struct configfs_subsystem *subsys = parent_group->cg_subsys;
+   struct dentry *parent;
+   int ret;
+
+   mutex_lock(>su_mutex);
+   link_group(parent_group, group);
+   mutex_unlock(>su_mutex);
+
+   parent = parent_group->cg_item.ci_dentry;
+
+   mutex_lock_nested(_inode(parent)->i_mutex, I_MUTEX_PARENT);
+   ret = create_default_group(parent_group, group);
+   if (!ret) {
+   spin_lock(_dirent_lock);
+   configfs_dir_set_ready(group->cg_item.ci_dentry->d_fsdata);
+   spin_unlock(_dirent_lock);
+   }
+   mutex_unlock(_inode(parent)->i_mutex);
+   return ret;
+}
+EXPORT_SYMBOL(configfs_register_group);
+
+/**
+ * configfs_unregister_group() - unregisters a child group from its parent
+ *
+ * @group: parent group to be unregistered
+ *
+ * Undoes condigfs_register_group()
+ */
+void configfs_unregister_group(struct config_group *group)
+{
+   struct configfs_subsystem *subsys = group->cg_subsys;
+   struct dentry *dentry = group->cg_item.ci_dentry;
+   struct dentry *parent = group->cg_item.ci_parent->ci_dentry;
+
+   mutex_lock_nested(_inode(parent)->i_mutex, I_MUTEX_PARENT);
+   spin_lock(_dirent_lock);
+   configfs_detach_prep(dentry, NULL);
+   spin_unlock(_dirent_lock);
+
+   configfs_detach_group(>cg_item);
+   d_inode(dentry)->i_flags |= S_DEAD;
+   dont_mount(dentry);
+   d_delete(dentry);
+   mutex_unlock(_inode(parent)->i_mutex);
+
+   dput(dentry);
+
+   mutex_lock(>su_mutex);
+   unlink_group(group);
+   mutex_unlock(>su_mutex);
+}
+EXPORT_SYMBOL(configfs_unregister_group);
+
 int configfs_register_subsystem(struct configfs_subsystem *subsys)
 {
int err;
diff --git a/include/linux/configfs.h b/include/linux/configfs.h
index 63a36e8..c522a5e 100644
--- a/include/linux/configfs.h
+++ b/include/linux/configfs.h
@@ -252,6 +252,14 @@ static inline struct configfs_subsystem 
*to_configfs_subsystem(struct config_gro
 int configfs_register_subsystem(struct configfs_subsystem *subsys);
 void configfs_unregister_subsystem(struct configfs_subsystem *subsys);
 
+struct config_group *
+configfs_alloc_group(const char *name, struct config_item_type *item_type);
+void configfs_free_group(struct config_group *group);
+
+int configfs_register_group(struct config_group *parent_group,
+   struct config_group *group);
+void configfs_unregister_group(struct config_group *group);
+
 /* These functions can sleep and can alloc with GFP_KERNEL */
 /* WARNING: These cannot be called underneath configfs callbacks!! */
 int configfs_depend_item(struct configfs_subsystem *subsys, struct config_item 
*target);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe 

[PATCH v9 4/5] iio: trigger: Introduce IIO hrtimer based trigger

[Daniel Baluta]

This patch registers a new IIO software trigger interrupt source
based on high resolution timers.

Notice that if configfs is enabled we create sampling_frequency
attribute allowing users to change hrtimer period (1/sampling_frequency).

The IIO hrtimer trigger has a long history, this patch is based on
an older version from Marten and Lars-Peter.

Signed-off-by: Marten Svanfeldt 
Signed-off-by: Lars-Peter Clausen 
Signed-off-by: Daniel Baluta 
---
 drivers/iio/trigger/Kconfig|  10 ++
 drivers/iio/trigger/Makefile   |   2 +
 drivers/iio/trigger/iio-trig-hrtimer.c | 193 +
 3 files changed, 205 insertions(+)
 create mode 100644 drivers/iio/trigger/iio-trig-hrtimer.c

diff --git a/drivers/iio/trigger/Kconfig b/drivers/iio/trigger/Kconfig
index 7999612..519e677 100644
--- a/drivers/iio/trigger/Kconfig
+++ b/drivers/iio/trigger/Kconfig
@@ -5,6 +5,16 @@
 
 menu "Triggers - standalone"
 
+config IIO_HRTIMER_TRIGGER
+   tristate "High resolution timer trigger"
+   depends on IIO_SW_TRIGGER
+   help
+ Provides a frequency based IIO trigger using high resolution
+ timers as interrupt source.
+
+ To compile this driver as a module, choose M here: the
+ module will be called iio-trig-hrtimer.
+
 config IIO_INTERRUPT_TRIGGER
tristate "Generic interrupt trigger"
help
diff --git a/drivers/iio/trigger/Makefile b/drivers/iio/trigger/Makefile
index 0694dae..fe06eb5 100644
--- a/drivers/iio/trigger/Makefile
+++ b/drivers/iio/trigger/Makefile
@@ -3,5 +3,7 @@
 #
 
 # When adding new entries keep the list in alphabetical order
+
+obj-$(CONFIG_IIO_HRTIMER_TRIGGER) += iio-trig-hrtimer.o
 obj-$(CONFIG_IIO_INTERRUPT_TRIGGER) += iio-trig-interrupt.o
 obj-$(CONFIG_IIO_SYSFS_TRIGGER) += iio-trig-sysfs.o
diff --git a/drivers/iio/trigger/iio-trig-hrtimer.c 
b/drivers/iio/trigger/iio-trig-hrtimer.c
new file mode 100644
index 000..5e6d451
--- /dev/null
+++ b/drivers/iio/trigger/iio-trig-hrtimer.c
@@ -0,0 +1,193 @@
+/**
+ * The industrial I/O periodic hrtimer trigger driver
+ *
+ * Copyright (C) Intuitive Aerial AB
+ * Written by Marten Svanfeldt, mar...@intuitiveaerial.com
+ * Copyright (C) 2012, Analog Device Inc.
+ * Author: Lars-Peter Clausen 
+ * Copyright (C) 2015, Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ */
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+/* default sampling frequency - 100Hz */
+#define HRTIMER_DEFAULT_SAMPLING_FREQUENCY 100
+
+struct iio_hrtimer_info {
+   struct iio_sw_trigger swt;
+   struct hrtimer timer;
+   unsigned long sampling_frequency;
+   ktime_t period;
+};
+
+static struct config_item_type iio_hrtimer_type = {
+   .ct_owner = THIS_MODULE,
+};
+
+static
+ssize_t iio_hrtimer_show_sampling_frequency(struct device *dev,
+   struct device_attribute *attr,
+   char *buf)
+{
+   struct iio_trigger *trig = to_iio_trigger(dev);
+   struct iio_hrtimer_info *info = iio_trigger_get_drvdata(trig);
+
+   return snprintf(buf, PAGE_SIZE, "%lu\n", info->sampling_frequency);
+}
+
+static
+ssize_t iio_hrtimer_store_sampling_frequency(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t len)
+{
+   struct iio_trigger *trig = to_iio_trigger(dev);
+   struct iio_hrtimer_info *info = iio_trigger_get_drvdata(trig);
+   unsigned long val;
+   int ret;
+
+   ret = kstrtoul(buf, 10, );
+   if (ret)
+   return ret;
+
+   if (!val || val > NSEC_PER_SEC)
+   return -EINVAL;
+
+   info->sampling_frequency = val;
+   info->period = ktime_set(0, NSEC_PER_SEC / val);
+
+   return len;
+}
+
+static DEVICE_ATTR(sampling_frequency, S_IRUGO | S_IWUSR,
+  iio_hrtimer_show_sampling_frequency,
+  iio_hrtimer_store_sampling_frequency);
+
+static struct attribute *iio_hrtimer_attrs[] = {
+   _attr_sampling_frequency.attr,
+   NULL
+};
+
+static const struct attribute_group iio_hrtimer_attr_group = {
+   .attrs = iio_hrtimer_attrs,
+};
+
+static const struct attribute_group *iio_hrtimer_attr_groups[] = {
+   _hrtimer_attr_group,
+   NULL
+};
+
+static enum hrtimer_restart iio_hrtimer_trig_handler(struct hrtimer *timer)
+{
+   struct iio_hrtimer_info *info;
+
+   info = container_of(timer, struct iio_hrtimer_info, timer);
+
+   hrtimer_forward_now(timer, info->period);
+   iio_trigger_poll(info->swt.trigger);
+
+   return HRTIMER_RESTART;
+}
+
+static int iio_trig_hrtimer_set_state(struct iio_trigger *trig, bool state)
+{
+   struct iio_hrtimer_info *trig_info;
+
+   

[PATCH v9 0/5] Add initial configfs support for IIO

[Daniel Baluta]

This patchset introduces IIO software triggers, offers a way of configuring
them via configfs and adds the IIO hrtimer based interrupt source to be used
with software triggers.

The arhitecture is now split in 3 parts, to remove all IIO trigger specific
parts from IIO configfs core:

(1) IIO configfs - creates the root of the IIO configfs subsys.
(2) IIO software triggers - software trigger implementation, dynamically
creating /config/iio/triggers group.
(3) IIO hrtimer trigger - is the first interrupt source for software triggers
(with syfs to follow). Each trigger type can implement its own set of
attributes.

Lockdep seems to be happy with the locking in configfs patch.

Changes since v8:
   * patch 1/5
* dynamically allocate groups as suggested by Christoph
* add kernel-doc documentation to the newly introduced functions
   * patch 2/5
* better isolation, here we only create the root of the IIO configfs
subys, and let the other modules (e.g software triggers) to create their
group.
   * patch 3/5
* dynamically create triggers/ group to better isolate the code
* fixes 0-day build warnings and compilation errors.
   * patch 4/5
* none
   * patch 5/5
* none

Changes since v7:
   * patch 1/5
* do not add dentry parameter for create_default_group, we can
  retrieve it from group.
* call configfs_detach_prep before configfs_detach_group in
  configfs_unregister_group.
* call link_group/unlink_group under su_mutex lock
* take configfs_dirent_lock when calling configfs_dir_set_ready
  * patch 2/5
* export iio_triggers_group, this will be later used by sw triggers
  * patch 3/5
* make iio_sw_trigger part of industrialio core
* fix compilation problem reported by Vladimir and Lars. Things didn't
get well when having IIO_SW_TRIGGER enabled and IIO_CONFIGFS disabled.
* use format string in config_item_set_name
* make iio_unregister_sw_trigger_type return type void.
  * patch 4/5
* none
  * patch 5/5
* include a small trigger type sample example.

Changes since v6:
* implemented Lars-Peter's idea (https://lkml.org/lkml/2015/5/13/302)
to switch from /config/iio/triggers/hrtimer-instance1 to
/config/iio/triggers/instance1.

Changes since v5: (after Lars comments)
* the most important change is that we moved sampling_frequency 
attribute
from configfs to trigger's directory in /sys.
* couple of const added to strings
* documentation to public API in sw_trigger.h
* replace pr_err with WARN_ONCE in trigger_make_group to avoid spamming
kernel log, but without leaving user clueless in case of errors.
* we still need to decide if we get a real gain by adding min/max limits
for sampling frequency in /config dir. Anyhow, this can be done in a 
later
patch.
* fix race in hrtimer_remove

Changes since v4:
* patch 1/4
- fixed "new line" nit in industrialio-sw-trigger.c
- added license header in sw_trigger.h o
* patch 2/4
- none
* patch 3/4
- none
* patch 4/4
- removed "Further work" chapter in iio_configfs.txt

- added configfs-iio file in Documentation/ABI/testing

Daniel Baluta (5):
  configfs: Allow dynamic group creation
  iio: core: Introduce IIO configfs support
  iio: core: Introduce IIO software triggers
  iio: trigger: Introduce IIO hrtimer based trigger
  iio: Documentation: Add IIO configfs documentation

 Documentation/ABI/testing/configfs-iio |  21 
 Documentation/iio/iio_configfs.txt |  93 +++
 drivers/iio/Kconfig|  16 +++
 drivers/iio/Makefile   |   2 +
 drivers/iio/industrialio-configfs.c|  50 
 drivers/iio/industrialio-sw-trigger.c  | 206 +
 drivers/iio/trigger/Kconfig|  10 ++
 drivers/iio/trigger/Makefile   |   2 +
 drivers/iio/trigger/iio-trig-hrtimer.c | 193 ++
 fs/configfs/dir.c  | 102 
 include/linux/configfs.h   |   8 ++
 include/linux/iio/sw_trigger.h |  71 
 12 files changed, 774 insertions(+)
 create mode 100644 Documentation/ABI/testing/configfs-iio
 create mode 100644 Documentation/iio/iio_configfs.txt
 create mode 100644 drivers/iio/industrialio-configfs.c
 create mode 100644 drivers/iio/industrialio-sw-trigger.c
 create mode 100644 drivers/iio/trigger/iio-trig-hrtimer.c
 create mode 100644 include/linux/iio/sw_trigger.h

-- 
1.9.1

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

[PATCH v9 2/5] iio: core: Introduce IIO configfs support

[Daniel Baluta]

This patch creates the IIO configfs root group. The group
will appear under /iio/, usually /config/iio.

We introduce configfs support in IIO in order to be able to easily
create IIO objects from userspace. The first supported IIO objects
are triggers introduced with next patches.

Signed-off-by: Daniel Baluta 
---
 drivers/iio/Kconfig |  8 ++
 drivers/iio/Makefile|  1 +
 drivers/iio/industrialio-configfs.c | 50 +
 3 files changed, 59 insertions(+)
 create mode 100644 drivers/iio/industrialio-configfs.c

diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index 66792e7..d0f1ddb 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -22,6 +22,14 @@ if IIO_BUFFER
source "drivers/iio/buffer/Kconfig"
 endif # IIO_BUFFER
 
+config IIO_CONFIGFS
+   tristate "Enable IIO configuration via configfs"
+   select CONFIGFS_FS
+   help
+ This allows configuring various IIO bits through configfs
+ (e.g. software triggers). For more info see
+ Documentation/iio/iio_configfs.txt.
+
 config IIO_TRIGGER
bool "Enable triggered sampling support"
help
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index aeca726..4e8ac82 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -7,6 +7,7 @@ industrialio-y := industrialio-core.o industrialio-event.o 
inkern.o
 industrialio-$(CONFIG_IIO_BUFFER) += industrialio-buffer.o
 industrialio-$(CONFIG_IIO_TRIGGER) += industrialio-trigger.o
 
+obj-$(CONFIG_IIO_CONFIGFS) += industrialio-configfs.o
 obj-$(CONFIG_IIO_TRIGGERED_EVENT) += industrialio-triggered-event.o
 
 obj-y += accel/
diff --git a/drivers/iio/industrialio-configfs.c 
b/drivers/iio/industrialio-configfs.c
new file mode 100644
index 000..83563dd
--- /dev/null
+++ b/drivers/iio/industrialio-configfs.c
@@ -0,0 +1,50 @@
+/*
+ * Industrial I/O configfs bits
+ *
+ * Copyright (c) 2015 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+static struct config_item_type iio_root_group_type = {
+   .ct_owner   = THIS_MODULE,
+};
+
+struct configfs_subsystem iio_configfs_subsys = {
+   .su_group = {
+   .cg_item = {
+   .ci_namebuf = "iio",
+   .ci_type = _root_group_type,
+   },
+   },
+   .su_mutex = __MUTEX_INITIALIZER(iio_configfs_subsys.su_mutex),
+};
+EXPORT_SYMBOL(iio_configfs_subsys);
+
+static int __init iio_configfs_init(void)
+{
+   config_group_init(_configfs_subsys.su_group);
+
+   return configfs_register_subsystem(_configfs_subsys);
+}
+module_init(iio_configfs_init);
+
+static void __exit iio_configfs_exit(void)
+{
+   configfs_unregister_subsystem(_configfs_subsys);
+}
+module_exit(iio_configfs_exit);
+
+MODULE_AUTHOR("Daniel Baluta ");
+MODULE_DESCRIPTION("Industrial I/O configfs support");
+MODULE_LICENSE("GPL v2");
-- 
1.9.1

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

[PATCH v9 5/5] iio: Documentation: Add IIO configfs documentation

[Daniel Baluta]

Signed-off-by: Daniel Baluta 
---
 Documentation/ABI/testing/configfs-iio | 21 
 Documentation/iio/iio_configfs.txt | 93 ++
 2 files changed, 114 insertions(+)
 create mode 100644 Documentation/ABI/testing/configfs-iio
 create mode 100644 Documentation/iio/iio_configfs.txt

diff --git a/Documentation/ABI/testing/configfs-iio 
b/Documentation/ABI/testing/configfs-iio
new file mode 100644
index 000..2483756
--- /dev/null
+++ b/Documentation/ABI/testing/configfs-iio
@@ -0,0 +1,21 @@
+What:  /config/iio
+Date:  October 2015
+KernelVersion: 4.4
+Contact:   linux-...@vger.kernel.org
+Description:
+   This represents Industrial IO configuration entry point
+   directory. It contains sub-groups corresponding to IIO
+   objects.
+
+What:  /config/iio/triggers
+Date:  October 2015
+KernelVersion: 4.4
+Description:
+   Industrial IO software triggers directory.
+
+What:  /config/iio/triggers/hrtimers
+Date:  October 2015
+KernelVersion: 4.4
+Description:
+   High resolution timers directory. Creating a directory here
+   will result in creating a hrtimer trigger in the IIO subsystem.
diff --git a/Documentation/iio/iio_configfs.txt 
b/Documentation/iio/iio_configfs.txt
new file mode 100644
index 000..f0add35
--- /dev/null
+++ b/Documentation/iio/iio_configfs.txt
@@ -0,0 +1,93 @@
+Industrial IIO configfs support
+
+1. Overview
+
+Configfs is a filesystem-based manager of kernel objects. IIO uses some
+objects that could be easily configured using configfs (e.g.: devices,
+triggers).
+
+See Documentation/filesystems/configfs/configfs.txt for more information
+about how configfs works.
+
+2. Usage
+
+In order to use configfs support in IIO we need to select it at compile
+time via CONFIG_IIO_CONFIGFS config option.
+
+Then, mount the configfs filesystem (usually under /config directory):
+
+$ mkdir /config
+$ mount -t configfs none /config
+
+At this point, all default IIO groups will be created and can be accessed
+under /config/iio. Next chapters will describe available IIO configuration
+objects.
+
+3. Software triggers
+
+One of the IIO default configfs groups is the "triggers" group. It is
+automagically accessible when the configfs is mounted and can be found
+under /config/iio/triggers.
+
+IIO software triggers implementation offers support for creating multiple
+trigger types. A new trigger type is usually implemented as a separate
+kernel module following the interface in include/linux/iio/sw_trigger.h:
+
+/*
+ * drivers/iio/trigger/iio-trig-sample.c
+ * sample kernel module implementing a new trigger type
+ */
+#include 
+
+
+static struct iio_sw_trigger *iio_trig_sample_probe(const char *name)
+{
+   /*
+* This allocates and registers an IIO trigger plus other
+* trigger type specific initialization.
+*/
+}
+
+static int iio_trig_hrtimer_remove(struct iio_sw_trigger *swt)
+{
+   /*
+* This undoes the actions in iio_trig_sample_probe
+*/
+}
+
+static const struct iio_sw_trigger_ops iio_trig_sample_ops = {
+   .probe  = iio_trig_sample_probe,
+   .remove = iio_trig_sample_remove,
+};
+
+static struct iio_sw_trigger_type iio_trig_sample = {
+   .name = "trig-sample",
+   .owner = THIS_MODULE,
+   .ops = _trig_sample_ops,
+};
+
+module_iio_sw_trigger_driver(iio_trig_sample);
+
+Each trigger type has its own directory under /config/iio/triggers. Loading
+iio-trig-sample module will create 'trig-sample' trigger type directory
+/config/iio/triggers/trig-sample.
+
+We support the following interrupt sources (trigger types):
+   * hrtimer, uses high resolution timers as interrupt source
+
+3.1 Hrtimer triggers creation and destruction
+
+Loading iio-trig-hrtimer module will register hrtimer trigger types allowing
+users to create hrtimer triggers under /config/iio/triggers/hrtimer.
+
+e.g:
+
+$ mkdir /config/triggers/hrtimer/instance1
+$ rmdir /config/triggers/hrtimer/instance1
+
+Each trigger can have one or more attributes specific to the trigger type.
+
+3.2 "hrtimer" trigger types attributes
+
+"hrtimer" trigger type doesn't have any configurable attribute from /config 
dir.
+It does introduce the sampling_frequency attribute to trigger directory.
-- 
1.9.1

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

[PATCH v9 3/5] iio: core: Introduce IIO software triggers

[Daniel Baluta]

A software trigger associates an IIO device trigger with a software
interrupt source (e.g: timer, sysfs). This patch adds the generic
infrastructure for handling software triggers.

Software interrupts sources are kept in a iio_trigger_types_list and
registered separately when the associated kernel module is loaded.

Software triggers can be created directly from drivers or from user
space via configfs interface.

To sum up, this dynamically creates "triggers" group to be found under
/config/iio/triggers and offers the possibility of dynamically
creating trigger types group. The first support trigger type is
"hrtimer" found under /config/iio/triggers/hrtimer.

Signed-off-by: Daniel Baluta 
---
 drivers/iio/Kconfig   |   8 ++
 drivers/iio/Makefile  |   1 +
 drivers/iio/industrialio-sw-trigger.c | 206 ++
 include/linux/iio/sw_trigger.h|  71 
 4 files changed, 286 insertions(+)
 create mode 100644 drivers/iio/industrialio-sw-trigger.c
 create mode 100644 include/linux/iio/sw_trigger.h

diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index d0f1ddb..5dfb4f1 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -46,6 +46,14 @@ config IIO_CONSUMERS_PER_TRIGGER
This value controls the maximum number of consumers that a
given trigger may handle. Default is 2.
 
+config IIO_SW_TRIGGER
+   tristate "Enable software triggers support"
+   select IIO_CONFIGFS
+   help
+Provides IIO core support for software triggers. A software
+trigger can be created via configfs or directly by a driver
+using the API provided.
+
 config IIO_TRIGGERED_EVENT
tristate
select IIO_TRIGGER
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index 4e8ac82..dc73c1f 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -8,6 +8,7 @@ industrialio-$(CONFIG_IIO_BUFFER) += industrialio-buffer.o
 industrialio-$(CONFIG_IIO_TRIGGER) += industrialio-trigger.o
 
 obj-$(CONFIG_IIO_CONFIGFS) += industrialio-configfs.o
+obj-$(CONFIG_IIO_SW_TRIGGER) += industrialio-sw-trigger.o
 obj-$(CONFIG_IIO_TRIGGERED_EVENT) += industrialio-triggered-event.o
 
 obj-y += accel/
diff --git a/drivers/iio/industrialio-sw-trigger.c 
b/drivers/iio/industrialio-sw-trigger.c
new file mode 100644
index 000..8911f22
--- /dev/null
+++ b/drivers/iio/industrialio-sw-trigger.c
@@ -0,0 +1,206 @@
+/*
+ * The Industrial I/O core, software trigger functions
+ *
+ * Copyright (c) 2015 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+static struct config_group *iio_triggers_group;
+static struct config_item_type iio_triggers_group_type = {
+   .ct_owner = THIS_MODULE,
+};
+
+static LIST_HEAD(iio_trigger_types_list);
+static DEFINE_MUTEX(iio_trigger_types_lock);
+
+static
+struct iio_sw_trigger_type *__iio_find_sw_trigger_type(const char *name,
+  unsigned len)
+{
+   struct iio_sw_trigger_type *t = NULL, *iter;
+
+   list_for_each_entry(iter, _trigger_types_list, list)
+   if (!strcmp(iter->name, name)) {
+   t = iter;
+   break;
+   }
+
+   return t;
+}
+
+int iio_register_sw_trigger_type(struct iio_sw_trigger_type *t)
+{
+   struct iio_sw_trigger_type *iter;
+   int ret = 0;
+
+   mutex_lock(_trigger_types_lock);
+   iter = __iio_find_sw_trigger_type(t->name, strlen(t->name));
+   if (iter)
+   ret = -EBUSY;
+   else
+   list_add_tail(>list, _trigger_types_list);
+   mutex_unlock(_trigger_types_lock);
+
+   if (!ret)
+   iio_sw_trigger_type_configfs_register(t);
+
+   return ret;
+}
+EXPORT_SYMBOL(iio_register_sw_trigger_type);
+
+void iio_unregister_sw_trigger_type(struct iio_sw_trigger_type *t)
+{
+   struct iio_sw_trigger_type *iter;
+
+   mutex_lock(_trigger_types_lock);
+   iter = __iio_find_sw_trigger_type(t->name, strlen(t->name));
+   if (iter)
+   list_del(>list);
+   mutex_unlock(_trigger_types_lock);
+
+   iio_sw_trigger_type_configfs_unregister(t);
+}
+EXPORT_SYMBOL(iio_unregister_sw_trigger_type);
+
+static
+struct iio_sw_trigger_type *iio_get_sw_trigger_type(const char *name)
+{
+   struct iio_sw_trigger_type *t;
+
+   mutex_lock(_trigger_types_lock);
+   t = __iio_find_sw_trigger_type(name, strlen(name));
+   if (t && !try_module_get(t->owner))
+   t = NULL;
+   mutex_unlock(_trigger_types_lock);
+
+   return t;
+}
+
+struct iio_sw_trigger *iio_sw_trigger_create(const char *type, const char 
*name)
+{
+   struct iio_sw_trigger *t;
+   struct iio_sw_trigger_type 

Re: [GIT PULL] On-demand device probing

[Tomeu Vizoso]

On 10/22/2015 09:26 PM, Greg Kroah-Hartman wrote:
> On Thu, Oct 22, 2015 at 11:53:31AM -0700, Frank Rowand wrote:
>> On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote:
>>> 
>>>
>>> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
 But that's moot currently because Greg believes that the time spent
 probing devices at boot time could be reduced enough so that the order
 in which devices are probed becomes irrelevant. IME that would have to
 be under 200ms so that the user doesn't notice and that's unicorn-far
 from any bootlog I have ever seen.
>>>
>>> But as no one has actually produced a bootlog, how do you know that?
>>> Where exactly is your time being spent?  What driver is causing long
>>> delays?  Why is the long-delay-drivers not being done in their own
>>> thread?  And most importantly, why are you ignoring the work that people
>>> did back in 2008 to solve the issue on other hardware platforms?
>>>
 Given that downstreams are already carrying as many hacks as they
 could think of to speed total boot up, I think this is effectively
 telling them to go away.
>>>
>>> No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to
>>> solve-the-random-issue-i'm-having type patch by putting random calls in
>>> semi-random subsystems all over the kernel.
>>>
>>> And when I ask for real data, you respond with the fact that you aren't
>>> trying to speed up boot time here at all, so what am I supposed to think
>>
>> I also had the understanding that this patch series was about improving
>> boot time.  But I was kindly corrected that the behavior change was
>> getting the panel displaying stuff at an earlier point in the boot sequence,
>> _not_ completing the entire boot faster. 
>>
>> The claim for the current series, in patch 0 in v7 is:
>>
>>With this series I get the kernel to output to the panel in 0.5s,
>>instead of 2.8s.
>>
>> Just to get side-tracked, one other approach at ordering to reduce
>> deferrals reported a modest boot time reduction for four boards and a
>> very slight boot time increase for one other board.) The report of boot
>> times with that approach was in:
>>
>>   http://article.gmane.org/gmane.linux.drivers.devicetree/133010
>>
>> from Alexander Holler.
>>
>> I have not searched further to see if there is more data of boot time
>> reductions from any of the other attempts to change driver binding
>> order to move dependencies before use of a resource.  But whether
>> there is a performance improvement or not, there continues to be
>> a stream of developers creatively impacting the binding order for
>> their specific driver(s) or board.  So it seems that maybe there
>> is an underlying problem, or we don't have adequate documentation
>> explaining how to avoid a need to order bindings, or the
>> documentation exists and is not being read.
>>
>> I have been defaulting to the position that has been asserted by
>> the device tree maintainters, that probe deferrals work just fine
>> for at least the majority of cases (and is the message I have been
>> sharing in my conference presentations about device tree).  But I
>> suspect that there is at least a small minority of cases that are not
>> well served by probe deferral.  (Not to be read as an endorsement of
>> this specific patch series, just a generic observation.)
> 
> I agree, there might be some small numbers that this is a problem for,
> and if so, great, show us the boot logs where things are taking up all
> of the time, and we can work on resolving those issues.
> 
> But without hard numbers / details, this all is just random hand-waving,
> and I don't like making core kernel changes on that basis.  And no one
> else should ever want us to do that either.

Hi,

have found the board in which Stéphane had the original issue on
(exynos5250-snow), and I'm attaching the bootlog of
next-20151013+exynos_defconfig with initcall_debug and DEBUG in dd.c.

As can be seen, 145b.dp-controller is tried reasonably early (at
0.25s), but is deferred and only retried at 0.9s, with the display
finally coming up at 1.35s.

But I'm not sure what's the point in discussing this further if you have
already said that it's fine if downstreams have to change the probing
order by moving files around in the makefiles and by fiddling with
initcall levels.

To give a better understanding of what's going on here, I wasn't
involved in the bringup of this board, but was tasked with fixing this
issue in mainline so it doesn't have to be worked around in every product.

Regards,

Tomeu

> thanks,
> 
> greg k-h
> 

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.3.0-rc5-next-20151013-dirty (tomeu@cizrna) (gcc 
version 5.2.1 20150716 (Red Hat Cross 5.2.1-3) (GCC) ) #3491 SMP PREEMPT Fri 
Oct 23 11:17:16 CEST 2015
[0.00] CPU: ARMv7 Processor [410fc0f4] revision 4 (ARMv7), cr=10c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[

Re: [PATCH] mm,vmscan: Use accurate values for zone_reclaimable() checks

[Tetsuo Handa]

Michal Hocko wrote:
> On Fri 23-10-15 19:36:30, Tejun Heo wrote:
> > Hello, Michal.
> > 
> > On Fri, Oct 23, 2015 at 10:33:16AM +0200, Michal Hocko wrote:
> > > Ohh, OK I can see wq_worker_sleeping now. I've missed your point in
> > > other email, sorry about that. But now I am wondering whether this
> > > is an intended behavior. The documentation says:
> > 
> > This is.
> > 
> > >   WQ_MEM_RECLAIM
> > > 
> > > All wq which might be used in the memory reclaim paths _MUST_
> > > have this flag set.  The wq is guaranteed to have at least one
> > > execution context regardless of memory pressure.
> > > 
> > > Which doesn't seem to be true currently, right? Now I can see your patch
> > 
> > It is true.
> > 
> > > to introduce WQ_IMMEDIATE but I am wondering which WQ_MEM_RECLAIM users
> > > could do without WQ_IMMEDIATE? I mean all current workers might be
> > > looping in the page allocator and it seems possible that WQ_MEM_RECLAIM
> > > work items might be waiting behind them so they cannot help to relieve
> > > the memory pressure. This doesn't sound right to me. Or I am completely
> > > confused and still fail to understand what is WQ_MEM_RECLAIM supposed to
> > > be used for.
> > 
> > It guarantees that there always is enough execution resource to
> > execute a work item from that workqueue. 
> 
> OK, strictly speaking the rescuer is there but it is kind of pointless
> if it doesn't fire up and do a work.
> 
> > The problem here is not lack
> > of execution resource but concurrency management misunderstanding the
> > situation. 
> 
> And this sounds like a bug to me.
> 
> > This also can be fixed by teaching concurrency management
> > to be a bit smarter - e.g. if a work item is burning a lot of CPU
> > cycles continuously or pool hasn't finished a work item over a certain
> > amount of time, automatically ignore the in-flight work item for the
> > purpose of concurrency management; however, this sort of inter-work
> > item busy waits are so extremely rare and undesirable that I'm not
> > sure the added complexity would be worthwhile.
> 
> Don't we have some IO related paths which would suffer from the same
> problem. I haven't checked all the WQ_MEM_RECLAIM users but from the
> name I would expect they _do_ participate in the reclaim and so they
> should be able to make a progress. Now if your new IMMEDIATE flag will
> guarantee that then I would argue that it should be implicit for
> WQ_MEM_RECLAIM otherwise we always risk a similar situation. What would
> be a counter argument for doing that?

WQ_MEM_RECLAIM only guarantees that a "struct task_struct" is preallocated
in order to avoid failing to allocate it on demand due to a GFP_KERNEL
allocation? Is this correct?

WQ_CPU_INTENSIVE only guarantees that work items don't participate in
concurrency management in order to avoid failing to wake up a "struct
task_struct" which will process the work items? Is this correct?

Is Michal's question "does it make sense to use WQ_MEM_RECLAIM without
WQ_CPU_INTENSIVE"? In other words, any "struct task_struct" which calls
rescuer_thread() must imply WQ_CPU_INTENSIVE in order to avoid failing to
wake up due to being participated in concurrency management?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] hp_sdc: convert struct timeval to ktime_t

[Pingbo Wen]

> 在 2015年10月23日，19:45，Arnd Bergmann  写道：
> 
> On Friday 23 October 2015 19:29:39 WEN Pingbo wrote:
>> 1. struct timeval is not y2038 safe, convert it to ktime_t, and there is no 
>> need to handle sec and usec separately
>> 
>> 
> 
> The patch looks good now, but the changelog still needs a tiny bit of
> work. First of all, your line wrapping is off, please start a new line
> after around 70 characters as you do in an email.
> 

Well, little fault:)
Will be fixed in next version.

> Also, we don't normally have enumerated lists in a changelog, just use
> normal text. The best changelogs typically have three paragraphs:
> 
> The first paragraph describes what the driver currently does. For really
> obvious cases, this can be combined with the second paragraph.
> 
> The second paragraph explains why that is bad. This is where you can
> mention the monotonic time vs real time issue and say whether we
> just want the timeval removed to fix the kernel in general or whether
> this particular driver is broken.
> 
> The third paragraph explains what the patch does to resolve the issue
> described in the second one. This is also where you can list other
> approaches that would have solved the problem, and why you picked on
> over the others.

Do we really need this in ChangeLog? Commit msg already states this. I think
the purpose of ChangeLog is let people know the main difference of two
version patch at a glance, and the ‘what’ and ‘why’ should be placed in
commit msg.

Pingbo--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 3/3] cgroup: replace unified-hierarchy.txt with a proper cgroup v2 documentation

[Vivek Goyal]

On Fri, Oct 23, 2015 at 10:18:07AM +0900, Tejun Heo wrote:
> Hello,
> 
> On Thu, Oct 22, 2015 at 11:36:05PM +0900, Tejun Heo wrote:
> > It works with ext2 and 4 and btrfs.  Will document it.  Thanks.
> 
> Updated to include all writeback information from
> blkio-controller.txt.
> 

Thanks Tejun. Looks good.

Vivek

> 5-3-2. Writeback
> 
> Page cache is dirtied through buffered writes and shared mmaps and
> written asynchronously to the backing filesystem by the writeback
> mechanism.  Writeback sits between the memory and IO domains and
> regulates the proportion of dirty memory by balancing dirtying and
> write IOs.
> 
> The io controller, in conjunction with the memory controller,
> implements control of page cache writeback IOs.  The memory controller
> defines the memory domain that dirty memory ratio is calculated and
> maintained for and the io controller defines the io domain which
> writes out dirty pages for the memory domain.  Both system-wide and
> per-cgroup dirty memory states are examined and the more restrictive
> of the two is enforced.
> 
> cgroup writeback requires explicit support from the underlying
> filesystem.  Currently, cgroup writeback is implemented on ext2, ext4
> and btrfs.  On other filesystems, all writeback IOs are attributed to
> the root cgroup.
> 
> There are inherent differences in memory and writeback management
> which affects how cgroup ownership is tracked.  Memory is tracked per
> page while writeback per inode.  For the purpose of writeback, an
> inode is assigned to a cgroup and all IO requests to write dirty pages
> from the inode are attributed to that cgroup.
> 
> As cgroup ownership for memory is tracked per page, there can be pages
> which are associated with different cgroups than the one the inode is
> associated with.  These are called foreign pages.  The writeback
> constantly keeps track of foreign pages and, if a particular foreign
> cgroup becomes the majority over a certain period of time, switches
> the ownership of the inode to that cgroup.
> 
> While this model is enough for most use cases where a given inode is
> mostly dirtied by a single cgroup even when the main writing cgroup
> changes over time, use cases where multiple cgroups write to a single
> inode simultaneously are not supported well.  In such circumstances, a
> significant portion of IOs are likely to be attributed incorrectly.
> As memory controller assigns page ownership on the first use and
> doesn't update it until the page is released, even if writeback
> strictly follows page ownership, multiple cgroups dirtying overlapping
> areas wouldn't work as expected.  It's recommended to avoid such usage
> patterns.
> 
> The sysctl knobs which affect writeback behavior are applied to cgroup
> writeback as follows.
> 
>   vm.dirty_background_ratio
>   vm.dirty_ratio
> 
>   These ratios apply the same to cgroup writeback with the
>   amount of available memory capped by limits imposed by the
>   memory controller and system-wide clean memory.
> 
>   vm.dirty_background_bytes
>   vm.dirty_bytes
> 
>   For cgroup writeback, this is calculated into ratio against
>   total available memory and applied the same way as
>   vm.dirty[_background]_ratio.
> 
> 
> P. Information on Kernel Programming
> 
> This section contains kernel programming information in the areas
> where interacting with cgroup is necessary.  cgroup core and
> controllers are not covered.
> 
> 
> P-1. Filesystem Support for Writeback
> 
> A filesystem can support cgroup writeback by updating
> address_space_operations->writepage[s]() to annotate bio's using the
> following two functions.
> 
>   wbc_init_bio(@wbc, @bio)
> 
>   Should be called for each bio carrying writeback data and
>   associates the bio with the inode's owner cgroup.  Can be
>   called anytime between bio allocation and submission.
> 
>   wbc_account_io(@wbc, @page, @bytes)
> 
>   Should be called for each data segment being written out.
>   While this function doesn't care exactly when it's called
>   during the writeback session, it's the easiest and most
>   natural to call it as data segments are added to a bio.
> 
> With writeback bio's annotated, cgroup support can be enabled per
> super_block by setting SB_I_CGROUPWB in ->s_iflags.  This allows for
> selective disabling of cgroup writeback support which is helpful when
> certain filesystem features, e.g. journaled data mode, are
> incompatible.
> 
> wbc_init_bio() binds the specified bio to its cgroup.  Depending on
> the configuration, the bio may be executed at a lower priority and if
> the writeback session is holding shared resources, e.g. a journal
> entry, may lead to priority inversion.  There is no one easy solution
> for the problem.  Filesystems can try to work around specific problem
> cases by skipping wbc_init_bio() or using bio_associate_blkcg()
> directly.
> 
> -- 
> tejun
--
To unsubscribe from this list: send the line "unsubscribe 

[PATCH 02/11] net: llc: fix a setting of error value to size_t

[LABBE Corentin]

The variable copied is a size_t, so setting a negative value to it is
invalid.
The patch add an "err" variable for getting the error code.

Signed-off-by: LABBE Corentin 
---
 net/llc/af_llc.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/net/llc/af_llc.c b/net/llc/af_llc.c
index 8dab4e5..79b915d 100644
--- a/net/llc/af_llc.c
+++ b/net/llc/af_llc.c
@@ -719,9 +719,10 @@ static int llc_ui_recvmsg(struct socket *sock, struct 
msghdr *msg, size_t len,
unsigned long used;
int target; /* Read at least this many bytes */
long timeo;
+   int err = 0;
 
lock_sock(sk);
-   copied = -ENOTCONN;
+   err = -ENOTCONN;
if (unlikely(sk->sk_type == SOCK_STREAM && sk->sk_state == TCP_LISTEN))
goto out;
 
@@ -745,9 +746,8 @@ static int llc_ui_recvmsg(struct socket *sock, struct 
msghdr *msg, size_t len,
 * and move it down to the bottom of the loop
 */
if (signal_pending(current)) {
-   if (copied)
-   break;
-   copied = timeo ? sock_intr_errno(timeo) : -EAGAIN;
+   if (!copied)
+   err = timeo ? sock_intr_errno(timeo) : -EAGAIN;
break;
}
 
@@ -775,7 +775,7 @@ static int llc_ui_recvmsg(struct socket *sock, struct 
msghdr *msg, size_t len,
break;
 
if (sk->sk_err) {
-   copied = sock_error(sk);
+   err = sock_error(sk);
break;
}
if (sk->sk_shutdown & RCV_SHUTDOWN)
@@ -787,13 +787,15 @@ static int llc_ui_recvmsg(struct socket *sock, struct 
msghdr *msg, size_t len,
 * This occurs when user tries to read
 * from never connected socket.
 */
-   copied = -ENOTCONN;
+   err = -ENOTCONN;
+   copied = 0;
break;
}
break;
}
if (!timeo) {
-   copied = -EAGAIN;
+   err = -EAGAIN;
+   copied = 0;
break;
}
}
@@ -823,7 +825,7 @@ static int llc_ui_recvmsg(struct socket *sock, struct 
msghdr *msg, size_t len,
if (rc) {
/* Exception. Bailout! */
if (!copied)
-   copied = -EFAULT;
+   err = -EFAULT;
break;
}
}
@@ -850,6 +852,8 @@ static int llc_ui_recvmsg(struct socket *sock, struct 
msghdr *msg, size_t len,
 
 out:
release_sock(sk);
+   if (err)
+   return err;
return copied;
 copy_uaddr:
if (uaddr != NULL && skb != NULL) {
-- 
2.4.10

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

Re: [PATCH v2 1/4] KVM: X86: Add arrays to save/restore LBR MSRs

[kbuild test robot]

Hi Jian,

[auto build test ERROR on v4.3-rc6 -- if it's inappropriate base, please 
suggest rules for selecting the more suitable base]

url:
https://github.com/0day-ci/linux/commits/Jian-Zhou/KVM-X86-Add-arrays-to-save-restore-LBR-MSRs/20151023-172601
config: x86_64-lkp (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

Note: the 
linux-review/Jian-Zhou/KVM-X86-Add-arrays-to-save-restore-LBR-MSRs/20151023-172601
 HEAD d402c03a709c1dff60e2800becbafaf3b2d86dcd builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

   In file included from include/linux/kvm_host.h:34:0,
from arch/x86/kvm/../../../virt/kvm/kvm_main.c:21:
>> arch/x86/include/asm/kvm_host.h:530:25: error: 'MAX_NUM_LBR_MSRS' undeclared 
>> here (not in a function)
  struct msr_data guest[MAX_NUM_LBR_MSRS];
^

vim +/MAX_NUM_LBR_MSRS +530 arch/x86/include/asm/kvm_host.h

   524  
   525  int lbr_status;
   526  int lbr_used;
   527  
   528  struct lbr_msr {
   529  unsigned nr;
 > 530  struct msr_data guest[MAX_NUM_LBR_MSRS];
   531  struct msr_data host[MAX_NUM_LBR_MSRS];
   532  }lbr_msr;
   533  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

[PATCH 01/11] net: change len parameter type for memcpy_[to|from]_msg

[LABBE Corentin]

The len parameter is only used with copy_from_iter() who wait for a
size_t and then compared to return type of copy_from_iter() which is
size_t also. So len must be set as size_t

Signed-off-by: LABBE Corentin 
---
 include/linux/skbuff.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 4398411..109a127 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -2827,12 +2827,12 @@ int skb_ensure_writable(struct sk_buff *skb, int 
write_len);
 int skb_vlan_pop(struct sk_buff *skb);
 int skb_vlan_push(struct sk_buff *skb, __be16 vlan_proto, u16 vlan_tci);
 
-static inline int memcpy_from_msg(void *data, struct msghdr *msg, int len)
+static inline int memcpy_from_msg(void *data, struct msghdr *msg, size_t len)
 {
return copy_from_iter(data, len, >msg_iter) == len ? 0 : -EFAULT;
 }
 
-static inline int memcpy_to_msg(struct msghdr *msg, void *data, int len)
+static inline int memcpy_to_msg(struct msghdr *msg, void *data, size_t len)
 {
return copy_to_iter(data, len, >msg_iter) == len ? 0 : -EFAULT;
 }
-- 
2.4.10

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 09/11] net: ipv6: hlen could be set as size_t

[LABBE Corentin]

The hlen member of raw6_frag_vec is used in operation/function that
wait for unsigned value. So it need to be set as size_t.

This patch do the same for the hlen variable.

Signed-off-by: LABBE Corentin 
---
 net/ipv6/raw.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/ipv6/raw.c b/net/ipv6/raw.c
index 5d9404b..434e9ad 100644
--- a/net/ipv6/raw.c
+++ b/net/ipv6/raw.c
@@ -618,7 +618,7 @@ static int rawv6_send_hdrinc(struct sock *sk, struct msghdr 
*msg, size_t length,
struct sk_buff *skb;
int err;
struct rt6_info *rt = (struct rt6_info *)*dstp;
-   int hlen = LL_RESERVED_SPACE(rt->dst.dev);
+   size_t hlen = LL_RESERVED_SPACE(rt->dst.dev);
int tlen = rt->dst.dev->needed_tailroom;
 
if (length > rt->dst.dev->mtu) {
@@ -674,7 +674,7 @@ error:
 
 struct raw6_frag_vec {
struct msghdr *msg;
-   int hlen;
+   size_t hlen;
char c[4];
 };
 
-- 
2.4.10

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 07/11] net: caif: change chunk from int to size_t

[LABBE Corentin]

chunk cannot be negative and is use in operation/function that
wait for unsigned value. This patch set it as size_t.
The patch do the same for the size variable.

Signed-off-by: LABBE Corentin 
---
 net/caif/caif_socket.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/net/caif/caif_socket.c b/net/caif/caif_socket.c
index cc85891..362f6d8 100644
--- a/net/caif/caif_socket.c
+++ b/net/caif/caif_socket.c
@@ -370,7 +370,7 @@ static int caif_stream_recvmsg(struct socket *sock, struct 
msghdr *msg,
timeo = sock_rcvtimeo(sk, flags_DONTWAIT);
 
do {
-   int chunk;
+   size_t chunk;
struct sk_buff *skb;
 
lock_sock(sk);
@@ -595,7 +595,8 @@ static int caif_stream_sendmsg(struct socket *sock, struct 
msghdr *msg,
 {
struct sock *sk = sock->sk;
struct caifsock *cf_sk = container_of(sk, struct caifsock, sk);
-   int err, size;
+   int err;
+   size_t size;
struct sk_buff *skb;
int sent = 0;
long timeo;
-- 
2.4.10

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 08/11] net: bluetooth: change the len parameter of sco_send_frame() to size_t

[LABBE Corentin]

len is used in operation/function that wait for unsigned value.
Furthermore the only one call of sco_send_frame give a size_t as argument.
So the parameter need to be set as size_t.

Signed-off-by: LABBE Corentin 
---
 net/bluetooth/sco.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
index f315c8d..1ae4b36 100644
--- a/net/bluetooth/sco.c
+++ b/net/bluetooth/sco.c
@@ -268,7 +268,7 @@ done:
return err;
 }
 
-static int sco_send_frame(struct sock *sk, struct msghdr *msg, int len)
+static int sco_send_frame(struct sock *sk, struct msghdr *msg, size_t len)
 {
struct sco_conn *conn = sco_pi(sk)->conn;
struct sk_buff *skb;
-- 
2.4.10

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 05/11] net: irda: change chunk from int to size_t

[LABBE Corentin]

chunk cannot be negative and is use in operation/function that
wait for unsigned value. This patch set it as size_t.

Signed-off-by: LABBE Corentin 
---
 net/irda/af_irda.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/irda/af_irda.c b/net/irda/af_irda.c
index fae6822..180cca2 100644
--- a/net/irda/af_irda.c
+++ b/net/irda/af_irda.c
@@ -1424,7 +1424,7 @@ static int irda_recvmsg_stream(struct socket *sock, 
struct msghdr *msg,
timeo = sock_rcvtimeo(sk, noblock);
 
do {
-   int chunk;
+   size_t chunk;
struct sk_buff *skb = skb_dequeue(>sk_receive_queue);
 
if (skb == NULL) {
-- 
2.4.10

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 04/11] net: packet: change vnet_hdr_len from int to size_t

[LABBE Corentin]

vnet_hdr_len cannot be negative and is use in operation/function that
wait for unsigned value.
This patch set vnet_hdr_len as size_t.

Signed-off-by: LABBE Corentin 
---
 net/packet/af_packet.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index aa4b15c..58a5c8f 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -2632,7 +2632,7 @@ static int packet_snd(struct socket *sock, struct msghdr 
*msg, size_t len)
int err, reserve = 0;
struct virtio_net_hdr vnet_hdr = { 0 };
int offset = 0;
-   int vnet_hdr_len;
+   size_t vnet_hdr_len;
struct packet_sock *po = pkt_sk(sk);
unsigned short gso_type = 0;
int hlen, tlen;
@@ -3106,7 +3106,7 @@ static int packet_recvmsg(struct socket *sock, struct 
msghdr *msg, size_t len,
struct sock *sk = sock->sk;
struct sk_buff *skb;
int copied, err;
-   int vnet_hdr_len = 0;
+   size_t vnet_hdr_len = 0;
unsigned int origlen = 0;
 
err = -EINVAL;
-- 
2.4.10

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 06/11] net: ipv6: set the length parameter of rawv6_send_hdrinc() to size_t

[LABBE Corentin]

length is used in operation/function that wait for unsigned value.
Furthermore the only one call of rawv6_send_hdrinc() give a size_t as
length arguments.
So the parameter need to be set as size_t.

Signed-off-by: LABBE Corentin 
---
 net/ipv6/raw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ipv6/raw.c b/net/ipv6/raw.c
index fdbada156..5d9404b 100644
--- a/net/ipv6/raw.c
+++ b/net/ipv6/raw.c
@@ -609,7 +609,7 @@ out:
return err;
 }
 
-static int rawv6_send_hdrinc(struct sock *sk, struct msghdr *msg, int length,
+static int rawv6_send_hdrinc(struct sock *sk, struct msghdr *msg, size_t 
length,
struct flowi6 *fl6, struct dst_entry **dstp,
unsigned int flags)
 {
-- 
2.4.10

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 11/11] crypto: algif: Change some variable to size_t

[LABBE Corentin]

Some variable are set as int but store only positive values.
Furthermore there are used in operation/function that wait for unsigned
value.
This patch set them as size_t.

Signed-off-by: LABBE Corentin 
---
 crypto/algif_aead.c |  6 +++---
 crypto/algif_skcipher.c | 10 +-
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/crypto/algif_aead.c b/crypto/algif_aead.c
index 0aa6fdf..f70bcf8 100644
--- a/crypto/algif_aead.c
+++ b/crypto/algif_aead.c
@@ -213,7 +213,7 @@ static int aead_sendmsg(struct socket *sock, struct msghdr 
*msg, size_t size)
}
 
while (size) {
-   unsigned long len = size;
+   size_t len = size;
struct scatterlist *sg = NULL;
 
/* use the existing memory in an allocated page */
@@ -247,7 +247,7 @@ static int aead_sendmsg(struct socket *sock, struct msghdr 
*msg, size_t size)
/* allocate a new page */
len = min_t(unsigned long, size, aead_sndbuf(sk));
while (len) {
-   int plen = 0;
+   size_t plen = 0;
 
if (sgl->cur >= ALG_MAX_PAGES) {
aead_put_sgl(sk);
@@ -256,7 +256,7 @@ static int aead_sendmsg(struct socket *sock, struct msghdr 
*msg, size_t size)
}
 
sg = sgl->sg + sgl->cur;
-   plen = min_t(int, len, PAGE_SIZE);
+   plen = min_t(size_t, len, PAGE_SIZE);
 
sg_assign_page(sg, alloc_page(GFP_KERNEL));
err = -ENOMEM;
diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
index af31a0e..bbb1b66 100644
--- a/crypto/algif_skcipher.c
+++ b/crypto/algif_skcipher.c
@@ -40,7 +40,7 @@ struct skcipher_ctx {
struct af_alg_completion completion;
 
atomic_t inflight;
-   unsigned used;
+   size_t used;
 
unsigned int len;
bool more;
@@ -153,7 +153,7 @@ static int skcipher_alloc_sgl(struct sock *sk)
return 0;
 }
 
-static void skcipher_pull_sgl(struct sock *sk, int used, int put)
+static void skcipher_pull_sgl(struct sock *sk, size_t used, int put)
 {
struct alg_sock *ask = alg_sk(sk);
struct skcipher_ctx *ctx = ask->private;
@@ -167,7 +167,7 @@ static void skcipher_pull_sgl(struct sock *sk, int used, 
int put)
sg = sgl->sg;
 
for (i = 0; i < sgl->cur; i++) {
-   int plen = min_t(int, used, sg[i].length);
+   size_t plen = min_t(size_t, used, sg[i].length);
 
if (!sg_page(sg + i))
continue;
@@ -348,7 +348,7 @@ static int skcipher_sendmsg(struct socket *sock, struct 
msghdr *msg,
while (size) {
struct scatterlist *sg;
unsigned long len = size;
-   int plen;
+   size_t plen;
 
if (ctx->merge) {
sgl = list_entry(ctx->tsgl.prev,
@@ -390,7 +390,7 @@ static int skcipher_sendmsg(struct socket *sock, struct 
msghdr *msg,
sg_unmark_end(sg + sgl->cur);
do {
i = sgl->cur;
-   plen = min_t(int, len, PAGE_SIZE);
+   plen = min_t(size_t, len, PAGE_SIZE);
 
sg_assign_page(sg + i, alloc_page(GFP_KERNEL));
err = -ENOMEM;
-- 
2.4.10

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 10/11] net: ipv4: hlen could be set as size_t

[LABBE Corentin]

The hlen member of raw_frag_vec is used in operation/function that wait
for unsigned value. So it need to be set as size_t.

Signed-off-by: LABBE Corentin 
---
 net/ipv4/raw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c
index 561cd4b..a00aaed 100644
--- a/net/ipv4/raw.c
+++ b/net/ipv4/raw.c
@@ -86,7 +86,7 @@ struct raw_frag_vec {
struct icmphdr icmph;
char c[1];
} hdr;
-   int hlen;
+   size_t hlen;
 };
 
 static struct raw_hashinfo raw_v4_hashinfo = {
-- 
2.4.10

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

[PATCH 03/11] net: llc: change copied to size_t in llc_ui_sendmsg

[LABBE Corentin]

The variable copied in llc_ui_sendmsg() cannot be negative and is used
in functions that wait for unsigned value, so set it as size_t (like it
is in llc_ui_recvmsg())

Signed-off-by: LABBE Corentin 
---
 net/llc/af_llc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/llc/af_llc.c b/net/llc/af_llc.c
index 79b915d..f435b77 100644
--- a/net/llc/af_llc.c
+++ b/net/llc/af_llc.c
@@ -891,7 +891,8 @@ static int llc_ui_sendmsg(struct socket *sock, struct 
msghdr *msg, size_t len)
int noblock = flags & MSG_DONTWAIT;
struct sk_buff *skb;
size_t size = 0;
-   int rc = -EINVAL, copied = 0, hdrlen;
+   int rc = -EINVAL, hdrlen;
+   size_t copied = 0;
 
dprintk("%s: sending from %02X to %02X\n", __func__,
llc->laddr.lsap, llc->daddr.lsap);
-- 
2.4.10

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

[no subject]

[LABBE Corentin]

Hello

This patch series was begun by my finding that memcpy_[to|from]_msg have
a parameter len which is an int but used as size_t in whole functions.
Without blindly changing the parameter to size_t, I have tried to see if
anywhere in linux source code, someone give a negative argument with
the following (unfinished) coccinnelle patch.
virtual report
@@
type T;
signed T i;
@@
(
memcpy_from_msg
|
memcpy_to_msg
)
 (...,
- i)
+ (size_t)i)

With that I found many place where int variable is used to store unsigned values
and which could be set as size_t since there are used againt size_t
and/or given to functions that wait for size_t.
It permit also to found a bug in net/llc/af_llc.c where a size_t variable
stored error codes.

Regards

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] devicetree: add binding for Aurora VLSI NB8800 Ethernet controller

[Marc Gonzalez]

On 22/10/2015 16:02, Mans Rullgard wrote:

> This adds a binding for the Aurora VLSI NB8800 Ethernet controller
> using the "aurora,nb8800" compatible string.  When used in Sigma
> Designs chips a few additional control registers are available.
> This variant is indicated by the "sigma,smp8640-ethernet" compatible
> string.
> 
> Signed-off-by: Mans Rullgard 
> ---
>  .../devicetree/bindings/net/aurora,nb8800.txt  | 26 
> ++
>  1 file changed, 26 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/net/aurora,nb8800.txt
> 
> diff --git a/Documentation/devicetree/bindings/net/aurora,nb8800.txt 
> b/Documentation/devicetree/bindings/net/aurora,nb8800.txt
> new file mode 100644
> index 000..c19f615
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/aurora,nb8800.txt
> @@ -0,0 +1,26 @@
> +* Aurora VLSI AU-NB8800 Ethernet controller
> +
> +Required properties:
> +- compatible: Should be "aurora,nb8800", "sigma,smp8640-ethernet"
> + The latter indicates presence of extra features added by Sigma Designs.

I've been meaning to ask a noob question to the devicetree group
about how names for compatible strings are chosen.

Sigma Designs has two active SoC families, Tango3 (which consists of
about a dozen MIPS-based SoCs, typically named SMP86xx) and Tango4
(a few ARM-based SoCs, typically named SMP87xx). I should note that
there is no SMP8640 SoC AFAIK, rather SMP864x is a Tango3 sub-family
(I could locate 42,43,44,45,46).

AFAIK, all our SoCs are using the same Aurora NB8800 Ethernet MAC,
along with the extra features. I find it odd to use a specific SoC
model to refer to this device, instead of a more generic name.
(It's weird having to mention smp8640 in the tango4 DT.)

Would it be possible to have a compatible string which makes it
clear that it is an Aurora MAC with vendor-specific tweaks?
Something like "sigma,aurora-nb8800-mac" ?

> +- reg: Should be MMIO address space of the device
> +- interrupts: Should contain the interrupt specifier for the device
> +- interrupt-parent: Should be a phandle for the interrupt controller
> +- clocks: Should be a phandle for the clock for the device
> +
> +Common properties described in ethernet.txt:
> +- local-mac-address
> +- mac-address
> +- max-speed
> +- phy-mode
> +
> +Example:
> +
> +ethernet@26000 {
> + compatible = "aurora,nb8800";
> + reg = <0x1 0x800>;
> + interrupts = <42>;

I thought one had to specify also whether the device sent "edge"
or "level" IRQs?

> + clocks = <_clk>;
> + max-speed = <1000>;
> + phy-connection-type = "rgmii";
> +};

Regards.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/2] Staging: lustre: lnet: lib-move return of an errno should typically be negative (ie: return -EAGAIN)

[Nilesh Kokane]

On Fri, Oct 23, 2015 at 5:10 PM, Dilger, Andreas
 wrote:
> On 2015/10/22, 22:30, "Nilesh Kokane"  wrote:
>>Fixed- Return of an errno should typically be negative (ie: return
>>-EAGAIN)
>
> Nak. Please do not change these function return values.  They are
> converted as necessary by the callers before returning to userspace, but
> allow the code to distinguish between errors generated internally or from
> lower networking layers.
>
> As you will note, many of them are explicitly annotated with comments that
> they are returning positive values.  The patch as it stands would totally
> break the code.

Ok. I'll take care next time.

-- 
//Nilesh Kokane
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Make vmstat deferrable again (was Re: [PATCH] mm,vmscan: Use accurate values for zone_reclaimable() checks)

[Sergey Senozhatsky]

On (10/23/15 06:43), Christoph Lameter wrote:
> Is this ok?

kernel/sched/loadavg.c: In function ‘calc_load_enter_idle’:
kernel/sched/loadavg.c:195:2: error: implicit declaration of function 
‘quiet_vmstat’ [-Werror=implicit-function-declaration]
  quiet_vmstat();
^

> Subject: Fix vmstat: make vmstat_updater deferrable again and shut down on 
> idle
> 
> Currently the vmstat updater is not deferrable as a result of commit
> ba4877b9ca51f80b5d30f304a46762f0509e1635. This in turn can cause multiple
> interruptions of the applications because the vmstat updater may run at
> different times than tick processing. No good.
> 
> Make vmstate_update deferrable again and provide a function that
> shuts down the vmstat updater when we go idle by folding the differentials.
> Shut it down from the load average calculation logic introduced by nohz.
> 
> Note that the shepherd thread will continue scanning the differentials
> from another processor and will reenable the vmstat workers if it
> detects any changes.
> 
> Fixes: ba4877b9ca51f80b5d30f304a46762f0509e1635 (do not use deferrable delay)
> Signed-off-by: Christoph Lameter 
> 
> Index: linux/mm/vmstat.c
> ===
> --- linux.orig/mm/vmstat.c
> +++ linux/mm/vmstat.c
> @@ -1395,6 +1395,20 @@ static void vmstat_update(struct work_st
>  }
> 
>  /*
> + * Switch off vmstat processing and then fold all the remaining differentials
> + * until the diffs stay at zero. The function is used by NOHZ and can only be
> + * invoked when tick processing is not active.
> + */
> +void quiet_vmstat(void)
> +{
> + do {
> + if (!cpumask_test_and_set_cpu(smp_processor_id(), cpu_stat_off))
> + cancel_delayed_work(this_cpu_ptr(_work));

shouldn't preemption be disable for smp_processor_id() here?

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

Re: [PATCH 1/2] mmc: dw_mmc: add hw_reset support

[Jaehoon Chung]

Hi, Shawn.

On 10/22/2015 03:19 PM, Shawn Lin wrote:
> This patch implement hw_reset function for DesignWare
> MMC controller. By adding this feature, mmc blk can
> do some basic recovery if emmc device cannot work any
> more for unknown reasons.

Are there any other issue before applied this patch?

> 
> Signed-off-by: Shawn Lin 
> 
> ---
> 
>  drivers/mmc/host/dw_mmc.c | 29 +
>  drivers/mmc/host/dw_mmc.h |  4 
>  2 files changed, 33 insertions(+)
> 
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index 6e600e8..8a0f2995 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -1478,6 +1478,34 @@ static int dw_mci_get_cd(struct mmc_host *mmc)
>   return present;
>  }
>  
> +static void dw_mci_hw_reset(struct mmc_host *mmc)
> +{
> + struct dw_mci_slot *slot = mmc_priv(mmc);
> + struct dw_mci *host = slot->host;
> +
> + if (host->use_dma == TRANS_MODE_IDMAC)
> + dw_mci_idmac_reset(host);
> +
> + if (!dw_mci_ctrl_reset(host, SDMMC_CTRL_DMA_RESET) ||
> + (!dw_mci_ctrl_reset(host, SDMMC_CTRL_FIFO_RESET)))

Why does it reset twice? Can't reset together with DMA and FIFO?
dw_mci_ctrl_reset(host, SDMMC_CTRL_DMA_RESET | SDMMC_CTRL_FIFO_RESET)?

> + return;
> +
> + /* CARD_RESET
> +  * According to eMMC spec
> +  * tRstW >= 1us:   RST_n pulse width
> +  * tRSCA >= 200us: RST_n to Command time
> +  * tRSTH >= 1us:   RST_n high period
> +  * Note: add some margin to make rst timing not too
> +  * "spec" for some bad qulity eMMC devices.

some bad quality? Which devices are bad quality devices?

> +  */
> +  mci_writel(slot->host, RST_N, SDMMC_RST_HWRESET);
> +  wmb(); /* drain writebuffer */
> +  usleep_range(5, 10);
> +  mci_writel(slot->host, RST_N, SDMMC_RST_HWACTIVE);
> +  wmb(); /* drain writebuffer */
> +  usleep_range(500, 1000);

Need to drain writebuffer at here?
I don't know why you choose those values..Just some margin?
And if you want to apply this, i recommend to use the shift with card number.

Best Regards,
Jaehoon Chung

> +}
> +
>  static void dw_mci_init_card(struct mmc_host *mmc, struct mmc_card *card)
>  {
>   struct dw_mci_slot *slot = mmc_priv(mmc);
> @@ -1564,6 +1592,7 @@ static const struct mmc_host_ops dw_mci_ops = {
>   .set_ios= dw_mci_set_ios,
>   .get_ro = dw_mci_get_ro,
>   .get_cd = dw_mci_get_cd,
> + .hw_reset   = dw_mci_hw_reset,
>   .enable_sdio_irq= dw_mci_enable_sdio_irq,
>   .execute_tuning = dw_mci_execute_tuning,
>   .card_busy  = dw_mci_card_busy,
> diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
> index f2a88d4..9df18c1 100644
> --- a/drivers/mmc/host/dw_mmc.h
> +++ b/drivers/mmc/host/dw_mmc.h
> @@ -46,6 +46,7 @@
>  #define SDMMC_VERID  0x06c
>  #define SDMMC_HCON   0x070
>  #define SDMMC_UHS_REG0x074
> +#define SDMMC_RST_N  0x078
>  #define SDMMC_BMOD   0x080
>  #define SDMMC_PLDMND 0x084
>  #define SDMMC_DBADDR 0x088
> @@ -169,6 +170,9 @@
>  #define SDMMC_IDMAC_ENABLE   BIT(7)
>  #define SDMMC_IDMAC_FB   BIT(1)
>  #define SDMMC_IDMAC_SWRESET  BIT(0)
> +/* H/W reset*/
> +#define SDMMC_RST_HWACTIVE   0x1
> +#define SDMMC_RST_HWRESET0x0
>  /* Version ID register define */
>  #define SDMMC_GET_VERID(x)   ((x) & 0x)
>  /* Card read threshold */
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 net-next] bpf: fix bpf_perf_event_read() helper

[Peter Zijlstra]

On Thu, Oct 22, 2015 at 05:10:14PM -0700, Alexei Starovoitov wrote:
> +++ b/kernel/trace/bpf_trace.c
> @@ -199,6 +199,11 @@ static u64 bpf_perf_event_read(u64 r1, u64 index, u64 
> r3, u64 r4, u64 r5)
>   if (!event)
>   return -ENOENT;
>  
> + /* make sure event is local and doesn't have pmu::count */
> + if (event->oncpu != smp_processor_id() ||
> + event->pmu->count)
> + return -EINVAL;
> +
>   /*
>* we don't know if the function is run successfully by the
>* return value. It can be judged in other places, such as

I might want to go turn that into a helper function to keep !perf code
from poking around in the event itself, but its ok for now I suppose.

> @@ -207,7 +212,7 @@ static u64 bpf_perf_event_read(u64 r1, u64 index, u64 r3, 
> u64 r4, u64 r5)
>   return perf_event_read_local(event);
>  }

So the bpf_perf_event_read() returns the count value, does this not also
mean that returning -EINVAL here is also 'wrong'?

I mean, sure an actual count value that high is unlikely, but its still
a broken interface.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] cpuidle: mvebu: disable the bind/unbind attributes and use builtin_platform_driver

[Daniel Lezcano]

From: Russell King 

As the driver doesn't support unbinding, nor does it support arbitary
binding of devices, disable the bind/unbind attributes for this driver.
Also, as the driver has no remove function, it can never be modular,
so use builtin_platform_driver() to avoid the module exit boilerplate.

Signed-off-by: Russell King 
Signed-off-by: Daniel Lezcano 
---
 drivers/cpuidle/cpuidle-mvebu-v7.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/cpuidle/cpuidle-mvebu-v7.c 
b/drivers/cpuidle/cpuidle-mvebu-v7.c
index facd7d3..01a8569 100644
--- a/drivers/cpuidle/cpuidle-mvebu-v7.c
+++ b/drivers/cpuidle/cpuidle-mvebu-v7.c
@@ -127,11 +127,12 @@ static struct platform_driver mvebu_cpuidle_driver = {
.probe = mvebu_v7_cpuidle_probe,
.driver = {
.name = "cpuidle-mbevu",
+   .suppress_bind_attrs = true,
},
.id_table = mvebu_cpuidle_ids,
 };
 
-module_platform_driver(mvebu_cpuidle_driver);
+builtin_platform_driver(mvebu_cpuidle_driver);
 
 MODULE_AUTHOR("Gregory CLEMENT ");
 MODULE_DESCRIPTION("Marvell EBU v7 cpuidle driver");
-- 
1.9.1

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

[PATCH 1/2] cpuidle: mvebu: clean up multiple platform drivers

[Daniel Lezcano]

From: Russell King 

There's no need to use multiple platform drivers, especially when we
want to do something different in the probe, but we still use a common
probe function.

We can use the platform ID system to only register one platform driver,
but have it match several devices, and give us the CPU idle driver via
the ID's driver_data.

Signed-off-by: Russell King 
Signed-off-by: Daniel Lezcano 
---
 drivers/cpuidle/cpuidle-mvebu-v7.c | 45 +-
 1 file changed, 20 insertions(+), 25 deletions(-)

diff --git a/drivers/cpuidle/cpuidle-mvebu-v7.c 
b/drivers/cpuidle/cpuidle-mvebu-v7.c
index 980151f..facd7d3 100644
--- a/drivers/cpuidle/cpuidle-mvebu-v7.c
+++ b/drivers/cpuidle/cpuidle-mvebu-v7.c
@@ -99,44 +99,39 @@ static struct cpuidle_driver armada38x_idle_driver = {
 
 static int mvebu_v7_cpuidle_probe(struct platform_device *pdev)
 {
-   mvebu_v7_cpu_suspend = pdev->dev.platform_data;
+   const struct platform_device_id *id = pdev->id_entry;
 
-   if (!strcmp(pdev->dev.driver->name, "cpuidle-armada-xp"))
-   return cpuidle_register(_idle_driver, NULL);
-   else if (!strcmp(pdev->dev.driver->name, "cpuidle-armada-370"))
-   return cpuidle_register(_idle_driver, NULL);
-   else if (!strcmp(pdev->dev.driver->name, "cpuidle-armada-38x"))
-   return cpuidle_register(_idle_driver, NULL);
-   else
+   if (!id)
return -EINVAL;
-}
 
-static struct platform_driver armadaxp_cpuidle_plat_driver = {
-   .driver = {
-   .name = "cpuidle-armada-xp",
-   },
-   .probe = mvebu_v7_cpuidle_probe,
-};
+   mvebu_v7_cpu_suspend = pdev->dev.platform_data;
 
-module_platform_driver(armadaxp_cpuidle_plat_driver);
+   return cpuidle_register((struct cpuidle_driver *)id->driver_data, NULL);
+}
 
-static struct platform_driver armada370_cpuidle_plat_driver = {
-   .driver = {
+static const struct platform_device_id mvebu_cpuidle_ids[] = {
+   {
+   .name = "cpuidle-armada-xp",
+   .driver_data = (unsigned long)_idle_driver,
+   }, {
.name = "cpuidle-armada-370",
+   .driver_data = (unsigned long)_idle_driver,
+   }, {
+   .name = "cpuidle-armada-38x",
+   .driver_data = (unsigned long)_idle_driver,
},
-   .probe = mvebu_v7_cpuidle_probe,
+   {}
 };
 
-module_platform_driver(armada370_cpuidle_plat_driver);
-
-static struct platform_driver armada38x_cpuidle_plat_driver = {
+static struct platform_driver mvebu_cpuidle_driver = {
+   .probe = mvebu_v7_cpuidle_probe,
.driver = {
-   .name = "cpuidle-armada-38x",
+   .name = "cpuidle-mbevu",
},
-   .probe = mvebu_v7_cpuidle_probe,
+   .id_table = mvebu_cpuidle_ids,
 };
 
-module_platform_driver(armada38x_cpuidle_plat_driver);
+module_platform_driver(mvebu_cpuidle_driver);
 
 MODULE_AUTHOR("Gregory CLEMENT ");
 MODULE_DESCRIPTION("Marvell EBU v7 cpuidle driver");
-- 
1.9.1

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

[PULL] cpuidle for 4.4

[Daniel Lezcano]

Hi Rafael,

this pull request contains a couple of changes from Russel King.

 - Disable bind/unbind attribute and use builtin_platform_driver for 
mvebu (Russell King)


 - Clean up the code by removing the multiple platform drivers and use 
the platform ID instead (Russell King)


Thanks !

  -- Daniel

The following changes since commit 7379047d5585187d1288486d4627873170d0005a:

  Linux 4.3-rc6 (2015-10-18 16:08:42 -0700)

are available in the git repository at:

  http://git.linaro.org/people/daniel.lezcano/linux.git cpuidle/4.4

for you to fetch changes up to ab319939a58678c19a68ff10c8a08cef462a3ba6:

  cpuidle: mvebu: disable the bind/unbind attributes and use 
builtin_platform_driver (2015-10-23 12:40:48 +0200)



Russell King (2):
  cpuidle: mvebu: clean up multiple platform drivers
  cpuidle: mvebu: disable the bind/unbind attributes and use 
builtin_platform_driver


 drivers/cpuidle/cpuidle-mvebu-v7.c | 46 
+-

 1 file changed, 21 insertions(+), 25 deletions(-)


--
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

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

Re: [PATCH v8 00/14] support "task_isolation" mode for nohz_full

[Theodore Ts'o]

On Fri, Oct 23, 2015 at 11:04:59AM +0200, Peter Zijlstra wrote:
> > If you think this is actually the wrong thing, is it worth trying
> > to fix the git docs to deprecate this option?
> 
> As said in the other email; git has different standards than lkml. By
> now we're just one of many many users of git.

Even git developers will create a new thread for a large (more than
2-3 patches) patch set.  However, for a single patch, people have
chained the -v3 version of the draft --- not to the v2 version,
though, but to the review of the patch.  And I've seen that behavior
on some LKML lists, and I'm certainly fine with it on linux-ext4.

But if you have a huge patch series, and you keep chaining it unto the
8th, 10th, 22nd version, it certainly will get **very** annoying for
some MUA's.

The bottom line is that you should use common sense, and it can be
hard to document every last bit of what should be "common sense" into
a rule that is followed by robots or a perl script.  (Which is one of
the reasons why I'm not fond of the philosophy that every single last
checkpatch warning or error should result in a "cleanup" patch, but
that's another issue.)

Cheers,

- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 05/11] dt-binding: Add ngpios property to GPIO controller node

[Rob Herring]

On Fri, Oct 23, 2015 at 4:08 AM, Laurent Pinchart
 wrote:
> On Thursday 22 October 2015 18:41:05 Rob Herring wrote:
>> On Thu, Oct 22, 2015 at 1:52 PM, Ray Jui wrote:
>> > On 10/22/2015 11:43 AM, Rob Herring wrote:
>> >> On Mon, Oct 19, 2015 at 12:43 AM, Pramod Kumar wrote:
>> >>> Add ngpios property to the gpio controller's DT node so that controller
>> >>> driver extracts total number of gpio lines present in controller
>> >>> from DT and removes dependency on driver.
>> >>>
>> >>> Signed-off-by: Pramod Kumar 
>> >>> Reviewed-by: Ray Jui 
>> >>> Reviewed-by: Scott Branden 
>> >>> ---
>> >>>
>> >>>  Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt | 5 +++
>> >>>  1 file changed, 5 insertions(+)
>> >>>
>> >>> diff --git
>> >>> a/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt
>> >>> b/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt
>> >>> index f92b833..655a8d7 100644
>> >>> --- a/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt
>> >>> +++ b/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt
>> >>>
>> >>> @@ -10,6 +10,9 @@ Required properties:
>> >>>   Define the base and range of the I/O address space that contains
>> >>> the Cygnus
>> >>>   GPIO/PINCONF controller registers
>> >>>
>> >>> +- ngpios:
>> >>> +Total number of GPIOs the controller provides
>> >>
>> >> This must be optional for compatibility and the driver needs to handle
>> >> it not present.
>> >
>> > You meant to be compatible with existing Cygnus devices, correct?
>> >
>> > Just to clarify, here you suggest we still leave the existing hard coded
>> > ngpios in the driver, in order to be compatible with all existing Cygnus
>> > devices (while the Cygnus device tree changes to use ngpio is still being
>> > merged and through different maintainer), and have all new iProc SoCs
>> > switch to use ngpios from device tree, right?
>>
>> Yes, an existing dtb should continue to work with a new kernel. You
>> can add the DT property to the older devices too and then eventually
>> remove the hard coded values some time in the future. That could be
>> immediately (don't care about compatibility at all), a couple of
>> kernel cycles, never... It all depends on users of the impacted
>> platforms.
>
> But shouldn't the property still be documented as required to ensure that new
> DTs always include it ?

Good point. If the intent is to eventually remove it from the driver,
then yes. We probably need "required for new designs" as a category or
maybe "recommended"? The wording is not so important here, but I'm
thinking about as we try to standardize the naming.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/4] KVM: use simple waitqueue for vcpu->wq

[Daniel Wagner]

Hi Paul,

On 10/21/2015 01:13 PM, Peter Zijlstra wrote:
> On Wed, Oct 21, 2015 at 08:24:11PM +1100, Paul Mackerras wrote:
>> On Tue, Oct 20, 2015 at 04:00:31PM +0200, Peter Zijlstra wrote:
>>>
>>> Should we not take this opportunity to get rid of these open-coded wait
>>> loops?
>>>
>>>
>>> Does this work?
>>
>> No, on Book3S HV (POWER8) the VM hangs immediately after the kernel
>> brings up all the secondary vCPUs, and is then unkillable.  I'm not
>> sure what's wrong, although I wonder why you have TASK_IDLE rather
>> than TASK_INTERRUPTIBLE in the ___wait_event call.
> 
> This was under the assumption that INTERRUPTIBLE was because you wanted
> to avoid increasing load. Which was based on the lack of
> signal_pending() tests near there (although there might have been in the
> outermost loop which I overlooked).
> 
> If it does rely on signals, then this was obviously false and TASK_IDLE
> is indeed wrong.

If I get this right, the current patch is okay but you are going to
redactor the code? Maybe I can cherry pick your patch then and update
this patch accordingly.

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

Re: [PATCH v2 1/2] i2c: uniphier: add UniPhier FIFO-less I2C driver

[Wolfram Sang]

On Fri, Oct 23, 2015 at 07:51:59PM +0900, Masahiro Yamada wrote:
> Add support for on-chip I2C controller used on old UniPhier SoCs
> such as PH1-LD4, PH1-sLD8, etc.  This adapter is so simple that
> it has no FIFO in it.
> 
> Signed-off-by: Masahiro Yamada 

Applied to for-next, thanks!



signature.asc
Description: Digital signature

Re: [PATCH v2 2/2] i2c: uniphier_f: add UniPhier FIFO-builtin I2C driver

[Wolfram Sang]

On Fri, Oct 23, 2015 at 07:52:00PM +0900, Masahiro Yamada wrote:
> Add support for on-chip I2C controller used on newer UniPhier SoCs
> such as PH1-Pro4, PH1-Pro5, etc.  This adapter is equipped with
> 8-depth TX/RX FIFOs.
> 
> Signed-off-by: Masahiro Yamada 

Applied to for-next, thanks!



signature.asc
Description: Digital signature

[PATCH] of/fdt: fix error checking for earlycon address

[Masahiro Yamada]

fdt_translate_address() returns OF_BAD_ADDR on error.  It is defined as
a u64 value, so the variable "addr" should be defined as u64 as well.

Fixes: fb11ffe74c79 ("of/fdt: add FDT serial scanning for earlycon")
Signed-off-by: Masahiro Yamada 
---

 drivers/of/fdt.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 9fc3568..196e449 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -822,14 +822,15 @@ static int __init early_init_dt_scan_chosen_serial(void)
return -ENODEV;
 
while (match->compatible[0]) {
-   unsigned long addr;
+   u64 addr;
+
if (fdt_node_check_compatible(fdt, offset, match->compatible)) {
match++;
continue;
}
 
addr = fdt_translate_address(fdt, offset);
-   if (!addr)
+   if (addr == OF_BAD_ADDR)
return -ENXIO;
 
of_setup_earlycon(addr, match->data);
-- 
1.9.1

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

[GIT PULL] x86 fixes

[Ingo Molnar]

Linus,

Please pull the latest x86-urgent-for-linus git tree from:

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

   # HEAD: f7d27c35ddff7c100d7a98db499ac0040149ac05 x86/mm, kasan: Silence 
KASAN warnings in get_wchan()

Misc fixes: two KASAN fixes, two EFI boot fixes, two boot-delay optimization 
fixes, and a fix for a IRQ handling hang observed on virtual platforms.


  out-of-topic modifications in x86-urgent-for-linus:
  -
  include/linux/compiler.h   # d976441f44bc: compiler, atomics, kasan: 
Pr

 Thanks,

Ingo

-->
Andrey Ryabinin (3):
  x86, kasan: Fix build failure on KASAN=y && KMEMCHECK=y kernels
  compiler, atomics, kasan: Provide READ_ONCE_NOCHECK()
  x86/mm, kasan: Silence KASAN warnings in get_wchan()

Kővágó, Zoltán (1):
  x86/efi: Fix multiple GOP device support

Len Brown (2):
  x86/smpboot: Fix cpu_init_udelay=1 corner case boot parameter 
misbehavior
  x86/smpboot: Fix CPU #1 boot timeout

Paolo Bonzini (1):
  x86/setup: Extend low identity map to cover whole kernel range

Vitaly Kuznetsov (1):
  x86/ioapic: Disable interrupts when re-routing legacy IRQs


 arch/x86/boot/compressed/eboot.c |  8 +++--
 arch/x86/include/asm/string_64.h |  5 ++-
 arch/x86/kernel/apic/io_apic.c   |  4 +++
 arch/x86/kernel/process.c|  6 ++--
 arch/x86/kernel/setup.c  |  8 +
 arch/x86/kernel/smpboot.c| 15 ++---
 include/linux/compiler-gcc.h | 13 
 include/linux/compiler.h | 66 
 8 files changed, 100 insertions(+), 25 deletions(-)

diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index ee1b6d346b98..db51c1f27446 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -667,6 +667,7 @@ setup_gop32(struct screen_info *si, efi_guid_t *proto,
bool conout_found = false;
void *dummy = NULL;
u32 h = handles[i];
+   u32 current_fb_base;
 
status = efi_call_early(handle_protocol, h,
proto, (void **));
@@ -678,7 +679,7 @@ setup_gop32(struct screen_info *si, efi_guid_t *proto,
if (status == EFI_SUCCESS)
conout_found = true;
 
-   status = __gop_query32(gop32, , , _base);
+   status = __gop_query32(gop32, , , _fb_base);
if (status == EFI_SUCCESS && (!first_gop || conout_found)) {
/*
 * Systems that use the UEFI Console Splitter may
@@ -692,6 +693,7 @@ setup_gop32(struct screen_info *si, efi_guid_t *proto,
pixel_format = info->pixel_format;
pixel_info = info->pixel_information;
pixels_per_scan_line = info->pixels_per_scan_line;
+   fb_base = current_fb_base;
 
/*
 * Once we've found a GOP supporting ConOut,
@@ -770,6 +772,7 @@ setup_gop64(struct screen_info *si, efi_guid_t *proto,
bool conout_found = false;
void *dummy = NULL;
u64 h = handles[i];
+   u32 current_fb_base;
 
status = efi_call_early(handle_protocol, h,
proto, (void **));
@@ -781,7 +784,7 @@ setup_gop64(struct screen_info *si, efi_guid_t *proto,
if (status == EFI_SUCCESS)
conout_found = true;
 
-   status = __gop_query64(gop64, , , _base);
+   status = __gop_query64(gop64, , , _fb_base);
if (status == EFI_SUCCESS && (!first_gop || conout_found)) {
/*
 * Systems that use the UEFI Console Splitter may
@@ -795,6 +798,7 @@ setup_gop64(struct screen_info *si, efi_guid_t *proto,
pixel_format = info->pixel_format;
pixel_info = info->pixel_information;
pixels_per_scan_line = info->pixels_per_scan_line;
+   fb_base = current_fb_base;
 
/*
 * Once we've found a GOP supporting ConOut,
diff --git a/arch/x86/include/asm/string_64.h b/arch/x86/include/asm/string_64.h
index e4661196994e..ff8b9a17dc4b 100644
--- a/arch/x86/include/asm/string_64.h
+++ b/arch/x86/include/asm/string_64.h
@@ -27,12 +27,11 @@ static __always_inline void *__inline_memcpy(void *to, 
const void *from, size_t
function. */
 
 #define __HAVE_ARCH_MEMCPY 1
+extern void *memcpy(void *to, const void *from, size_t len);
 extern void *__memcpy(void *to, const void *from, size_t len);
 
 #ifndef CONFIG_KMEMCHECK
-#if (__GNUC__ == 4 && __GNUC_MINOR__ >= 3) || __GNUC__ > 4
-extern void *memcpy(void *to, const void *from, size_t len);
-#else
+#if 

Re: [PATCH V3] hp_sdc: convert struct timeval to ktime_t

[Arnd Bergmann]

On Friday 23 October 2015 19:29:39 WEN Pingbo wrote:
> 1. struct timeval is not y2038 safe, convert it to ktime_t, and there is no 
> need to handle sec and usec separately
> 
> 2. hp_sdc.rtv is only used for time diff, monotonic time is better here
> 
> Signed-off-by: WEN Pingbo 
> ---
> 
> Version 2:
> Using ktime_t instead of struct timespec64
> Version 3:
> Commit msg adjustment, and using ktime_to_ns to extract nsecs 
> 

The patch looks good now, but the changelog still needs a tiny bit of
work. First of all, your line wrapping is off, please start a new line
after around 70 characters as you do in an email.

Also, we don't normally have enumerated lists in a changelog, just use
normal text. The best changelogs typically have three paragraphs:

The first paragraph describes what the driver currently does. For really
obvious cases, this can be combined with the second paragraph.

The second paragraph explains why that is bad. This is where you can
mention the monotonic time vs real time issue and say whether we
just want the timeval removed to fix the kernel in general or whether
this particular driver is broken.

The third paragraph explains what the patch does to resolve the issue
described in the second one. This is also where you can list other
approaches that would have solved the problem, and why you picked on
over the others.

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

Make vmstat deferrable again (was Re: [PATCH] mm,vmscan: Use accurate values for zone_reclaimable() checks)

[Christoph Lameter]

On Fri, 23 Oct 2015, Michal Hocko wrote:

> On Thu 22-10-15 10:33:20, Christoph Lameter wrote:
> > Ok that also makes me rethink commit
> > ba4877b9ca51f80b5d30f304a46762f0509e1635 which seems to be a similar fix
> > this time related to idle mode not updating the counters.
> >
> > Could we fix that by folding the counters before going to idle mode?
>
> This would work as well.

Is this ok?


Subject: Fix vmstat: make vmstat_updater deferrable again and shut down on idle

Currently the vmstat updater is not deferrable as a result of commit
ba4877b9ca51f80b5d30f304a46762f0509e1635. This in turn can cause multiple
interruptions of the applications because the vmstat updater may run at
different times than tick processing. No good.

Make vmstate_update deferrable again and provide a function that
shuts down the vmstat updater when we go idle by folding the differentials.
Shut it down from the load average calculation logic introduced by nohz.

Note that the shepherd thread will continue scanning the differentials
from another processor and will reenable the vmstat workers if it
detects any changes.

Fixes: ba4877b9ca51f80b5d30f304a46762f0509e1635 (do not use deferrable delay)
Signed-off-by: Christoph Lameter 

Index: linux/mm/vmstat.c
===
--- linux.orig/mm/vmstat.c
+++ linux/mm/vmstat.c
@@ -1395,6 +1395,20 @@ static void vmstat_update(struct work_st
 }

 /*
+ * Switch off vmstat processing and then fold all the remaining differentials
+ * until the diffs stay at zero. The function is used by NOHZ and can only be
+ * invoked when tick processing is not active.
+ */
+void quiet_vmstat(void)
+{
+   do {
+   if (!cpumask_test_and_set_cpu(smp_processor_id(), cpu_stat_off))
+   cancel_delayed_work(this_cpu_ptr(_work));
+
+   } while (refresh_cpu_vm_stats());
+}
+
+/*
  * Check if the diffs for a certain cpu indicate that
  * an update is needed.
  */
@@ -1426,7 +1440,7 @@ static bool need_update(int cpu)
  */
 static void vmstat_shepherd(struct work_struct *w);

-static DECLARE_DELAYED_WORK(shepherd, vmstat_shepherd);
+static DECLARE_DEFERRABLE_WORK(shepherd, vmstat_shepherd);

 static void vmstat_shepherd(struct work_struct *w)
 {
Index: linux/include/linux/vmstat.h
===
--- linux.orig/include/linux/vmstat.h
+++ linux/include/linux/vmstat.h
@@ -211,6 +211,7 @@ extern void __inc_zone_state(struct zone
 extern void dec_zone_state(struct zone *, enum zone_stat_item);
 extern void __dec_zone_state(struct zone *, enum zone_stat_item);

+void quiet_vmstat(void);
 void cpu_vm_stats_fold(int cpu);
 void refresh_zone_stat_thresholds(void);

@@ -272,6 +273,7 @@ static inline void __dec_zone_page_state
 static inline void refresh_cpu_vm_stats(int cpu) { }
 static inline void refresh_zone_stat_thresholds(void) { }
 static inline void cpu_vm_stats_fold(int cpu) { }
+static inline void quiet_vmstat(void) { }

 static inline void drain_zonestat(struct zone *zone,
struct per_cpu_pageset *pset) { }
Index: linux/kernel/sched/loadavg.c
===
--- linux.orig/kernel/sched/loadavg.c
+++ linux/kernel/sched/loadavg.c
@@ -191,6 +191,8 @@ void calc_load_enter_idle(void)

atomic_long_add(delta, _load_idle[idx]);
}
+   /* Fold the current vmstat counters and disable vmstat updater */
+   quiet_vmstat();
 }

 void calc_load_exit_idle(void)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sched/deadline: fix typo

[Vincent Guittot]

Fix a typo in the code comment.

Signed-off-by: Vincent Guittot 
---
 kernel/sched/deadline.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index 142df26..0688a20 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -591,7 +591,7 @@ static enum hrtimer_restart dl_task_timer(struct hrtimer 
*timer)
 
/*
 * The task might have changed its scheduling policy to something
-* different than SCHED_DEADLINE (through switched_fromd_dl()).
+* different than SCHED_DEADLINE (through switched_from_dl()).
 */
if (!dl_task(p)) {
__dl_clear_params(p);
-- 
1.9.1

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

Re: [PATCH 2/2] Staging: lustre: lnet: lib-move return of an errno should typically be negative (ie: return -EAGAIN)

[Dilger, Andreas]

On 2015/10/22, 22:30, "Nilesh Kokane"  wrote:
>Fixed- Return of an errno should typically be negative (ie: return
>-EAGAIN)

Nak. Please do not change these function return values.  They are
converted as necessary by the callers before returning to userspace, but
allow the code to distinguish between errors generated internally or from
lower networking layers.

As you will note, many of them are explicitly annotated with comments that
they are returning positive values.  The patch as it stands would totally
break the code.

Cheers, Andreas

>Signed-off-by: Nilesh Kokane 
>---
> drivers/staging/lustre/lnet/lnet/lib-move.c | 22 +++---
> 1 file changed, 11 insertions(+), 11 deletions(-)
>
>diff --git a/drivers/staging/lustre/lnet/lnet/lib-move.c
>b/drivers/staging/lustre/lnet/lnet/lib-move.c
>index 433faae..10f886f 100644
>--- a/drivers/staging/lustre/lnet/lnet/lib-move.c
>+++ b/drivers/staging/lustre/lnet/lnet/lib-move.c
>@@ -808,7 +808,7 @@ lnet_post_send_locked(lnet_msg_t *msg, int do_send)
>   lnet_finalize(ni, msg, -EHOSTUNREACH);
> 
>   lnet_net_lock(cpt);
>-  return EHOSTUNREACH;
>+  return -EHOSTUNREACH;
>   }
> 
>   if (msg->msg_md != NULL &&
>@@ -821,7 +821,7 @@ lnet_post_send_locked(lnet_msg_t *msg, int do_send)
>   lnet_finalize(ni, msg, -ECANCELED);
> 
>   lnet_net_lock(cpt);
>-  return ECANCELED;
>+  return -ECANCELED;
>   }
> 
>   if (!msg->msg_peertxcredit) {
>@@ -838,7 +838,7 @@ lnet_post_send_locked(lnet_msg_t *msg, int do_send)
>   if (lp->lp_txcredits < 0) {
>   msg->msg_tx_delayed = 1;
>   list_add_tail(>msg_list, >lp_txq);
>-  return EAGAIN;
>+  return -EAGAIN;
>   }
>   }
> 
>@@ -855,7 +855,7 @@ lnet_post_send_locked(lnet_msg_t *msg, int do_send)
>   if (tq->tq_credits < 0) {
>   msg->msg_tx_delayed = 1;
>   list_add_tail(>msg_list, >tq_delayed);
>-  return EAGAIN;
>+  return -EAGAIN;
>   }
>   }
> 
>@@ -922,7 +922,7 @@ lnet_post_routed_recv_locked(lnet_msg_t *msg, int
>do_recv)
>   LASSERT(msg->msg_rx_ready_delay);
>   msg->msg_rx_delayed = 1;
>   list_add_tail(>msg_list, >lp_rtrq);
>-  return EAGAIN;
>+  return -EAGAIN;
>   }
>   }
> 
>@@ -942,7 +942,7 @@ lnet_post_routed_recv_locked(lnet_msg_t *msg, int
>do_recv)
>   LASSERT(msg->msg_rx_ready_delay);
>   msg->msg_rx_delayed = 1;
>   list_add_tail(>msg_list, >rbp_msgs);
>-  return EAGAIN;
>+  return -EAGAIN;
>   }
>   }
> 
>@@ -1426,7 +1426,7 @@ lnet_parse_put(lnet_ni_t *ni, lnet_msg_t *msg)
>   libcfs_id2str(info.mi_id), info.mi_portal,
>   info.mi_mbits, info.mi_roffset, info.mi_rlength, rc);
> 
>-  return ENOENT;  /* +ve: OK but no match */
>+  return -ENOENT; /* +ve: OK but no match */
>   }
> }
> 
>@@ -1457,7 +1457,7 @@ lnet_parse_get(lnet_ni_t *ni, lnet_msg_t *msg, int
>rdma_get)
>   CNETERR("Dropping GET from %s portal %d match %llu offset %d 
> length
>%d\n",
>   libcfs_id2str(info.mi_id), info.mi_portal,
>   info.mi_mbits, info.mi_roffset, info.mi_rlength);
>-  return ENOENT;  /* +ve: OK but no match */
>+  return -ENOENT; /* +ve: OK but no match */
>   }
> 
>   LASSERT(rc == LNET_MATCHMD_OK);
>@@ -1524,7 +1524,7 @@ lnet_parse_reply(lnet_ni_t *ni, lnet_msg_t *msg)
>  md->md_me->me_portal);
> 
>   lnet_res_unlock(cpt);
>-  return ENOENT;/* +ve: OK but no match */
>+  return -ENOENT;   /* +ve: OK but no match */
>   }
> 
>   LASSERT(md->md_offset == 0);
>@@ -1539,7 +1539,7 @@ lnet_parse_reply(lnet_ni_t *ni, lnet_msg_t *msg)
>   rlength, hdr->msg.reply.dst_wmd.wh_object_cookie,
>   mlength);
>   lnet_res_unlock(cpt);
>-  return ENOENT;/* +ve: OK but no match */
>+  return -ENOENT;   /* +ve: OK but no match */
>   }
> 
>   CDEBUG(D_NET, "%s: Reply from %s of length %d/%d into md %#llx\n",
>@@ -1592,7 +1592,7 @@ lnet_parse_ack(lnet_ni_t *ni, lnet_msg_t *msg)
>  md->md_me->me_portal);
> 
>   lnet_res_unlock(cpt);
>-  return ENOENT;/* +ve! */
>+  return -ENOENT;   /* +ve! */
>   }
> 
>   CDEBUG(D_NET, "%s: ACK from %s into md %#llx\n",
>-- 
>1.9.1
>
>


Cheers, Andreas
-- 
Andreas Dilger

Lustre Software Architect
Intel High 

[GIT PULL] scheduler fixes

[Ingo Molnar]

Linus,

Please pull the latest sched-urgent-for-linus git tree from:

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

   # HEAD: 0aaafaabfcba8aa991913cd3280a5dbf7f111a2a sched/core: Add missing 
lockdep_unpin() annotations

Misc fixes all around the map: an instrumentation fix, a nohz usability fix, a 
lockdep annotation fix and two task group scheduling fixes.

 Thanks,

Ingo

-->
Daniel Bristot de Oliveira (1):
  sched, tracing: Stop/start critical timings around the idle=poll idle loop

Frederic Weisbecker (1):
  nohz: Revert "nohz: Set isolcpus when nohz_full is set"

Luca Abeni (1):
  sched/deadline: Fix migration of SCHED_DEADLINE tasks

Peter Zijlstra (1):
  sched/core: Add missing lockdep_unpin() annotations

Yuyang Du (2):
  sched/fair: Fix overly small weight for interactive group entities
  sched/fair: Update task group's load_avg after task migration


 kernel/sched/core.c | 12 
 kernel/sched/deadline.c | 17 +
 kernel/sched/fair.c |  9 +
 kernel/sched/idle.c |  2 ++
 4 files changed, 28 insertions(+), 12 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 10a8faa1b0d4..bcd214e4b4d6 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2366,8 +2366,15 @@ void wake_up_new_task(struct task_struct *p)
trace_sched_wakeup_new(p);
check_preempt_curr(rq, p, WF_FORK);
 #ifdef CONFIG_SMP
-   if (p->sched_class->task_woken)
+   if (p->sched_class->task_woken) {
+   /*
+* Nothing relies on rq->lock after this, so its fine to
+* drop it.
+*/
+   lockdep_unpin_lock(>lock);
p->sched_class->task_woken(rq, p);
+   lockdep_pin_lock(>lock);
+   }
 #endif
task_rq_unlock(rq, p, );
 }
@@ -7238,9 +7245,6 @@ void __init sched_init_smp(void)
alloc_cpumask_var(_isolated_cpus, GFP_KERNEL);
alloc_cpumask_var(_doms, GFP_KERNEL);
 
-   /* nohz_full won't take effect without isolating the cpus. */
-   tick_nohz_full_add_cpus_to(cpu_isolated_map);
-
sched_init_numa();
 
/*
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index fc8f01083527..8b0a15e285f9 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -668,8 +668,15 @@ static enum hrtimer_restart dl_task_timer(struct hrtimer 
*timer)
 * Queueing this task back might have overloaded rq, check if we need
 * to kick someone away.
 */
-   if (has_pushable_dl_tasks(rq))
+   if (has_pushable_dl_tasks(rq)) {
+   /*
+* Nothing relies on rq->lock after this, so its safe to drop
+* rq->lock.
+*/
+   lockdep_unpin_lock(>lock);
push_dl_task(rq);
+   lockdep_pin_lock(>lock);
+   }
 #endif
 
 unlock:
@@ -1066,8 +1073,9 @@ select_task_rq_dl(struct task_struct *p, int cpu, int 
sd_flag, int flags)
int target = find_later_rq(p);
 
if (target != -1 &&
-   dl_time_before(p->dl.deadline,
-   cpu_rq(target)->dl.earliest_dl.curr))
+   (dl_time_before(p->dl.deadline,
+   cpu_rq(target)->dl.earliest_dl.curr) ||
+   (cpu_rq(target)->dl.dl_nr_running == 0)))
cpu = target;
}
rcu_read_unlock();
@@ -1417,7 +1425,8 @@ static struct rq *find_lock_later_rq(struct task_struct 
*task, struct rq *rq)
 
later_rq = cpu_rq(cpu);
 
-   if (!dl_time_before(task->dl.deadline,
+   if (later_rq->dl.dl_nr_running &&
+   !dl_time_before(task->dl.deadline,
later_rq->dl.earliest_dl.curr)) {
/*
 * Target rq has tasks of equal or earlier deadline,
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 6e2e3483b1ec..9a5e60fe721a 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2363,7 +2363,7 @@ static inline long calc_tg_weight(struct task_group *tg, 
struct cfs_rq *cfs_rq)
 */
tg_weight = atomic_long_read(>load_avg);
tg_weight -= cfs_rq->tg_load_avg_contrib;
-   tg_weight += cfs_rq_load_avg(cfs_rq);
+   tg_weight += cfs_rq->load.weight;
 
return tg_weight;
 }
@@ -2373,7 +2373,7 @@ static long calc_cfs_shares(struct cfs_rq *cfs_rq, struct 
task_group *tg)
long tg_weight, load, shares;
 
tg_weight = calc_tg_weight(tg, cfs_rq);
-   load = cfs_rq_load_avg(cfs_rq);
+   load = cfs_rq->load.weight;
 
shares = (tg->shares * load);
if (tg_weight)
@@ -2664,13 +2664,14 @@ static inline u64 cfs_rq_clock_task(struct cfs_rq 
*cfs_rq);
 /* Group cfs_rq's load_avg is used 

Re: [PATCH] soc: qcom: Introduce WCNSS_CTRL SMD client

[yfw]

Hi Bjorn,

On 2015/10/22 21:50, Bjorn Andersson wrote:

On Thu 22 Oct 03:25 PDT 2015, yfw wrote:


Hi Bjorn,

On 2015/9/22 1:52, Bjorn Andersson wrote:

[..]


I have a question: Do you have plan to add the nob to trigger wcnss firmware
downloading which is also common for wifi and BT?



In caf the wcnss driver is actually two drivers intermingled;
* a SMD client driver, responsible for pushing NV, something related to
   calibration, some power properties and so on

* a platform_driver implementing the wcnss specifics of the PIL through
   some hooks and providing the knob to trigger the PIL.

The first driver is related to the "OS" running on the wcnss, so that
should follow the life cycle of the SMD channel "WCNSS_CTRL". This is
what this patch provides - it loads the NV every time the wcnss core is
booted.


For the second part, I strongly believe that the PIL implementation
should deal with the specifics (e.g. regulator handling and
xo_calibration), rather than having a piece bolted on elsewhere - so
that's in the remoteproc-wcnss driver.


Yes. I meant this remoteproc-wcnss driver. Will you try to upstream it?



Left is a mechanism to trigger the thing to boot and shutdown. One
potential solution would be to have the module_init/exit call
rproc_boot/shutdown from the WiFi & BT drivers. That way if one loads
the wcn36xx driver, the core is booted. This would also fit quite nicely
for other things - e.g. load the ALSA driver to trigger the ADSP
loading.

The problem here is that we're then forced to either have a method of
deferring the rproc_boot() until the firmware is available or we always
must compile these drivers as kernel modules. This because the
file system isn't there during boot to provide the firmware.

The firmware file could be put to initrd. That should allow wcn wifi driver
builtin.



We do have the same thing in e.g. the Broadcom WiFi/BT solution and
there seems to be discussions related to this.


So for now, I punted and put a knob in the wcnss remoteproc driver.

Regards,
Bjorn



Regards
Yin, Fengwei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/8] mm: memcontrol: export root_mem_cgroup

[Michal Hocko]

On Thu 22-10-15 00:21:30, Johannes Weiner wrote:
> A later patch will need this symbol in files other than memcontrol.c,
> so export it now and replace mem_cgroup_root_css at the same time.
> 
> Signed-off-by: Johannes Weiner 

Acked-by: Michal Hocko 

> ---
>  include/linux/memcontrol.h | 3 ++-
>  mm/backing-dev.c   | 2 +-
>  mm/memcontrol.c| 5 ++---
>  3 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index 805da1f..19ff87b 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -275,7 +275,8 @@ struct mem_cgroup {
>   struct mem_cgroup_per_node *nodeinfo[0];
>   /* WARNING: nodeinfo must be the last member here */
>  };
> -extern struct cgroup_subsys_state *mem_cgroup_root_css;
> +
> +extern struct mem_cgroup *root_mem_cgroup;
>  
>  /**
>   * mem_cgroup_events - count memory events against a cgroup
> diff --git a/mm/backing-dev.c b/mm/backing-dev.c
> index 095b23b..73ab967 100644
> --- a/mm/backing-dev.c
> +++ b/mm/backing-dev.c
> @@ -702,7 +702,7 @@ static int cgwb_bdi_init(struct backing_dev_info *bdi)
>  
>   ret = wb_init(>wb, bdi, 1, GFP_KERNEL);
>   if (!ret) {
> - bdi->wb.memcg_css = mem_cgroup_root_css;
> + bdi->wb.memcg_css = _mem_cgroup->css;
>   bdi->wb.blkcg_css = blkcg_root_css;
>   }
>   return ret;
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index a8ccdbc..e54f434 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -76,9 +76,9 @@
>  struct cgroup_subsys memory_cgrp_subsys __read_mostly;
>  EXPORT_SYMBOL(memory_cgrp_subsys);
>  
> +struct mem_cgroup *root_mem_cgroup __read_mostly;
> +
>  #define MEM_CGROUP_RECLAIM_RETRIES   5
> -static struct mem_cgroup *root_mem_cgroup __read_mostly;
> -struct cgroup_subsys_state *mem_cgroup_root_css __read_mostly;
>  
>  /* Whether the swap controller is active */
>  #ifdef CONFIG_MEMCG_SWAP
> @@ -4213,7 +4213,6 @@ mem_cgroup_css_alloc(struct cgroup_subsys_state 
> *parent_css)
>   /* root ? */
>   if (parent_css == NULL) {
>   root_mem_cgroup = memcg;
> - mem_cgroup_root_css = >css;
>   page_counter_init(>memory, NULL);
>   memcg->high = PAGE_COUNTER_MAX;
>   memcg->soft_limit = PAGE_COUNTER_MAX;
> -- 
> 2.6.1

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

Re: [PATCH 1/8] mm: page_counter: let page_counter_try_charge() return bool

[Michal Hocko]

On Thu 22-10-15 00:21:29, Johannes Weiner wrote:
> page_counter_try_charge() currently returns 0 on success and -ENOMEM
> on failure, which is surprising behavior given the function name.
> 
> Make it follow the expected pattern of try_stuff() functions that
> return a boolean true to indicate success, or false for failure.
> 
> Signed-off-by: Johannes Weiner 

Acked-by: Michal Hocko 

> ---
>  include/linux/page_counter.h |  6 +++---
>  mm/hugetlb_cgroup.c  |  3 ++-
>  mm/memcontrol.c  | 11 +--
>  mm/page_counter.c| 14 +++---
>  4 files changed, 17 insertions(+), 17 deletions(-)
> 
> diff --git a/include/linux/page_counter.h b/include/linux/page_counter.h
> index 17fa4f8..7e62920 100644
> --- a/include/linux/page_counter.h
> +++ b/include/linux/page_counter.h
> @@ -36,9 +36,9 @@ static inline unsigned long page_counter_read(struct 
> page_counter *counter)
>  
>  void page_counter_cancel(struct page_counter *counter, unsigned long 
> nr_pages);
>  void page_counter_charge(struct page_counter *counter, unsigned long 
> nr_pages);
> -int page_counter_try_charge(struct page_counter *counter,
> - unsigned long nr_pages,
> - struct page_counter **fail);
> +bool page_counter_try_charge(struct page_counter *counter,
> +  unsigned long nr_pages,
> +  struct page_counter **fail);
>  void page_counter_uncharge(struct page_counter *counter, unsigned long 
> nr_pages);
>  int page_counter_limit(struct page_counter *counter, unsigned long limit);
>  int page_counter_memparse(const char *buf, const char *max,
> diff --git a/mm/hugetlb_cgroup.c b/mm/hugetlb_cgroup.c
> index 6a44263..d8fb10d 100644
> --- a/mm/hugetlb_cgroup.c
> +++ b/mm/hugetlb_cgroup.c
> @@ -186,7 +186,8 @@ again:
>   }
>   rcu_read_unlock();
>  
> - ret = page_counter_try_charge(_cg->hugepage[idx], nr_pages, );
> + if (!page_counter_try_charge(_cg->hugepage[idx], nr_pages, ))
> + ret = -ENOMEM;
>   css_put(_cg->css);
>  done:
>   *ptr = h_cg;
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index c71fe40..a8ccdbc 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -2018,8 +2018,8 @@ retry:
>   return 0;
>  
>   if (!do_swap_account ||
> - !page_counter_try_charge(>memsw, batch, )) {
> - if (!page_counter_try_charge(>memory, batch, ))
> + page_counter_try_charge(>memsw, batch, )) {
> + if (page_counter_try_charge(>memory, batch, ))
>   goto done_restock;
>   if (do_swap_account)
>   page_counter_uncharge(>memsw, batch);
> @@ -2383,14 +2383,13 @@ int __memcg_kmem_charge_memcg(struct page *page, 
> gfp_t gfp, int order,
>  {
>   unsigned int nr_pages = 1 << order;
>   struct page_counter *counter;
> - int ret = 0;
> + int ret;
>  
>   if (!memcg_kmem_is_active(memcg))
>   return 0;
>  
> - ret = page_counter_try_charge(>kmem, nr_pages, );
> - if (ret)
> - return ret;
> + if (!page_counter_try_charge(>kmem, nr_pages, ))
> + return -ENOMEM;
>  
>   ret = try_charge(memcg, gfp, nr_pages);
>   if (ret) {
> diff --git a/mm/page_counter.c b/mm/page_counter.c
> index 11b4bed..7c6a63d 100644
> --- a/mm/page_counter.c
> +++ b/mm/page_counter.c
> @@ -56,12 +56,12 @@ void page_counter_charge(struct page_counter *counter, 
> unsigned long nr_pages)
>   * @nr_pages: number of pages to charge
>   * @fail: points first counter to hit its limit, if any
>   *
> - * Returns 0 on success, or -ENOMEM and @fail if the counter or one of
> - * its ancestors has hit its configured limit.
> + * Returns %true on success, or %false and @fail if the counter or one
> + * of its ancestors has hit its configured limit.
>   */
> -int page_counter_try_charge(struct page_counter *counter,
> - unsigned long nr_pages,
> - struct page_counter **fail)
> +bool page_counter_try_charge(struct page_counter *counter,
> +  unsigned long nr_pages,
> +  struct page_counter **fail)
>  {
>   struct page_counter *c;
>  
> @@ -99,13 +99,13 @@ int page_counter_try_charge(struct page_counter *counter,
>   if (new > c->watermark)
>   c->watermark = new;
>   }
> - return 0;
> + return true;
>  
>  failed:
>   for (c = counter; c != *fail; c = c->parent)
>   page_counter_cancel(c, nr_pages);
>  
> - return -ENOMEM;
> + return false;
>  }
>  
>  /**
> -- 
> 2.6.1

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

[PATCH v7 04/17] drm: bridge: analogix/dp: remove duplicate configuration of link rate and link count

[Yakir Yang]

link_rate and lane_count already configured in analogix_dp_set_link_train(),
so we don't need to config those repeatly after training finished, just
remove them out.

Beside Display Port 1.2 already support 5.4Gbps link rate, the maximum sets
would change from {1.62Gbps, 2.7Gbps} to {1.62Gbps, 2.7Gbps, 5.4Gbps}.

Tested-by: Javier Martinez Canillas 
Signed-off-by: Yakir Yang 
---
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Update commit message more readable. (Jingoo)
- Adjust the order from 05 to 04

Changes in v3:
- The link_rate and lane_count shouldn't config to the DT property value
  directly, but we can take those as hardware limite. For example, RK3288
  only support 4 physical lanes of 2.7/1.62 Gbps/lane, so DT property would
  like "link-rate = 0x0a" "lane-count = 4". (Thierry)

Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 8 
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 5 +++--
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 334181c..96afb67 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -624,6 +624,8 @@ static void analogix_dp_get_max_rx_bandwidth(struct 
analogix_dp_device *dp,
/*
 * For DP rev.1.1, Maximum link rate of Main Link lanes
 * 0x06 = 1.62 Gbps, 0x0a = 2.7 Gbps
+* For DP rev.1.2, Maximum link rate of Main Link lanes
+* 0x06 = 1.62 Gbps, 0x0a = 2.7 Gbps, 0x14 = 5.4Gbps
 */
analogix_dp_read_byte_from_dpcd(dp, DP_MAX_LINK_RATE, );
*bandwidth = data;
@@ -657,7 +659,8 @@ static void analogix_dp_init_training(struct 
analogix_dp_device *dp,
analogix_dp_get_max_rx_lane_count(dp, >link_train.lane_count);
 
if ((dp->link_train.link_rate != LINK_RATE_1_62GBPS) &&
-   (dp->link_train.link_rate != LINK_RATE_2_70GBPS)) {
+   (dp->link_train.link_rate != LINK_RATE_2_70GBPS) &&
+   (dp->link_train.link_rate != LINK_RATE_5_40GBPS)) {
dev_err(dp->dev, "Rx Max Link Rate is abnormal :%x !\n",
dp->link_train.link_rate);
dp->link_train.link_rate = LINK_RATE_1_62GBPS;
@@ -898,9 +901,6 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
analogix_dp_enable_rx_to_enhanced_mode(dp, 1);
analogix_dp_enable_enhanced_mode(dp, 1);
 
-   analogix_dp_set_lane_count(dp, dp->video_info->lane_count);
-   analogix_dp_set_link_bandwidth(dp, dp->video_info->link_rate);
-
analogix_dp_init_video(dp);
ret = analogix_dp_config_video(dp);
if (ret)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index 14d20be..9a90a18 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -21,8 +21,9 @@
 #define MAX_EQ_LOOP 5
 
 enum link_rate_type {
-   LINK_RATE_1_62GBPS = 0x06,
-   LINK_RATE_2_70GBPS = 0x0a
+   LINK_RATE_1_62GBPS = DP_LINK_BW_1_62,
+   LINK_RATE_2_70GBPS = DP_LINK_BW_2_7,
+   LINK_RATE_5_40GBPS = DP_LINK_BW_5_4,
 };
 
 enum link_lane_count_type {
-- 
2.1.2


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

[PATCH v7 03/17] drm: bridge: analogix/dp: fix some obvious code style

[Yakir Yang]

Fix some obvious alignment problems, like alignment and line
over 80 characters problems, make this easy to be maintained
later.

Reviewed-by: Krzysztof Kozlowski 
Tested-by: Javier Martinez Canillas 
Signed-off-by: Yakir Yang 
---
Changes in v7: None
Changes in v6: None
Changes in v5:
- Resequence this patch after analogix_dp driver have been split
  from exynos_dp code, and rephrase reasonable commit message, and
  remove some controversial style (Krzysztof)
-   analogix_dp_write_byte_to_dpcd(
-   dp, DP_TEST_RESPONSE,
+   analogix_dp_write_byte_to_dpcd(dp,
+   DP_TEST_RESPONSE,
DP_TEST_EDID_CHECKSUM_WRITE);

Changes in v4: None
Changes in v3: None
Changes in v2:
- Improved commit message more readable, and avoid using some
  uncommon style like bellow: (Joe Preches)
-  retval = exynos_dp_read_bytes_from_i2c(...
  ...);
+  retval =
+  exynos_dp_read_bytes_from_i2c(..);

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 129 ++---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  72 ++--
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 124 ++--
 3 files changed, 163 insertions(+), 162 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index e561590..334181c 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -61,7 +61,7 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device 
*dp)
 
while (analogix_dp_get_plug_in_status(dp) != 0) {
timeout_loop++;
-   if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) {
+   if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
dev_err(dp->dev, "failed to get hpd plug status\n");
return -ETIMEDOUT;
}
@@ -98,8 +98,8 @@ static int analogix_dp_read_edid(struct analogix_dp_device 
*dp)
 
/* Read Extension Flag, Number of 128-byte EDID extension blocks */
retval = analogix_dp_read_byte_from_i2c(dp, I2C_EDID_DEVICE_ADDR,
-   EDID_EXTENSION_FLAG,
-   _block);
+   EDID_EXTENSION_FLAG,
+   _block);
if (retval)
return retval;
 
@@ -107,7 +107,8 @@ static int analogix_dp_read_edid(struct analogix_dp_device 
*dp)
dev_dbg(dp->dev, "EDID data includes a single extension!\n");
 
/* Read EDID data */
-   retval = analogix_dp_read_bytes_from_i2c(dp, 
I2C_EDID_DEVICE_ADDR,
+   retval = analogix_dp_read_bytes_from_i2c(dp,
+   I2C_EDID_DEVICE_ADDR,
EDID_HEADER_PATTERN,
EDID_BLOCK_LENGTH,
[EDID_HEADER_PATTERN]);
@@ -138,7 +139,7 @@ static int analogix_dp_read_edid(struct analogix_dp_device 
*dp)
}
 
analogix_dp_read_byte_from_dpcd(dp, DP_TEST_REQUEST,
-   _vector);
+   _vector);
if (test_vector & DP_TEST_LINK_EDID_READ) {
analogix_dp_write_byte_to_dpcd(dp,
DP_TEST_EDID_CHECKSUM,
@@ -152,10 +153,8 @@ static int analogix_dp_read_edid(struct analogix_dp_device 
*dp)
 
/* Read EDID data */
retval = analogix_dp_read_bytes_from_i2c(dp,
-   I2C_EDID_DEVICE_ADDR,
-   EDID_HEADER_PATTERN,
-   EDID_BLOCK_LENGTH,
-   [EDID_HEADER_PATTERN]);
+   I2C_EDID_DEVICE_ADDR, EDID_HEADER_PATTERN,
+   EDID_BLOCK_LENGTH, [EDID_HEADER_PATTERN]);
if (retval != 0) {
dev_err(dp->dev, "EDID Read failed!\n");
return -EIO;
@@ -166,16 +165,13 @@ static int analogix_dp_read_edid(struct 
analogix_dp_device *dp)
return -EIO;
}
 
-   analogix_dp_read_byte_from_dpcd(dp,
-   DP_TEST_REQUEST,
-   _vector);
+   analogix_dp_read_byte_from_dpcd(dp, DP_TEST_REQUEST,
+   _vector);
if (test_vector & DP_TEST_LINK_EDID_READ) {
analogix_dp_write_byte_to_dpcd(dp,
-   DP_TEST_EDID_CHECKSUM,
-   edid[EDID_CHECKSUM]);
+   DP_TEST_EDID_CHECKSUM, 

[PATCH v7 05/17] drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & dynamic_range

[Yakir Yang]

Both hsync/vsync polarity and interlace mode can be parsed from
drm display mode, and dynamic_range and ycbcr_coeff can be judge
by the video code.

But presumably Exynos still relies on the DT properties, so take
good use of mode_fixup() in to achieve the compatibility hacks.

Reviewed-by: Krzysztof Kozlowski 
Tested-by: Javier Martinez Canillas 
Signed-off-by: Yakir Yang 
---
Changes in v7:
- Back to use the of_property_read_bool() interfacs to provoid backward
  compatibility of "hsync-active-high" "vsync-active-high" "interlaced"
  to avoid -EOVERFLOW error (Krzysztof)

Changes in v6: None
Changes in v5:
- Switch video timing type to "u32", so driver could use "of_property_read_u32"
  to get the backword timing values. Krzysztof suggest me that driver could use
  the "of_property_read_bool" to get backword timing values, but that interfacs
  would modify the original drm_display_mode timing directly (whether those
  properties exists or not).

Changes in v4:
- Provide backword compatibility with samsung. (Krzysztof)

Changes in v3:
- Dynamic parse video timing info from struct drm_display_mode and
  struct drm_display_info. (Thierry)

Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 148 +
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |   2 +-
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  |  14 +-
 3 files changed, 103 insertions(+), 61 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 96afb67..6307060 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -890,8 +890,8 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
return;
}
 
-   ret = analogix_dp_set_link_train(dp, dp->video_info->lane_count,
-dp->video_info->link_rate);
+   ret = analogix_dp_set_link_train(dp, dp->video_info.lane_count,
+dp->video_info.link_rate);
if (ret) {
dev_err(dp->dev, "unable to do link train\n");
return;
@@ -1030,6 +1030,85 @@ static void analogix_dp_bridge_disable(struct drm_bridge 
*bridge)
dp->dpms_mode = DRM_MODE_DPMS_OFF;
 }
 
+static void analogix_dp_bridge_mode_set(struct drm_bridge *bridge,
+   struct drm_display_mode *orig_mode,
+   struct drm_display_mode *mode)
+{
+   struct analogix_dp_device *dp = bridge->driver_private;
+   struct drm_display_info *display_info = >connector->display_info;
+   struct video_info *video = >video_info;
+   struct device_node *dp_node = dp->dev->of_node;
+   int vic;
+
+   /* Input video interlaces & hsync pol & vsync pol */
+   video->interlaced = !!(mode->flags & DRM_MODE_FLAG_INTERLACE);
+   video->v_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NVSYNC);
+   video->h_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NHSYNC);
+
+   /* Input video dynamic_range & colorimetry */
+   vic = drm_match_cea_mode(mode);
+   if ((vic == 6) || (vic == 7) || (vic == 21) || (vic == 22) ||
+   (vic == 2) || (vic == 3) || (vic == 17) || (vic == 18)) {
+   video->dynamic_range = CEA;
+   video->ycbcr_coeff = COLOR_YCBCR601;
+   } else if (vic) {
+   video->dynamic_range = CEA;
+   video->ycbcr_coeff = COLOR_YCBCR709;
+   } else {
+   video->dynamic_range = VESA;
+   video->ycbcr_coeff = COLOR_YCBCR709;
+   }
+
+   /* Input vide bpc and color_formats */
+   switch (display_info->bpc) {
+   case 12:
+   video->color_depth = COLOR_12;
+   break;
+   case 10:
+   video->color_depth = COLOR_10;
+   break;
+   case 8:
+   video->color_depth = COLOR_8;
+   break;
+   case 6:
+   video->color_depth = COLOR_6;
+   break;
+   default:
+   video->color_depth = COLOR_8;
+   break;
+   }
+   if (display_info->color_formats & DRM_COLOR_FORMAT_YCRCB444)
+   video->color_space = COLOR_YCBCR444;
+   else if (display_info->color_formats & DRM_COLOR_FORMAT_YCRCB422)
+   video->color_space = COLOR_YCBCR422;
+   else if (display_info->color_formats & DRM_COLOR_FORMAT_RGB444)
+   video->color_space = COLOR_RGB;
+   else
+   video->color_space = COLOR_RGB;
+
+   /*
+* NOTE: those property parsing code is used for providing backward
+* compatibility for samsung platform.
+* Due to we used the "of_property_read_u32" interfaces, when this
+* property isn't present, the "video_info" can keep the original
+* values and wouldn't be modified.
+*/
+   

[PATCH v7 01/17] drm: exynos: dp: convert to drm bridge mode

[Yakir Yang]

In order to move exynos dp code to bridge directory,
we need to convert driver drm bridge mode first. As
dp driver already have a ptn3460 bridge, so we need
to move ptn bridge to the next bridge of dp bridge.

Tested-by: Javier Martinez Canillas 
Signed-off-by: Yakir Yang 
---
Changes in v7: None
Changes in v6:
- Fix the wrong code in previous series, and test on Samsung snow Chromebook
  successfully, here are the detail changes:
=>
-   if (!dp->panel && !dp->bridge) {
+   if (!dp->panel && !dp->ptn_bridge) {
ret = exynos_dp_dt_parse_panel(dp);
if (ret)
=>
+   encoder->bridge = bridge;
bridge->driver_private = dp;
bridge->encoder = encoder;
bridge->funcs = _dp_bridge_funcs;
ret = drm_bridge_attach(drm_dev, bridge);

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
- Keep author name list no changed (Jingoo)

 drivers/gpu/drm/exynos/exynos_dp_core.c | 103 
 drivers/gpu/drm/exynos/exynos_dp_core.h |   1 +
 2 files changed, 78 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 124fb9a..aedd074 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1009,9 +1009,9 @@ static int exynos_drm_attach_lcd_bridge(struct 
exynos_dp_device *dp,
 {
int ret;
 
-   encoder->bridge = dp->bridge;
-   dp->bridge->encoder = encoder;
-   ret = drm_bridge_attach(encoder->dev, dp->bridge);
+   encoder->bridge->next = dp->ptn_bridge;
+   dp->ptn_bridge->encoder = encoder;
+   ret = drm_bridge_attach(encoder->dev, dp->ptn_bridge);
if (ret) {
DRM_ERROR("Failed to attach bridge to drm\n");
return ret;
@@ -1020,14 +1020,15 @@ static int exynos_drm_attach_lcd_bridge(struct 
exynos_dp_device *dp,
return 0;
 }
 
-static int exynos_dp_create_connector(struct drm_encoder *encoder)
+static int exynos_dp_bridge_attach(struct drm_bridge *bridge)
 {
-   struct exynos_dp_device *dp = encoder_to_dp(encoder);
+   struct exynos_dp_device *dp = bridge->driver_private;
+   struct drm_encoder *encoder = >encoder;
struct drm_connector *connector = >connector;
int ret;
 
/* Pre-empt DP connector creation if there's a bridge */
-   if (dp->bridge) {
+   if (dp->ptn_bridge) {
ret = exynos_drm_attach_lcd_bridge(dp, encoder);
if (!ret)
return 0;
@@ -1052,22 +1053,9 @@ static int exynos_dp_create_connector(struct drm_encoder 
*encoder)
return ret;
 }
 
-static bool exynos_dp_mode_fixup(struct drm_encoder *encoder,
-const struct drm_display_mode *mode,
-struct drm_display_mode *adjusted_mode)
-{
-   return true;
-}
-
-static void exynos_dp_mode_set(struct drm_encoder *encoder,
-  struct drm_display_mode *mode,
-  struct drm_display_mode *adjusted_mode)
-{
-}
-
-static void exynos_dp_enable(struct drm_encoder *encoder)
+static void exynos_dp_bridge_enable(struct drm_bridge *bridge)
 {
-   struct exynos_dp_device *dp = encoder_to_dp(encoder);
+   struct exynos_dp_device *dp = bridge->driver_private;
struct exynos_drm_crtc *crtc = dp_to_crtc(dp);
 
if (dp->dpms_mode == DRM_MODE_DPMS_ON)
@@ -1092,9 +1080,9 @@ static void exynos_dp_enable(struct drm_encoder *encoder)
dp->dpms_mode = DRM_MODE_DPMS_ON;
 }
 
-static void exynos_dp_disable(struct drm_encoder *encoder)
+static void exynos_dp_bridge_disable(struct drm_bridge *bridge)
 {
-   struct exynos_dp_device *dp = encoder_to_dp(encoder);
+   struct exynos_dp_device *dp = bridge->driver_private;
struct exynos_drm_crtc *crtc = dp_to_crtc(dp);
 
if (dp->dpms_mode != DRM_MODE_DPMS_ON)
@@ -1123,6 +,69 @@ static void exynos_dp_disable(struct drm_encoder 
*encoder)
dp->dpms_mode = DRM_MODE_DPMS_OFF;
 }
 
+static void exynos_dp_bridge_nop(struct drm_bridge *bridge)
+{
+   /* do nothing */
+}
+
+static const struct drm_bridge_funcs exynos_dp_bridge_funcs = {
+   .enable = exynos_dp_bridge_enable,
+   .disable = exynos_dp_bridge_disable,
+   .pre_enable = exynos_dp_bridge_nop,
+   .post_disable = exynos_dp_bridge_nop,
+   .attach = exynos_dp_bridge_attach,
+};
+
+static int exynos_dp_create_connector(struct drm_encoder *encoder)
+{
+   struct exynos_dp_device *dp = encoder_to_dp(encoder);
+   struct drm_device *drm_dev = dp->drm_dev;
+   struct drm_bridge *bridge;
+   int ret;
+
+   bridge = devm_kzalloc(drm_dev->dev, sizeof(*bridge), GFP_KERNEL);
+   if (!bridge) {
+   DRM_ERROR("failed to allocate for drm bridge\n");
+   return -ENOMEM;
+   }
+
+   dp->bridge = bridge;
+
+   

[PATCH V3] hp_sdc: convert struct timeval to ktime_t

[WEN Pingbo]

1. struct timeval is not y2038 safe, convert it to ktime_t, and there is no 
need to handle sec and usec separately

2. hp_sdc.rtv is only used for time diff, monotonic time is better here

Signed-off-by: WEN Pingbo 
---

Version 2:
Using ktime_t instead of struct timespec64
Version 3:
Commit msg adjustment, and using ktime_to_ns to extract nsecs 

 drivers/input/serio/hp_sdc.c | 16 ++--
 include/linux/hp_sdc.h   |  6 +++---
 2 files changed, 9 insertions(+), 13 deletions(-)

diff --git a/drivers/input/serio/hp_sdc.c b/drivers/input/serio/hp_sdc.c
index 852858e..17e3725 100644
--- a/drivers/input/serio/hp_sdc.c
+++ b/drivers/input/serio/hp_sdc.c
@@ -193,7 +193,7 @@ static void hp_sdc_take(int irq, void *dev_id, uint8_t 
status, uint8_t data)
curr->seq[curr->idx++] = status;
curr->seq[curr->idx++] = data;
hp_sdc.rqty -= 2;
-   do_gettimeofday(_sdc.rtv);
+   hp_sdc.rtv = ktime_get();
 
if (hp_sdc.rqty <= 0) {
/* All data has been gathered. */
@@ -306,13 +306,9 @@ static void hp_sdc_tasklet(unsigned long foo)
write_lock_irq(_sdc.rtq_lock);
 
if (hp_sdc.rcurr >= 0) {
-   struct timeval tv;
+   ktime_t time_diff = ktime_sub(ktime_get(), hp_sdc.rtv);
 
-   do_gettimeofday();
-   if (tv.tv_sec > hp_sdc.rtv.tv_sec)
-   tv.tv_usec += USEC_PER_SEC;
-
-   if (tv.tv_usec - hp_sdc.rtv.tv_usec > HP_SDC_MAX_REG_DELAY) {
+   if (ktime_to_ns(time_diff) > HP_SDC_MAX_REG_DELAY) {
hp_sdc_transaction *curr;
uint8_t tmp;
 
@@ -321,8 +317,8 @@ static void hp_sdc_tasklet(unsigned long foo)
 * we'll need to figure out a way to communicate
 * it back to the application. and be less verbose.
 */
-   printk(KERN_WARNING PREFIX "read timeout (%ius)!\n",
-  (int)(tv.tv_usec - hp_sdc.rtv.tv_usec));
+   printk(KERN_WARNING PREFIX "read timeout (%llins)!\n",
+  ktime_to_ns(time_diff));
curr->idx += hp_sdc.rqty;
hp_sdc.rqty = 0;
tmp = curr->seq[curr->actidx];
@@ -551,7 +547,7 @@ unsigned long hp_sdc_put(void)
 
/* Start a new read */
hp_sdc.rqty = curr->seq[curr->idx];
-   do_gettimeofday(_sdc.rtv);
+   hp_sdc.rtv = ktime_get();
curr->idx++;
/* Still need to lock here in case of spurious irq. */
write_lock_irq(_sdc.rtq_lock);
diff --git a/include/linux/hp_sdc.h b/include/linux/hp_sdc.h
index d392975..348a9b5 100644
--- a/include/linux/hp_sdc.h
+++ b/include/linux/hp_sdc.h
@@ -47,9 +47,9 @@
 #endif
 
 
-/* No 4X status reads take longer than this (in usec).
+/* No 4X status reads take longer than this (in nsec).
  */
-#define HP_SDC_MAX_REG_DELAY 2
+#define HP_SDC_MAX_REG_DELAY 2000
 
 typedef void (hp_sdc_irqhook) (int irq, void *dev_id, 
   uint8_t status, uint8_t data);
@@ -281,7 +281,7 @@ typedef struct {
hp_sdc_transaction *tq[HP_SDC_QUEUE_LEN]; /* All pending read/writes */
 
int rcurr, rqty;/* Current read transact in process */
-   struct timeval  rtv;/* Time when current read started */
+   ktime_t rtv;/* Time when current read started */
int wcurr;  /* Current write transact in process */
 
int dev_err;/* carries status from registration */
-- 
1.9.1

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

[PATCH v4 2/3] thermal: rockchip: support the sleep pinctrl state to avoid glitches in s2r

[Caesar Wang]

When we come out of system suspend state (S3) the tsadc will have been
reset and back at its default state.  While reprogramming the tsadc
it's possible that we'll glitch the output and unintentionally cause
the "over temperature" GPIO to be asserted.  Since the over
temperature GPIO is often hooked up to something that will cause a
reboot or shutdown in hardware, this glitch can be catastrophic on
some boards.

We'll add support for selecting the "sleep" pinctrl state at suspend
time.  Boards can use this to effectively disable the tsadc at suspend
time and avoid glitches when the system is resumed.

Signed-off-by: Caesar Wang 

---

Changes in v4:
  - take the Doug's commit as correct decription.

Changes in v3:
  - Add the pinctrl state for in the suspend/resume.

Changes in v2: None
Changes in v1: None

 drivers/thermal/rockchip_thermal.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/thermal/rockchip_thermal.c 
b/drivers/thermal/rockchip_thermal.c
index c89ffb2..3b8fbda 100644
--- a/drivers/thermal/rockchip_thermal.c
+++ b/drivers/thermal/rockchip_thermal.c
@@ -642,6 +642,8 @@ static int __maybe_unused rockchip_thermal_suspend(struct 
device *dev)
clk_disable(thermal->pclk);
clk_disable(thermal->clk);
 
+   pinctrl_pm_select_sleep_state(dev);
+
return 0;
 }
 
@@ -678,6 +680,8 @@ static int __maybe_unused rockchip_thermal_resume(struct 
device *dev)
for (i = 0; i < ARRAY_SIZE(thermal->sensors); i++)
rockchip_thermal_toggle_sensor(>sensors[i], true);
 
+   pinctrl_pm_select_default_state(dev);
+
return 0;
 }
 
-- 
1.9.1

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

[PATCH v4 0/3] fix the TSHUT issue on rockchip thermal

[Caesar Wang]

Thank you all for providing inputs and comments on previous versions of
this patchset.
Especially thanks to the (Doug, Rob).

We need the OTP pin is gpio state before resetting the TSADC controller,
since the tshut polarity will generate a high signal.

Says:
The TSHUT temperature is setting more than 80 degree, the default
tshut polarity is HIGH.

If T > 80C, the OTP output the High Signal.
If T < 80C, the OTP output the Low Signal.

On the moment, the TSADC controller is reset, the tshut polarity will be
Low in a short period of time.

So:
If T < 80C, the OTP output the High Signal.
If T > 80C, the OTP output the Low Signal.

In some cases, the OTP pin is connected to the PMIC, maybe the PMIC can
accept the reset response time to avoid this issue.

In other words, the system will be always reboot if we make the OTP pin
is connected the others IC to control the power.

This series patchs are depend on Doug's 
patch.(https://patchwork.kernel.org/patch/7454311/)

This series patchs are based on the Linus master branch.

518cd44 ARM: dts: rockchip: Add the OTP gpio pinctrl
83e0bab dt-bindings: Add the "init" pinctrl in this document
150426c drivers/pinctrl: Add the concept of an "init" state
ce1fad2 Merge branch 'keys-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs
1099f86 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
911b79c KEYS: Don't permit request_key() to construct a new keyring
37850e3 net: bcmgenet: Fix early link interrupt enabling
afc050d Merge tag 'wireless-drivers-for-davem-2015-10-17' of 
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers
e277de5 tunnels: Don't require remote endpoint or ID during creation.
740dbc2 openvswitch: Scrub skb between namespaces


Tested on box board.


Changes in v4:
  - take the Doug's commit as correct decription.

Changes in v3:
  - Add the pictrl states decription in document.
  - Add the pinctrl state for in the suspend/resume.
  - Add the "sleep" pinctrl as the gpio state in PATCH[3/3]

Changes in v2:
  - Add the 'init' pinctrl more decription in commit.
  - Fix the subject to make more obvious in PATCH[1/2]
  - Resend this patch v2 since fix the subject to be specific.
  - Add some commits for more obvious in PATCH[2/2]

Changes in v1:
  - As the Doug comments, add the 'init' property to sync document.
  - As the Doug comments, drop the thermal driver patchs since
we can with pinctrl changing to work.
  - As the Doug's patch to add the 'init' property.

Caesar Wang (3):
  dt-bindings: rockchip-thermal: Add the pinctrl states in this document
  thermal: rockchip: support the sleep pinctrl state to avoid glitches
in s2r
  ARM: dts: rockchip: Add the OTP gpio pinctrl

 .../devicetree/bindings/thermal/rockchip-thermal.txt  | 11 +--
 arch/arm/boot/dts/rk3288.dtsi | 10 --
 drivers/thermal/rockchip_thermal.c|  4 
 3 files changed, 21 insertions(+), 4 deletions(-)

-- 
1.9.1

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

[PATCH v4 1/3] dt-bindings: rockchip-thermal: Add the pinctrl states in this document

[Caesar Wang]

The "init" pinctrl is defined we'll set
pinctrl to this state before probe and then "default" after probe.
Add the "init" and "sleep" pinctrl as the OTP gpio state, since we need
switch the pin to gpio state before the TSADC controller is reset.

AFAIK, the TSADC controller is reset, the tshut polarity will be
a *low* signal in a short period of time for some devices.

Says:
The TSADC get the temperature on rockchip thermal.

If T(current temperature) < (setting temperature), the OTP output the
*high* signal.
If T(current temperature) > (setting temperature), the OTP output the
*low* Signal.

In some cases, the OTP pin is connected to the PMIC, maybe the
PMIC can accept the reset response time to avoid this issue.

In other words, the system will be always reboot if we make the
OTP pin is connected the others IC to control the power.

Signed-off-by: Caesar Wang 
Reviewed-by: Douglas Anderson 
---

Changes in v4: None
Changes in v3:
  - Add the pictrl states decription in document.

Changes in v2:
  - Add the 'init' pinctrl more decription in commit.
  - Fix the subject to make more obvious in PATCH[1/2]
  - Resend this patch v2 since fix the subject to be specific.

Changes in v1:
  - As the Doug comments, add the 'init' property to sync document.

 .../devicetree/bindings/thermal/rockchip-thermal.txt  | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt 
b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
index ef802de..b38200d 100644
--- a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
@@ -12,6 +12,11 @@ Required properties:
 - resets : Must contain an entry for each entry in reset-names.
   See ../reset/reset.txt for details.
 - reset-names : Must include the name "tsadc-apb".
+- pinctrl-names : The pin control state names;
+- pinctrl-0 : The "init" pinctrl state, it will be set before device probe.
+- pinctrl-1 : The "default" pinctrl state, it will be set after reset the
+ TSADC controller.
+- pinctrl-2 : The "sleep" pinctrl state, it will be in for suspend.
 - #thermal-sensor-cells : Should be 1. See ./thermal.txt for a description.
 - rockchip,hw-tshut-temp : The hardware-controlled shutdown temperature value.
 - rockchip,hw-tshut-mode : The hardware-controlled shutdown mode 0:CRU 1:GPIO.
@@ -27,8 +32,10 @@ tsadc: tsadc@ff28 {
clock-names = "tsadc", "apb_pclk";
resets = < SRST_TSADC>;
reset-names = "tsadc-apb";
-   pinctrl-names = "default";
-   pinctrl-0 = <_out>;
+   pinctrl-names = "init", "default", "sleep";
+   pinctrl-0 = <_gpio>;
+   pinctrl-1 = <_out>;
+   pinctrl-2 = <_gpio>;
#thermal-sensor-cells = <1>;
rockchip,hw-tshut-temp = <95000>;
rockchip,hw-tshut-mode = <0>;
-- 
1.9.1

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

[PATCH v4 3/3] ARM: dts: rockchip: Add the OTP gpio pinctrl

[Caesar Wang]

Add the "init" anf "sleep" pinctrl as the OTP gpio state.
We need the OTP pin is gpio state before resetting the TSADC controller,
since the tshut polarity will generate a high signal.

"init" pinctrl property is defined by Doug's Patch[0].

Patch[0]:
https://patchwork.kernel.org/patch/7454311/

Signed-off-by: Caesar Wang 
Reviewed-by: Douglas Anderson 
---

Changes in v4: None
Changes in v3:
  - Add the "sleep" pinctrl as the gpio state in PATCH[3/3]

Changes in v2:
  - Add some commits for more obvious in PATCH[2/2]

Changes in v1:
  - As the Doug comments, drop the thermal driver patchs since
we can with pinctrl changing to work.
  - As the Doug's patch to add the 'init' property.

 arch/arm/boot/dts/rk3288.dtsi | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 906e938..13ff09a 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -447,8 +447,10 @@
clock-names = "tsadc", "apb_pclk";
resets = < SRST_TSADC>;
reset-names = "tsadc-apb";
-   pinctrl-names = "default";
-   pinctrl-0 = <_out>;
+   pinctrl-names = "init", "default", "sleep";
+   pinctrl-0 = <_gpio>;
+   pinctrl-1 = <_out>;
+   pinctrl-2 = <_gpio>;
#thermal-sensor-cells = <1>;
rockchip,hw-tshut-temp = <95000>;
status = "disabled";
@@ -1273,6 +1275,10 @@
};
 
tsadc {
+   otp_gpio: otp-gpio {
+   rockchip,pins = <0 10 RK_FUNC_GPIO 
_pull_none>;
+   };
+
otp_out: otp-out {
rockchip,pins = <0 10 RK_FUNC_1 
_pull_none>;
};
-- 
1.9.1

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

[PATCH v7 0/17] Add Analogix Core Display Port Driver

[Yakir Yang]

Hi all,

   The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
share the same IP, so a lot of parts can be re-used. I split the common
code into bridge directory, then rk3288 and exynos only need to keep
some platform code. Cause I can't find the exact IP name of exynos dp
controller, so I decide to name dp core driver with "analogix" which I
find in rk3288 eDP TRM :)

But  there are still three light registers setting differents bewteen
exynos and rk3288.
1. RK3288 have five special pll resigters which not indicata in exynos
   dp controller.
2. The address of DP_PHY_PD(dp phy power manager register) are different
   between rk3288 and exynos.
3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug
   register).

This series have been well tested on Rockchip platform with eDP panel on
Jerry Chromebook and Display Port Monitor on RK3288 board. Also I have
tested on Samsung Snow and Peach Pit Chromebooks, and thanks to Javier@Samsung
help to retest the whole series on Samsung Exynos5800 Peach Pi Chromebook,
glad to say that things works rightlly.

This series have been keep very quite about one month from v5 to v7 (thanks
to Krzysztof's reviewed and Javier's test and some comment Kishon during this
time), is there any chances to share some ackes from Exynos DRM maintainers
and Bridge maintainers?

Best regards,
- Yakir

Changes in v7:
- Back to use the of_property_read_bool() interfacs to provoid backward
  compatibility of "hsync-active-high" "vsync-active-high" "interlaced"
  to avoid -EOVERFLOW error (Krzysztof)

Changes in v6:
- Fix the wrong code in previous series, and test on Samsung snow Chromebook
  successfully, here are the detail changes:
=>
-   if (!dp->panel && !dp->bridge) {
+   if (!dp->panel && !dp->ptn_bridge) {
ret = exynos_dp_dt_parse_panel(dp);
if (ret)
=>
+   encoder->bridge = bridge;
bridge->driver_private = dp;
bridge->encoder = encoder;
bridge->funcs = _dp_bridge_funcs;
ret = drm_bridge_attach(drm_dev, bridge);
- Fix the Kconfig recursive dependency (Javier)
- Fix Peach Pit hpd property name error:
-   hpd-gpio = < 6 0>;
+   hpd-gpios = < 6 0>;
- Simply the commit message. (Kishon)
- Symmetrical enable/disbale the phy clock and power. (Kishon)

Changes in v5:
- Correct the check condition of gpio_is_valid when driver try to get
  the "hpd-gpios" DT propery. (Heiko)
- Move the platform attach callback in the front of core driver bridge
  attch function. Cause once platform failed at attach, core driver should
  still failed, so no need to init connector before platform attached 
(Krzysztof)
- Keep code style no changes with the previous exynos_dp_code.c in this
  patch, and update commit message about the new export symbol (Krzysztof)
- Gather the device type patch (v4 11/16) into this one. (Krzysztof)
- leave out the connector registration to analogix platform driver. (Thierry)
- Resequence this patch after analogix_dp driver have been split
  from exynos_dp code, and rephrase reasonable commit message, and
  remove some controversial style (Krzysztof)
-   analogix_dp_write_byte_to_dpcd(
-   dp, DP_TEST_RESPONSE,
+   analogix_dp_write_byte_to_dpcd(dp,
+   DP_TEST_RESPONSE,
DP_TEST_EDID_CHECKSUM_WRITE);
- Switch video timing type to "u32", so driver could use "of_property_read_u32"
  to get the backword timing values. Krzysztof suggest me that driver could use
  the "of_property_read_bool" to get backword timing values, but that interfacs
  would modify the original drm_display_mode timing directly (whether those
  properties exists or not).
- Correct the misspell in commit message. (Krzysztof)
- Remove the empty line at the end of document, and correct the endpoint
  numbers in the example DT node, and remove the regulator iomux setting
  in driver code while using the pinctl in devicetree instead. (Heiko)
- Add device type declared, cause the previous "platform device type
  support (v4 11/16)" already merge into (v5 02/14).
- Implement connector registration code. (Thierry)
- Split binding doc's from driver changes. (Rob)
- Add eDP hotplug pinctrl property. (Heiko)
- Remove "reg" DT property, cause driver could poweron/poweroff phy via
  the exist "grf" syscon already. And rename the example DT node from
  "edp_phy: phy@ff770274" to "edp_phy: edp-phy" directly. (Heiko)
- Add deivce_node at the front of driver, update phy_ops type from "static
  struct" to "static const struct". And correct the input paramters of
  devm_phy_create() interfaces. (Heiko)
- Split binding doc's from driver changes. (Rob)
- Update the rockchip,grf explain in document, and correct the clock required
  elemets in document. (Rob & Heiko)
- Fix compiled error (Heiko)
- Using the connector display info message to configure eDP driver input
  video mode, 

Re: [PATCH 5/6] drm/vc4: Make sure that planes aren't scaled.

[Daniel Vetter]

On Fri, Oct 23, 2015 at 11:32:35AM +0100, Eric Anholt wrote:
> We would scan out the memory around them if an upscale was attempted,
> and would just scan out incorrectly for downscaling.
> 
> Signed-off-by: Eric Anholt 
> ---
> 
> It looks like, while modetest only wants to set scaling on overlay
> planes, one could do so on our primary/cursor planes if the fd was in
> universal planes mode.
> 
>  drivers/gpu/drm/vc4/vc4_plane.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
> index 2db5092..887f3ca 100644
> --- a/drivers/gpu/drm/vc4/vc4_plane.c
> +++ b/drivers/gpu/drm/vc4/vc4_plane.c
> @@ -157,6 +157,16 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
>   int crtc_w = state->crtc_w;
>   int crtc_h = state->crtc_h;
>  
> + if (state->crtc_w << 16 != state->src_w ||
> + state->crtc_h << 16 != state->src_h) {
> + /* We don't support scaling yet, which involves
> +  * allocating the LBM memory for scaling temporary
> +  * storage, and putting filter kernels in the HVS
> +  * context.
> +  */
> + return -EINVAL;
> + }

Just aside: There's drm_plane_helper_check_update for the common cases.
Unfortunately it suffers a bit from a bikeshed since it wants struct
drm_rect but atomic states don't give you that.
-Daniel

> +
>   if (crtc_x < 0) {
>   offset += drm_format_plane_cpp(fb->pixel_format, 0) * -crtc_x;
>   crtc_w += crtc_x;
> -- 
> 2.6.1
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 05/15] scsi: ufs: increase fDeviceInit query response timeout

[Akinobu Mita]

2015-09-02 19:13 GMT+09:00 Yaniv Gardi :
> fDeviceInit query response time for some devices is too long that default
> query request timeout of 100ms may not be enough. Experiments show that
> fDeviceInit response sometimes takes 500ms so to be on safer side this
> change sets the timeout to 600ms. Without this change, we might
> unnecessarily have to retry fDeviceInit query requests multiple times and
> each query request timeout prints one error message.
>
> Signed-off-by: Subhash Jadavani 
> Signed-off-by: Yaniv Gardi 
>
> ---
>  drivers/scsi/ufs/ufshcd.c | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index e0b8755..573a8cb 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -58,6 +58,12 @@
>  #define QUERY_REQ_RETRIES 10
>  /* Query request timeout */
>  #define QUERY_REQ_TIMEOUT 30 /* msec */
> +/*
> + * Query request timeout for fDeviceInit flag
> + * fDeviceInit query response time for some devices is too large that default
> + * QUERY_REQ_TIMEOUT may not be enough for such devices.
> + */
> +#define QUERY_FDEVICEINIT_REQ_TIMEOUT 600 /* msec */

How about just increasing QUERY_REQ_TIMEOUT from 30ms to 600ms
instead of conditionally setting timeout depending on ufs flag?

>
>  /* Task management command timeout */
>  #define TM_CMD_TIMEOUT 100 /* msecs */
> @@ -1651,6 +1657,7 @@ static int ufshcd_query_flag(struct ufs_hba *hba, enum 
> query_opcode opcode,
> struct ufs_query_req *request = NULL;
> struct ufs_query_res *response = NULL;
> int err, index = 0, selector = 0;
> +   int timeout = QUERY_REQ_TIMEOUT;
>
> BUG_ON(!hba);
>
> @@ -1683,7 +1690,10 @@ static int ufshcd_query_flag(struct ufs_hba *hba, enum 
> query_opcode opcode,
> goto out_unlock;
> }
>
> -   err = ufshcd_exec_dev_cmd(hba, DEV_CMD_TYPE_QUERY, QUERY_REQ_TIMEOUT);
> +   if (idn == QUERY_FLAG_IDN_FDEVICEINIT)
> +   timeout = QUERY_FDEVICEINIT_REQ_TIMEOUT;
> +
> +   err = ufshcd_exec_dev_cmd(hba, DEV_CMD_TYPE_QUERY, timeout);
>
> if (err) {
> dev_err(hba->dev,
> --
> 1.8.5.2
>
> --
> QUALCOMM ISRAEL, on behalf of 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-scsi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 2/2] serial: earlycon: allow to specify uartclk in earlycon kernel-parameter

[Masahiro Yamada]

2015-10-23 0:34 GMT+09:00 Rob Herring :
> On Tue, Oct 20, 2015 at 8:20 PM, Masahiro Yamada
>  wrote:
>> Hi Peter,
>> (+ Rob Herring, Stefan Agner)
>>
>> 2015-10-20 23:00 GMT+09:00 Peter Hurley :
>>> On 10/19/2015 11:36 PM, Masahiro Yamada wrote:
 The input clock frequency varies from device to device, but the
 earlycon uses the fixed frequency (BASE_BAUD * 16).  It makes
 impossible to set the correct divisor to the register.
>>>
>>> So the bootloader hasn't setup the serial port?
>>
>> It does.
>> I use U-boot and the serial port is already set up by U-boot.
>
> This problem is now moving into u-boot which is using DT for configuration.
>
>> But, earlycon setup functions update hardware registers.
>> See  early_serial8250_setup(), ingenic_early_console_setup(), etc.
>>
>>
>> Without port->uartclk set to a valid value,
>> the init code in earlycon setup does not make sense.
>>
>>
>> What I want to clarify is,
>> what should we do in the earlycon setup function?
>>
>> Currently, I see
>>  [1] set device->con->write callback
>>  [2] initialize UART port registers
>>
>>
>> For [2], we need to know baudrate and input clock frequency.
>> (and the latter is missing, that's why my patch is here.)
>
> I'm missing context of what you did, but it needs to be parse-able
> from a flattened tree. My suggestion would be use clock-frequency
> property in the uart node. We should be able to parse that. This came
> up with u-boot as well[1].

Right.

But, I think things have been going wrong
since SPL started to parse a device tree.




-- 
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mm,vmscan: Use accurate values for zone_reclaimable() checks

[Michal Hocko]

On Fri 23-10-15 19:36:30, Tejun Heo wrote:
> Hello, Michal.
> 
> On Fri, Oct 23, 2015 at 10:33:16AM +0200, Michal Hocko wrote:
> > Ohh, OK I can see wq_worker_sleeping now. I've missed your point in
> > other email, sorry about that. But now I am wondering whether this
> > is an intended behavior. The documentation says:
> 
> This is.
> 
> >   WQ_MEM_RECLAIM
> > 
> > All wq which might be used in the memory reclaim paths _MUST_
> > have this flag set.  The wq is guaranteed to have at least one
> > execution context regardless of memory pressure.
> > 
> > Which doesn't seem to be true currently, right? Now I can see your patch
> 
> It is true.
> 
> > to introduce WQ_IMMEDIATE but I am wondering which WQ_MEM_RECLAIM users
> > could do without WQ_IMMEDIATE? I mean all current workers might be
> > looping in the page allocator and it seems possible that WQ_MEM_RECLAIM
> > work items might be waiting behind them so they cannot help to relieve
> > the memory pressure. This doesn't sound right to me. Or I am completely
> > confused and still fail to understand what is WQ_MEM_RECLAIM supposed to
> > be used for.
> 
> It guarantees that there always is enough execution resource to
> execute a work item from that workqueue. 

OK, strictly speaking the rescuer is there but it is kind of pointless
if it doesn't fire up and do a work.

> The problem here is not lack
> of execution resource but concurrency management misunderstanding the
> situation. 

And this sounds like a bug to me.

> This also can be fixed by teaching concurrency management
> to be a bit smarter - e.g. if a work item is burning a lot of CPU
> cycles continuously or pool hasn't finished a work item over a certain
> amount of time, automatically ignore the in-flight work item for the
> purpose of concurrency management; however, this sort of inter-work
> item busy waits are so extremely rare and undesirable that I'm not
> sure the added complexity would be worthwhile.

Don't we have some IO related paths which would suffer from the same
problem. I haven't checked all the WQ_MEM_RECLAIM users but from the
name I would expect they _do_ participate in the reclaim and so they
should be able to make a progress. Now if your new IMMEDIATE flag will
guarantee that then I would argue that it should be implicit for
WQ_MEM_RECLAIM otherwise we always risk a similar situation. What would
be a counter argument for doing that?
-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] mtd: nand: automate NAND timings selection

[Boris Brezillon]

The NAND framework provides several helpers to query timing modes supported
by a NAND chip, but this implies that all NAND controller drivers have
to implement the same timings selection dance.

Provide a common logic to select the best timings based on ONFI or
->onfi_timing_mode_default information.
NAND controller willing to support timings adjustment should just
implement the ->setup_data_interface() method.

Signed-off-by: Boris Brezillon 
---
 drivers/mtd/nand/nand_base.c | 189 ++-
 include/linux/mtd/nand.h | 115 +++---
 2 files changed, 254 insertions(+), 50 deletions(-)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index eaf1fcd..52a1f89 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -3323,6 +3323,144 @@ static void nand_onfi_detect_micron(struct nand_chip 
*chip,
chip->setup_read_retry = nand_setup_read_retry_micron;
 }
 
+/**
+ * nand_setup_data_interface - Setup the data interface and timings on the
+ *controller side
+ * @mtd: MTD device structure
+ * @conf: new configuration to apply
+ *
+ * Try to configure the NAND controller to support the provided data
+ * interface configuration.
+ *
+ * Returns 0 in case of success or -ERROR_CODE.
+ */
+static int nand_setup_data_interface(struct mtd_info *mtd,
+const struct nand_data_interface *conf)
+{
+   struct nand_chip *chip = mtd->priv;
+   int ret;
+
+   if (!chip->setup_data_interface)
+   return -ENOTSUPP;
+
+   ret = chip->setup_data_interface(mtd, conf, false);
+   if (ret)
+   return ret;
+
+   *chip->data_iface = *conf;
+
+   return 0;
+}
+
+/**
+ * nand_setup_data_interface - Check if a data interface config is supported
+ *by the NAND controller
+ * @mtd: MTD device structure
+ * @conf: new configuration to apply
+ *
+ * Check if the provided data interface configuration is supported by the
+ * NAND controller.
+ *
+ * Returns 0 if it is supported or -ERROR_CODE.
+ */
+static int nand_check_data_interface(struct mtd_info *mtd,
+const struct nand_data_interface *conf)
+{
+   struct nand_chip *chip = mtd->priv;
+
+   if (!chip->setup_data_interface)
+   return -ENOTSUPP;
+
+   return chip->setup_data_interface(mtd, conf, true);
+}
+
+/**
+ * nand_configure_data_interface - Configure the data interface and timings
+ * @mtd: MTD device structure
+ *
+ * Try to configure the data interface and NAND timings appropriately.
+ * First tries to retrieve supported timing modes from ONFI information,
+ * and if the NAND chip does not support ONFI, relies on the
+ * ->onfi_timing_mode_default specified in the nand_ids table.
+ *
+ * Returns 0 in case of success or -ERROR_CODE.
+ */
+static int nand_configure_data_interface(struct mtd_info *mtd)
+{
+   struct nand_chip *chip = mtd->priv;
+   struct nand_data_interface *conf;
+   int modes, mode, ret = -EINVAL;
+
+   conf = kzalloc(sizeof(*conf), GFP_KERNEL);
+   if (!conf)
+   return -ENOMEM;
+
+   /* TODO: support DDR interfaces */
+   conf->type = NAND_SDR_IFACE;
+
+   /*
+* First try to identify the best timings from ONFI parameters and
+* if the NAND does not support ONFI, fallback to the default ONFI
+* timing mode.
+*/
+   modes = onfi_get_async_timing_mode(chip);
+   if (modes != ONFI_TIMING_MODE_UNKNOWN) {
+   for (mode = fls(modes) - 1; mode >= 0; mode--) {
+   conf->timings.sdr =
+   *onfi_async_timing_mode_to_sdr_timings(mode);
+
+   ret = nand_check_data_interface(mtd, conf);
+   if (!ret)
+   break;
+   }
+   } else {
+   mode = chip->onfi_timing_mode_default;
+   conf->timings.sdr =
+   *onfi_async_timing_mode_to_sdr_timings(mode);
+
+   ret = nand_check_data_interface(mtd, conf);
+   }
+
+   if (!ret) {
+   uint8_t tmode_param[ONFI_SUBFEATURE_PARAM_LEN] = { mode };
+   int i;
+
+   /*
+* Ensure the timing mode has be changed on the chip side
+* before changing timings on the controller side.
+*/
+   if (modes != ONFI_TIMING_MODE_UNKNOWN) {
+   /*
+* FIXME: should we really set the timing mode on all
+* dies?
+*/
+   for (i = 0; i < chip->numchips; i++) {
+   chip->select_chip(mtd, i);
+   ret = chip->onfi_set_features(mtd, chip,
+   

[PATCH 0/2] mtd: nand: automate NAND timings selection

[Boris Brezillon]

Hello,

This series aims at automating the NAND timings selection which is
currently supposed to be done in each NAND controller driver, thus
simplifying drivers implementation.

Patch 1 also opens the door to DDR NAND support, though setting DDR
timings is currently not supported.

Note that patch 2 is given here as an example of how patch 1 simplifies
things, but won't apply cleanly on mtd-next (it's based on top of other
changes I haven't submitted yet).

Best Regards,

Boris

Boris Brezillon (2):
  mtd: nand: automate NAND timings selection
  mtd: nand: sunxi: switch from manual to automated timing config

 drivers/mtd/nand/nand_base.c  | 189 +-
 drivers/mtd/nand/sunxi_nand.c |  72 
 include/linux/mtd/nand.h  | 115 ++---
 3 files changed, 270 insertions(+), 106 deletions(-)

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

[PATCH 2/2] mtd: nand: sunxi: switch from manual to automated timing config

[Boris Brezillon]

The NAND framework is now able to select the best NAND timings for us.
All we have to do is implement a ->setup_data_interface() function to
apply those timings and remove the timing selection code from the sunxi
driver.

Signed-off-by: Boris Brezillon 
---
 drivers/mtd/nand/sunxi_nand.c | 72 ++-
 1 file changed, 16 insertions(+), 56 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
index b657235..b6f21f4 100644
--- a/drivers/mtd/nand/sunxi_nand.c
+++ b/drivers/mtd/nand/sunxi_nand.c
@@ -1131,7 +1131,8 @@ static int _sunxi_nand_lookup_timing(const s32 *lut, int 
lut_size, u32 duration,
_sunxi_nand_lookup_timing(l, ARRAY_SIZE(l), p, c)
 
 static int sunxi_nand_chip_set_timings(struct sunxi_nand_chip *chip,
-  const struct nand_sdr_timings *timings)
+  const struct nand_sdr_timings *timings,
+  bool check_only)
 {
struct sunxi_nfc *nfc = to_sunxi_nfc(chip->nand.controller);
u32 min_clk_period = 0;
@@ -1224,6 +1225,9 @@ static int sunxi_nand_chip_set_timings(struct 
sunxi_nand_chip *chip,
return tRHW;
}
 
+   if (check_only)
+   return 0;
+
/*
 * TODO: according to ONFI specs this value only applies for DDR NAND,
 * but Allwinner seems to set this to 0x7. Mimic them for now.
@@ -1254,42 +1258,19 @@ static int sunxi_nand_chip_set_timings(struct 
sunxi_nand_chip *chip,
return 0;
 }
 
-static int sunxi_nand_chip_init_timings(struct sunxi_nand_chip *chip,
-   struct device_node *np)
+static int sunxi_nand_setup_data_interface(struct mtd_info *mtd,
+   const struct nand_data_interface *conf,
+   bool check_only)
 {
-   const struct nand_sdr_timings *timings;
-   int ret;
-   int mode;
-
-   mode = onfi_get_async_timing_mode(>nand);
-   if (mode == ONFI_TIMING_MODE_UNKNOWN) {
-   mode = chip->nand.onfi_timing_mode_default;
-   } else {
-   uint8_t feature[ONFI_SUBFEATURE_PARAM_LEN] = {};
-   int i;
-
-   mode = fls(mode) - 1;
-   if (mode < 0)
-   mode = 0;
-
-   feature[0] = mode;
-   for (i = 0; i < chip->nsels; i++) {
-   chip->nand.select_chip(>mtd, i);
-   ret = chip->nand.onfi_set_features(>mtd,
-   >nand,
-   ONFI_FEATURE_ADDR_TIMING_MODE,
-   feature);
-   chip->nand.select_chip(>mtd, -1);
-   if (ret)
-   return ret;
-   }
-   }
+   struct nand_chip *nand = mtd->priv;
+   struct sunxi_nand_chip *sunxi_nand = to_sunxi_nand(nand);
 
-   timings = onfi_async_timing_mode_to_sdr_timings(mode);
-   if (IS_ERR(timings))
-   return PTR_ERR(timings);
+   /* TODO: add support for DDR NANDs */
+   if (conf->type != NAND_SDR_IFACE)
+   return -ENOTSUPP;
 
-   return sunxi_nand_chip_set_timings(chip, timings);
+   return sunxi_nand_chip_set_timings(sunxi_nand, >timings.sdr,
+  check_only);
 }
 
 static int sunxi_nand_hw_common_ecc_ctrl_init(struct mtd_info *mtd,
@@ -1502,7 +1483,6 @@ static int sunxi_nand_ecc_init(struct mtd_info *mtd, 
struct nand_ecc_ctrl *ecc,
 static int sunxi_nand_chip_init(struct device *dev, struct sunxi_nfc *nfc,
struct device_node *np)
 {
-   const struct nand_sdr_timings *timings;
struct sunxi_nand_chip *chip;
struct mtd_part_parser_data ppdata;
struct mtd_info *mtd;
@@ -1578,21 +1558,6 @@ static int sunxi_nand_chip_init(struct device *dev, 
struct sunxi_nfc *nfc,
}
}
 
-   timings = onfi_async_timing_mode_to_sdr_timings(0);
-   if (IS_ERR(timings)) {
-   ret = PTR_ERR(timings);
-   dev_err(dev,
-   "could not retrieve timings for ONFI mode 0: %d\n",
-   ret);
-   return ret;
-   }
-
-   ret = sunxi_nand_chip_set_timings(chip, timings);
-   if (ret) {
-   dev_err(dev, "could not configure chip timings: %d\n", ret);
-   return ret;
-   }
-
nand = >nand;
/* Default tR value specified in the ONFI spec (chapter 4.15.1) */
nand->chip_delay = 200;
@@ -1608,6 +1573,7 @@ static int sunxi_nand_chip_init(struct device *dev, 
struct sunxi_nfc *nfc,
nand->read_buf = sunxi_nfc_read_buf;
nand->write_buf = sunxi_nfc_write_buf;
nand->read_byte = sunxi_nfc_read_byte;
+   

Re: [PATCH 2/3] i2c: uniphier_f: add UniPhier FIFO-builtin I2C driver

[Masahiro Yamada]

2015-10-23 6:06 GMT+09:00 Wolfram Sang :
> On Thu, Jul 30, 2015 at 05:12:21PM +0900, Masahiro Yamada wrote:
>> Add support for on-chip I2C controller used on newer UniPhier SoCs
>> such as PH1-Pro4, PH1-Pro5, etc.  This adapter is equipped with
>> 8-depth TX/RX FIFOs.
>>
>> Signed-off-by: Masahiro Yamada 
>
> Same comments as for the other driver.

Fixed in v2.

> And quite some debug messages left. Could you check if you still want
> them or if they were mostly useful during development of the driver?

Yes, I want to keep them.  I do not think they are too much.


I will probably come back to these drivers when I find some time
in order to implement further features such as the slave mode.   :)

dev_dbg() might be useful for the new development
as well as for checking something when hardware went wrong for some reason.


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

[PATCH v2 1/2] i2c: uniphier: add UniPhier FIFO-less I2C driver

[Masahiro Yamada]

Add support for on-chip I2C controller used on old UniPhier SoCs
such as PH1-LD4, PH1-sLD8, etc.  This adapter is so simple that
it has no FIFO in it.

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - Delete if-block after platform_get_resource()
  - Add I2C_FUNC_SMBUS_EMUL to functionality
  - Add bindings document
  - Add entry to MAINTAINERS

 .../devicetree/bindings/i2c/i2c-uniphier.txt   |  25 ++
 MAINTAINERS|   1 +
 drivers/i2c/busses/Kconfig |   8 +
 drivers/i2c/busses/Makefile|   1 +
 drivers/i2c/busses/i2c-uniphier.c  | 441 +
 5 files changed, 476 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-uniphier.txt
 create mode 100644 drivers/i2c/busses/i2c-uniphier.c

diff --git a/Documentation/devicetree/bindings/i2c/i2c-uniphier.txt 
b/Documentation/devicetree/bindings/i2c/i2c-uniphier.txt
new file mode 100644
index 000..26f9d95
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-uniphier.txt
@@ -0,0 +1,25 @@
+UniPhier I2C controller (FIFO-less)
+
+Required properties:
+- compatible: should be "socionext,uniphier-i2c".
+- #address-cells: should be 1.
+- #size-cells: should be 0.
+- reg: offset and length of the register set for the device.
+- interrupts: a single interrupt specifier.
+- clocks: phandle to the input clock.
+
+Optional properties:
+- clock-frequency: desired I2C bus frequency in Hz.  The maximum supported
+  value is 40.  Defaults to 10 if not specified.
+
+Examples:
+
+   i2c0: i2c@5840 {
+   compatible = "socionext,uniphier-i2c";
+   reg = <0x5840 0x40>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   interrupts = <0 41 1>;
+   clocks = <_clk>;
+   clock-frequency = <10>;
+   };
diff --git a/MAINTAINERS b/MAINTAINERS
index fb7d2e4..b21c456 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1607,6 +1607,7 @@ L:linux-arm-ker...@lists.infradead.org (moderated 
for non-subscribers)
 S: Maintained
 F: arch/arm/boot/dts/uniphier*
 F: arch/arm/mach-uniphier/
+F: drivers/i2c/busses/i2c-uniphier*
 F: drivers/pinctrl/uniphier/
 F: drivers/tty/serial/8250/8250_uniphier.c
 N: uniphier
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 08b8617..2a176b0 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -902,6 +902,14 @@ config I2C_TEGRA
  If you say yes to this option, support will be included for the
  I2C controller embedded in NVIDIA Tegra SOCs
 
+config I2C_UNIPHIER
+   tristate "UniPhier FIFO-less I2C controller"
+   depends on ARCH_UNIPHIER
+   help
+ If you say yes to this option, support will be included for
+ the UniPhier FIFO-less I2C interface embedded in PH1-LD4, PH1-sLD8,
+ or older UniPhier SoCs.
+
 config I2C_VERSATILE
tristate "ARM Versatile/Realview I2C bus support"
depends on ARCH_VERSATILE || ARCH_REALVIEW || ARCH_VEXPRESS
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 6df3b30..f9f0902 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -87,6 +87,7 @@ obj-$(CONFIG_I2C_ST)  += i2c-st.o
 obj-$(CONFIG_I2C_STU300)   += i2c-stu300.o
 obj-$(CONFIG_I2C_SUN6I_P2WI)   += i2c-sun6i-p2wi.o
 obj-$(CONFIG_I2C_TEGRA)+= i2c-tegra.o
+obj-$(CONFIG_I2C_UNIPHIER) += i2c-uniphier.o
 obj-$(CONFIG_I2C_VERSATILE)+= i2c-versatile.o
 obj-$(CONFIG_I2C_WMT)  += i2c-wmt.o
 obj-$(CONFIG_I2C_OCTEON)   += i2c-octeon.o
diff --git a/drivers/i2c/busses/i2c-uniphier.c 
b/drivers/i2c/busses/i2c-uniphier.c
new file mode 100644
index 000..e3c3861
--- /dev/null
+++ b/drivers/i2c/busses/i2c-uniphier.c
@@ -0,0 +1,441 @@
+/*
+ * Copyright (C) 2015 Masahiro Yamada 
+ *
+ * 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; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define UNIPHIER_I2C_DTRM  0x00/* TX register */
+#define UNIPHIER_I2C_DTRM_IRQENBIT(11) /* enable interrupt */
+#define UNIPHIER_I2C_DTRM_STA  BIT(10) /* start condition */
+#define UNIPHIER_I2C_DTRM_STO  BIT(9)  /* stop condition */
+#define UNIPHIER_I2C_DTRM_NACK BIT(8)  /* do not return ACK */
+#define UNIPHIER_I2C_DTRM_RD   BIT(0)  /* read transaction */
+#define UNIPHIER_I2C_DREC  

Re: [PATCH 3/3] i2c: uniphier: add bindings for UniPhier I2C controllers

[Masahiro Yamada]

2015-10-23 6:00 GMT+09:00 Wolfram Sang :
> On Thu, Jul 30, 2015 at 05:12:22PM +0900, Masahiro Yamada wrote:
>> Device Tree bindings for two I2C controllers embedded in
>> UniPhier SoCs.
>>
>> Signed-off-by: Masahiro Yamada 
>
> Please split this into two files with filenames matching those of the
> drivers. I know they will be very similar but I'd like to keep
> consistent.
>

OK, I splited it in v2.

Each document was merged into the corresponding driver patch.



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

[PATCH v2 0/2] i2c: uniphier: add two I2C controller drivers for UniPhier SoC platform

[Masahiro Yamada]

This series adds two I2C controller drivers.
(they are completely different IPs.)

The first one is a very simple FIFO-less I2C controller,
which is used on some older UniPhier SoCs.

The other one is higher-performance I2C controller with TX/RX FIFO,
used on newer UniPhier SoCs.


Changes in v2:
  - Delete if-block after platform_get_resource()
  - Add I2C_FUNC_SMBUS_EMUL to functionality
  - Add bindings document
  - Add entry to MAINTAINERS
  - Delete if-block after platform_get_resource()
  - Add I2C_FUNC_SMBUS_EMUL to functionality
  - Add bindings document
  - Fix a typo in a comment block

Masahiro Yamada (2):
  i2c: uniphier: add UniPhier FIFO-less I2C driver
  i2c: uniphier_f: add UniPhier FIFO-builtin I2C driver

 .../devicetree/bindings/i2c/i2c-uniphier-f.txt |  25 +
 .../devicetree/bindings/i2c/i2c-uniphier.txt   |  25 +
 MAINTAINERS|   1 +
 drivers/i2c/busses/Kconfig |  16 +
 drivers/i2c/busses/Makefile|   2 +
 drivers/i2c/busses/i2c-uniphier-f.c| 584 +
 drivers/i2c/busses/i2c-uniphier.c  | 441 
 7 files changed, 1094 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-uniphier-f.txt
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-uniphier.txt
 create mode 100644 drivers/i2c/busses/i2c-uniphier-f.c
 create mode 100644 drivers/i2c/busses/i2c-uniphier.c

-- 
1.9.1

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

Re: [PATCH 1/3] i2c: uniphier: add UniPhier FIFO-less I2C driver

[Masahiro Yamada]

Hi Wolfram,


Thanks for your review!

2015-10-23 5:59 GMT+09:00 Wolfram Sang :
> On Thu, Jul 30, 2015 at 05:12:20PM +0900, Masahiro Yamada wrote:
>> Add support for on-chip I2C controller used on old UniPhier SoCs
>> such as PH1-LD4, PH1-sLD8, etc..  This adapter is so simple that
>> it has no FIFO in it.
>>
>> Signed-off-by: Masahiro Yamada 
>
> Finally! Mostly looking good.
>
>> +static u32 uniphier_i2c_functionality(struct i2c_adapter *adap)
>> +{
>> + return I2C_FUNC_I2C;
>> +}
>
> No I2C_FUNC_SMBUS_EMUL? But check if SMBUS_QUICK is supported by your
> adapter.

Added in v2.


>> + regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + if (!regs) {
>> + dev_err(dev, "failed to get memory resource");
>> + return -EINVAL;
>> + }
>
> This 'if'-block can go. devm_ioremap_resource will check it for you.
>

Fixed in v2.

Thanks!


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

[PATCH v2 2/2] i2c: uniphier_f: add UniPhier FIFO-builtin I2C driver

[Masahiro Yamada]

Add support for on-chip I2C controller used on newer UniPhier SoCs
such as PH1-Pro4, PH1-Pro5, etc.  This adapter is equipped with
8-depth TX/RX FIFOs.

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - Delete if-block after platform_get_resource()
  - Add I2C_FUNC_SMBUS_EMUL to functionality
  - Add bindings document
  - Fix a typo in a comment block

 .../devicetree/bindings/i2c/i2c-uniphier-f.txt |  25 +
 drivers/i2c/busses/Kconfig |   8 +
 drivers/i2c/busses/Makefile|   1 +
 drivers/i2c/busses/i2c-uniphier-f.c| 584 +
 4 files changed, 618 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-uniphier-f.txt
 create mode 100644 drivers/i2c/busses/i2c-uniphier-f.c

diff --git a/Documentation/devicetree/bindings/i2c/i2c-uniphier-f.txt 
b/Documentation/devicetree/bindings/i2c/i2c-uniphier-f.txt
new file mode 100644
index 000..27fc6f8
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-uniphier-f.txt
@@ -0,0 +1,25 @@
+UniPhier I2C controller (FIFO-builtin)
+
+Required properties:
+- compatible: should be "socionext,uniphier-fi2c".
+- #address-cells: should be 1.
+- #size-cells: should be 0.
+- reg: offset and length of the register set for the device.
+- interrupts: a single interrupt specifier.
+- clocks: phandle to the input clock.
+
+Optional properties:
+- clock-frequency: desired I2C bus frequency in Hz.  The maximum supported
+  value is 40.  Defaults to 10 if not specified.
+
+Examples:
+
+   i2c0: i2c@5878 {
+   compatible = "socionext,uniphier-fi2c";
+   reg = <0x5878 0x80>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   interrupts = <0 41 4>;
+   clocks = <_clk>;
+   clock-frequency = <10>;
+   };
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 2a176b0..0111219 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -910,6 +910,14 @@ config I2C_UNIPHIER
  the UniPhier FIFO-less I2C interface embedded in PH1-LD4, PH1-sLD8,
  or older UniPhier SoCs.
 
+config I2C_UNIPHIER_F
+   tristate "UniPhier FIFO-builtin I2C controller"
+   depends on ARCH_UNIPHIER
+   help
+ If you say yes to this option, support will be included for
+ the UniPhier FIFO-builtin I2C interface embedded in PH1-Pro4,
+ PH1-Pro5, or newer UniPhier SoCs.
+
 config I2C_VERSATILE
tristate "ARM Versatile/Realview I2C bus support"
depends on ARCH_VERSATILE || ARCH_REALVIEW || ARCH_VEXPRESS
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index f9f0902..37f2819 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -88,6 +88,7 @@ obj-$(CONFIG_I2C_STU300)  += i2c-stu300.o
 obj-$(CONFIG_I2C_SUN6I_P2WI)   += i2c-sun6i-p2wi.o
 obj-$(CONFIG_I2C_TEGRA)+= i2c-tegra.o
 obj-$(CONFIG_I2C_UNIPHIER) += i2c-uniphier.o
+obj-$(CONFIG_I2C_UNIPHIER_F)   += i2c-uniphier-f.o
 obj-$(CONFIG_I2C_VERSATILE)+= i2c-versatile.o
 obj-$(CONFIG_I2C_WMT)  += i2c-wmt.o
 obj-$(CONFIG_I2C_OCTEON)   += i2c-octeon.o
diff --git a/drivers/i2c/busses/i2c-uniphier-f.c 
b/drivers/i2c/busses/i2c-uniphier-f.c
new file mode 100644
index 000..e8d03bc
--- /dev/null
+++ b/drivers/i2c/busses/i2c-uniphier-f.c
@@ -0,0 +1,584 @@
+/*
+ * Copyright (C) 2015 Masahiro Yamada 
+ *
+ * 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; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define UNIPHIER_FI2C_CR   0x00/* control register */
+#define UNIPHIER_FI2C_CR_MST   BIT(3)  /* master mode */
+#define UNIPHIER_FI2C_CR_STA   BIT(2)  /* start condition */
+#define UNIPHIER_FI2C_CR_STO   BIT(1)  /* stop condition */
+#define UNIPHIER_FI2C_CR_NACK  BIT(0)  /* do not return ACK */
+#define UNIPHIER_FI2C_DTTX 0x04/* TX FIFO */
+#define UNIPHIER_FI2C_DTTX_CMD BIT(8)  /* send command (slave addr) */
+#define UNIPHIER_FI2C_DTTX_RD  BIT(0)  /* read transaction */
+#define UNIPHIER_FI2C_DTRX 0x04/* RX FIFO */
+#define UNIPHIER_FI2C_SLAD 0x0c/* slave address */
+#define UNIPHIER_FI2C_CYC  0x10/* clock cycle control */
+#define UNIPHIER_FI2C_LCTL 0x14/* clock low period control */
+#define UNIPHIER_FI2C_SSUT 0x18/* restart/stop setup time control */
+#define UNIPHIER_FI2C_DSUT 0x1c  

Re: [PATCH v3 1/3] dt-bindings: Consolidate SRAM bindings from all vendors

[Heiko Stübner]

Am Freitag, 23. Oktober 2015, 10:39:19 schrieb Krzysztof Kozlowski:
> SRAM bindings for various SoCs, using the mmio-sram genalloc
> API, are spread over different places - per SoC vendor. Since all of
> these are quite similar (they depend on mmio-sram) move them to a common
> place.
> 
> Signed-off-by: Krzysztof Kozlowski 
> Cc: Heiko Stuebner 
> Cc: Maxime Ripard 
> Cc: Chen-Yu Tsai 
> Cc: Kukjin Kim 
> Suggested-by: Rob Herring 
> 
> ---
> 
> Changes since v2:
> 1. Update paths to sram.txt.
> 
> Changes since v1:
> 1. New patch. Extended suggestion from Rob.
> ---

> .../bindings/{arm/rockchip/pmu-sram.txt => sram/rockchip-pmu-sram.txt} 
> .../bindings/{arm/rockchip/smp-sram.txt => sram/rockchip-smp-sram.txt} 

for the Rockchip parts
Acked-by: Heiko Stuebner 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/2] ARM: dts: mediatek: add MT2701 basic support

[Matthias Brugger]

On 20/10/15 08:34, Erin Lo wrote:

This adds basic chip support for Mediatek 2701.

Signed-off-by: Erin Lo 
---
  arch/arm/boot/dts/Makefile|   1 +
  arch/arm/boot/dts/mt2701-evb.dts  |  29 
  arch/arm/boot/dts/mt2701.dtsi | 146 ++
  arch/arm/mach-mediatek/mediatek.c |   1 +
  4 files changed, 177 insertions(+)
  create mode 100644 arch/arm/boot/dts/mt2701-evb.dts
  create mode 100644 arch/arm/boot/dts/mt2701.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 233159d..aec787e 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -732,6 +732,7 @@ dtb-$(CONFIG_MACH_DOVE) += \
dove-dove-db.dtb \
dove-sbc-a510.dtb
  dtb-$(CONFIG_ARCH_MEDIATEK) += \
+   mt2701-evb.dtb \
mt6580-evbp1.dtb \
mt6589-aquaris5.dtb \
mt6592-evb.dtb \
diff --git a/arch/arm/boot/dts/mt2701-evb.dts b/arch/arm/boot/dts/mt2701-evb.dts
new file mode 100644
index 000..082ca88
--- /dev/null
+++ b/arch/arm/boot/dts/mt2701-evb.dts
@@ -0,0 +1,29 @@
+/*
+ * Copyright (c) 2015 MediaTek Inc.
+ * Author: Erin Lo 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+/dts-v1/;
+#include "mt2701.dtsi"
+
+/ {
+   model = "MediaTek MT2701 evaluation board";
+   compatible = "mediatek,mt2701-evb", "mediatek,mt2701";
+
+   memory {
+   reg = <0 0x8000 0 0x4000>;
+   };
+};
+
+ {
+   status = "okay";
+};
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
new file mode 100644
index 000..69f240f
--- /dev/null
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -0,0 +1,146 @@
+/*
+ * Copyright (c) 2015 MediaTek Inc.
+ * Author: Erin.Lo 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include "skeleton64.dtsi"
+
+/ {
+   compatible = "mediatek,mt2701";
+   interrupt-parent = <>;
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0x0>;
+   };
+   cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0x1>;
+   };
+   cpu@2 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0x2>;
+   };
+   cpu@3 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0x3>;
+   };
+   };
+
+   system_clk: dummy13m {
+   compatible = "fixed-clock";
+   clock-frequency = <1300>;
+   #clock-cells = <0>;
+   };
+
+   rtc_clk: dummy32k {
+   compatible = "fixed-clock";
+   clock-frequency = <32000>;
+   #clock-cells = <0>;
+   };
+
+   uart_clk: dummy26m {
+   compatible = "fixed-clock";
+   clock-frequency = <2600>;
+   #clock-cells = <0>;
+   };
+
+   timer {
+   compatible = "arm,armv7-timer";
+   interrupt-parent = <>;
+   interrupts = ,
+,
+,
+;
+   };
+
+   watchdog: watchdog@10007000 {
+   compatible = "mediatek,mt2701-wdt",
+"mediatek,mt6589-wdt";
+   reg = <0 0x10007000 0 0x100>;
+   };
+
+   timer: timer@10008000 {
+   compatible = "mediatek,mt2701-timer",
+"mediatek,mt6577-timer";
+   reg = <0x10008000 0x80>;


I suppose reg should look like this:
reg = <0 0x10008000 0 0x80>;

I fixed it and pushed the patch to v4.4-next/dts
Please let me know if this is not working, I have no hardware to test it.


+   interrupts = ;
+   clocks = <_clk>, <_clk>;
+   clock-names = "system-clk", "rtc-clk";
+   };
+
+   

Re: [PATCH v3 0/2] Add basic support for Mediatek MT2701 SoC

[Matthias Brugger]

On 20/10/15 08:34, Erin Lo wrote:

MT2701 is a SoC based on 32bit ARMv7 architecture. It contains 4 CA7 cores.
MT2701 share many HW IP with MT65xx series. This patchset was tested
on MT2701 evaluation board, and boot to shell ok.

This series contains document bindings, device tree including
interrupt, uart, timer and wdt.

Change in v3:
1. Add the compatible string to arch/arm/mach-mediatek/mediatek.c

Change in v2:
1. Use one tab in stead of spaces in front of "mediatek,mt2701-sysirq" 
(mediatek,sysirq.txt)
2. Sorting the compatible SoC and add back mt6595 since accidently deleted in 
previous version (mtk-uart.txt)
3. Correct the mt2701-timer from mt6589-timer since the mistake in previous 
version (mediatek,mtk-timer.txt)

Erin Lo (2):
   Document: DT: Add bindings for mediatek MT2701 SoC Platform
   ARM: dts: mediatek: add MT2701 basic support



Applied with the Ack from Rob.
Thanks.


  Documentation/devicetree/bindings/arm/mediatek.txt |   4 +
  .../bindings/arm/mediatek/mediatek,sysirq.txt  |   1 +
  .../devicetree/bindings/serial/mtk-uart.txt|  14 +-
  .../bindings/timer/mediatek,mtk-timer.txt  |   5 +-
  .../devicetree/bindings/watchdog/mtk-wdt.txt   |   6 +-
  arch/arm/boot/dts/Makefile |   1 +
  arch/arm/boot/dts/mt2701-evb.dts   |  29 
  arch/arm/boot/dts/mt2701.dtsi  | 146 +
  arch/arm/mach-mediatek/mediatek.c  |   1 +
  9 files changed, 197 insertions(+), 10 deletions(-)
  create mode 100644 arch/arm/boot/dts/mt2701-evb.dts
  create mode 100644 arch/arm/boot/dts/mt2701.dtsi

--
1.9.1


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

[RFC PATCH] pci: pci_vpd_pci22_size can be static

[kbuild test robot]

Signed-off-by: Fengguang Wu 
---
 access.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/access.c b/drivers/pci/access.c
index 3a49b14..41d86f6 100644
--- a/drivers/pci/access.c
+++ b/drivers/pci/access.c
@@ -495,7 +495,7 @@ static int pci_vpd_f0_dev_check(struct pci_dev *dev)
  * @old_size:  current assumed size, also maximum allowed size
  *
  */
-size_t
+static size_t
 pci_vpd_pci22_size(struct pci_dev *dev, size_t old_size)
 {
loff_t off = 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] pci: Update VPD size with correct length

[kbuild test robot]

Hi Hannes,

[auto build test WARNING on pci/next -- if it's inappropriate base, please 
suggest rules for selecting the more suitable base]

url:
https://github.com/0day-ci/linux/commits/Hannes-Reinecke/pci-Update-VPD-size-with-correct-length/20151023-171224
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> drivers/pci/access.c:499:1: sparse: symbol 'pci_vpd_pci22_size' was not 
>> declared. Should it be static?

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] perf tools: Don't set inherit bit for system wide evsel

[Wang Nan]

Inherit bit is useless for a system wide evsel [1]. Further kernel
improvements are giving more constrain [2] on inherit events. This
patch set inherit bit to 0 to avoid potential constrains.

[1] 
http://lkml.kernel.org/r/20151022124142.gq17...@twins.programming.kicks-ass.net
[2] http://lkml.kernel.org/r/1445559014-4667-1-git-send-email-...@kernel.org

Signed-off-by: Wang Nan 
Cc: Arnaldo Carvalho de Melo 
Cc: Alexei Starovoitov 
Cc: Peter Zijlstra 
Cc: Li Zefan 
Cc: pi3or...@163.com
Link: http://lkml.kernel.org/n/ebpf-0tgilipxoo6fiebcxu3ft...@git.kernel.org
---

evsel->system_wide doesn't correct reflect whether this evsel is system
wide or not, so checks pid when invoking perf_event_open, and it is
always correct.

---
 tools/perf/util/evsel.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 5566b16..e2d6c9a 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -1337,6 +1337,7 @@ retry_sample_id:
 
for (thread = 0; thread < nthreads; thread++) {
int group_fd;
+   struct perf_event_attr attr;
 
if (!evsel->cgrp && !evsel->system_wide)
pid = thread_map__pid(threads, thread);
@@ -1346,7 +1347,10 @@ retry_open:
pr_debug2("sys_perf_event_open: pid %d  cpu %d  
group_fd %d  flags %#lx\n",
  pid, cpus->map[cpu], group_fd, flags);
 
-   FD(evsel, cpu, thread) = 
sys_perf_event_open(>attr,
+   attr = evsel->attr;
+   if (pid == -1)
+   attr.inherit = 0;
+   FD(evsel, cpu, thread) = sys_perf_event_open(,
 pid,
 
cpus->map[cpu],
 group_fd, 
flags);
-- 
1.8.3.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] mm,vmscan: Use accurate values for zone_reclaimable()checks

[Tejun Heo]

On Fri, Oct 23, 2015 at 10:36:12AM +0200, Michal Hocko wrote:
> If WQ_MEM_RECLAIM can really guarantee one worker as described in the
> documentation then I agree that fixing vmstat is a better fix. But that
> doesn't seem to be the case currently.

It does.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mm,vmscan: Use accurate values for zone_reclaimable() checks

[Tejun Heo]

Hello, Michal.

On Fri, Oct 23, 2015 at 10:33:16AM +0200, Michal Hocko wrote:
> Ohh, OK I can see wq_worker_sleeping now. I've missed your point in
> other email, sorry about that. But now I am wondering whether this
> is an intended behavior. The documentation says:

This is.

>   WQ_MEM_RECLAIM
> 
> All wq which might be used in the memory reclaim paths _MUST_
> have this flag set.  The wq is guaranteed to have at least one
> execution context regardless of memory pressure.
> 
> Which doesn't seem to be true currently, right? Now I can see your patch

It is true.

> to introduce WQ_IMMEDIATE but I am wondering which WQ_MEM_RECLAIM users
> could do without WQ_IMMEDIATE? I mean all current workers might be
> looping in the page allocator and it seems possible that WQ_MEM_RECLAIM
> work items might be waiting behind them so they cannot help to relieve
> the memory pressure. This doesn't sound right to me. Or I am completely
> confused and still fail to understand what is WQ_MEM_RECLAIM supposed to
> be used for.

It guarantees that there always is enough execution resource to
execute a work item from that workqueue.  The problem here is not lack
of execution resource but concurrency management misunderstanding the
situation.  This also can be fixed by teaching concurrency management
to be a bit smarter - e.g. if a work item is burning a lot of CPU
cycles continuously or pool hasn't finished a work item over a certain
amount of time, automatically ignore the in-flight work item for the
purpose of concurrency management; however, this sort of inter-work
item busy waits are so extremely rare and undesirable that I'm not
sure the added complexity would be worthwhile.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/6] drm/vc4: fix platform_no_drv_owner.cocci warnings

[Eric Anholt]

From: Julia Lawall 

drivers/gpu/drm/vc4/vc4_drv.c:248:3-8: No need to set .owner here. The core 
will do it.

 Remove .owner field if calls are used which set it automatically

Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci

Signed-off-by: Fengguang Wu 
Signed-off-by: Julia Lawall 
Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_drv.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 6e73060..d5db9e0 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -259,7 +259,6 @@ static struct platform_driver vc4_platform_driver = {
.remove = vc4_platform_drm_remove,
.driver = {
.name   = "vc4-drm",
-   .owner  = THIS_MODULE,
.of_match_table = vc4_of_match,
},
 };
-- 
2.6.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/

VC4 fixes for -next

[Eric Anholt]

Merging vc4 to drm-next got a few automatic sparse and coccinelle
warning reports generated.  The first 3 patches come from the
maintainers of those systems (thanks!), and the last 3 are fixes I've
come up with in the last few days.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/6] drm/vc4: Fix some failure to track __iomem decorations on pointers.

[Eric Anholt]

Caught by the kbuild test robot.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_crtc.c | 3 ++-
 drivers/gpu/drm/vc4/vc4_hvs.c  | 8 
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index a3a77dd..32c0348 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -401,7 +401,8 @@ static void vc4_crtc_atomic_flush(struct drm_crtc *crtc,
dlist_next++;
 
HVS_WRITE(SCALER_DISPLISTX(vc4_crtc->channel),
- (u32 *)vc4_crtc->dlist - (u32 *)vc4->hvs->dlist);
+ (u32 __iomem *)vc4_crtc->dlist -
+ (u32 __iomem *)vc4->hvs->dlist);
 
/* Make the next display list start after ours. */
vc4_crtc->dlist_size -= (dlist_next - vc4_crtc->dlist);
diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
index ab1673f..4d81d43 100644
--- a/drivers/gpu/drm/vc4/vc4_hvs.c
+++ b/drivers/gpu/drm/vc4/vc4_hvs.c
@@ -75,10 +75,10 @@ void vc4_hvs_dump_state(struct drm_device *dev)
for (i = 0; i < 64; i += 4) {
DRM_INFO("0x%08x (%s): 0x%08x 0x%08x 0x%08x 0x%08x\n",
 i * 4, i < HVS_BOOTLOADER_DLIST_END ? "B" : "D",
-((uint32_t *)vc4->hvs->dlist)[i + 0],
-((uint32_t *)vc4->hvs->dlist)[i + 1],
-((uint32_t *)vc4->hvs->dlist)[i + 2],
-((uint32_t *)vc4->hvs->dlist)[i + 3]);
+readl((u32 __iomem *)vc4->hvs->dlist + 0),
+readl((u32 __iomem *)vc4->hvs->dlist + 1),
+readl((u32 __iomem *)vc4->hvs->dlist + 2),
+readl((u32 __iomem *)vc4->hvs->dlist + 3));
}
 }
 
-- 
2.6.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 5/6] drm/vc4: Make sure that planes aren't scaled.

[Eric Anholt]

We would scan out the memory around them if an upscale was attempted,
and would just scan out incorrectly for downscaling.

Signed-off-by: Eric Anholt 
---

It looks like, while modetest only wants to set scaling on overlay
planes, one could do so on our primary/cursor planes if the fd was in
universal planes mode.

 drivers/gpu/drm/vc4/vc4_plane.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index 2db5092..887f3ca 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -157,6 +157,16 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
int crtc_w = state->crtc_w;
int crtc_h = state->crtc_h;
 
+   if (state->crtc_w << 16 != state->src_w ||
+   state->crtc_h << 16 != state->src_h) {
+   /* We don't support scaling yet, which involves
+* allocating the LBM memory for scaling temporary
+* storage, and putting filter kernels in the HVS
+* context.
+*/
+   return -EINVAL;
+   }
+
if (crtc_x < 0) {
offset += drm_format_plane_cpp(fb->pixel_format, 0) * -crtc_x;
crtc_w += crtc_x;
-- 
2.6.1

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

[PATCH 1/6] drm/vc4: vc4_plane_duplicate_state() can be static

[Eric Anholt]

From: kbuild test robot 

Signed-off-by: Fengguang Wu 
Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_plane.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index cdd8b10..2db5092 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -70,7 +70,7 @@ static bool plane_enabled(struct drm_plane_state *state)
return state->fb && state->crtc;
 }
 
-struct drm_plane_state *vc4_plane_duplicate_state(struct drm_plane *plane)
+static struct drm_plane_state *vc4_plane_duplicate_state(struct drm_plane 
*plane)
 {
struct vc4_plane_state *vc4_state;
 
@@ -97,8 +97,8 @@ struct drm_plane_state *vc4_plane_duplicate_state(struct 
drm_plane *plane)
return _state->base;
 }
 
-void vc4_plane_destroy_state(struct drm_plane *plane,
-struct drm_plane_state *state)
+static void vc4_plane_destroy_state(struct drm_plane *plane,
+   struct drm_plane_state *state)
 {
struct vc4_plane_state *vc4_state = to_vc4_plane_state(state);
 
@@ -108,7 +108,7 @@ void vc4_plane_destroy_state(struct drm_plane *plane,
 }
 
 /* Called during init to allocate the plane's atomic state. */
-void vc4_plane_reset(struct drm_plane *plane)
+static void vc4_plane_reset(struct drm_plane *plane)
 {
struct vc4_plane_state *vc4_state;
 
-- 
2.6.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 6/6] drm/vc4: Add support for more a few more RGB display plane formats.

[Eric Anholt]

These were all touch-tested with modetest.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_plane.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index 887f3ca..b31dfce 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -51,6 +51,22 @@ static const struct hvs_format {
.drm = DRM_FORMAT_ARGB, .hvs = HVS_PIXEL_FORMAT_RGBA,
.pixel_order = HVS_PIXEL_ORDER_ABGR, .has_alpha = true,
},
+   {
+   .drm = DRM_FORMAT_RGB565, .hvs = HVS_PIXEL_FORMAT_RGB565,
+   .pixel_order = HVS_PIXEL_ORDER_XRGB, .has_alpha = false,
+   },
+   {
+   .drm = DRM_FORMAT_BGR565, .hvs = HVS_PIXEL_FORMAT_RGB565,
+   .pixel_order = HVS_PIXEL_ORDER_XBGR, .has_alpha = false,
+   },
+   {
+   .drm = DRM_FORMAT_ARGB1555, .hvs = HVS_PIXEL_FORMAT_RGBA5551,
+   .pixel_order = HVS_PIXEL_ORDER_ABGR, .has_alpha = true,
+   },
+   {
+   .drm = DRM_FORMAT_XRGB1555, .hvs = HVS_PIXEL_FORMAT_RGBA5551,
+   .pixel_order = HVS_PIXEL_ORDER_ABGR, .has_alpha = false,
+   },
 };
 
 static const struct hvs_format *vc4_get_hvs_format(u32 drm_format)
-- 
2.6.1

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

Re: [PATCH 2/2] efi: Fix warning of int-to-pointer-cast on x86 32-bit builds

[Ingo Molnar]

* Ingo Molnar  wrote:

> 
> * Ingo Molnar  wrote:
> 
> > 
> > * Ard Biesheuvel  wrote:
> > 
> > > From: Taku Izumi 
> > > 
> > > Commit 0f96a99dab36 ("efi: Add "efi_fake_mem" boot option")
> > > introduces the following warning message:
> > > 
> > >   drivers/firmware/efi/fake_mem.c:186:20: warning: cast to pointer
> > >   from integer of different size [-Wint-to-pointer-cast]
> > > 
> > > new_memmap_phy was defined as a u64 value and cast to void*, causing
> > > a int-to-pointer-cast warning on x86 32-bit builds.
> > > However, since the void* type is inappropriate for a physical
> > > address, the definition of struct efi_memory_map::phys_map has been
> > > changed to phys_addr_t in the previous patch, and so the cast can be
> > > dropped entirely.
> > > 
> > > This patch also changes the type of the "new_memmap_phy" variable
> > > from "u64" to "phys_addr_t" to align with the types of
> > > memblock_alloc() and struct efi_memory_map::phys_map.
> > > 
> > > Reported-by: Ingo Molnar 
> > > Signed-off-by: Taku Izumi 
> > > [ard.biesheuvel: removed void* cast, updated commit log]
> > > Signed-off-by: Ard Biesheuvel 
> > > ---
> > >  drivers/firmware/efi/fake_mem.c | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/firmware/efi/fake_mem.c 
> > > b/drivers/firmware/efi/fake_mem.c
> > > index 32bcb14df2c8..ed3a854950cc 100644
> > > --- a/drivers/firmware/efi/fake_mem.c
> > > +++ b/drivers/firmware/efi/fake_mem.c
> > > @@ -59,7 +59,7 @@ void __init efi_fake_memmap(void)
> > >   u64 start, end, m_start, m_end, m_attr;
> > >   int new_nr_map = memmap.nr_map;
> > >   efi_memory_desc_t *md;
> > > - u64 new_memmap_phy;
> > > + phys_addr_t new_memmap_phy;
> > >   void *new_memmap;
> > >   void *old, *new;
> > >   int i;
> > > @@ -183,7 +183,7 @@ void __init efi_fake_memmap(void)
> > >   /* swap into new EFI memmap */
> > >   efi_unmap_memmap();
> > >   memmap.map = new_memmap;
> > > - memmap.phys_map = (void *)new_memmap_phy;
> > > + memmap.phys_map = new_memmap_phy;
> > >   memmap.nr_map = new_nr_map;
> > >   memmap.map_end = memmap.map + memmap.nr_map * memmap.desc_size;
> > 
> > Please guys, think for a change!
> > 
> > How is this supposed to work with:
> > 
> >include/linux/efi.h:void *phys_map;
> > 
> > ?
> 
> Ah, I take that back, now I see your patch 1/2 that changes it to phys_addr_t.
> 
> That's the right solution, and it also cleans up the code:
> 
>   Reviewed-by: Ingo Molnar 

Matt, do you want to take these fixes, or should I apply them directly?

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 v2 net-next] xfrm: Fix unaligned access to stats in copy_to_user_state()

[Steffen Klassert]

On Wed, Oct 21, 2015 at 11:48:25AM -0400, Sowmini Varadhan wrote:
> 
> On sparc, deleting established SAs (e.g., by restarting ipsec)
> results in unaligned access messages via xfrm_del_sa -> 
> km_state_notify -> xfrm_send_state_notify().
> 
> Even though struct xfrm_usersa_info is aligned on 8-byte boundaries,
> netlink attributes are fundamentally only 4 byte aligned, and this
> cannot be changed for nla_data() that is passed up to userspace.
> As a result, the put_unaligned() macro needs to be used to
> set up potentially unaligned fields such as the xfrm_stats in
> copy_to_user_state()
> 
> Signed-off-by: Sowmini Varadhan 
> ---
> v2: review comment from thread: cannot use PTR_ALIGN as this would break
> userspace assumptions about 4 byte alignment. Use *_unaligned() macros
> as needed, instead.

This works on intel 32-bit and 64-bit as expected.
Patch applied to ipsec-next, thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/6] drm/vc4: fix itnull.cocci warnings

[Eric Anholt]

From: Julia Lawall 

Connector cannot be null because it is a list entry, ie accessed at an
offset from the positions of the list structure pointers themselves.

Generated by: scripts/coccinelle/iterators/itnull.cocci

Signed-off-by: Fengguang Wu 
Signed-off-by: Julia Lawall 
Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_crtc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 8489d5b..a3a77dd 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -168,7 +168,7 @@ static int vc4_get_clock_select(struct drm_crtc *crtc)
struct drm_connector *connector;
 
drm_for_each_connector(connector, crtc->dev) {
-   if (connector && connector->state->crtc == crtc) {
+   if (connector->state->crtc == crtc) {
struct drm_encoder *encoder = connector->encoder;
struct vc4_encoder *vc4_encoder =
to_vc4_encoder(encoder);
-- 
2.6.1

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

Re: Generic DT binding for IPIs

[Qais Yousef]

On 10/22/2015 02:43 PM, Rob Herring wrote:

On Wed, Oct 14, 2015 at 5:18 AM, Qais Yousef  wrote:

Hi,

This is an attempt to revive a discussion on the right list this time with
all the correct people hopefully on CC.

devicetree-spec would be more appropriate list for something like this.


Thanks I didn't know about it.




While trying to upstream a driver, Thomas and Marc Zyngier pointed out the
need for a generic IPI support in the kernel to allow driver to reserve and
send ones. Hopefully my latest RFC patch will help to clarify what's being
done.

 https://lkml.org/lkml/2015/10/13/227

We need a generic DT binding support to accompany that to allow a driver to
reserve an IPI using this new mechanism.

MarcZ had the following suggestion:

 https://lkml.org/lkml/2015/8/24/628

Which in summary is

 mydevice@f000 {
 interrupt-source = < INT_SPEC 2  >;

What is INT_SPEC and "2"? A drawing of the h/w connections and then
what the binding looks like would be helpful.


INT_SPEC are the interrupt controller specific parameters. I think 2 
refers to how many 'interrupt-sink' references it's being passed.





 };

 inttarg1: mydevice@f100 {
 interrupt-sink = < HWAFFINITY1>;

What is HWAFFINITY1? I want to be able to see if say this value is 1,
then the affinity is for cpu0.


HWAFFINITY is the CPU to map the IPI to. The actual value would be 
specific to the interrupt controller. The controller implementation can 
always provide a set of defines if the mapping is not straightforward.





 };

 inttarg2: cpu@1 {
 interrupt-sink = < HWAFFINITY2>;
 };


interrupt-sink requests to reserve an IPI that it will receive at HWAFFINITY
cpumask. interrupt-source will not do any reservation. It will simply
connect an IPI reserved by interrupt-sink to the device that will be
responsible for generating that IPI. This description should allow
connecting any 2 devices.
Correct me Marc if I got it wrong please.

I suggested a simplification by assuming that IPIs will only be between host
OS and a coprocessor which would gives us this form which I think is easier
to deal with

 coprocessor {
  interrupt-source = < INT_SPEC COP_HWAFFINITY>;
  interrupt-sink = < INT_SPEC CPU_HWAFFINITY>;
 }


interrupt-source here reserves an IPI to be sent from host OS to coprocessor
at COP_HWAFFINITY. interrupt-sink will reserve an IPI to be received by host
OS at CPU_HWAFFINITY. Less generic but I don't know how important it is for
host OS to setup IPIs between 2 external coprocessors and whether it should
really be doing that.

Could we use the existing interrupts binding for interrupt-sink?


No. interrupt-sink will cause an IPI to be dynamically allocated and 
mapped to that processor. Of course, if the connection is hardwired then 
interrupts property is the right thing to use.





What do the DT experts think? Any preference or a better suggestion?

Depends how you would assign coproc to coproc IPIs in a system. It may
be fixed in firmware, or more complex coprocs may read the dtb.


OK. I'll try to cook some RFC patches that implement this which 
hopefully will make it easier to review and build on.


Thanks,
Qais
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v12 2/6] pci: add Altera PCI vendor ID

[Ley Foon Tan]

Signed-off-by: Ley Foon Tan 
---
 include/linux/pci_ids.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index d9ba49c..08e4462 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -1550,6 +1550,8 @@
 #define PCI_DEVICE_ID_SERVERWORKS_CSB6LPC 0x0227
 #define PCI_DEVICE_ID_SERVERWORKS_HT1100LD 0x0408
 
+#define PCI_VENDOR_ID_ALTERA   0x1172
+
 #define PCI_VENDOR_ID_SBE  0x1176
 #define PCI_DEVICE_ID_SBE_WANXL100 0x0301
 #define PCI_DEVICE_ID_SBE_WANXL200 0x0302
-- 
1.8.2.1

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

Re: [PATCH 2/2] efi: Fix warning of int-to-pointer-cast on x86 32-bit builds

[Ingo Molnar]

* Ingo Molnar  wrote:

> 
> * Ard Biesheuvel  wrote:
> 
> > From: Taku Izumi 
> > 
> > Commit 0f96a99dab36 ("efi: Add "efi_fake_mem" boot option")
> > introduces the following warning message:
> > 
> >   drivers/firmware/efi/fake_mem.c:186:20: warning: cast to pointer
> >   from integer of different size [-Wint-to-pointer-cast]
> > 
> > new_memmap_phy was defined as a u64 value and cast to void*, causing
> > a int-to-pointer-cast warning on x86 32-bit builds.
> > However, since the void* type is inappropriate for a physical
> > address, the definition of struct efi_memory_map::phys_map has been
> > changed to phys_addr_t in the previous patch, and so the cast can be
> > dropped entirely.
> > 
> > This patch also changes the type of the "new_memmap_phy" variable
> > from "u64" to "phys_addr_t" to align with the types of
> > memblock_alloc() and struct efi_memory_map::phys_map.
> > 
> > Reported-by: Ingo Molnar 
> > Signed-off-by: Taku Izumi 
> > [ard.biesheuvel: removed void* cast, updated commit log]
> > Signed-off-by: Ard Biesheuvel 
> > ---
> >  drivers/firmware/efi/fake_mem.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/firmware/efi/fake_mem.c 
> > b/drivers/firmware/efi/fake_mem.c
> > index 32bcb14df2c8..ed3a854950cc 100644
> > --- a/drivers/firmware/efi/fake_mem.c
> > +++ b/drivers/firmware/efi/fake_mem.c
> > @@ -59,7 +59,7 @@ void __init efi_fake_memmap(void)
> > u64 start, end, m_start, m_end, m_attr;
> > int new_nr_map = memmap.nr_map;
> > efi_memory_desc_t *md;
> > -   u64 new_memmap_phy;
> > +   phys_addr_t new_memmap_phy;
> > void *new_memmap;
> > void *old, *new;
> > int i;
> > @@ -183,7 +183,7 @@ void __init efi_fake_memmap(void)
> > /* swap into new EFI memmap */
> > efi_unmap_memmap();
> > memmap.map = new_memmap;
> > -   memmap.phys_map = (void *)new_memmap_phy;
> > +   memmap.phys_map = new_memmap_phy;
> > memmap.nr_map = new_nr_map;
> > memmap.map_end = memmap.map + memmap.nr_map * memmap.desc_size;
> 
> Please guys, think for a change!
> 
> How is this supposed to work with:
> 
>include/linux/efi.h:void *phys_map;
> 
> ?

Ah, I take that back, now I see your patch 1/2 that changes it to phys_addr_t.

That's the right solution, and it also cleans up the code:

  Reviewed-by: Ingo Molnar 

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/

[PATCH v12 5/6] Documentation: dt-bindings: pci: altera pcie device tree binding

[Ley Foon Tan]

This patch adds the bindings for Altera PCIe host controller driver and
Altera PCIe MSI driver.

Signed-off-by: Ley Foon Tan 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/pci/altera-pcie-msi.txt| 28 +
 .../devicetree/bindings/pci/altera-pcie.txt| 49 ++
 2 files changed, 77 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/altera-pcie-msi.txt
 create mode 100644 Documentation/devicetree/bindings/pci/altera-pcie.txt

diff --git a/Documentation/devicetree/bindings/pci/altera-pcie-msi.txt 
b/Documentation/devicetree/bindings/pci/altera-pcie-msi.txt
new file mode 100644
index 000..09cd3bc
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/altera-pcie-msi.txt
@@ -0,0 +1,28 @@
+* Altera PCIe MSI controller
+
+Required properties:
+- compatible:  should contain "altr,msi-1.0"
+- reg: specifies the physical base address of the controller and
+   the length of the memory mapped region.
+- reg-names:   must include the following entries:
+   "csr": CSR registers
+   "vector_slave": vectors slave port region
+- interrupt-parent:interrupt source phandle.
+- interrupts:  specifies the interrupt source of the parent interrupt
+   controller. The format of the interrupt specifier depends on the
+   parent interrupt controller.
+- num-vectors: number of vectors, range 1 to 32.
+- msi-controller:  indicates that this is MSI controller node
+
+
+Example
+msi0: msi@0xFF20 {
+   compatible = "altr,msi-1.0";
+   reg = <0xFF20 0x0010
+   0xFF200010 0x0080>;
+   reg-names = "csr", "vector_slave";
+   interrupt-parent = <_0_arm_gic_0>;
+   interrupts = <0 42 4>;
+   msi-controller;
+   num-vectors = <32>;
+};
diff --git a/Documentation/devicetree/bindings/pci/altera-pcie.txt 
b/Documentation/devicetree/bindings/pci/altera-pcie.txt
new file mode 100644
index 000..2951a6a
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/altera-pcie.txt
@@ -0,0 +1,49 @@
+* Altera PCIe controller
+
+Required properties:
+- compatible : should contain "altr,pcie-root-port-1.0"
+- reg: a list of physical base address and length for TXS and CRA.
+- reg-names:   must include the following entries:
+   "Txs": TX slave port region
+   "Cra": Control register access region
+- interrupt-parent:interrupt source phandle.
+- interrupts:  specifies the interrupt source of the parent interrupt 
controller.
+   The format of the interrupt specifier depends on the parent 
interrupt
+   controller.
+- device_type: must be "pci"
+- #address-cells:  set to <3>
+- #size-cells: set to <2>
+- #interrupt-cells:set to <1>
+- ranges:  describes the translation of addresses for root ports 
and standard
+   PCI regions.
+- interrupt-map-mask and interrupt-map: standard PCI properties to define the
+   mapping of the PCIe interface to interrupt numbers.
+
+Optional properties:
+- msi-parent:  Link to the hardware entity that serves as the MSI controller 
for this PCIe
+   controller.
+- bus-range:   PCI bus numbers covered
+
+Example
+   pcie_0: pcie@0xc {
+   compatible = "altr,pcie-root-port-1.0";
+   reg = <0xc000 0x2000>,
+   <0xff22 0x4000>;
+   reg-names = "Txs", "Cra";
+   interrupt-parent = <_0_arm_gic_0>;
+   interrupts = <0 40 4>;
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   bus-range = <0x0 0xFF>;
+   device_type = "pci";
+   msi-parent = <_to_gic_gen_0>;
+   #address-cells = <3>;
+   #size-cells = <2>;
+   interrupt-map-mask = <0 0 0 7>;
+   interrupt-map = <0 0 0 1 _0 1>,
+   <0 0 0 2 _0 2>,
+   <0 0 0 3 _0 3>,
+   <0 0 0 4 _0 4>;
+   ranges = <0x8200 0x 0x 0xc000 
0x 0x1000
+   0x8200 0x 0x1000 0xd000 
0x 0x1000>;
+   };
-- 
1.8.2.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 v12 4/6] pci: altera: Add Altera PCIe MSI driver

[Ley Foon Tan]

This patch adds Altera PCIe MSI driver. This soft IP supports configurable
number of vectors, which is a dts parameter.

Signed-off-by: Ley Foon Tan 
Reviewed-by: Marc Zyngier 
---
 drivers/pci/host/Kconfig   |   8 +
 drivers/pci/host/Makefile  |   1 +
 drivers/pci/host/pcie-altera-msi.c | 314 +
 3 files changed, 323 insertions(+)
 create mode 100644 drivers/pci/host/pcie-altera-msi.c

diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index e569a64..b06c2d9 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -153,4 +153,12 @@ config PCIE_ALTERA
  Say Y here if you want to enable PCIe controller support on Altera
  FPGA.
 
+config PCIE_ALTERA_MSI
+   bool "Altera PCIe MSI feature"
+   depends on PCI_MSI
+   select PCI_MSI_IRQ_DOMAIN
+   help
+ Say Y here if you want PCIe MSI support for the Altera FPGA.
+ This MSI driver supports Altera MSI to GIC controller IP.
+
 endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 6954f76..6c4913d 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -18,3 +18,4 @@ obj-$(CONFIG_PCIE_IPROC) += pcie-iproc.o
 obj-$(CONFIG_PCIE_IPROC_PLATFORM) += pcie-iproc-platform.o
 obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
 obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
+obj-$(CONFIG_PCIE_ALTERA_MSI) += pcie-altera-msi.o
diff --git a/drivers/pci/host/pcie-altera-msi.c 
b/drivers/pci/host/pcie-altera-msi.c
new file mode 100644
index 000..367b462
--- /dev/null
+++ b/drivers/pci/host/pcie-altera-msi.c
@@ -0,0 +1,314 @@
+/*
+ * Copyright Altera Corporation (C) 2013-2015. All rights reserved
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MSI_STATUS 0x0
+#define MSI_ERROR  0x4
+#define MSI_INTMASK0x8
+
+#define MAX_MSI_VECTORS32
+
+struct altera_msi {
+   DECLARE_BITMAP(used, MAX_MSI_VECTORS);
+   struct mutexlock;   /* proctect used variable */
+   struct platform_device  *pdev;
+   struct irq_domain   *msi_domain;
+   struct irq_domain   *inner_domain;
+   void __iomem*csr_base;
+   void __iomem*vector_base;
+   phys_addr_t vector_phy;
+   u32 num_of_vectors;
+   int irq;
+};
+
+static inline void msi_writel(struct altera_msi *msi, const u32 value,
+ const u32 reg)
+{
+   writel_relaxed(value, msi->csr_base + reg);
+}
+
+static inline u32 msi_readl(struct altera_msi *msi, const u32 reg)
+{
+   return readl_relaxed(msi->csr_base + reg);
+}
+
+static void altera_msi_isr(struct irq_desc *desc)
+{
+   struct irq_chip *chip = irq_desc_get_chip(desc);
+   struct altera_msi *msi;
+   unsigned long status;
+   u32 num_of_vectors;
+   u32 bit;
+   u32 virq;
+
+   chained_irq_enter(chip, desc);
+   msi = irq_desc_get_handler_data(desc);
+   num_of_vectors = msi->num_of_vectors;
+
+   while ((status = msi_readl(msi, MSI_STATUS)) != 0) {
+   for_each_set_bit(bit, , msi->num_of_vectors) {
+   /* Dummy read from vector to clear the interrupt */
+   readl_relaxed(msi->vector_base + (bit * sizeof(u32)));
+
+   virq = irq_find_mapping(msi->inner_domain, bit);
+   if (virq)
+   generic_handle_irq(virq);
+   else
+   dev_err(>pdev->dev, "unexpected MSI\n");
+   }
+   }
+
+   chained_irq_exit(chip, desc);
+}
+
+static struct irq_chip altera_msi_irq_chip = {
+   .name = "Altera PCIe MSI",
+   .irq_mask = pci_msi_mask_irq,
+   .irq_unmask = pci_msi_unmask_irq,
+};
+
+static struct msi_domain_info altera_msi_domain_info = {
+   .flags  = (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
+MSI_FLAG_PCI_MSIX),
+   .chip   = _msi_irq_chip,
+};
+
+static void altera_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
+{
+   struct altera_msi *msi = irq_data_get_irq_chip_data(data);
+   phys_addr_t addr = msi->vector_phy + (data->hwirq * sizeof(u32));
+

[PATCH v12 6/6] MAINTAINERS: Add Altera PCIe and MSI drivers maintainer

[Ley Foon Tan]

Signed-off-by: Ley Foon Tan 
---
 MAINTAINERS | 16 
 1 file changed, 16 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index b8577ad9..96b9fac 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7958,6 +7958,14 @@ F:   include/linux/pci*
 F: arch/x86/pci/
 F: arch/x86/kernel/quirks.c
 
+PCI DRIVER FOR ALTERA PCIE IP
+M: Ley Foon Tan 
+L: r...@lists.rocketboards.org (moderated for non-subscribers)
+L: linux-...@vger.kernel.org
+S: Supported
+F: Documentation/devicetree/bindings/pci/altera-pcie.txt
+F: drivers/pci/host/pcie-altera.c
+
 PCI DRIVER FOR ARM VERSATILE PLATFORM
 M: Rob Herring 
 L: linux-...@vger.kernel.org
@@ -8059,6 +8067,14 @@ L:   linux-...@vger.kernel.org
 S: Maintained
 F: drivers/pci/host/*spear*
 
+PCI MSI DRIVER FOR ALTERA MSI IP
+M: Ley Foon Tan 
+L: r...@lists.rocketboards.org (moderated for non-subscribers)
+L: linux-...@vger.kernel.org
+S: Supported
+F: Documentation/devicetree/bindings/pci/altera-pcie-msi.txt
+F: drivers/pci/host/pcie-altera-msi.c
+
 PCI MSI DRIVER FOR APPLIEDMICRO XGENE
 M: Duc Dang 
 L: linux-...@vger.kernel.org
-- 
1.8.2.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 v12 0/6] Altera PCIe host controller driver with MSI support

[Ley Foon Tan]

This is the 12th version of patch set to add support for Altera PCIe host
controller with MSI feature on Altera FPGA device families. This patchset
mainly resovle the comments from Bjorn.


This patchset is based on v4.3-rc6.

v11->v12 changes:
- pcie-altera: use DECLARE_PCI_FIXUP_EARLY for pcie retrain fixup
- pcie-altera: move pcie_bus_configure_settings before pci_bus_add_devices
- pcie-altera: add %d for irq bit in dev_err()
- pcie-altera: prevent enumeration of root complex resources in config accessors
- Documentation: add Acked-by from Rob Herring

History:
---
[v1]: https://lkml.org/lkml/2015/7/28/395
[v2]: https://lkml.org/lkml/2015/7/31/267
[v3]: http://www.kernelhub.org/?msg=811940=2
[v4]: https://lkml.org/lkml/2015/8/17/141
[v5]: https://lkml.org/lkml/2015/8/25/238
[v6]: https://lkml.org/lkml/2015/9/1/177
[v7]: https://lkml.org/lkml/2015/9/20/193
[v8]: http://www.kernelhub.org/?msg=853553=2
[v9]: https://lkml.org/lkml/2015/10/13/998
[v10]: https://lkml.org/lkml/2015/10/19/139
[v11]: https://lkml.org/lkml/2015/10/22/206


Ley Foon Tan (6):
  arm: add msi.h to Kbuild
  pci: add Altera PCI vendor ID
  pci:host: Add Altera PCIe host controller driver
  pci: altera: Add Altera PCIe MSI driver
  Documentation: dt-bindings: pci: altera pcie device tree binding
  MAINTAINERS: Add Altera PCIe and MSI drivers maintainer

 .../devicetree/bindings/pci/altera-pcie-msi.txt|  28 +
 .../devicetree/bindings/pci/altera-pcie.txt|  49 ++
 MAINTAINERS|  16 +
 arch/arm/include/asm/Kbuild|   1 +
 drivers/pci/host/Kconfig   |  16 +
 drivers/pci/host/Makefile  |   2 +
 drivers/pci/host/pcie-altera-msi.c | 314 +++
 drivers/pci/host/pcie-altera.c | 580 +
 include/linux/pci_ids.h|   2 +
 9 files changed, 1008 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/altera-pcie-msi.txt
 create mode 100644 Documentation/devicetree/bindings/pci/altera-pcie.txt
 create mode 100644 drivers/pci/host/pcie-altera-msi.c
 create mode 100644 drivers/pci/host/pcie-altera.c

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