Re: [RFC PATCH 1/2] mm, vmscan: account the number of isolated pages per zone

[Michal Hocko]

On Wed 22-02-17 11:02:21, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > On Tue 21-02-17 23:35:07, Tetsuo Handa wrote:
> > > Michal Hocko wrote:
> > > > OK, so it seems that all the distractions are handled now and linux-next
> > > > should provide a reasonable base for testing. You said you weren't able
> > > > to reproduce the original long stalls on too_many_isolated(). I would be
> > > > still interested to see those oom reports and potential anomalies in the
> > > > isolated counts before I send the patch for inclusion so your further
> > > > testing would be more than appreciated. Also stalls > 10s without any
> > > > previous occurrences would be interesting.
> > > 
> > > I confirmed that linux-next-20170221 with kmallocwd applied can reproduce
> > > infinite too_many_isolated() loop problem. Please send your patches to 
> > > linux-next.
> > 
> > So I assume that you didn't see the lockup with the patch applied and
> > the OOM killer has resolved the situation by killing other tasks, right?
> > Can I assume your Tested-by?
> 
> No. I tested linux-next-20170221 which does not include your patch.
> I didn't test linux-next-20170221 with your patch applied. Your patch will
> avoid infinite too_many_isolated() loop problem in shrink_inactive_list().
> But we need to test different workloads by other people. Thus, I suggest
> you to send your patches to linux-next without my testing.

I will send the patch to Andrew later after merge window closes. It
would be really helpful, though, to see how it handles your workload
which is known to reproduce the oom starvation.
-- 
Michal Hocko
SUSE Labs

Re: [RFC 1/3] procfs: fdinfo -- Extend information about epoll target files

[Cyrill Gorcunov]

On Wed, Feb 22, 2017 at 10:44:07AM +0300, Pavel Emelyanov wrote:
> On 02/21/2017 10:16 PM, Cyrill Gorcunov wrote:
> > On Tue, Feb 21, 2017 at 10:41:12AM -0800, Andy Lutomirski wrote:
> >>> Thus lets add file position, inode and device number where
> >>> this target lays. This three fields can be used as a primary
> >>> key for sorting, and together with kcmp help CRIU can find
> >>> out an exact file target (from the whole set of processes
> >>> being checkpointed).
> >>
> >> I have no problem with this, but I'm wondering whether kcmp's ordered
> >> comparisons could also be used for this purpose.
> > 
> > Yes it can, but it would increas number of kcmp calls signisicantly.
> 
> Actually it shouldn't. If you extend the kcmp argument to accept the
> epollfd:epollslot pair, this would be effectively the same as if you
> had all your epoll-ed files injected into your fdtable with "strange"
> fd numbers. We already have two-level rbtree for this in criu, adding
> extended ("strange") fd to it should be OK.

Nope. Pavel, I guess you forget how we handle file tree in criu currently.
We call for kcmp only if we have to -- when primary key for two entries
is the same.

[PATCH] sched/fair: Update rq clock before changing a task's CPU affinity

[Wanpeng Li]

From: Wanpeng Li 

 [ cut here ]
 WARNING: CPU: 6 PID: 81 at kernel/sched/sched.h:812 set_next_entity+0x11d/0x380
 rq->clock_update_flags < RQCF_ACT_SKIP
 CPU: 6 PID: 81 Comm: torture_shuffle Not tainted 4.10.0+ #1
 Hardware name: LENOVO ThinkCentre M8500t-N000/SHARKBAY, BIOS FBKTC1AUS 
02/16/2016
 Call Trace:
  dump_stack+0x85/0xc2
  __warn+0xcb/0xf0
  warn_slowpath_fmt+0x5f/0x80
  set_next_entity+0x11d/0x380
  set_curr_task_fair+0x2b/0x60
  do_set_cpus_allowed+0x139/0x180
  __set_cpus_allowed_ptr+0x113/0x260
  set_cpus_allowed_ptr+0x10/0x20
  torture_shuffle+0xfd/0x180
  kthread+0x10f/0x150
  ? torture_shutdown_init+0x60/0x60
  ? kthread_create_on_node+0x60/0x60
  ret_from_fork+0x31/0x40
 ---[ end trace dd94d92344cea9c6 ]---

This is triggered during boot when CONFIG_SCHED_DEBUG is enabled. The 
task is running && !queued, so there is no rq clock update before calling 
set_curr_task.

This patch fixes it by updating rq clock after holding rq->lock/pi_lock 
just as what other dequeue + put_prev + enqueue + set_curr story does.

Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Matt Fleming 
Signed-off-by: Wanpeng Li 
---
 kernel/sched/core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 34e2291..2c51bdf 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1087,6 +1087,7 @@ static int __set_cpus_allowed_ptr(struct task_struct *p,
int ret = 0;
 
rq = task_rq_lock(p, &rf);
+   update_rq_clock(rq);
 
if (p->flags & PF_KTHREAD) {
/*
-- 
2.7.4

Re: [PATCH 1/2] Correct function definition for C++

[Joakim Tjernlund]

On Wed, 2017-02-22 at 08:10 +0100, Greg KH wrote:
> On Tue, Feb 21, 2017 at 04:24:04PM +0100, Joakim Tjernlund wrote:
> > C++ does does not like the extra extern before asmlinkage, remove it.
> > 
> > Signed-off-by: Joakim Tjernlund 
> > ---
> >  include/linux/printk.h | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/include/linux/printk.h b/include/linux/printk.h
> > index 3472cc6..be823f5 100644
> > --- a/include/linux/printk.h
> > +++ b/include/linux/printk.h
> 
> 
> Why are you building this file with a C++ compiler?

virtualbox uses C++ and includes various kernel headers and the build
fails, virtualbox guest additions has not build for quite some time now and
this is one of the problems.

> 
> Also, this is not the correct way to submit patches for inclusion in the
> stable kernel tree.  Please read Documentation/stable_kernel_rules.txt
> for how to do this properly.

Sorry, I was in a hurry(lazy:) so I just included stable directly as
I know it needs to be fixed in 4.9 as well.

 Jocke

[PATCH] net: realtek: 8139cp: use new api ethtool_{get|set}_link_ksettings

[Philippe Reynes]

The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.

As I don't have the hardware, I'd be very pleased if
someone may test this patch.

Signed-off-by: Philippe Reynes 
---
 drivers/net/ethernet/realtek/8139cp.c |   14 --
 1 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/realtek/8139cp.c 
b/drivers/net/ethernet/realtek/8139cp.c
index 672f6b6..72233ab 100644
--- a/drivers/net/ethernet/realtek/8139cp.c
+++ b/drivers/net/ethernet/realtek/8139cp.c
@@ -1406,27 +1406,29 @@ static int cp_get_sset_count (struct net_device *dev, 
int sset)
}
 }
 
-static int cp_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
+static int cp_get_link_ksettings(struct net_device *dev,
+struct ethtool_link_ksettings *cmd)
 {
struct cp_private *cp = netdev_priv(dev);
int rc;
unsigned long flags;
 
spin_lock_irqsave(&cp->lock, flags);
-   rc = mii_ethtool_gset(&cp->mii_if, cmd);
+   rc = mii_ethtool_get_link_ksettings(&cp->mii_if, cmd);
spin_unlock_irqrestore(&cp->lock, flags);
 
return rc;
 }
 
-static int cp_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
+static int cp_set_link_ksettings(struct net_device *dev,
+const struct ethtool_link_ksettings *cmd)
 {
struct cp_private *cp = netdev_priv(dev);
int rc;
unsigned long flags;
 
spin_lock_irqsave(&cp->lock, flags);
-   rc = mii_ethtool_sset(&cp->mii_if, cmd);
+   rc = mii_ethtool_set_link_ksettings(&cp->mii_if, cmd);
spin_unlock_irqrestore(&cp->lock, flags);
 
return rc;
@@ -1578,8 +1580,6 @@ static void cp_get_ethtool_stats (struct net_device *dev,
.get_drvinfo= cp_get_drvinfo,
.get_regs_len   = cp_get_regs_len,
.get_sset_count = cp_get_sset_count,
-   .get_settings   = cp_get_settings,
-   .set_settings   = cp_set_settings,
.nway_reset = cp_nway_reset,
.get_link   = ethtool_op_get_link,
.get_msglevel   = cp_get_msglevel,
@@ -1593,6 +1593,8 @@ static void cp_get_ethtool_stats (struct net_device *dev,
.get_eeprom = cp_get_eeprom,
.set_eeprom = cp_set_eeprom,
.get_ringparam  = cp_get_ringparam,
+   .get_link_ksettings = cp_get_link_ksettings,
+   .set_link_ksettings = cp_set_link_ksettings,
 };
 
 static int cp_ioctl (struct net_device *dev, struct ifreq *rq, int cmd)
-- 
1.7.4.4

[PATCH] drm: bridge: dw-hdmi: support i2c extended read mode

[Nickey Yang]

"I2C Master Interface Extended Read Mode" implements a segment
pointer-based read operation using the Special Register configuration.

This patch fix https://patchwork.kernel.org/patch/7098101/ mentioned
"The current implementation does not support "I2C Master Interface
Extended Read Mode" to read data addressed by non-zero segment
pointer, this means that if EDID has more than 1 extension blocks"

With this patch,dw-hdmi can read EDID data with 1/2/4 blocks.

Signed-off-by: Nickey Yang 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 38 --
 1 file changed, 24 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 9a9ec27..6ad7b87 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -33,6 +33,7 @@
 #include "dw-hdmi-audio.h"
 
 #define HDMI_EDID_LEN  512
+#define DDC_SEGMENT_ADDR   0x30
 
 #define RGB0
 #define YCBCR444   1
@@ -111,6 +112,7 @@ struct dw_hdmi_i2c {
 
u8  slave_reg;
boolis_regaddr;
+   boolis_segment;
 };
 
 struct dw_hdmi_phy_data {
@@ -258,8 +260,12 @@ static int dw_hdmi_i2c_read(struct dw_hdmi *hdmi,
reinit_completion(&i2c->cmp);
 
hdmi_writeb(hdmi, i2c->slave_reg++, HDMI_I2CM_ADDRESS);
-   hdmi_writeb(hdmi, HDMI_I2CM_OPERATION_READ,
-   HDMI_I2CM_OPERATION);
+   if (i2c->is_segment)
+   hdmi_writeb(hdmi, HDMI_I2CM_OPERATION_READ_EXT,
+   HDMI_I2CM_OPERATION);
+   else
+   hdmi_writeb(hdmi, HDMI_I2CM_OPERATION_READ,
+   HDMI_I2CM_OPERATION);
 
stat = wait_for_completion_timeout(&i2c->cmp, HZ / 10);
if (!stat)
@@ -271,6 +277,7 @@ static int dw_hdmi_i2c_read(struct dw_hdmi *hdmi,
 
*buf++ = hdmi_readb(hdmi, HDMI_I2CM_DATAI);
}
+   i2c->is_segment = false;
 
return 0;
 }
@@ -320,12 +327,6 @@ static int dw_hdmi_i2c_xfer(struct i2c_adapter *adap,
dev_dbg(hdmi->dev, "xfer: num: %d, addr: %#x\n", num, addr);
 
for (i = 0; i < num; i++) {
-   if (msgs[i].addr != addr) {
-   dev_warn(hdmi->dev,
-"unsupported transfer, changed slave 
address\n");
-   return -EOPNOTSUPP;
-   }
-
if (msgs[i].len == 0) {
dev_dbg(hdmi->dev,
"unsupported transfer %d/%d, no data\n",
@@ -345,15 +346,24 @@ static int dw_hdmi_i2c_xfer(struct i2c_adapter *adap,
/* Set slave device register address on transfer */
i2c->is_regaddr = false;
 
+   /* Set segment pointer for I2C extended read mode operation */
+   i2c->is_segment = false;
+
for (i = 0; i < num; i++) {
dev_dbg(hdmi->dev, "xfer: num: %d/%d, len: %d, flags: %#x\n",
i + 1, num, msgs[i].len, msgs[i].flags);
-
-   if (msgs[i].flags & I2C_M_RD)
-   ret = dw_hdmi_i2c_read(hdmi, msgs[i].buf, msgs[i].len);
-   else
-   ret = dw_hdmi_i2c_write(hdmi, msgs[i].buf, msgs[i].len);
-
+   if (msgs[i].addr == DDC_SEGMENT_ADDR && msgs[i].len == 1) {
+   i2c->is_segment = true;
+   hdmi_writeb(hdmi, DDC_SEGMENT_ADDR, HDMI_I2CM_SEGADDR);
+   hdmi_writeb(hdmi, *msgs[i].buf, HDMI_I2CM_SEGPTR);
+   } else {
+   if (msgs[i].flags & I2C_M_RD)
+   ret = dw_hdmi_i2c_read(hdmi, msgs[i].buf,
+  msgs[i].len);
+   else
+   ret = dw_hdmi_i2c_write(hdmi, msgs[i].buf,
+   msgs[i].len);
+   }
if (ret < 0)
break;
}
-- 
1.9.1

Re: [PATCH v5 10/10] landlock: Add user and kernel documentation for Landlock

[Mickaël Salaün]

On 22/02/2017 06:21, Andy Lutomirski wrote:
> On Tue, Feb 21, 2017 at 5:26 PM, Mickaël Salaün  wrote:
>> This documentation can be built with the Sphinx framework.
>>
>> Signed-off-by: Mickaël Salaün 
>> Cc: Alexei Starovoitov 
>> Cc: Andy Lutomirski 
>> Cc: Daniel Borkmann 
>> Cc: David S. Miller 
>> Cc: James Morris 
>> Cc: Jonathan Corbet 
>> Cc: Kees Cook 
>> Cc: Serge E. Hallyn 
> 
> 
>> +
>> +Writing a rule
>> +--
>> +
>> +To enforce a security policy, a thread first needs to create a Landlock 
>> rule.
>> +The easiest way to write an eBPF program depicting a security rule is to 
>> write
>> +it in the C language.  As described in *samples/bpf/README.rst*, LLVM can
>> +compile such programs.  Files *samples/bpf/landlock1_kern.c* and those in
>> +*tools/testing/selftests/landlock/rules/* can be used as examples.  The
>> +following example is a simple rule to forbid file creation, whatever syscall
>> +may be used (e.g. open, mkdir, link...).
>> +
>> +.. code-block:: c
>> +
>> +static int deny_file_creation(struct landlock_context *ctx)
>> +{
>> +if (ctx->arg2 & LANDLOCK_ACTION_FS_NEW)
>> +return 1;
>> +return 0;
>> +}
>> +
> 
> Would it make sense to define landlock_context (or at least a prefix
> thereof) in here?  Also, can't "arg2" have a better name?

arg2 is a generic name. Its meaning depends on the Landlock event, here
it is an action bitfield (FS event).

> 
> Can you specify what the return value means?  Are 0 and 1 the only
> choices?  Would "KILL" be useful?  How about "COREDUMP"?

This is explained thereafter and in the kernel Q&A section. I need to
briefly introduce that here.

> 
>> +File system action types
>> +
>> +
>> +Flags are used to express actions.  This makes it possible to compose 
>> actions
>> +and leaves room for future improvements to add more fine-grained action 
>> types.
>> +
>> +.. kernel-doc:: include/uapi/linux/bpf.h
>> +:doc: landlock_action_fs
>> +
>> +.. flat-table:: FS action types availability
>> +
>> +* - flags
>> +  - since
>> +
>> +* - LANDLOCK_ACTION_FS_EXEC
>> +  - v1
>> +
>> +* - LANDLOCK_ACTION_FS_WRITE
>> +  - v1
>> +
>> +* - LANDLOCK_ACTION_FS_READ
>> +  - v1
>> +
>> +* - LANDLOCK_ACTION_FS_NEW
>> +  - v1
>> +
>> +* - LANDLOCK_ACTION_FS_GET
>> +  - v1
>> +
>> +* - LANDLOCK_ACTION_FS_REMOVE
>> +  - v1
>> +
>> +* - LANDLOCK_ACTION_FS_IOCTL
>> +  - v1
>> +
>> +* - LANDLOCK_ACTION_FS_LOCK
>> +  - v1
>> +
>> +* - LANDLOCK_ACTION_FS_FCNTL
>> +  - v1
> 
> What happens if you run an old program on a new kernel?  Can you get
> unexpected action types?

The old flags will still make sense, the new ones should be ignored by
the rule.

> 
>> +
>> +
>> +Ability types
>> +-
>> +
>> +The ability of a Landlock rule describes the available features (i.e. 
>> context
>> +fields and helpers).  This is useful to abstract user-space privileges for
>> +Landlock rules, which may not need all abilities (e.g. debug).  Only the
>> +minimal set of abilities should be used (e.g. disable debug once in
>> +production).
>> +
>> +
>> +.. kernel-doc:: include/uapi/linux/bpf.h
>> +:doc: landlock_subtype_ability
>> +
>> +.. flat-table:: Ability types availability
>> +
>> +* - flags
>> +  - since
>> +  - capability
>> +
>> +* - LANDLOCK_SUBTYPE_ABILITY_WRITE
>> +  - v1
>> +  - CAP_SYS_ADMIN
>> +
>> +* - LANDLOCK_SUBTYPE_ABILITY_DEBUG
>> +  - v1
>> +  - CAP_SYS_ADMIN
>> +
> 
> What do "WRITE" and "DEBUG" mean in this context?  I'm totally lost.
> 
> Hmm.  Reading below, "WRITE" seems to mean "modify state".  Would that
> be accurate?

That is correct, but handling a state in a safe way imply more than only
the ability to "write" outside bpfland (e.g. sequential execution).

> 
>> +
>> +Helper functions
>> +
>> +
>> +See *include/uapi/linux/bpf.h* for functions documentation.
>> +
>> +.. flat-table:: Generic functions availability
>> +
> 
>> +
>> +* - bpf_get_current_comm
>> +  - v1
>> +  - LANDLOCK_SUBTYPE_ABILITY_DEBUG
> 
> What would this be used for?

To get more information about the process which trigger an action?

> 
>> +* - bpf_get_trace_printk
>> +  - v1
>> +  - LANDLOCK_SUBTYPE_ABILITY_DEBUG
>> +
> 
> This is different from the other DEBUG stuff in that it has side
> effects.  I wonder if it should have a different flag.

I think the debug flag is a clear warning to not ship a rule using this
ability. Maybe a sub-flag LANDLOCK_SUBTYPE_ABILITY_DEBUG_PRINT would fit
here?

 Mickaël



signature.asc
Description: OpenPGP digital signature

Re: [RFC 1/3] procfs: fdinfo -- Extend information about epoll target files

[Pavel Emelyanov]

On 02/21/2017 10:16 PM, Cyrill Gorcunov wrote:
> On Tue, Feb 21, 2017 at 10:41:12AM -0800, Andy Lutomirski wrote:
>>> Thus lets add file position, inode and device number where
>>> this target lays. This three fields can be used as a primary
>>> key for sorting, and together with kcmp help CRIU can find
>>> out an exact file target (from the whole set of processes
>>> being checkpointed).
>>
>> I have no problem with this, but I'm wondering whether kcmp's ordered
>> comparisons could also be used for this purpose.
> 
> Yes it can, but it would increas number of kcmp calls signisicantly.

Actually it shouldn't. If you extend the kcmp argument to accept the
epollfd:epollslot pair, this would be effectively the same as if you
had all your epoll-ed files injected into your fdtable with "strange"
fd numbers. We already have two-level rbtree for this in criu, adding
extended ("strange") fd to it should be OK.

> Look, here is how we build files tree in criu: we take inode^sdev^pos
> as a primary key and remember it inside rbtree while we're dumping files
> (note also that we don't keep files opened but rather dump them in
> chunks). Then once we find that two files have same primary key
> we use kcmp to build subtree. This really helps a lot. And I plan
> to do the same with target files from epolls:
> 
>  - they gonna be handled after all opened files of all processes
>in container (or children processes if dumping single task),
>thus the complete tree with primary key already will be built
> 
>  - on every target file I calculate primary key and then using
>kcmp will find if file is exactly one matching
> .
> 

Re: [PATCH] Add pidfs filesystem

[Pavel Emelyanov]

On 02/21/2017 05:57 PM, Oleg Nesterov wrote:
> On 02/18, Alexey Gladkov wrote:
>>
>> This patch allows to mount only the part of /proc related to pids
>> without rest objects. Since this is an addon to /proc, flags applied to
>> /proc have an effect on this pidfs filesystem.
> 
> I leave this to you and Eric, but imo it would be nice to avoid another
> filesystem.
> 
>> Why not implement it as another flag to /proc ?
>>
>> The /proc flags is stored in the pid_namespace and are global for
>> namespace. It means that if you add a flag to hide all except the pids,
>> then it will act on all mounted instances of /proc.
> 
> But perhaps we can use mnt_flags? For example, lets abuse MNT_NODEV, see
> the simple patch below. Not sure it is correct/complete, just to illustrate
> the idea.
> 
> With this patch you can mount proc with -onodev and it will only show
> pids/self/thread_self:
> 
>   # mkdir /tmp/D
>   # mount -t proc -o nodev none /tmp/D
>   # ls /tmp/D
>   1   11  13  15  17  19  20  22  24  28  3   31  33  4  56  7  9 
> thread-self
>   10  12  14  16  18  2   21  23  27  29  30  32  34  5  6   8  self
>   # cat /tmp/D/meminfo
>   cat: /tmp/D/meminfo: No such file or directory
>   # ls /tmp/D/irq
>   ls: cannot open directory /tmp/D/irq: No such file or directory
> 
> No?

Yes!!! If this whole effort with pidfs and overlayfs will move forward, I would
prefer seeing the nodev procfs version, rather than another fs.

As far as the overlayfs part is concerned, having an overlayfs mounted on /proc
inside container may result in problems as applications sometimes check for 
/proc
containing procfs (by checking statfs.f_type == PROC_SUPER_MAGIC or by reading
the /proc/mounts).

-- Pavel

> Oleg.
> 
> 
> --- a/fs/proc/generic.c
> +++ b/fs/proc/generic.c
> @@ -305,11 +305,22 @@ int proc_readdir_de(struct proc_dir_entry *de, struct 
> file *file,
>  
>  int proc_readdir(struct file *file, struct dir_context *ctx)
>  {
> + int mnt_flags = file->f_path.mnt->mnt_flags;
>   struct inode *inode = file_inode(file);
>  
> + if (mnt_flags & MNT_NODEV)
> + return 1;
> +
>   return proc_readdir_de(PDE(inode), file, ctx);
>  }
>  
> +static int proc_dir_open(struct inode *inode, struct file *file)
> +{
> + if (file->f_path.mnt->mnt_flags & MNT_NODEV)
> + return -ENOENT;
> + return 0;
> +}
> +
>  /*
>   * These are the generic /proc directory operations. They
>   * use the in-memory "struct proc_dir_entry" tree to parse
> @@ -319,6 +330,7 @@ static const struct file_operations proc_dir_operations = 
> {
>   .llseek = generic_file_llseek,
>   .read   = generic_read_dir,
>   .iterate_shared = proc_readdir,
> + .open   = proc_dir_open,
>  };
>  
>  /*
> --- a/fs/proc/inode.c
> +++ b/fs/proc/inode.c
> @@ -318,12 +318,16 @@ proc_reg_get_unmapped_area(struct file *file, unsigned 
> long orig_addr,
>  
>  static int proc_reg_open(struct inode *inode, struct file *file)
>  {
> + int mnt_flags = file->f_path.mnt->mnt_flags;
>   struct proc_dir_entry *pde = PDE(inode);
>   int rv = 0;
>   int (*open)(struct inode *, struct file *);
>   int (*release)(struct inode *, struct file *);
>   struct pde_opener *pdeo;
>  
> + if (mnt_flags & MNT_NODEV)
> + return -ENOENT;
> +
>   /*
>* Ensure that
>* 1) PDE's ->release hook will be called no matter what
> 
> .
> 

Re: crypto/cavium MSI-X fixups

[Christoph Hellwig]

On Tue, Feb 21, 2017 at 09:36:04AM -0800, David Daney wrote:
> With respect to pci_enable_msix(), what do you recommend as a replacement?  

pci_alloc_irq_vectors.  In fact I have a tree ready for after -rc1
that removes pci_enable_msix() entirely.

> For the crypto/cavium driver, you recommend pci_alloc_irq_vectors(), which 
> works well if the required MSI-X indexes are contiguous starting at zero.   
> What would be used for a device that has 184 MSI-X, but only a sparse 
> subset (fewer than half) of these are required for the driver operation.  
> It would waste system resources to use an API that forces us to allocate 
> 184 when only 80 are required.

Currently we don't have a good API for that.  I've not been through all
users of pci_enable_msix_{range,exact} yet, but so far I've only found
one user not using all vectors from 0 to some limit.  Depending how many
such users we have and how they'll look I will have to look into an API
to support that use case.

Re: [Outreachy kernel] [PATCH 2/7] staging: most: Using macro DIV_ROUND_UP

[Julia Lawall]

On Tue, 21 Feb 2017, SIMRAN SINGHAL wrote:

>
>
> On Wednesday, February 22, 2017 at 1:28:52 AM UTC+5:30, Julia Lawall wrote:
>
>
>   On Wed, 22 Feb 2017, simran singhal wrote:
>
>   > The macro DIV_ROUND_UP performs the computation (((n) + (d) -
>   1) /(d)).
>   > It clarifies the divisor calculations. This occurence was
>   detected using
>   > the coccinelle script:
>   >
>   > @@
>   > expression e1;
>   > expression e2;
>   > @@
>   > (
>   > - ((e1) + e2 - 1) / (e2)
>   > + DIV_ROUND_UP(e1,e2)
>   > |
>   > - ((e1) + (e2 - 1)) / (e2)
>   > + DIV_ROUND_UP(e1,e2)
>   > )
>
>
>   DIV_ROUND_UP is defined in kernel.h, which defines some other
>   generally
>   useful things.  Maybe there is an opportunity for making rules
>   from some
>   of them also.
>
>
> yes, for sure I will make other rules also, but do I have to include other
> rules in
> this patch only and resend v2.  

It was just a suggestion for future work, not a complaint about this patch
:)

julia

>
>
>   julia
>
>   >
>   > Signed-off-by: simran singhal 
>   > ---
>   >  drivers/staging/most/hdm-dim2/dim2_hal.c | 6 +++---
>   >  1 file changed, 3 insertions(+), 3 deletions(-)
>   >
>   > diff --git a/drivers/staging/most/hdm-dim2/dim2_hal.c
>   b/drivers/staging/most/hdm-dim2/dim2_hal.c
>   > index 0b9816c..6824826 100644
>   > --- a/drivers/staging/most/hdm-dim2/dim2_hal.c
>   > +++ b/drivers/staging/most/hdm-dim2/dim2_hal.c
>   > @@ -49,7 +49,7 @@
>   >  #define DBR_SIZE  (16 * 1024) /* specified by IP */
>   >  #define DBR_BLOCK_SIZE  (DBR_SIZE / 32 / DBR_MAP_SIZE)
>   >
>   > -#define ROUND_UP_TO(x, d)  (((x) + (d) - 1) / (d) * (d))
>   > +#define ROUND_UP_TO(x, d)  (DIV_ROUND_UP(x, (d)) * (d))
>   >
>   >  /*
>   
> --
>   */
>   >  /* generic helper functions and macros */
>   > @@ -117,7 +117,7 @@ static int alloc_dbr(u16 size)
>   >  return DBR_SIZE; /* out of memory */
>   >
>   >  for (i = 0; i < DBR_MAP_SIZE; i++) {
>   > -u32 const blocks = (size + DBR_BLOCK_SIZE -
>   1) / DBR_BLOCK_SIZE;
>   > +u32 const blocks = DIV_ROUND_UP(size,
>   DBR_BLOCK_SIZE);
>   >  u32 mask = ~((~(u32)0) << blocks);
>   >
>   >  do {
>   > @@ -137,7 +137,7 @@ static int alloc_dbr(u16 size)
>   >  static void free_dbr(int offs, int size)
>   >  {
>   >  int block_idx = offs / DBR_BLOCK_SIZE;
>   > -u32 const blocks = (size + DBR_BLOCK_SIZE - 1) /
>   DBR_BLOCK_SIZE;
>   > +u32 const blocks = DIV_ROUND_UP(size,
>   DBR_BLOCK_SIZE);
>   >  u32 mask = ~((~(u32)0) << blocks);
>   >
>   >  mask <<= block_idx % 32;
>   > --
>   > 2.7.4
>   >
>   > --
>   > You received this message because you are subscribed to the
>   Google Groups "outreachy-kernel" group.
>   > To unsubscribe from this group and stop receiving emails from
>   it, send an email to outreachy-kern...@googlegroups.com.
>   > To post to this group, send email to
>   outreach...@googlegroups.com.
>   > To view this discussion on the web 
> visithttps://groups.google.com/d/msgid/outreachy-kernel/20170221185615.GA25627%4
>   0singhal-Inspiron-5558.
>   > For more options, visit https://groups.google.com/d/optout.
>   >
>
> --
> You received this message because you are subscribed to the Google Groups
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web 
> visithttps://groups.google.com/d/msgid/outreachy-kernel/e9a638db-16fe-4e85-a132-
> c45c39307df1%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>

Re: [f2fs-dev] [PATCH 09/10] f2fs: avoid needless checkpoint in f2fs_trim_fs

[Chao Yu]

On 2016/12/31 2:51, Jaegeuk Kim wrote:
> The f2fs_trim_fs() doesn't need to do checkpoint if there are newly allocated
> data blocks only which didn't change the critical checkpoint data such as nat
> and sit entries.
> 
> Signed-off-by: Jaegeuk Kim 

Reviewed-by: Chao Yu 

Re: [f2fs-dev] [PATCH 10/10] f2fs: return fs_trim if there is no candidate

[Chao Yu]

On 2016/12/31 2:51, Jaegeuk Kim wrote:
> If there is no candidate to submit discard command during f2sf_trim_fs, let's
> return without checkpoint.
> 
> Signed-off-by: Jaegeuk Kim 

Reviewed-by: Chao Yu 

Please see comments below.

> ---
>  fs/f2fs/checkpoint.c |  5 +
>  fs/f2fs/f2fs.h   |  1 +
>  fs/f2fs/segment.c| 28 +++-
>  3 files changed, 29 insertions(+), 5 deletions(-)
> 
> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
> index 917b5c5053ae..ccea40763d9d 100644
> --- a/fs/f2fs/checkpoint.c
> +++ b/fs/f2fs/checkpoint.c
> @@ -1249,6 +1249,11 @@ int write_checkpoint(struct f2fs_sb_info *sbi, struct 
> cp_control *cpc)
>  
>   /* this is the case of multiple fstrims without any changes */
>   if (cpc->reason == CP_DISCARD) {
> + if (!exist_trim_candidates(sbi, cpc)) {
> + unblock_operations(sbi);
> + goto out;
> + }
> +
>   if (NM_I(sbi)->dirty_nat_cnt == 0 &&
>   SIT_I(sbi)->dirty_sentries == 0 &&
>   prefree_segments(sbi) == 0) {
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index f2f40fce9d31..04d113f0d6bf 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -2119,6 +2119,7 @@ void release_discard_addrs(struct f2fs_sb_info *);
>  int npages_for_summary_flush(struct f2fs_sb_info *, bool);
>  void allocate_new_segments(struct f2fs_sb_info *);
>  int f2fs_trim_fs(struct f2fs_sb_info *, struct fstrim_range *);
> +bool exist_trim_candidates(struct f2fs_sb_info *, struct cp_control *);
>  struct page *get_sum_page(struct f2fs_sb_info *, unsigned int);
>  void update_meta_page(struct f2fs_sb_info *, void *, block_t);
>  void write_meta_page(struct f2fs_sb_info *, struct page *);
> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> index 9a38424c3c1f..82078734f379 100644
> --- a/fs/f2fs/segment.c
> +++ b/fs/f2fs/segment.c
> @@ -836,7 +836,8 @@ static void __add_discard_entry(struct f2fs_sb_info *sbi,
>   SM_I(sbi)->nr_discards += end - start;
>  }
>  
> -static void add_discard_addrs(struct f2fs_sb_info *sbi, struct cp_control 
> *cpc)
> +static bool add_discard_addrs(struct f2fs_sb_info *sbi, struct cp_control 
> *cpc,
> + bool check_only)
>  {
>   int entries = SIT_VBLOCK_MAP_SIZE / sizeof(unsigned long);
>   int max_blocks = sbi->blocks_per_seg;
> @@ -850,12 +851,12 @@ static void add_discard_addrs(struct f2fs_sb_info *sbi, 
> struct cp_control *cpc)
>   int i;
>  
>   if (se->valid_blocks == max_blocks || !f2fs_discard_en(sbi))
> - return;
> + return false;
>  
>   if (!force) {
>   if (!test_opt(sbi, DISCARD) || !se->valid_blocks ||
>   SM_I(sbi)->nr_discards >= SM_I(sbi)->max_discards)
> - return;
> + return false;
>   }
>  
>   /* SIT_VBLOCK_MAP_SIZE should be multiple of sizeof(unsigned long) */
> @@ -873,8 +874,12 @@ static void add_discard_addrs(struct f2fs_sb_info *sbi, 
> struct cp_control *cpc)
>   && (end - start) < cpc->trim_minlen)
>   continue;
>  
> + if (check_only)
> + return true;
> +
>   __add_discard_entry(sbi, cpc, se, start, end);
>   }
> + return false;
>  }
>  
>  void release_discard_addrs(struct f2fs_sb_info *sbi)
> @@ -1455,6 +1460,19 @@ static const struct segment_allocation 
> default_salloc_ops = {
>   .allocate_segment = allocate_segment_by_default,
>  };
>  
> +bool exist_trim_candidates(struct f2fs_sb_info *sbi, struct cp_control *cpc)
> +{
> + __u64 trim_start = cpc->trim_start;

bool has_candidate = false;

> +
> + mutex_lock(&SIT_I(sbi)->sentry_lock);
> + for (; trim_start <= cpc->trim_end; trim_start++)
> + if (add_discard_addrs(sbi, cpc, true))
> + break;

for (; cpc->trim_start <= cpc->trim_end; cpc->trim_start++)
if (add_discard_addrs(sbi, cpc, true)) {
has_candidate = true;
break;
}

cpc->trim_start = trim_start;

> + mutex_unlock(&SIT_I(sbi)->sentry_lock);
> +
> + return trim_start <= cpc->trim_end;

return has_candidate;

Thanks,

> +}
> +
>  int f2fs_trim_fs(struct f2fs_sb_info *sbi, struct fstrim_range *range)
>  {
>   __u64 start = F2FS_BYTES_TO_BLK(range->start);
> @@ -2251,7 +2269,7 @@ void flush_sit_entries(struct f2fs_sb_info *sbi, struct 
> cp_control *cpc)
>   /* add discard candidates */
>   if (cpc->reason != CP_DISCARD) {
>   cpc->trim_start = segno;
> - add_discard_addrs(sbi, cpc);
> + add_discard_addrs(sbi, cpc, false);
>   }
>  
>   if (to_journal) {
> @@ -2289,7 +2307,7 @@ void flush_sit_entries(struct f2fs_s

Re: [f2fs-dev] [PATCH 08/10] f2fs: relax async discard commands more

[Chao Yu]

On 2017/1/6 10:42, Jaegeuk Kim wrote:
> Hi Chao,
> 
> On 01/06, Chao Yu wrote:
>> On 2017/1/6 3:46, Jaegeuk Kim wrote:
>>> On 01/05, Chao Yu wrote:
 On 2017/1/4 17:29, Chao Yu wrote:
> On 2016/12/31 2:51, Jaegeuk Kim wrote:
>> This patch relaxes async discard commands to avoid waiting its end_io 
>> during
>> checkpoint.
>> Instead of waiting them during checkpoint, it will be done when actually 
>> reusing
>> them.
>>
>> Test on initial partition of nvme drive.
>>
>>  # time fstrim /mnt/test
>>
>> Before : 6.158s
>> After : 4.822s
>>
>> Signed-off-by: Jaegeuk Kim 
>
> Reviewed-by: Chao Yu 
>
> One comment below,

 I still have a comment on this patch.

>> -void f2fs_wait_all_discard_bio(struct f2fs_sb_info *sbi)
>> +/* This should be covered by global mutex, &sit_i->sentry_lock */
>> +void f2fs_wait_discard_bio(struct f2fs_sb_info *sbi, unsigned int segno)
>>  {
>>  struct list_head *wait_list = &(SM_I(sbi)->wait_list);
>>  struct bio_entry *be, *tmp;
>> @@ -646,7 +650,15 @@ void f2fs_wait_all_discard_bio(struct f2fs_sb_info 
>> *sbi)
>>  struct bio *bio = be->bio;
>>  int err;
>>  
>> -wait_for_completion_io(&be->event);
>> +if (!completion_done(&be->event)) {
>> +if ((be->start_segno >= segno &&
>> +be->end_segno <= segno) ||
>
> segno >= be->start_segno && segno < be->end_segno ?
>>
>> Still can not understand this judgment condition, we should wait completion 
>> of
>> discard command only when segno is locate in range of [start_segno, 
>> end_segno]?
>>
>> But now, this condition can be true only when segno, start_segno, end_segno 
>> have
>> equal value.
>>
>> Please correct me if I'm wrong.
> 
> Urg. I rewrote it to use block addresses.
> 
> How about this?
> 
>>From fe24461eedd62815e0c56317f010a3a6e3004434 Mon Sep 17 00:00:00 2001
> From: Jaegeuk Kim 
> Date: Thu, 29 Dec 2016 14:07:53 -0800
> Subject: [PATCH] f2fs: relax async discard commands more
> 
> This patch relaxes async discard commands to avoid waiting its end_io during
> checkpoint.
> Instead of waiting them during checkpoint, it will be done when actually 
> reusing
> them.
> 
> Test on initial partition of nvme drive.
> 
>  # time fstrim /mnt/test
> 
> Before : 6.158s
> After : 4.822s

We should wait for completion of all discard IOs in fstrim, since we can't
guarantee discard command can be handled successfully by device after we return
success to caller. Right?

Thanks,

> 
> Reviewed-by: Chao Yu 
> Signed-off-by: Jaegeuk Kim 
> ---
>  fs/f2fs/checkpoint.c |  7 ++-
>  fs/f2fs/f2fs.h   |  4 +++-
>  fs/f2fs/segment.c| 23 +++
>  fs/f2fs/super.c  |  3 +++
>  4 files changed, 27 insertions(+), 10 deletions(-)
> 
> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
> index f73ee9534d83..1a9ba69a22ba 100644
> --- a/fs/f2fs/checkpoint.c
> +++ b/fs/f2fs/checkpoint.c
> @@ -1254,7 +1254,6 @@ int write_checkpoint(struct f2fs_sb_info *sbi, struct 
> cp_control *cpc)
>   f2fs_bug_on(sbi, prefree_segments(sbi));
>   flush_sit_entries(sbi, cpc);
>   clear_prefree_segments(sbi, cpc);
> - f2fs_wait_all_discard_bio(sbi);
>   unblock_operations(sbi);
>   goto out;
>   }
> @@ -1273,12 +1272,10 @@ int write_checkpoint(struct f2fs_sb_info *sbi, struct 
> cp_control *cpc)
>  
>   /* unlock all the fs_lock[] in do_checkpoint() */
>   err = do_checkpoint(sbi, cpc);
> - if (err) {
> + if (err)
>   release_discard_addrs(sbi);
> - } else {
> + else
>   clear_prefree_segments(sbi, cpc);
> - f2fs_wait_all_discard_bio(sbi);
> - }
>  
>   unblock_operations(sbi);
>   stat_inc_cp_count(sbi->stat_info);
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index bdcfe2a9b532..e0db895fd84c 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -183,6 +183,8 @@ struct discard_entry {
>  
>  struct bio_entry {
>   struct list_head list;
> + block_t lstart;
> + block_t len;
>   struct bio *bio;
>   struct completion event;
>   int error;
> @@ -2111,7 +2113,7 @@ void destroy_flush_cmd_control(struct f2fs_sb_info *, 
> bool);
>  void invalidate_blocks(struct f2fs_sb_info *, block_t);
>  bool is_checkpointed_data(struct f2fs_sb_info *, block_t);
>  void refresh_sit_entry(struct f2fs_sb_info *, block_t, block_t);
> -void f2fs_wait_all_discard_bio(struct f2fs_sb_info *);
> +void f2fs_wait_discard_bio(struct f2fs_sb_info *, block_t);
>  void clear_prefree_segments(struct f2fs_sb_info *, struct cp_control *);
>  void release_discard_addrs(struct f2fs_sb_info *);
>  int npages_for_summary_flush(struct f2fs_sb_info *, bool);
> diff --git a/fs/f2fs/segment.c b/fs/f2fs/seg

Re: [Outreachy kernel] [PATCH v3] staging: xgifb: function definition argument should also have an identifier name

[Julia Lawall]

On Wed, 22 Feb 2017, Arushi Singhal wrote:

> function definition argument like 'struct vb_device_info *','unsigned
> long' etc. should also have an identifier name.

Actually, this is not really clear.  The definition of a function is the
thing that has the actual code, like

int foo(int x) {
  return x;
}

What you are referring to is the prototype, ie

int foo(int);

What you want to say is that function prototypes should also have
parameter names.

>
> Signed-off-by: Arushi Singhal 
> ---
> Changes in v2:
>   - By mistake one irrelevant line was added which is removed in this
> patch.
>   - write the changes done in previous version in correct format.
> ---

The second --- is not needed.

julia

>  drivers/staging/xgifb/vb_setmode.h | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/staging/xgifb/vb_setmode.h 
> b/drivers/staging/xgifb/vb_setmode.h
> index 6f082a7a5a4a..c6317ab00474 100644
> --- a/drivers/staging/xgifb/vb_setmode.h
> +++ b/drivers/staging/xgifb/vb_setmode.h
> @@ -1,14 +1,14 @@
>  #ifndef _VBSETMODE_
>  #define _VBSETMODE_
>
> -void InitTo330Pointer(unsigned char, struct vb_device_info *);
> -void XGI_UnLockCRT2(struct vb_device_info *);
> -void XGI_LockCRT2(struct vb_device_info *);
> -void XGI_DisplayOff(struct xgifb_video_info *,
> - struct xgi_hw_device_info *,
> - struct vb_device_info *);
> -void XGI_GetVBType(struct vb_device_info *);
> -void XGI_SenseCRT1(struct vb_device_info *);
> +void InitTo330Pointer(unsigned char ChipType, struct vb_device_info 
> *pVBInfo);
> +void XGI_UnLockCRT2(struct vb_device_info *pVBInfo);
> +void XGI_LockCRT2(struct vb_device_info *pVBInfo);
> +void XGI_DisplayOff(struct xgifb_video_info *xgifb_info,
> + struct xgi_hw_device_info *pXGIHWDE,
> + struct vb_device_info *pVBInfo);
> +void XGI_GetVBType(struct vb_device_info *pVBInfo);
> +void XGI_SenseCRT1(struct vb_device_info *pVBInfo);
>  unsigned char XGISetModeNew(struct xgifb_video_info *xgifb_info,
>   struct xgi_hw_device_info *HwDeviceExtension,
>   unsigned short ModeNo);
> @@ -18,6 +18,6 @@ unsigned char XGI_SearchModeID(unsigned short ModeNo,
>  unsigned short XGI_GetRatePtrCRT2(struct xgi_hw_device_info *pXGIHWDE,
> unsigned short ModeNo,
> unsigned short ModeIdIndex,
> -   struct vb_device_info *);
> +   struct vb_device_info *pVBInfo);
>
>  #endif
> --
> 2.11.0
>
> --
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/20170222024823.GA25104%40arushi-HP-Pavilion-Notebook.
> For more options, visit https://groups.google.com/d/optout.
>

[PATCH-SPEAKUP 1/2] return same error value from spk_set_key_info

[Pranay Kr. Srivastava]

This patch makes spk_set_key_info return -EINVAL
in case of failure instead of returning 4 different
values for the type of error that occurred.

Print the offending values instead as debug message.

Signed-off-by: Pranay Kr. Srivastava 
---
 drivers/staging/speakup/main.c | 27 +++
 1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index c2f70ef..6667cf2 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -1216,13 +1216,19 @@ int spk_set_key_info(const u_char *key_info, u_char 
*k_buffer)
u_char ch, version, num_keys;
 
version = *cp++;
-   if (version != KEY_MAP_VER)
-   return -1;
+   if (version != KEY_MAP_VER) {
+   pr_debug("version found %d should be %d\n",
+version, KEY_MAP_VER);
+   return -EINVAL;
+   }
num_keys = *cp;
states = (int)cp[1];
key_data_len = (states + 1) * (num_keys + 1);
-   if (key_data_len + SHIFT_TBL_SIZE + 4 >= sizeof(spk_key_buf))
-   return -2;
+   if (key_data_len + SHIFT_TBL_SIZE + 4 >= sizeof(spk_key_buf)) {
+   pr_debug("too many key_infos (%d over %lu)\n",
+key_data_len + SHIFT_TBL_SIZE + 4, 
sizeof(spk_key_buf));
+   return -EINVAL;
+   }
memset(k_buffer, 0, SHIFT_TBL_SIZE);
memset(spk_our_keys, 0, sizeof(spk_our_keys));
spk_shift_table = k_buffer;
@@ -1233,14 +1239,19 @@ int spk_set_key_info(const u_char *key_info, u_char 
*k_buffer)
cp1 += 2;   /* now pointing at shift states */
for (i = 1; i <= states; i++) {
ch = *cp1++;
-   if (ch >= SHIFT_TBL_SIZE)
-   return -3;
+   if (ch >= SHIFT_TBL_SIZE) {
+   pr_debug("(%d) not valid shift state (max_allowed = 
%d)\n", ch,
+SHIFT_TBL_SIZE);
+   return -EINVAL;
+   }
spk_shift_table[ch] = i;
}
keymap_flags = *cp1++;
while ((ch = *cp1)) {
-   if (ch >= MAX_KEY)
-   return -4;
+   if (ch >= MAX_KEY) {
+   pr_debug("(%d), not valid key, (max_allowed = %d)\n", 
ch, MAX_KEY);
+   return -EINVAL;
+   }
spk_our_keys[ch] = cp1;
cp1 += states + 1;
}
-- 
2.10.2

[PATCH-SPEAKUP 2/2] remove unecessary initial allocation of vc

[Pranay Kr. Srivastava]

This patch removes the unnecessary allocation of
current foreground vc during initialization.

This initialization is already handled in the loop
that follows it for all available virtual consoles.

Also change the prototype of speakup_allocate to take
extra argument of gfp_* flags. Thus not requiring
GFP_ATOMIC during initialization.

Signed-off-by: Pranay Kr. Srivastava 
---
 drivers/staging/speakup/main.c | 19 ---
 1 file changed, 4 insertions(+), 15 deletions(-)

diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index 6667cf2..f81a936 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -1327,14 +1327,14 @@ static int edit_bits(struct vc_data *vc, u_char type, 
u_char ch, u_short key)
 }
 
 /* Allocation concurrency is protected by the console semaphore */
-static int speakup_allocate(struct vc_data *vc)
+static int speakup_allocate(struct vc_data *vc, gfp_t gfp_flags)
 {
int vc_num;
 
vc_num = vc->vc_num;
if (speakup_console[vc_num] == NULL) {
speakup_console[vc_num] = kzalloc(sizeof(*speakup_console[0]),
- GFP_ATOMIC);
+ gfp_flags);
if (speakup_console[vc_num] == NULL)
return -ENOMEM;
speakup_date(vc);
@@ -2257,7 +2257,7 @@ static int vt_notifier_call(struct notifier_block *nb,
switch (code) {
case VT_ALLOCATE:
if (vc->vc_mode == KD_TEXT)
-   speakup_allocate(vc);
+   speakup_allocate(vc, GFP_ATOMIC);
break;
case VT_DEALLOCATE:
speakup_deallocate(vc);
@@ -2317,7 +2317,6 @@ static int __init speakup_init(void)
 {
int i;
long err = 0;
-   struct st_spk_t *first_console;
struct vc_data *vc = vc_cons[fg_console].d;
struct var_t *var;
 
@@ -2342,18 +2341,9 @@ static int __init speakup_init(void)
if (err)
goto error_virtkeyboard;
 
-   first_console = kzalloc(sizeof(*first_console), GFP_KERNEL);
-   if (!first_console) {
-   err = -ENOMEM;
-   goto error_alloc;
-   }
-
-   speakup_console[vc->vc_num] = first_console;
-   speakup_date(vc);
-
for (i = 0; i < MAX_NR_CONSOLES; i++)
if (vc_cons[i].d) {
-   err = speakup_allocate(vc_cons[i].d);
+   err = speakup_allocate(vc_cons[i].d, GFP_KERNEL);
if (err)
goto error_kobjects;
}
@@ -2412,7 +2402,6 @@ static int __init speakup_init(void)
for (i = 0; i < MAX_NR_CONSOLES; i++)
kfree(speakup_console[i]);
 
-error_alloc:
speakup_remove_virtual_keyboard();
 
 error_virtkeyboard:
-- 
2.10.2

[no subject]

[Pranay Kr. Srivastava]

Sending both patches as series instead. Made the required changes as
suggessted in earlier versions and fixed the warnings reported from
kbuild test robot.

Re: [HMM v17 00/14] HMM (Heterogeneous Memory Management) v17

[Balbir Singh]

On Fri, Jan 27, 2017 at 05:52:07PM -0500, Jérôme Glisse wrote:
> Cliff note: HMM offers 2 things (each standing on its own). First
> it allows to use device memory transparently inside any process
> without any modifications to process program code. Second it allows
> to mirror process address space on a device.
> 
> Change since v16:
>   - move HMM unaddressable device memory to its own radix tree and
> thus find_dev_pagemap() will no longer return HMM dev_pagemap
>   - rename HMM migration helper (drop the prefix) and make them
> completely independent of HMM
> 
> Migration can now be use to implement thing like multi-threaded
> copy or make use of specific memory allocator for destination
> memory.
> 
> Work is under way to use this feature inside nouveau (the upstream
> open source driver for NVidia GPU) either 411 or 4.12 timeframe.
> But this patchset have been otherwise tested with the close source
> driver for NVidia GPU and thus we are confident it works and allow
> to use the hardware for seamless interaction between CPU and GPU
> in common address space of a process.
> 
> I also discussed the features with other company and i am confident
> it can be use on other, yet, unrelease hardware.
> 
> Please condiser applying for 4.11
>

Andrew, do we expect to get this in 4.11/4.12? Just curious.

Balbir Singh. 

Re: [Outreachy kernel] [PATCH] staging: wilc1000: renames struct tstrRSSI and its members u8Index, u8Full

[Julia Lawall]

On Tue, 21 Feb 2017, Tahia Khan wrote:

> Fixes multiple camel case checks on struct tstrRSSI from checkpatch.pl:
>
> Avoid CamelCase: 
> Avoid CamelCase: 
> Avoid CamelCase: 
>
> Signed-off-by: Tahia Khan 
> ---
>  drivers/staging/wilc1000/coreconfigurator.h   |  8 
>  drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 10 +-
>  2 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/staging/wilc1000/coreconfigurator.h 
> b/drivers/staging/wilc1000/coreconfigurator.h
> index cff1698..c9cf23b 100644
> --- a/drivers/staging/wilc1000/coreconfigurator.h
> +++ b/drivers/staging/wilc1000/coreconfigurator.h
> @@ -70,9 +70,9 @@ enum connect_status {
>   CONNECT_STS_FORCE_16_BIT = 0x
>  };
>
> -struct tstrRSSI {
> - u8 u8Full;
> - u8 u8Index;
> +struct tstr_RSSI {
> + u8 u8_full;
> + u8 u8_index;

The kernel doesn't use variable names that incorporate types.  These could
just be full and index.

julia

>   s8 as8RSSI[NUM_RSSI];
>  };
>
> @@ -93,7 +93,7 @@ struct network_info {
>   u8 *ies;
>   u16 ies_len;
>   void *join_params;
> - struct tstrRSSI str_rssi;
> + struct tstr_RSSI str_rssi;
>   u64 tsf_hi;
>  };
>
> diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c 
> b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> index f7ce47c..30285b9 100644
> --- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> +++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> @@ -205,8 +205,8 @@ static u32 get_rssi_avg(struct network_info *network_info)
>  {
>   u8 i;
>   int rssi_v = 0;
> - u8 num_rssi = (network_info->str_rssi.u8Full) ?
> -NUM_RSSI : (network_info->str_rssi.u8Index);
> + u8 num_rssi = (network_info->str_rssi.u8_full) ?
> +NUM_RSSI : (network_info->str_rssi.u8_index);
>
>   for (i = 0; i < num_rssi; i++)
>   rssi_v += network_info->str_rssi.as8RSSI[i];
> @@ -346,13 +346,13 @@ static void add_network_to_shadow(struct network_info 
> *pstrNetworkInfo,
>   } else {
>   ap_index = ap_found;
>   }
> - rssi_index = last_scanned_shadow[ap_index].str_rssi.u8Index;
> + rssi_index = last_scanned_shadow[ap_index].str_rssi.u8_index;
>   last_scanned_shadow[ap_index].str_rssi.as8RSSI[rssi_index++] = 
> pstrNetworkInfo->rssi;
>   if (rssi_index == NUM_RSSI) {
>   rssi_index = 0;
> - last_scanned_shadow[ap_index].str_rssi.u8Full = 1;
> + last_scanned_shadow[ap_index].str_rssi.u8_full = 1;
>   }
> - last_scanned_shadow[ap_index].str_rssi.u8Index = rssi_index;
> + last_scanned_shadow[ap_index].str_rssi.u8_index = rssi_index;
>   last_scanned_shadow[ap_index].rssi = pstrNetworkInfo->rssi;
>   last_scanned_shadow[ap_index].cap_info = pstrNetworkInfo->cap_info;
>   last_scanned_shadow[ap_index].ssid_len = pstrNetworkInfo->ssid_len;
> --
> 2.7.4
>
> --
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/20170222045543.GA27847%40coolbox.
> For more options, visit https://groups.google.com/d/optout.
>

Re: [PATCH v2 1/3] fpga: Add flag to indicate bitstream needs decrypting

[Greg Kroah-Hartman]

On Tue, Feb 21, 2017 at 12:26:17PM -0600, Alan Tull wrote:
> On Tue, Feb 21, 2017 at 10:35 AM, Alan Tull 
> 
> Hi Greg,
> 
> Would it be helpful for us to resend patches for you to take with you
> on cc?  Or is it enough that they are on lkml?

Yes, please send patches with your signed-off-by: for what I should
take.

thanks,

greg k-h

Re: [PATCH 1/2] Correct function definition for C++

[Greg KH]

On Tue, Feb 21, 2017 at 04:24:04PM +0100, Joakim Tjernlund wrote:
> C++ does does not like the extra extern before asmlinkage, remove it.
> 
> Signed-off-by: Joakim Tjernlund 
> ---
>  include/linux/printk.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/printk.h b/include/linux/printk.h
> index 3472cc6..be823f5 100644
> --- a/include/linux/printk.h
> +++ b/include/linux/printk.h


Why are you building this file with a C++ compiler?

Also, this is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read Documentation/stable_kernel_rules.txt
for how to do this properly.

thanks,

greg k-h

Re: [PATCH v3 2/2] drm/fb-helper: implement ioctl FBIO_WAITFORVSYNC

[Michel Dänzer]

On 21/02/17 07:00 PM, Stefan Lengfeld wrote:
> 
> 2/ Wait for a single vsync event on all active crtcs as Ville Syrjälä 
>described here [2] in the optimal implementation.

FWIW, this seems like a bad idea, since with multiple active CRTCs it
would make it essentially random at which intervals the ioctl returns,
and which CRTCs are in vertical blank when it does. So it would be
useless for both timing and tearing prevention purposes, i.e. more or
less completely useless.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

Re: [PATCH 1/3] mm, vmscan: fix zone balance check in prepare_kswapd_sleep

[Minchan Kim]

Hi,

On Wed, Feb 15, 2017 at 09:22:45AM +, Mel Gorman wrote:
> From: Shantanu Goel 
> 
> The check in prepare_kswapd_sleep needs to match the one in balance_pgdat
> since the latter will return as soon as any one of the zones in the
> classzone is above the watermark.  This is specially important for higher
> order allocations since balance_pgdat will typically reset the order to
> zero relying on compaction to create the higher order pages.  Without this
> patch, prepare_kswapd_sleep fails to wake up kcompactd since the zone
> balance check fails.
> 
> On 4.9.7 kswapd is failing to wake up kcompactd due to a mismatch in the
> zone balance check between balance_pgdat() and prepare_kswapd_sleep().
> balance_pgdat() returns as soon as a single zone satisfies the allocation
> but prepare_kswapd_sleep() requires all zones to do +the same.  This causes
> prepare_kswapd_sleep() to never succeed except in the order == 0 case and
> consequently, wakeup_kcompactd() is never called.  On my machine prior to
> apply this patch, the state of compaction from /proc/vmstat looked this
> way after a day and a half +of uptime:
> 
> compact_migrate_scanned 240496
> compact_free_scanned 76238632
> compact_isolated 123472
> compact_stall 1791
> compact_fail 29
> compact_success 1762
> compact_daemon_wake 0
> 
> After applying the patch and about 10 hours of uptime the state looks
> like this:
> 
> compact_migrate_scanned 59927299
> compact_free_scanned 2021075136
> compact_isolated 640926
> compact_stall 4
> compact_fail 2
> compact_success 2
> compact_daemon_wake 5160
> 
> Further notes from Mel that motivated him to pick this patch up and
> resend it;
> 
> It was observed for the simoop workload (pressures the VM similar to HADOOP)
> that kswapd was failing to keep ahead of direct reclaim. The investigation
> noted that there was a need to rationalise kswapd decisions to reclaim
> with kswapd decisions to sleep. With this patch on a 2-socket box, there
> was a 43% reduction in direct reclaim scanning.
> 
> However, the impact otherwise is extremely negative. Kswapd reclaim
> efficiency dropped from 98% to 76%. simoop has three latency-related
> metrics for read, write and allocation (an anonymous mmap and fault).
> 
>  4.10.0-rc74.10.0-rc7
>  mmots-20170209   fixcheck-v1
> Ameanp50-Read 22325202.49 (  0.00%) 20026926.55 ( 10.29%)
> Ameanp95-Read 26102988.80 (  0.00%) 27023360.00 ( -3.53%)
> Ameanp99-Read 30935176.53 (  0.00%) 30994432.00 ( -0.19%)
> Ameanp50-Write 976.44 (  0.00%) 1905.28 (-95.12%)
> Ameanp95-Write   15471.29 (  0.00%)36210.09 (-134.05%)
> Ameanp99-Write   35108.62 (  0.00%)   479494.96 (-1265.75%)
> Ameanp50-Allocation  76382.61 (  0.00%)87603.20 (-14.69%)
> Ameanp95-Allocation 12.39 (  0.00%)   244491.38 (-91.34%)
> Ameanp99-Allocation 187937.39 (  0.00%)  1745237.33 (-828.63%)
> 
> There are also more allocation stalls. One of the largest impacts was due
> to pages written back from kswapd context rising from 0 pages to 4516642
> pages during the hour the workload ran for. By and large, the patch has very
> bad behaviour but easily missed as the impact on a UMA machine is negligible.
> 
> This patch is included with the data in case a bisection leads to this area.
> This patch is also a pre-requisite for the rest of the series.
> 
> Signed-off-by: Shantanu Goel 
> Signed-off-by: Mel Gorman 

Hmm, I don't understand why we should bind wakeup_kcompactd to kswapd's
short sleep point where every eligible zones are balanced.
What's the correlation between them?

Can't we wake up kcompactd once we found a zone has enough free pages
above high watermark like this?

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 26c3b405ef34..f4f0ad0e9ede 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -3346,13 +3346,6 @@ static void kswapd_try_to_sleep(pg_data_t *pgdat, int 
alloc_order, int reclaim_o
 * that pages and compaction may succeed so reset the cache.
 */
reset_isolation_suitable(pgdat);
-
-   /*
-* We have freed the memory, now we should compact it to make
-* allocation of the requested order possible.
-*/
-   wakeup_kcompactd(pgdat, alloc_order, classzone_idx);
-
remaining = schedule_timeout(HZ/10);
 
/*
@@ -3451,6 +3444,14 @@ static int kswapd(void *p)
bool ret;
 
 kswapd_try_sleep:
+   /*
+* We have freed the memory, now we should compact it to make
+* allocation of the requested order possible.
+*/
+   if (alloc_order > 0 && zone_balanced(zone, reclaim_order,
+   classzone_idx))
+

Re: [PATCH] ALSA: emu10k1: Remove cast from memory allocation

[Takashi Iwai]

On Wed, 22 Feb 2017 07:47:16 +0100,
Tobin C. Harding wrote:
> 
> Coccinelle emits multiple WARNING: casting value returned by memory allocation
> function to (u_int32_t __user *) is useless.
> 
> Remove unnecessary cast.
> 
> Signed-off-by: Tobin C. Harding 

__user annotation requires the explicit cast.


Takashi


> ---
>  sound/pci/emu10k1/emufx.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/sound/pci/emu10k1/emufx.c b/sound/pci/emu10k1/emufx.c
> index 56fc47b..8a39a6f 100644
> --- a/sound/pci/emu10k1/emufx.c
> +++ b/sound/pci/emu10k1/emufx.c
> @@ -1186,8 +1186,8 @@ static int _snd_emu10k1_audigy_init_efx(struct 
> snd_emu10k1 *emu)
>   if (!icode)
>   return err;
>  
> - icode->gpr_map = (u_int32_t __user *) kcalloc(512 + 256 + 256 + 2 * 
> 1024,
> -   sizeof(u_int32_t), 
> GFP_KERNEL);
> + icode->gpr_map = kcalloc(512 + 256 + 256 + 2 * 1024,
> + sizeof(u_int32_t), GFP_KERNEL);
>   if (!icode->gpr_map)
>   goto __err_gpr;
>   controls = kcalloc(SND_EMU10K1_GPR_CONTROLS,
> @@ -1824,8 +1824,8 @@ static int _snd_emu10k1_init_efx(struct snd_emu10k1 
> *emu)
>   if (!icode)
>   return err;
>  
> - icode->gpr_map = (u_int32_t __user *) kcalloc(256 + 160 + 160 + 2 * 512,
> -   sizeof(u_int32_t), 
> GFP_KERNEL);
> + icode->gpr_map = kcalloc(256 + 160 + 160 + 2 * 512,
> + sizeof(u_int32_t), GFP_KERNEL);
>   if (!icode->gpr_map)
>   goto __err_gpr;
>  
> -- 
> 2.7.4
> 
> 

Re: [PATCH] net/dccp: fix use after free in tw_timer_handler()

[Dmitry Vyukov]

On Tue, Feb 21, 2017 at 2:56 PM, Dmitry Vyukov  wrote:
> On Tue, Feb 21, 2017 at 2:27 PM, Andrey Ryabinin
>  wrote:
>> DCCP doesn't purge timewait sockets on network namespace shutdown.
>> So, after net namespace destroyed we could still have an active timer
>> which will trigger use after free in tw_timer_handler():
>>
>> BUG: KASAN: use-after-free in tw_timer_handler+0x4a/0xa0 at addr 
>> 88010e0d1e10
>> Read of size 8 by task swapper/1/0
>> Call Trace:
>>  __asan_load8+0x54/0x90
>>  tw_timer_handler+0x4a/0xa0
>>  call_timer_fn+0x127/0x480
>>  expire_timers+0x1db/0x2e0
>>  run_timer_softirq+0x12f/0x2a0
>>  __do_softirq+0x105/0x5b4
>>  irq_exit+0xdd/0xf0
>>  smp_apic_timer_interrupt+0x57/0x70
>>  apic_timer_interrupt+0x90/0xa0
>>
>> Object at 88010e0d1bc0, in cache net_namespace size: 6848
>> Allocated:
>>  save_stack_trace+0x1b/0x20
>>  kasan_kmalloc+0xee/0x180
>>  kasan_slab_alloc+0x12/0x20
>>  kmem_cache_alloc+0x134/0x310
>>  copy_net_ns+0x8d/0x280
>>  create_new_namespaces+0x23f/0x340
>>  unshare_nsproxy_namespaces+0x75/0xf0
>>  SyS_unshare+0x299/0x4f0
>>  entry_SYSCALL_64_fastpath+0x18/0xad
>> Freed:
>>  save_stack_trace+0x1b/0x20
>>  kasan_slab_free+0xae/0x180
>>  kmem_cache_free+0xb4/0x350
>>  net_drop_ns+0x3f/0x50
>>  cleanup_net+0x3df/0x450
>>  process_one_work+0x419/0xbb0
>>  worker_thread+0x92/0x850
>>  kthread+0x192/0x1e0
>>  ret_from_fork+0x2e/0x40
>>
>> Add .exit_batch hook to dccp_v4_ops()/dccp_v6_ops() which will purge
>> timewait sockets on net namespace destruction and prevent above issue.
>
>
> Aha! Thanks for tracking this down!
>
> Queued the patch on syzkaller bots, should have the verdict in several hours.

I do not see the crash happening after applying the patch.

[PATCH] ALSA: emu10k1: Remove cast from memory allocation

[Tobin C. Harding]

Coccinelle emits multiple WARNING: casting value returned by memory allocation
function to (u_int32_t __user *) is useless.

Remove unnecessary cast.

Signed-off-by: Tobin C. Harding 
---
 sound/pci/emu10k1/emufx.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/sound/pci/emu10k1/emufx.c b/sound/pci/emu10k1/emufx.c
index 56fc47b..8a39a6f 100644
--- a/sound/pci/emu10k1/emufx.c
+++ b/sound/pci/emu10k1/emufx.c
@@ -1186,8 +1186,8 @@ static int _snd_emu10k1_audigy_init_efx(struct 
snd_emu10k1 *emu)
if (!icode)
return err;
 
-   icode->gpr_map = (u_int32_t __user *) kcalloc(512 + 256 + 256 + 2 * 
1024,
- sizeof(u_int32_t), 
GFP_KERNEL);
+   icode->gpr_map = kcalloc(512 + 256 + 256 + 2 * 1024,
+   sizeof(u_int32_t), GFP_KERNEL);
if (!icode->gpr_map)
goto __err_gpr;
controls = kcalloc(SND_EMU10K1_GPR_CONTROLS,
@@ -1824,8 +1824,8 @@ static int _snd_emu10k1_init_efx(struct snd_emu10k1 *emu)
if (!icode)
return err;
 
-   icode->gpr_map = (u_int32_t __user *) kcalloc(256 + 160 + 160 + 2 * 512,
- sizeof(u_int32_t), 
GFP_KERNEL);
+   icode->gpr_map = kcalloc(256 + 160 + 160 + 2 * 512,
+   sizeof(u_int32_t), GFP_KERNEL);
if (!icode->gpr_map)
goto __err_gpr;
 
-- 
2.7.4

[PATCH] proc: Remove cast from memory allocation

[Tobin C. Harding]

Coccinelle emits WARNING: casting value returned by memory allocation
function to (struct proc_inode *) is useless.

Remove unnecessary cast.

Signed-off-by: Tobin C. Harding 
---
 fs/proc/inode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/proc/inode.c b/fs/proc/inode.c
index 842a5ff..1eb2326 100644
--- a/fs/proc/inode.c
+++ b/fs/proc/inode.c
@@ -57,7 +57,7 @@ static struct inode *proc_alloc_inode(struct super_block *sb)
struct proc_inode *ei;
struct inode *inode;
 
-   ei = (struct proc_inode *)kmem_cache_alloc(proc_inode_cachep, 
GFP_KERNEL);
+   ei = kmem_cache_alloc(proc_inode_cachep, GFP_KERNEL);
if (!ei)
return NULL;
ei->pid = NULL;
-- 
2.7.4

[GIT PULL] s390 patches for 4.11 merge window #1

[Martin Schwidefsky]

Hi Linus,

please pull from the 'for-linus' branch of

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

to receive the following updates:
--
The first part of the s390 update for 4.11. Changes included:

* New entropy generation for the pseudo random number generator.

* Early boot printk output via sclp to help debug crashes on boot.
  This needs to be enabled with a kernel parameter.

* Add proper no-execute support with a bit in the page table entry.

* Bug fixes and cleanups.
--

A small fixup is needed for the merge conflict in arch/s390/Kconfig.debug:

diff --git a/arch/s390/Kconfig.debug b/arch/s390/Kconfig.debug
index 8564bd0..ba5f878 100644
--- a/arch/s390/Kconfig.debug
+++ b/arch/s390/Kconfig.debug
@@ -17,14 +17,7 @@ config S390_PTDUMP
  kernel.
  If in doubt, say "N"
 
-<<< HEAD
-config DEBUG_SET_MODULE_RONX
-   def_bool y
-   depends on MODULES
-
 config EARLY_PRINTK
def_bool y
 
-===
->>> master
 endmenu

The Shortlog:

Christian Borntraeger (1):
  s390: replace ACCESS_ONCE with READ_ONCE

Corentin Labbe (1):
  s390/zcore: remove unneeded linux/miscdevice.h include

Daniel Borkmann (1):
  s390/bpf: remove redundant check for non-null image

Gerald Schaefer (1):
  s390/dcssblk: fix device size calculation in dcssblk_direct_access()

Harald Freudenberger (4):
  s390/crypto: Extend key length check for AES-XTS in fips mode.
  s390/prng: Adjust generation of entropy to produce real 256 bits.
  s390/zcrypt: use spin_lock_bh for all queue locks and unlocks.
  s390/zcrypt: Removed unneeded debug feature directory creation.

Heiko Carstens (27):
  s390/cpumf: get rid of variable length array
  s390/lib: improve memmove, memset and memcpy
  s390/cio: get rid of variable length array
  s390/zcrypt: make structures static
  s390/zcrypt: get rid of variable length arrays
  s390: proper type casts for csum_partial invocations
  s390/setup: call memblock_reserve only for size > 0
  s390/mem_detect: add debugging output
  s390/mem_detect: fix memory type of first block
  s390/topology: reduce number of printks
  s390: remove couple of unneeded semicolons
  s390: use false/true when using bool
  s390/topology: make "topology=off" parameter work
  s390/sclp: make early sclp irq handler more robust
  s390/sclp: always stay within bounds of the early sccb
  s390: provide sclp based boot console
  s390: make setup_randomness work
  s390/sclp: move early printk code to drivers
  s390/sclp: disable early sclp code as soon as the base sclp driver is 
active
  s390/sclp: make early sclp code readable
  s390/sclp: don't add new lines to each printed string
  s390/sclp: get rid of common response code handling
  s390: use correct input data address for setup_randomness
  s390/mm: make memory_block_size_bytes available for !MEMORY_HOTPLUG
  s390: get rid of MACHINE_HAS_PFMF and MACHINE_HAS_HPAGE
  s390/mm: add cond_resched call to kernel page table dumper
  s390: add missing "do {} while (0)" loop constructs to multiline macros

Jan Höppner (2):
  s390/dasd: Always store parameter elements in an array
  s390/dasd: Improve parameter list parsing

Julian Wiedmann (4):
  s390/qdio: clear DSCI prior to scanning multiple input queues
  s390/qdio: clean up q->irq_ptr usage
  s390/qdio: fix up tiqdio_thinint_handler() kerneldoc
  s390/qdio: improve some debug prints

Martin Schwidefsky (6):
  s390: store breaking event address only for program checks
  s390/topology: correct allocation of topology information
  s390/debug: make debug event time stamps relative to the boot TOD clock
  s390: report new vector facilities
  s390: add no-execute support
  s390/syscall: fix single stepped system calls

Matthew Rosato (1):
  s390/crypto: Check des3_ede keys for uniqueness in fips mode

Michael Holzheu (1):
  s390/kdump: Use "LINUX" ELF note name instead of "CORE"

Paul Gortmaker (4):
  s390: kernel: Audit and remove any unnecessary uses of module.h
  s390: mm: Audit and remove any unnecessary uses of module.h
  s390: Audit and remove any remaining unnecessary uses of module.h
  s390/zcrypt: make ap_bus explicitly non-modular

Sebastian Ott (8):
  s390/cio: clarify cssid usage
  s390/cio: use cssid for pgid generation
  s390/cio: css attribute cleanup
  s390/cio: css initialization cleanup
  s390/cio: export real cssid
  s390/cio: remove unused struct member
  s390/pci: use proper endianness annotations
  s390/cio: remove cmf related code relevant for 31 bit only

Stefan Haberland (4):
  s390/dasd: allow 0 for path_threshold attribute
  s390/dasd: check for device error pointer within state change interrupts
  s390/dasd: check blockdevice pointer before trying to sync blockdevice
  s390/dasd: correct incon

Re: linux-next: manual merge of the kspp tree with the net-next tree

[Daniel Borkmann]

On 02/22/2017 12:51 AM, Stephen Rothwell wrote:

Hi Kees,

Today's linux-next merge of the kspp tree got a conflict in:

   arch/arm/Kconfig

between commit:

   d2852a224050 ("arch: add ARCH_HAS_SET_MEMORY config")

from the net-next tree and commit:

   ad21fc4faa2a ("arch: Move CONFIG_DEBUG_RODATA and CONFIG_SET_MODULE_RONX to be 
common")

from the kspp tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.


Also looks good to me.

[PATCH] fs/9p: Remove cast from memory allocation

[Tobin C. Harding]

Coccinelle emits WARNING: casting value returned by memory allocation
function to (struct v9fs_inode *) is useless.

Remove unnecessary cast.

Signed-off-by: Tobin C. Harding 
---
 fs/9p/vfs_inode.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/fs/9p/vfs_inode.c b/fs/9p/vfs_inode.c
index f4f4450..462e9e4 100644
--- a/fs/9p/vfs_inode.c
+++ b/fs/9p/vfs_inode.c
@@ -238,8 +238,7 @@ v9fs_blank_wstat(struct p9_wstat *wstat)
 struct inode *v9fs_alloc_inode(struct super_block *sb)
 {
struct v9fs_inode *v9inode;
-   v9inode = (struct v9fs_inode *)kmem_cache_alloc(v9fs_inode_cache,
-   GFP_KERNEL);
+   v9inode = kmem_cache_alloc(v9fs_inode_cache, GFP_KERNEL);
if (!v9inode)
return NULL;
 #ifdef CONFIG_9P_FSCACHE
-- 
2.7.4

Re: linux-next: manual merge of the net-next tree with the s390 tree

[Daniel Borkmann]

On 02/22/2017 12:15 AM, Stephen Rothwell wrote:

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

   arch/s390/net/bpf_jit_comp.c

between commit:

   9437964885f8 ("s390/bpf: remove redundant check for non-null image")

from the s390 tree and commit:

   9d876e79df6a ("bpf: fix unlocking of jited image when module ronx not set")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.


Looks good, thanks!

Re: linux-next: manual merge of the kspp tree with the net-next tree

[Daniel Borkmann]

On 02/22/2017 01:06 AM, Stephen Rothwell wrote:

Hi all,

Today's linux-next merge of the kspp tree got a conflict in:

   include/linux/filter.h

between commit:

   9d876e79df6a ("bpf: fix unlocking of jited image when module ronx not set")

from the net-next tree and commit:

   0f5bf6d0afe4 ("arch: Rename CONFIG_DEBUG_RODATA and 
CONFIG_DEBUG_MODULE_RONX")

from the kspp tree.

Hmmm, both these change the ifdef guards I have used the one from the
net-next tree (CONFIG_ARCH_HAS_SET_MEMORY) for today, please let me know
if that is not correct.


That's fine, thanks!

[PATCH] ncpfs: Remove cast from memory allocation

[Tobin C. Harding]

Coccinelle emits WARNING: casting value returned by memory allocation
function to (struct ncp_inode_info *) is useless.

Remove unnecessary cast.

Signed-off-by: Tobin C. Harding 
---
 fs/ncpfs/inode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/ncpfs/inode.c b/fs/ncpfs/inode.c
index 7eb89c2..a1b8e7a 100644
--- a/fs/ncpfs/inode.c
+++ b/fs/ncpfs/inode.c
@@ -52,7 +52,7 @@ static struct kmem_cache * ncp_inode_cachep;
 static struct inode *ncp_alloc_inode(struct super_block *sb)
 {
struct ncp_inode_info *ei;
-   ei = (struct ncp_inode_info *)kmem_cache_alloc(ncp_inode_cachep, 
GFP_KERNEL);
+   ei = lkmem_cache_alloc(ncp_inode_cachep, GFP_KERNEL);
if (!ei)
return NULL;
return &ei->vfs_inode;
-- 
2.7.4

Re: [PATCH v3 13/18] power: supply: add battery driver for AXP20X and AXP22X PMICs

[Chen-Yu Tsai]

Hi,

On Wed, Feb 22, 2017 at 2:19 AM, Quentin Schulz
 wrote:
> Hi Chen-Yu,
>
> On 21/02/2017 05:44, Chen-Yu Tsai wrote:
>> On Tue, Feb 14, 2017 at 5:41 PM, Quentin Schulz
>>  wrote:
>>> The X-Powers AXP20X and AXP22X PMICs can have a battery as power supply.
>>>
>>> This patch adds the battery power supply driver to get various data from
>>> the PMIC, such as the battery status (charging, discharging, full,
>>> dead), current max limit, current current, battery capacity (in
>>> percentage), voltage max and min limits, current voltage and battery
>>> capacity (in Ah).
>>>
>>> This battery driver uses the AXP20X/AXP22X ADC driver as PMIC data
>>> provider.
>>>
>>> Signed-off-by: Quentin Schulz 
>>> Acked-by: Jonathan Cameron 
>>> Acked-by: Maxime Ripard 
> [...]
>>> +static int axp20x_set_constant_charge_current(struct axp20x_batt_ps 
>>> *axp_batt,
>>> + int charge_current)
>>> +{
>>> +   if (axp_batt->axp_id == AXP209_ID)
>>> +   charge_current = (charge_current - 30) / 10;
>>> +   else
>>> +   charge_current = (charge_current - 30) / 15;
>>> +
>>> +   if (charge_current > AXP20X_CHRG_CTRL1_TGT_CURR || charge_current < 
>>> 0)
>>> +   return -EINVAL;
>>
>> I would add a check or warn if the value to be programmed exceeds that 
>> returned
>> by power_supply_get_battery_info.
>
> Completely agree on a warning.
>
>> A charge current exceeding the limits of the
>> battery is potentially disastrous. The battery may be destroyed or even burst
>> into flames and explode, taking the board and anything nearby with it. 
>> Otherwise
>>
>
> Yes, I understand. Maybe I'm seeing this ability to set the (max)
> constant current charge the wrong way. Here is what I think:
> If we limit the max constant charge current with a DT property, it would
> require a DT rebuild when changing the battery (i.e. if an end-user
> decides to change the battery with a bigger constant charge current, he
> has to recompile the DT to change the DT value).

I guess this mostly applies for development boards.

Swapping out the battery would also affect design capacity, which may be
exported to userspace via the power supply / fuel gauge device? What then?

> What I can suggest is the following:
>  - set the max constant charge current and the default constant charge
> current from the DT property,

OK.

>  - allow the user to change the constant charge current via sysfs within
> minimal-DT value range,

You mean the "current" max constant charge current known to the driver, right?

>  - allow the user to set max constant charge current via sysfs (and
> print a warning as well when setting it), then the user can set a higher
> constant charge current,
>
> That would require a two steps modification with a printed warning.
> "Safer" but does not remove the ability to change the constant charge
> current in the case of battery swapping/changing.

Yeah that sounds like a good proposal. If you want to be really safe,
you could make the option to override the maximum a sysfs option? It
is possible warning messages aren't immediately noticed, such as when
the user is running X.

Reminds me of the anti foot-shooting option in FreeBSD.

Regards
ChenYu


>> Acked-by: Chen-Yu Tsai 
>>
>> Speaking of power_supply_get_battery_info, is it merged or ready to be 
>> merged?
>>
>
> v7 under way IIRC.
>
> Thanks,
> Quentin
>
> --
> Quentin Schulz, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt

[Binoy Jayan]

Hi Herbert,

On 8 February 2017 at 13:02, Gilad Ben-Yossef  wrote:
> On Tue, Feb 7, 2017 at 12:35 PM, Binoy Jayan  wrote:
>> ===
>> dm-crypt optimization for larger block sizes
>> ===
>>
>> Currently, the iv generation algorithms are implemented in dm-crypt.c. The 
>> goal
>> is to move these algorithms from the dm layer to the kernel crypto layer by
>> implementing them as template ciphers so they can be used in relation with
>> algorithms like aes, and with multiple modes like cbc, ecb etc. As part of 
>> this
>> patchset, the iv-generation code is moved from the dm layer to the crypto 
>> layer
>> and adapt the dm-layer to send a whole 'bio' (as defined in the block layer)
>> at a time. Each bio contains the in memory representation of physically
>> contiguous disk blocks. Since the bio itself may not be contiguous in main
>> memory, the dm layer sets up a chained scatterlist of these blocks split into
>> physically contiguous segments in memory so that DMA can be performed.

> Ran Bonnie++ on it last night  (Luks mode, plain64, Qemu Virt platform
> Arm64) and it works just fine.
>
> Tested-by: Gilad Ben-Yossef 

I was wondering if this is near to be ready for submission (apart from
the testmgr.c
changes) or I need to make some changes to make it similar to the IPSec offload?

Thanks,
Binoy

Re: [RFC 7/8] fpga-region: add sysfs interface

[Moritz Fischer]

On Tue, Feb 21, 2017 at 9:46 PM, Nadathur, Sundar
 wrote:
> On February 21, 2017 9:39 PM, Moritz Fischer wrote:
>
>> TLV Seems easy enough. To give an update, I played with fdt a bit to see how
>> far I get in half an hour. I got bool / int / strings to work quite fast 
>> (~30mins).
>> Please disregard the horrible hackyness of this ...
>> [...]
>> So I'm fairly convinced I can make this work, TVLs seem like it could work,
>> too.
>>
>> > So far the only thing we know we need is a 'bool' for encrypted and a
>> > stringish guid thing for partial reconfiguration.
>
> These things have a way of growing beyond their original anticipated needs.

True. But yeah, not sure about the requirement for a tree, maybe it is overkill.

> Say we upstream a metadata parser. Subsequently, an FPGA image is released 
> with an additional metadata field that the upstreamed version does not 
> handle. How will this be handled if the metadata were in FDT or KVP format?

The code above will gently ignore it, as I said I spent about half an hour on
writing that, just to prove to myself it can be done easily.
Logically I don't see anything wrong with ignoring features from the future.
But if one insisted one could make a compatibility number part of the
required properties I suppose and error out instead. There are examples
of optional properties in the devicetree parsing code in the kernel.

That being said older drivers / fpga-mgr  will not deal with newer features.
TLV / KV or whatever doesn't change this fact, or am I missing something?

Adding new properties to devicetrees is a well known exercise to cope with
newer versions or variations of hardware and happens all the time in the kernel.
Older kernels will just ignore them.

Thanks,

Moritz

Re: [PATCH 2/4] ARM: dts: da850: add vpif video display pins

[Sekhar Nori]

On Tuesday 21 February 2017 02:53 PM, Bartosz Golaszewski wrote:
> 2017-02-21 5:49 GMT+01:00 Sekhar Nori :
>> On Monday 20 February 2017 09:12 PM, Bartosz Golaszewski wrote:
>>> 2017-02-20 11:29 GMT+01:00 Sekhar Nori :
 On Thursday 16 February 2017 11:45 PM, Bartosz Golaszewski wrote:
> Add a new pinctrl sub-node for vpif display pins. Move VP_CLKIN3 and
> VP_CLKIN2 to the display node where they actually belong (vide section
> 35.2.2 of the da850 datasheet).

 You mean 36.2.2. Also, its in the technical reference manual (TRM). The
 datahseet is another document.

>>>
>>> I'm looking at the revision from September 2016 and it's 35.2.2: VPIF
>>> -> Architecture -> signal descriptions.
>>
>> Is this the document ?
>>
>> http://www.ti.com/lit/ug/spruh77c/spruh77c.pdf
>>
>> In this VPIF is chapter 36.
>>
>> Thanks,
>> Sekhar
>>
> 
> -ETOOMANYPDFS I was looking at spruh82c.pdf.
> 
> You're right of course.

I see. I guess its better to call it OMAP-L138 technical reference
manual (instead of da850) and also provide a link.

Thanks,
Sekhar

Re: [PATCH 0/6] Enable parallel page migration

[Anshuman Khandual]

On 02/22/2017 10:34 AM, Balbir Singh wrote:
> On Fri, Feb 17, 2017 at 04:54:47PM +0530, Anshuman Khandual wrote:
>>  This patch series is base on the work posted by Zi Yan back in
>> November 2016 (https://lkml.org/lkml/2016/11/22/457) but includes some
>> amount clean up and re-organization. This series depends on THP migration
>> optimization patch series posted by Naoya Horiguchi on 8th November 2016
>> (https://lwn.net/Articles/705879/). Though Zi Yan has recently reposted
>> V3 of the THP migration patch series (https://lwn.net/Articles/713667/),
>> this series is yet to be rebased.
>>
>>  Primary motivation behind this patch series is to achieve higher
>> bandwidth of memory migration when ever possible using multi threaded
>> instead of a single threaded copy. Did all the experiments using a two
>> socket X86 sytsem (Intel(R) Xeon(R) CPU E5-2650). All the experiments
>> here have same allocation size 4K * 10 (which did not split evenly
>> for the 2MB huge pages). Here are the results.
>>
>> Vanilla:
>>
>> Moved 10 normal pages in 247.00 msecs 1.544412 GBs
>> Moved 10 normal pages in 238.00 msecs 1.602814 GBs
>> Moved 195 huge pages in 252.00 msecs 1.513769 GBs
>> Moved 195 huge pages in 257.00 msecs 1.484318 GBs
>>
>> THP migration improvements:
>>
>> Moved 10 normal pages in 302.00 msecs 1.263145 GBs
> 
> Is there a decrease here for normal pages?

Yeah.

> 
>> Moved 10 normal pages in 262.00 msecs 1.455991 GBs
>> Moved 195 huge pages in 120.00 msecs 3.178914 GBs
>> Moved 195 huge pages in 129.00 msecs 2.957130 GBs
>>
>> THP migration improvements + Multi threaded page copy:
>>
>> Moved 10 normal pages in 1589.00 msecs 0.240069 GBs **
> 
> Ditto?

Yeah, I have already mentioned about this after these data in
the cover letter. This new flag is controlled from user space
while invoking the system calls. Users should be careful in
using it for scenarios where its useful and avoid it for cases
where it hurts.

> 
>> Moved 10 normal pages in 1932.00 msecs 0.197448 GBs **
>> Moved 195 huge pages in 54.00 msecs 7.064254 GBs ***
>> Moved 195 huge pages in 86.00 msecs 4.435694 GBs ***
>>
> 
> Could you also comment on the CPU utilization impact of these
> patches. 

Yeah, it really makes sense to analyze this impact. I have mentioned
about this in the outstanding issues section of the series. But what
exactly we need to analyze from CPU utilization impact point of view
? Like whats the probability that the work queue requested jobs will
throw some tasks from the run queue and make them starve for some
more time ? Could you please give some details on this ?

Re: [PATCH v2 1/2] usbip: Fix-format-overflow

[Krzysztof Opasiak]

Hi,

W dniu 2017-02-21 o 18:57, Jonathan Dieter pisze:

The usbip userspace tools call sprintf()/snprintf() and don't check for
the return value which can lead the paths to overflow, truncating the
final file in the path.

More urgently, GCC 7 now warns that these aren't checked with
-Wformat-overflow, and with -Werror enabled in configure.ac, that makes
these tools unbuildable.

This patch fixes these problems by replacing sprintf() with snprintf() in
one place and adding checks for the return value of snprintf().

Reviewed-by: Peter Senna Tschudin 
Signed-off-by: Jonathan Dieter 
---
 tools/usb/usbip/libsrc/usbip_common.c  |  8 +++-
 tools/usb/usbip/libsrc/usbip_host_common.c | 25 -
 2 files changed, 27 insertions(+), 6 deletions(-)

diff --git a/tools/usb/usbip/libsrc/usbip_common.c 
b/tools/usb/usbip/libsrc/usbip_common.c
index ac73710..01dd4b2 100644
--- a/tools/usb/usbip/libsrc/usbip_common.c
+++ b/tools/usb/usbip/libsrc/usbip_common.c
@@ -215,9 +215,15 @@ int read_usb_interface(struct usbip_usb_device *udev, int 
i,
   struct usbip_usb_interface *uinf)
 {
char busid[SYSFS_BUS_ID_SIZE];
+   unsigned int size;


I'm not really convinced to use unsigned here. snprintf() is declared to 
return signed integer so we should assume that some of its 
implementation may return negative error code. Any rationale to this 
instead of just doing a cast for comparsion but signed value to print error?


Best regards
--
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics

Re: [PATCH] x86/mce: Keep quiet in case of broadcasted mce after system panic

[Xunlei Pang]

On 02/22/2017 at 02:20 AM, Luck, Tony wrote:
>> It's from my understanding, I didn't get the explicit description from the 
>> intel SDM on this point.
>> If a broadcast SRAO comes on real hardware, will MSR_IA32_MCG_STATUS of each 
>> cpu have MCG_STATUS_RIPV bit set?
> MCG_STATUS is a per-thread MSR and will contain the status appropriate for 
> that thread when #MC is delivered.
> So the RIPV bit will be set if, and only if, the thread saved a valid return 
> address for this exception. The net result
> is that it is almost always set for "innocent bystander" CPUs that were 
> dragged into the exception handler because
> of a broadcast #MC. We make the test because if it isn't set, then the 
> do_machine_check() had better not return
> because we have no idea where it will return to - since there is not a valid 
> return IP.
>

Got it, thanks for the details.

Regards,
Xunlei

RE: [RFC 7/8] fpga-region: add sysfs interface

[Nadathur, Sundar]

On February 21, 2017 9:39 PM, Moritz Fischer wrote:

> TLV Seems easy enough. To give an update, I played with fdt a bit to see how
> far I get in half an hour. I got bool / int / strings to work quite fast 
> (~30mins).
> Please disregard the horrible hackyness of this ...
> [...]
> So I'm fairly convinced I can make this work, TVLs seem like it could work,
> too.
> 
> > So far the only thing we know we need is a 'bool' for encrypted and a
> > stringish guid thing for partial reconfiguration.

These things have a way of growing beyond their original anticipated needs. 

> Yeah, shouldn't be hard to implement either way.
> 
> Cheers,
> 
> Moritz

Say we upstream a metadata parser. Subsequently, an FPGA image is released with 
an additional metadata field that the upstreamed version does not handle. How 
will this be handled if the metadata were in FDT or KVP format?

Thanks,
Sundar

[PATCH] mm: do not access page->mapping directly on page_endio

[Minchan Kim]

With rw_page, page_endio is used for completing IO on a page
and it propagates write error to the address space if the IO
fails. The problem is it accesses page->mapping directly which
might be okay for file-backed pages but it shouldn't for
anonymous page. Otherwise, it can corrupt one of field from
anon_vma under us and system goes panic randomly.

Cc: Matthew Wilcox 
Cc: 
Signed-off-by: Minchan Kim 
---
 mm/filemap.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/mm/filemap.c b/mm/filemap.c
index 2ba46f410c7c..1944c631e3e6 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -1008,9 +1008,12 @@ void page_endio(struct page *page, bool is_write, int 
err)
unlock_page(page);
} else {
if (err) {
+   struct address_space *mapping;
+
SetPageError(page);
-   if (page->mapping)
-   mapping_set_error(page->mapping, err);
+   mapping = page_mapping(page);
+   if (mapping)
+   mapping_set_error(mapping, err);
}
end_page_writeback(page);
}
-- 
2.7.4

Re: [RFC 7/8] fpga-region: add sysfs interface

[Moritz Fischer]

Hi all,

On Tue, Feb 21, 2017 at 9:12 PM, Jason Gunthorpe
 wrote:
> On Tue, Feb 21, 2017 at 07:49:19PM -0800, Moritz Fischer wrote:
>
>> fdt does this out of the box, too. So far I've seen nothing fdt
>> couldn't do (or doesn't do let's rather say).
>
> tlv/fdt/http headers are all essentially exactly the same
> thing. Key/value pairs with various encoding schemes.
>
> I don't think we don't need a tree of data, so fdt is overkill.
>
> tlv is not substantially easier to parse correctly than the
> structured plain text headers.. It is just in binary so it can
> represent binary-ish things better.

TLV Seems easy enough. To give an update, I played with fdt a bit to see
how far I get in half an hour. I got bool / int / strings to work
quite fast (~30mins).
Please disregard the horrible hackyness of this ...

For simplicity I stuck the header on top of my bitfile with:


/dts-v1/;

/{
description = "Test";
compressed = <0>;
encrypted = <1>;
};


$ dtc -o header.dtb header.dts

$ cat header.dtb mybitfile.bin > /lib/firmware/bitfile_header.bin

+ static int __fpga_mgr_blob_to_image_info(const void *blob,
+  struct fpga_image_info *info)
+ {
+ int root_offset;
+ const char *desc;
+ const uint32_t *_compressed, *_encrypted;
+ int compressed, encrypted;
+
+ if (fdt_check_header(blob)) {
+ pr_err("Invalid device tree blob header\n");
+ return -EINVAL;
+ }
+
+ root_offset = fdt_path_offset(blob, "/");
+ if (root_offset < 0) {
+ pr_err("Invalid root offset\n");
+ return -EINVAL;
+ }
+
+ desc = fdt_getprop(blob, root_offset, "description", NULL);
+
+ _compressed = fdt_getprop(blob, root_offset, "compressed", NULL);
+ if (_compressed)
+ compressed = fdt32_to_cpu(*_compressed);
+
+ _encrypted = fdt_getprop(blob, root_offset, "encrypted", NULL);
+ if (_encrypted)
+ encrypted = fdt32_to_cpu(*_encrypted);
+
+ if (desc)
+ pr_info("%s: description=%s\n", __func__, desc);
+
+ if (_encrypted && _compressed)
+ pr_info("%s: compressed? %s encrypted? %s\n", __func__,
+ compressed ? "Yes" : "No", encrypted ? "Yes" : "No");
+
+ return 0;
+ }

Which gave me:



[   19.325182] fpga_manager fpga0: writing bitfile_header.bin to
Xilinx Zynq FPGA Manager
[   20.091222] __fpga_mgr_blob_to_image_info: description=Test
[   20.096730] __fpga_mgr_blob_to_image_info: compressed? No encrypted? Yes



So I'm fairly convinced I can make this work, TVLs seem like it could work, too.

> So far the only thing we know we need is a 'bool' for encrypted and a
> stringish guid thing for partial reconfiguration.

Yeah, shouldn't be hard to implement either way.

Cheers,

Moritz

Re: next-20170217 boot on POWER8 LPAR : WARNING @kernel/jump_label.c:287

[Michael Ellerman]

Jason Baron  writes:

> On 02/20/2017 10:05 PM, Sachin Sant wrote:
>>
>>> On 20-Feb-2017, at 8:27 PM, Jason Baron >> > wrote:
>>>
>>> Hi,
>>>
>>> On 02/19/2017 09:07 AM, Sachin Sant wrote:
 While booting next-20170217 on a POWER8 LPAR following
 warning is displayed.

 Reverting the following commit helps boot cleanly.
 commit 3821fd35b5 :  jump_label: Reduce the size of struct static_key

 [   11.393008] [ cut here ]
 [   11.393031] WARNING: CPU: 5 PID: 2890 at kernel/jump_label.c:287
 static_key_set_entries.isra.10+0x3c/0x50
>>>
>>> Thanks for the report. So this is saying that the jump_entry table is
>>> not at least 4-byte aligned. I wonder if this fixes it up?
>>>
>>
>> Yes. With this patch the warning is gone.
>
> Hi,
>
> Thanks for testing. We probably need something like the following to 
> make sure we don't hit this on other arches. Steve - I will send 4 
> separate patches for this to get arch maintainers' acks for this?

What's the 4 byte alignment requirement from?

On 64-bit our JUMP_ENTRY_TYPE is 8 bytes, should we be aligning to 8
bytes?

> diff --git a/arch/powerpc/include/asm/jump_label.h 
> b/arch/powerpc/include/asm/jump_label.h
> index 9a287e0ac8b1..f870a85bac46 100644
> --- a/arch/powerpc/include/asm/jump_label.h
> +++ b/arch/powerpc/include/asm/jump_label.h
> @@ -24,6 +24,7 @@ static __always_inline bool arch_static_branch(struct 
> static_key *key, bool bran
>  asm_volatile_goto("1:\n\t"
>   "nop # arch_static_branch\n\t"
>   ".pushsection __jump_table,  \"aw\"\n\t"
> +".balign 4 \n\t"

Can you line those up vertically?

(That may just be an email artifact)

>   JUMP_ENTRY_TYPE "1b, %l[l_yes], %c0\n\t"
>   ".popsection \n\t"
>   : :  "i" (&((char *)key)[branch]) : : l_yes);
> @@ -38,6 +39,7 @@ static __always_inline bool 
> arch_static_branch_jump(struct static_key *key, bool
>  asm_volatile_goto("1:\n\t"
>   "b %l[l_yes] # arch_static_branch_jump\n\t"
>   ".pushsection __jump_table,  \"aw\"\n\t"
> +".balign 4 \n\t"
>   JUMP_ENTRY_TYPE "1b, %l[l_yes], %c0\n\t"
>   ".popsection \n\t"
>   : :  "i" (&((char *)key)[branch]) : : l_yes);
> @@ -63,6 +65,7 @@ struct jump_entry {
>   #define ARCH_STATIC_BRANCH(LABEL, KEY) \
>   1098:  nop;\
>  .pushsection __jump_table, "aw";\
> +   .balign 4;  \
>  FTR_ENTRY_LONG 1098b, LABEL, KEY;   \
>  .popsection
>   #endif

Otherwise that looks fine assuming 4 bytes is the correct alignment.

cheers

Re: [PATCH] usb: misc: remove unnecessary code

[Gustavo A. R. Silva]

Hi Peter,

Quoting Peter Senna Tschudin :


On Mon, Feb 20, 2017 at 05:28:46PM -0600, Gustavo A. R. Silva wrote:

'val' is an unsigned variable, and less-than-zero comparison of an unsigned
variable is never true.


I would add that val is set by kstrtoul() that converts a string to an
unsigned long.



Addresses-Coverity-ID: 1230257

Reviewed-by: Peter Senna Tschudin 

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/usb/misc/lvstest.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/misc/lvstest.c b/drivers/usb/misc/lvstest.c
index c7c2104..6f37610 100644
--- a/drivers/usb/misc/lvstest.c
+++ b/drivers/usb/misc/lvstest.c
@@ -193,7 +193,7 @@ static ssize_t u2_timeout_store(struct device *dev,
return ret;
}

-   if (val < 0 || val > 127)
+   if (val > 127)
return -EINVAL;

ret = lvs_rh_set_port_feature(hdev, lvs->portnum | (val << 8),
--
2.5.0



Thanks for your comments.
--
Gustavo A. R. Silva

Re: [x86/vsyscall] 3dc33bd30f Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

[Kees Cook]

On Tue, Feb 21, 2017 at 9:23 PM, Andy Lutomirski  wrote:
> On Tue, Feb 21, 2017 at 4:46 PM, Kees Cook  wrote:
>> On Tue, Feb 21, 2017 at 4:39 PM, Chunyu Hu  wrote:
>>> I hit the similar panic on Fedora 25. Is it the same issue?
>>>
>>>
>>> [2.527391] Freeing unused kernel memory: 1688K (bdf66000 -
>>> be10c000)
>>> [2.535222] Write protecting the kernel read-only data: 14336k
>>> [2.542679] Freeing unused kernel memory: 1892K (94cb30827000 -
>>> 94cb30a0)
>>> [2.553482] Freeing unused kernel memory: 700K (94cb30d51000 -
>>> 94cb30e0)
>>> [2.572048] x86/mm: Checked W+X mappings: passed, no W+X pages found.
>>> Fatal: [2.598239] traps: init[1] general protection ip:7fc841bfc642
>>> sp:7ffc3fd85870 error:0no entropy gathering module dete[2.606473]  in
>>> libc-2.24.so[7fc841bc5000+1bd000]
>>> cted
>>
>> I would not expect a vsyscall table problem if it's truly using glibc
>> 2.24. Maybe something regressed in glibc? That really looks like an
>> attempt to call vsyscalls?
>
> There should be a vsyscall error if so, and shouldn't it be a page
> fault, not a gpf?

Yeah, the earlier email from Fengguang included a vsyscall error, so
I'm not sure what this is, exactly. But if it bisects to the same
commit, we likely need to investigate a bit more.

-Kees

-- 
Kees Cook
Pixel Security

Re: [PATCH] usercopy: ARM NOMMU has no 64-bit get_user

[Kees Cook]

On Tue, Feb 21, 2017 at 2:01 PM, Arnd Bergmann  wrote:
> On a NOMMU ARM kernel, we get this link error:
>
> ERROR: "__get_user_bad" [lib/test_user_copy.ko] undefined!
>
> The problem is that the extended get_user/put_user definitions
> were only added for the noral (MMU based) case.
>
> We could add it for NOMMU as well, but it seems easier to just not
> call it, since no other code needs it.
>
> Fixes: 075c4ea5363d ("usercopy: Add tests for all get_user() sizes")
> Signed-off-by: Arnd Bergmann 

Ah, excellent, thanks! I'll get this in.

-Kees

> ---
>  lib/test_user_copy.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/lib/test_user_copy.c b/lib/test_user_copy.c
> index 4a79f2c1cd6e..361576b2cb3d 100644
> --- a/lib/test_user_copy.c
> +++ b/lib/test_user_copy.c
> @@ -30,7 +30,8 @@
>   * As there doesn't appear to be anything that can safely determine
>   * their capability at compile-time, we just have to opt-out certain archs.
>   */
> -#if BITS_PER_LONG == 64 || (!defined(CONFIG_AVR32)  && \
> +#if BITS_PER_LONG == 64 || (!(defined(CONFIG_ARM) && !defined(MMU)) && \
> +   !defined(CONFIG_AVR32)  &&  \
> !defined(CONFIG_BLACKFIN) &&\
> !defined(CONFIG_M32R) &&\
> !defined(CONFIG_M68K) &&\
> --
> 2.9.0
>



-- 
Kees Cook
Pixel Security

Re: [PATCH] usb: misc: add a missing continue and refactor code

[Gustavo A. R. Silva]

Quoting "Gustavo A. R. Silva" :


Hi Alan,

Quoting Alan Stern :


On Tue, 21 Feb 2017, Gustavo A. R. Silva wrote:


Code refactoring to make the flow easier to follow and add missing
'continue' for case USB_ENDPOINT_XFER_INT.

Addresses-Coverity-ID: 1248733
Cc: Alan Stern 
Signed-off-by: Gustavo A. R. Silva 
---
drivers/usb/misc/usbtest.c | 50  
+++---

1 file changed, 30 insertions(+), 20 deletions(-)

diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index 3525626..8723e33 100644
--- a/drivers/usb/misc/usbtest.c
+++ b/drivers/usb/misc/usbtest.c
@@ -124,6 +124,32 @@ static struct usb_device  
*testdev_to_usbdev(struct usbtest_dev *test)


/*-*/

+static inline void try_intr(struct usb_host_endpoint *e,
+   struct usb_host_endpoint *int_in,
+   struct usb_host_endpoint *int_out)
+{
+   if (usb_endpoint_dir_in(&e->desc)) {
+   if (!int_in)
+   int_in = e;
+   } else {
+   if (!int_out)
+   int_out = e;
+   }
+}
+
+static inline void try_iso(struct usb_host_endpoint *e,
+  struct usb_host_endpoint *iso_in,
+  struct usb_host_endpoint *iso_out)
+{
+   if (usb_endpoint_dir_in(&e->desc)) {
+   if (!iso_in)
+   iso_in = e;
+   } else {
+   if (!iso_out)
+   iso_out = e;
+   }
+}
+


This is not at all what I had in mind.  First, it's incorrect (can you
see why?).  Second, by "inline" I meant moving the code to be actually
in-line next to the conditional, not some place else in a separate
subroutine (even if the subroutine is declared inline).



Interesting... let me double check.

I thought it would've been better to have separate inline  
subroutines for those "goto".



Also, the code for the USB_ENDPOINT_XFER_BULK case should look like the
other two.



Do you mean a 'continue' instead of the 'break'?



Oh I see, the following piece of code should be part of the  
USB_ENDPOINT_XFER_BULK case:


if (usb_endpoint_dir_in(&e->desc)) {
if (!in)
in = e;
} else {
if (!out)
out = e;
}
continue;

--
Gustavo A. R. Silva

Re: [PATCH_v4.1_0_3] Make core_pattern support namespace

[Cao Shufeng/曹树烽]

ping
在 2017-02-08三的 11:00 +0800，Cao Shufeng写道：
> This patchset includes following function points:
> 1: Let usermodehelper function possible to set pid namespace
>done by: [PATCH v4 1/3] Make call_usermodehelper_exec possible
>to set pid namespace.
> 2: Let pipe_type core_pattern write dump into container's rootfs
>done by: [PATCH v4 2/3] Limit dump_pipe program's permission to
>init for container.
> 2: Make separate core_pattern setting for each container
>done by: [PATCH v4 3/3] Make core_pattern support namespace
> 3: Compatibility with current system
>also included in: [PATCH v4 3/3] Make core_pattern support namespace
>If container hadn't change core_pattern setting, it will keep
>same setting with host.
> 
> Test:
> 1: Pass a test script for each function of this patchset
>## TEST IN HOST ##
>[root@kerneldev dumptest]# ./test_host
>Set file core_pattern: OK
>./test_host: line 41:  2366 Segmentation fault  (core dumped) "$SCRI=
> PT_BASE_DIR"/make_dump
>Checking dumpfile: OK
>Set file core_pattern: OK
>./test_host: line 41:  2369 Segmentation fault  (core dumped) "$SCRI=
> PT_BASE_DIR"/make_dump
>Checking dump_pipe triggered: OK
>Checking rootfs: OK
>Checking dumpfile: OK
>Checking namespace: OK
>Checking process list: OK
>Checking capabilities: OK
> 
>## TEST IN GUEST ##
># ./test
>Segmentation fault (core dumped)
>Checking dump_pipe triggered: OK
>Checking rootfs: OK
>Checking dumpfile: OK
>Checking namespace: OK
>Checking process list: OK
>Checking cg pids: OK
>Checking capabilities: OK
>[   64.940734] make_dump[2432]: segfault at 0 ip 0040049d sp 000=
> 07ffc4af025f0 error 6 in make_dump[40+a6000]
>#
> 2: Pass other test(which is not easy to do in script) by hand.
> 
> Changelog v4-v4.1:
> 1. Fix kernel panic pointed out by:
>xiaolong...@intel.com
> 
> Changelog v3.1-v4:
> 1. remove extra fork pointed out by:
>Andrei Vagin 
> 
> Changelog v3-v3.1:
> 1. Switch "pwd" of pipe program to container's root fs.
> 2. Rebase on top of v4.9-rc1
> 
> Changelog v2->v3:
> 1: Fix problem of setting pid namespace, pointed out by:
>Andrei Vagin 
> 
> Changelog v1(RFC)->v2:
> 1: Add [PATCH 2/2] which was todo in [RFC v1].
> 2: Pass a test script for each function.
> 3: Rebase on top of v4.7.
> 
> Suggested-by: Eric W. Biederman 
> Suggested-by: KOSAKI Motohiro 
> Signed-off-by: Zhao Lei 
> Signed-off-by: Cao Shufeng 
> 
> Cao Shufeng (2):
>   Make call_usermodehelper_exec possible to set namespaces
>   Limit dump_pipe program's permission to init for container
> 
> Zhao Lei (1):
>   Make core_pattern support namespace
> 
>  fs/coredump.c | 150 
> +++---
>  include/linux/binfmts.h   |   2 +
>  include/linux/kmod.h  |   5 ++
>  include/linux/pid_namespace.h |   3 +
>  init/do_mounts_initrd.c   |   3 +-
>  kernel/kmod.c |  55 +---
>  kernel/pid.c  |   2 +
>  kernel/pid_namespace.c|   2 +
>  kernel/sysctl.c   |  50 --
>  lib/kobject_uevent.c  |   3 +-
>  security/keys/request_key.c   |   4 +-
>  11 files changed, 253 insertions(+), 26 deletions(-)
> 

-- 
Best Regards,
Cao Shufeng
--
Cao Shufeng
Development Dept.I
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)
No.6 Wenzhu Road, Nanjing, 210012, China 
TEL: +86+25-86630566-8552
FUJITSU INTERNAL: 7998-8552
EMail: caosf.f...@cn.fujitsu.com

[PATCH 1/2] reset: Add API to count number of reset available with device

[Vivek Gautam]

Count number of reset phandles available with the device node
to know the resets a given device has.

Cc: Philipp Zabel 
Signed-off-by: Vivek Gautam 
---

Based on torvald's master branch.

 include/linux/reset.h | 16 
 1 file changed, 16 insertions(+)

diff --git a/include/linux/reset.h b/include/linux/reset.h
index 5daff15722d3..88f63a640153 100644
--- a/include/linux/reset.h
+++ b/include/linux/reset.h
@@ -2,6 +2,7 @@
 #define _LINUX_RESET_H_
 
 #include 
+#include 
 
 struct reset_control;
 
@@ -234,6 +235,21 @@ static inline struct reset_control 
*of_reset_control_get_shared_by_index(
 }
 
 /**
+ * of_reset_control_get_count - Count number of resets available with a device
+ * @node: device to be reset by the controller
+ */
+static inline unsigned int of_reset_control_get_count(struct device_node *node)
+{
+   int count;
+
+   count = of_count_phandle_with_args(node, "resets", "#reset-cells");
+   if (count < 0)
+   return 0;
+
+   return count;
+}
+
+/**
  * devm_reset_control_get_exclusive - resource managed
  *reset_control_get_exclusive()
  * @dev: device to be reset by the controller
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 2/2] usb; dwc3: of-simple: Add support to get resets for the device

[Vivek Gautam]

Add support to get a list of resets available for the device.
These resets must be kept de-asserted until the device is
in use.

Cc: Felipe Balbi 
Signed-off-by: Vivek Gautam 
---

Based on torvald's master branch.

 drivers/usb/dwc3/dwc3-of-simple.c | 49 +++
 1 file changed, 49 insertions(+)

diff --git a/drivers/usb/dwc3/dwc3-of-simple.c 
b/drivers/usb/dwc3/dwc3-of-simple.c
index fe414e7a9c78..025de7342d28 100644
--- a/drivers/usb/dwc3/dwc3-of-simple.c
+++ b/drivers/usb/dwc3/dwc3-of-simple.c
@@ -29,13 +29,52 @@
 #include 
 #include 
 #include 
+#include 
 
 struct dwc3_of_simple {
struct device   *dev;
struct clk  **clks;
int num_clocks;
+   struct reset_control**resets;
+   int num_resets;
 };
 
+static int dwc3_of_simple_reset_init(struct dwc3_of_simple *simple, int count)
+{
+   struct device   *dev = simple->dev;
+   int i;
+
+   simple->num_resets = count;
+
+   if (!count)
+   return 0;
+
+   simple->resets = devm_kcalloc(dev, simple->num_resets,
+   sizeof(struct reset_control *), GFP_KERNEL);
+   if (!simple->resets)
+   return -ENOMEM;
+
+   for (i = 0; i < simple->num_resets; i++) {
+   struct reset_control *reset;
+   int ret;
+
+   reset = devm_reset_control_get_by_index(dev, i);
+   if (IS_ERR(reset))
+   return PTR_ERR(reset);
+
+   simple->resets[i] = reset;
+
+   ret = reset_control_deassert(reset);
+   if (ret) {
+   while (--i >= 0)
+   reset_control_assert(reset);
+   return ret;
+   }
+   }
+
+   return 0;
+}
+
 static int dwc3_of_simple_clk_init(struct dwc3_of_simple *simple, int count)
 {
struct device   *dev = simple->dev;
@@ -100,6 +139,10 @@ static int dwc3_of_simple_probe(struct platform_device 
*pdev)
if (ret)
return ret;
 
+   ret = dwc3_of_simple_reset_init(simple, of_reset_control_get_count(np));
+   if (ret)
+   return ret;
+
ret = of_platform_populate(np, NULL, NULL, dev);
if (ret) {
for (i = 0; i < simple->num_clocks; i++) {
@@ -107,6 +150,9 @@ static int dwc3_of_simple_probe(struct platform_device 
*pdev)
clk_put(simple->clks[i]);
}
 
+   for (i = 0; i < simple->num_resets; i++)
+   reset_control_assert(simple->resets[i]);
+
return ret;
}
 
@@ -128,6 +174,9 @@ static int dwc3_of_simple_remove(struct platform_device 
*pdev)
clk_put(simple->clks[i]);
}
 
+   for (i = 0; i < simple->num_resets; i++)
+   reset_control_assert(simple->resets[i]);
+
of_platform_depopulate(dev);
 
pm_runtime_put_sync(dev);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [x86/vsyscall] 3dc33bd30f Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

[Andy Lutomirski]

On Tue, Feb 21, 2017 at 4:46 PM, Kees Cook  wrote:
> On Tue, Feb 21, 2017 at 4:39 PM, Chunyu Hu  wrote:
>> I hit the similar panic on Fedora 25. Is it the same issue?
>>
>>
>> [2.527391] Freeing unused kernel memory: 1688K (bdf66000 -
>> be10c000)
>> [2.535222] Write protecting the kernel read-only data: 14336k
>> [2.542679] Freeing unused kernel memory: 1892K (94cb30827000 -
>> 94cb30a0)
>> [2.553482] Freeing unused kernel memory: 700K (94cb30d51000 -
>> 94cb30e0)
>> [2.572048] x86/mm: Checked W+X mappings: passed, no W+X pages found.
>> Fatal: [2.598239] traps: init[1] general protection ip:7fc841bfc642
>> sp:7ffc3fd85870 error:0no entropy gathering module dete[2.606473]  in
>> libc-2.24.so[7fc841bc5000+1bd000]
>> cted
>
> I would not expect a vsyscall table problem if it's truly using glibc
> 2.24. Maybe something regressed in glibc? That really looks like an
> attempt to call vsyscalls?

There should be a vsyscall error if so, and shouldn't it be a page
fault, not a gpf?

--Andy

Re: [PATCH v5 10/10] landlock: Add user and kernel documentation for Landlock

[Andy Lutomirski]

On Tue, Feb 21, 2017 at 5:26 PM, Mickaël Salaün  wrote:
> This documentation can be built with the Sphinx framework.
>
> Signed-off-by: Mickaël Salaün 
> Cc: Alexei Starovoitov 
> Cc: Andy Lutomirski 
> Cc: Daniel Borkmann 
> Cc: David S. Miller 
> Cc: James Morris 
> Cc: Jonathan Corbet 
> Cc: Kees Cook 
> Cc: Serge E. Hallyn 


> +
> +Writing a rule
> +--
> +
> +To enforce a security policy, a thread first needs to create a Landlock rule.
> +The easiest way to write an eBPF program depicting a security rule is to 
> write
> +it in the C language.  As described in *samples/bpf/README.rst*, LLVM can
> +compile such programs.  Files *samples/bpf/landlock1_kern.c* and those in
> +*tools/testing/selftests/landlock/rules/* can be used as examples.  The
> +following example is a simple rule to forbid file creation, whatever syscall
> +may be used (e.g. open, mkdir, link...).
> +
> +.. code-block:: c
> +
> +static int deny_file_creation(struct landlock_context *ctx)
> +{
> +if (ctx->arg2 & LANDLOCK_ACTION_FS_NEW)
> +return 1;
> +return 0;
> +}
> +

Would it make sense to define landlock_context (or at least a prefix
thereof) in here?  Also, can't "arg2" have a better name?

Can you specify what the return value means?  Are 0 and 1 the only
choices?  Would "KILL" be useful?  How about "COREDUMP"?

> +File system action types
> +
> +
> +Flags are used to express actions.  This makes it possible to compose actions
> +and leaves room for future improvements to add more fine-grained action 
> types.
> +
> +.. kernel-doc:: include/uapi/linux/bpf.h
> +:doc: landlock_action_fs
> +
> +.. flat-table:: FS action types availability
> +
> +* - flags
> +  - since
> +
> +* - LANDLOCK_ACTION_FS_EXEC
> +  - v1
> +
> +* - LANDLOCK_ACTION_FS_WRITE
> +  - v1
> +
> +* - LANDLOCK_ACTION_FS_READ
> +  - v1
> +
> +* - LANDLOCK_ACTION_FS_NEW
> +  - v1
> +
> +* - LANDLOCK_ACTION_FS_GET
> +  - v1
> +
> +* - LANDLOCK_ACTION_FS_REMOVE
> +  - v1
> +
> +* - LANDLOCK_ACTION_FS_IOCTL
> +  - v1
> +
> +* - LANDLOCK_ACTION_FS_LOCK
> +  - v1
> +
> +* - LANDLOCK_ACTION_FS_FCNTL
> +  - v1

What happens if you run an old program on a new kernel?  Can you get
unexpected action types?

> +
> +
> +Ability types
> +-
> +
> +The ability of a Landlock rule describes the available features (i.e. context
> +fields and helpers).  This is useful to abstract user-space privileges for
> +Landlock rules, which may not need all abilities (e.g. debug).  Only the
> +minimal set of abilities should be used (e.g. disable debug once in
> +production).
> +
> +
> +.. kernel-doc:: include/uapi/linux/bpf.h
> +:doc: landlock_subtype_ability
> +
> +.. flat-table:: Ability types availability
> +
> +* - flags
> +  - since
> +  - capability
> +
> +* - LANDLOCK_SUBTYPE_ABILITY_WRITE
> +  - v1
> +  - CAP_SYS_ADMIN
> +
> +* - LANDLOCK_SUBTYPE_ABILITY_DEBUG
> +  - v1
> +  - CAP_SYS_ADMIN
> +

What do "WRITE" and "DEBUG" mean in this context?  I'm totally lost.

Hmm.  Reading below, "WRITE" seems to mean "modify state".  Would that
be accurate?

> +
> +Helper functions
> +
> +
> +See *include/uapi/linux/bpf.h* for functions documentation.
> +
> +.. flat-table:: Generic functions availability
> +

> +
> +* - bpf_get_current_comm
> +  - v1
> +  - LANDLOCK_SUBTYPE_ABILITY_DEBUG

What would this be used for?

> +* - bpf_get_trace_printk
> +  - v1
> +  - LANDLOCK_SUBTYPE_ABILITY_DEBUG
> +

This is different from the other DEBUG stuff in that it has side
effects.  I wonder if it should have a different flag.

--Andy

[GIT PULL] gcc-plugins updates for v4.11-rc1 (take 2)

[Kees Cook]

Hi,

Please pull these gcc-plugins changes for v4.11-rc1. (This is take 2,
with the initify series removed.) This includes infrastructure updates
and the structleak plugin, which performs forced initialization of certain
structures to avoid possible information exposures to userspace.

Thanks!

-Kees

The following changes since commit a121103c922847ba5010819a3f250f1f7fc84ab8:

  Linux 4.10-rc3 (2017-01-08 14:18:17 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git 
tags/gcc-plugins-v4.11-rc1

for you to fetch changes up to c054ee3bbf69ebcabb1f3218b7faf4b1b37a8eb6:

  Merge branch 'for-next/gcc-plugin/structleak' into for-linus/gcc-plugins 
(2017-02-21 21:12:57 -0800)


Updates to the gcc-plugins:
- infrastructure updates (gcc-common.h)
- introduce structleak plugin for forced initialization of some structures


Kees Cook (5):
  gcc-plugins: add PASS_INFO and build_const_char_string()
  gcc-plugins: consolidate on PASS_INFO macro
  gcc-plugins: Add structleak for more stack initialization
  Merge branch 'for-next/gcc-plugin-infrastructure' into 
for-linus/gcc-plugins
  Merge branch 'for-next/gcc-plugin/structleak' into for-linus/gcc-plugins

 arch/Kconfig|  22 +++
 include/linux/compiler.h|   6 +-
 scripts/Makefile.gcc-plugins|   4 +
 scripts/gcc-plugins/cyc_complexity_plugin.c |   6 +-
 scripts/gcc-plugins/gcc-common.h|  55 +--
 scripts/gcc-plugins/latent_entropy_plugin.c |   8 +-
 scripts/gcc-plugins/sancov_plugin.c |   8 +-
 scripts/gcc-plugins/structleak_plugin.c | 246 
 8 files changed, 326 insertions(+), 29 deletions(-)
 create mode 100644 scripts/gcc-plugins/structleak_plugin.c

-- 
Kees Cook
Pixel Security

Re: [RFC 7/8] fpga-region: add sysfs interface

[Jason Gunthorpe]

On Tue, Feb 21, 2017 at 07:49:19PM -0800, Moritz Fischer wrote:

> fdt does this out of the box, too. So far I've seen nothing fdt
> couldn't do (or doesn't do let's rather say).

tlv/fdt/http headers are all essentially exactly the same
thing. Key/value pairs with various encoding schemes.

I don't think we don't need a tree of data, so fdt is overkill.

tlv is not substantially easier to parse correctly than the
structured plain text headers.. It is just in binary so it can
represent binary-ish things better.

So far the only thing we know we need is a 'bool' for encrypted and a
stringish guid thing for partial reconfiguration.

The other stuff I've always used is pretty much all textual.

Jason

Re: [PATCH v6] drivers/misc: Add Aspeed LPC control driver

[Suraj Jitindar Singh]

On Fri, 2017-02-17 at 14:28 +1100, Cyril Bur wrote:

I may be too late, but see below...
> In order to manage server systems, there is typically another
> processor
> known as a BMC (Baseboard Management Controller) which is responsible
> for powering the server and other various elements, sometimes fans,
> often the system flash.
> 
> The Aspeed BMC family which is what is used on OpenPOWER machines and
> a
> number of x86 as well is typically connected to the host via an LPC
> (Low Pin Count) bus (among others).
> 
> The LPC bus is an ISA bus on steroids. It's generally used by the
> BMC chip to provide the host with access to the system flash (via
> MEM/FW
> cycles) that contains the BIOS or other host firmware along with a
> number of SuperIO-style IOs (via IO space) such as UARTs, IPMI
> controllers.
> 
> On the BMC chip side, this is all configured via a bunch of registers
> whose content is related to a given policy of what devices are
> exposed
> at a per system level, which is system/vendor specific, so we don't
> want
> to bolt that into the BMC kernel. This started with a need to provide
> something nicer than /dev/mem for user space to configure these
> things.
> 
> One important aspect of the configuration is how the MEM/FW space is
> exposed to the host (ie, the x86 or POWER). Some registers in that
> bridge can define a window remapping all or portion of the LPC MEM/FW
> space to a portion of the BMC internal bus, with no specific limits
> imposed in HW.
> 
> I think it makes sense to ensure that this window is configured by a
> kernel driver that can apply some serious sanity checks on what it is
> configured to map.
> 
> In practice, user space wants to control this by flipping the mapping
> between essentially two types of portions of the BMC address space:
> 
>    - The flash space. This is a region of the BMC MMIO space that
> more/less directly maps the system flash (at least for reads, writes
> are somewhat more complicated).
> 
>    - One (or more) reserved area(s) of the BMC physical memory.
> 
> The latter is needed for a number of things, such as avoiding letting
> the host manipulate the innards of the BMC flash controller via some
> evil backdoor, we want to do flash updates by routing the window to a
> portion of memory (under control of a mailbox protocol via some
> separate set of registers) which the host can use to write new data
> in
> bulk and then request the BMC to flash it. There are other uses, such
> as allowing the host to boot from an in-memory flash image rather
> than
> the one in flash (very handy for continuous integration and test, the
> BMC can just download new images).
> 
> It is important to note that due to the way the Aspeed chip lets the
> kernel configure the mapping between host LPC addresses and BMC ram
> addresses the offset within the window must be a multiple of size.
> Not doing so will fragment the accessible space rather than simply
> moving 'zero' upwards. This is caused by the nature of HICR8 being a
> mask and the way host LPC addresses are translated.
> 
> Signed-off-by: Cyril Bur 
> ---
> v2:
>    Removed unused functions
>    Removed use of access_ok()
>    All input is evil
>    Reworked the interface as per Benjamin Herrenschmidts vision
> v3:
>    Removed 'default y' from Kconfig
>    Reordered ioctl() struct fields
>    Reworeded some comments
> v4:
>    Reorder ioctl() struct fields (again)
> v5:
>    Style cleanups
>    Use of_address_to_resource()
>    Document ioctl structure fields
> v6:
>    Check and fail ioctl() if flags field non-zero
> 
>  drivers/misc/Kconfig |   8 ++
>  drivers/misc/Makefile|   1 +
>  drivers/misc/aspeed-lpc-ctrl.c   | 267
> +++
>  include/uapi/linux/aspeed-lpc-ctrl.h |  60 
>  4 files changed, 336 insertions(+)
>  create mode 100644 drivers/misc/aspeed-lpc-ctrl.c
>  create mode 100644 include/uapi/linux/aspeed-lpc-ctrl.h
> 
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index 64971baf11fa..7dc4c369012f 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -766,6 +766,14 @@ config PANEL_BOOT_MESSAGE
>     An empty message will only clear the display at driver
> init time. Any other
>     printf()-formatted message is valid with newline and
> escape codes.
>  
> +config ASPEED_LPC_CTRL
> + depends on (ARCH_ASPEED || COMPILE_TEST) && REGMAP &&
> MFD_SYSCON
> + tristate "Aspeed ast2400/2500 HOST LPC to BMC bridge
> control"
> + ---help---
> +   Control Aspeed ast2400/2500 HOST LPC to BMC mappings
> through
> +   ioctl()s, the driver also provides a read/write interface
> to a BMC ram
> +   region where the host LPC read/write region can be
> buffered.
> +
>  source "drivers/misc/c2port/Kconfig"
>  source "drivers/misc/eeprom/Kconfig"
>  source "drivers/misc/cb710/Kconfig"
> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> index 31983366090a..de1925a9c80b 100644

[no subject]

[DR ANDASON PHILLIP]

YOUR ATM CARD.pdf
Description: Adobe PDF document

Re: [GIT PULL] gcc-plugins updates for v4.11-rc1

[Kees Cook]

On Tue, Feb 21, 2017 at 6:34 PM, Linus Torvalds
 wrote:
> On Tue, Feb 21, 2017 at 12:16 PM, Kees Cook  wrote:
>>
>> Please pull these gcc-plugins changes for v4.11-rc1. This includes two new
>> plugins for the upstream kernel: structleak and initify. The structleak
>> plugin performs forced initialization of certain structures to avoid
>> possible information exposures to userspace. The initify plugin performs
>> analysis to find functions and strings that can be marked as __init or
>> __exit to reduce the runtime size of the kernel.
>
> I pulled this, but then looked at the patch, and decided to unpull it.

Hrm, I will send a pull for just the infrastructure and structleak
changes, since those are independent from the initify changes.

> The crazy "__nocapture()" annotations are too ugly to live, and make
> no sense. They are basically random noise to some very core header
> files. And the "__unverified_nocapture()" ones are worse.

Is it the naming, or something else? I tried to document them as
clearly as I could... the initify plugin needs to figure out if a
string is being retained by a function to decide if it can safely be
moved into the .init section.

> I'm not sure how to fix this issue.

I'm open to ideas. :) Initify certainly has more annotations than most
of the pending plugins, but there needs to be a way to mark things for
plugin consumption.

-Kees

-- 
Kees Cook
Pixel Security

Re: [PATCH 0/6] Enable parallel page migration

[Balbir Singh]

On Fri, Feb 17, 2017 at 04:54:47PM +0530, Anshuman Khandual wrote:
>   This patch series is base on the work posted by Zi Yan back in
> November 2016 (https://lkml.org/lkml/2016/11/22/457) but includes some
> amount clean up and re-organization. This series depends on THP migration
> optimization patch series posted by Naoya Horiguchi on 8th November 2016
> (https://lwn.net/Articles/705879/). Though Zi Yan has recently reposted
> V3 of the THP migration patch series (https://lwn.net/Articles/713667/),
> this series is yet to be rebased.
> 
>   Primary motivation behind this patch series is to achieve higher
> bandwidth of memory migration when ever possible using multi threaded
> instead of a single threaded copy. Did all the experiments using a two
> socket X86 sytsem (Intel(R) Xeon(R) CPU E5-2650). All the experiments
> here have same allocation size 4K * 10 (which did not split evenly
> for the 2MB huge pages). Here are the results.
> 
> Vanilla:
> 
> Moved 10 normal pages in 247.00 msecs 1.544412 GBs
> Moved 10 normal pages in 238.00 msecs 1.602814 GBs
> Moved 195 huge pages in 252.00 msecs 1.513769 GBs
> Moved 195 huge pages in 257.00 msecs 1.484318 GBs
> 
> THP migration improvements:
> 
> Moved 10 normal pages in 302.00 msecs 1.263145 GBs

Is there a decrease here for normal pages?

> Moved 10 normal pages in 262.00 msecs 1.455991 GBs
> Moved 195 huge pages in 120.00 msecs 3.178914 GBs
> Moved 195 huge pages in 129.00 msecs 2.957130 GBs
> 
> THP migration improvements + Multi threaded page copy:
> 
> Moved 10 normal pages in 1589.00 msecs 0.240069 GBs **

Ditto?

> Moved 10 normal pages in 1932.00 msecs 0.197448 GBs **
> Moved 195 huge pages in 54.00 msecs 7.064254 GBs ***
> Moved 195 huge pages in 86.00 msecs 4.435694 GBs ***
>

Could you also comment on the CPU utilization impact of these
patches. 

Balbir Singh.

Re: [PATCH v3 8/9] sched: Don't reinvent the wheel but use existing llist API

[Byungchul Park]

On Tue, Feb 14, 2017 at 04:26:29PM +0900, Byungchul Park wrote:
> Although llist provides proper APIs, they are not used. Make them used.

Hello,

What do you think?

> 
> Signed-off-by: Byungchul Park 
> ---
>  kernel/sched/core.c | 15 +++
>  1 file changed, 3 insertions(+), 12 deletions(-)
> 
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index d01f9d0..8938125 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -1773,7 +1773,7 @@ void sched_ttwu_pending(void)
>  {
>   struct rq *rq = this_rq();
>   struct llist_node *llist = llist_del_all(&rq->wake_list);
> - struct task_struct *p;
> + struct task_struct *p, *t;
>   unsigned long flags;
>   struct rq_flags rf;
>  
> @@ -1783,17 +1783,8 @@ void sched_ttwu_pending(void)
>   raw_spin_lock_irqsave(&rq->lock, flags);
>   rq_pin_lock(rq, &rf);
>  
> - while (llist) {
> - int wake_flags = 0;
> -
> - p = llist_entry(llist, struct task_struct, wake_entry);
> - llist = llist_next(llist);
> -
> - if (p->sched_remote_wakeup)
> - wake_flags = WF_MIGRATED;
> -
> - ttwu_do_activate(rq, p, wake_flags, &rf);
> - }
> + llist_for_each_entry_safe(p, t, llist, wake_entry)
> + ttwu_do_activate(rq, p, p->sched_remote_wakeup ? WF_MIGRATED : 
> 0, &rf);
>  
>   rq_unpin_lock(rq, &rf);
>   raw_spin_unlock_irqrestore(&rq->lock, flags);
> -- 
> 1.9.1

Re: [PATCH v3 1/2] sched/deadline: Remove unnecessary condition in push_dl_task()

[Byungchul Park]

On Thu, Feb 16, 2017 at 11:34:16AM +0900, Byungchul Park wrote:
> pick_next_pushable_dl_task(rq) has BUG_ON(rq->cpu != task_cpu(task))
> when it returns a task other than NULL, which means that task_cpu(task)
> must be rq->cpu. So if task == next_task, then task_cpu(next_task) must
> be rq->cpu as well. Remove the redundant condition and make code simpler.
> 
> By this patch, unnecessary one branch and two LOAD operations in 'if'
> statement can be avoided.

Hello,

What do you think?

> 
> Signed-off-by: Byungchul Park 
> Reviewed-by: Steven Rostedt (VMware) 
> Reviewed-by: Juri Lelli 
> ---
>  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 27737f3..ad8d577 100644
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -1483,7 +1483,7 @@ static int push_dl_task(struct rq *rq)
>* then possible that next_task has migrated.
>*/
>   task = pick_next_pushable_dl_task(rq);
> - if (task_cpu(next_task) == rq->cpu && task == next_task) {
> + if (task == next_task) {
>   /*
>* The task is still there. We don't try
>* again, some other cpu will pull it when ready.
> -- 
> 1.9.1

[PATCH] staging: wilc1000: renames struct tstrRSSI and its members u8Index, u8Full

[Tahia Khan]

Fixes multiple camel case checks on struct tstrRSSI from checkpatch.pl:

Avoid CamelCase: 
Avoid CamelCase: 
Avoid CamelCase: 

Signed-off-by: Tahia Khan 
---
 drivers/staging/wilc1000/coreconfigurator.h   |  8 
 drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 10 +-
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/wilc1000/coreconfigurator.h 
b/drivers/staging/wilc1000/coreconfigurator.h
index cff1698..c9cf23b 100644
--- a/drivers/staging/wilc1000/coreconfigurator.h
+++ b/drivers/staging/wilc1000/coreconfigurator.h
@@ -70,9 +70,9 @@ enum connect_status {
CONNECT_STS_FORCE_16_BIT = 0x
 };
 
-struct tstrRSSI {
-   u8 u8Full;
-   u8 u8Index;
+struct tstr_RSSI {
+   u8 u8_full;
+   u8 u8_index;
s8 as8RSSI[NUM_RSSI];
 };
 
@@ -93,7 +93,7 @@ struct network_info {
u8 *ies;
u16 ies_len;
void *join_params;
-   struct tstrRSSI str_rssi;
+   struct tstr_RSSI str_rssi;
u64 tsf_hi;
 };
 
diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c 
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index f7ce47c..30285b9 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -205,8 +205,8 @@ static u32 get_rssi_avg(struct network_info *network_info)
 {
u8 i;
int rssi_v = 0;
-   u8 num_rssi = (network_info->str_rssi.u8Full) ?
-  NUM_RSSI : (network_info->str_rssi.u8Index);
+   u8 num_rssi = (network_info->str_rssi.u8_full) ?
+  NUM_RSSI : (network_info->str_rssi.u8_index);
 
for (i = 0; i < num_rssi; i++)
rssi_v += network_info->str_rssi.as8RSSI[i];
@@ -346,13 +346,13 @@ static void add_network_to_shadow(struct network_info 
*pstrNetworkInfo,
} else {
ap_index = ap_found;
}
-   rssi_index = last_scanned_shadow[ap_index].str_rssi.u8Index;
+   rssi_index = last_scanned_shadow[ap_index].str_rssi.u8_index;
last_scanned_shadow[ap_index].str_rssi.as8RSSI[rssi_index++] = 
pstrNetworkInfo->rssi;
if (rssi_index == NUM_RSSI) {
rssi_index = 0;
-   last_scanned_shadow[ap_index].str_rssi.u8Full = 1;
+   last_scanned_shadow[ap_index].str_rssi.u8_full = 1;
}
-   last_scanned_shadow[ap_index].str_rssi.u8Index = rssi_index;
+   last_scanned_shadow[ap_index].str_rssi.u8_index = rssi_index;
last_scanned_shadow[ap_index].rssi = pstrNetworkInfo->rssi;
last_scanned_shadow[ap_index].cap_info = pstrNetworkInfo->cap_info;
last_scanned_shadow[ap_index].ssid_len = pstrNetworkInfo->ssid_len;
-- 
2.7.4

linux-next: Tree for Feb 22

[Stephen Rothwell]

Hi all,

Please do not add any material intended for v4.12 to your linux-next
included branches until after v4.11-rc1 has been released.

Changes since 20170221:

The net-next tree gained a conflict against the s390 tree.

The kspp tree gained conflicts against the net-next tree.

The scsi-mkp tree gained a build failure so I used the version from
next-20170221.

Non-merge commits (relative to Linus' tree): 8853
 9215 files changed, 403921 insertions(+), 184094 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 254 trees (counting Linus' and 37 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (772c8f6f3bbd Merge tag 'for-4.11/linus-merge-signed' of 
git://git.kernel.dk/linux-block)
Merging fixes/master (c470abd4fde4 Linux 4.10)
Merging kbuild-current/rc-fixes (c7858bf16c0b asm-prototypes: Clear any CPP 
defines before declaring the functions)
Merging arc-current/for-curr (8ba605b607b7 ARC: [plat-*] ARC_HAS_COH_CACHES no 
longer relevant)
Merging arm-current/fixes (9e3440481845 ARM: 8658/1: uaccess: fix zeroing of 
64-bit get_user())
Merging m68k-current/for-linus (3dfe33020ca8 m68k/sun3: Remove dead code in 
paging_init())
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (3f91a89d424a powerpc/64: Disable use of radix 
under a hypervisor)
Merging sparc/master (f9a42e0d58cf Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (00ea1ceebe0d ipv6: release dst on error in 
ip6_dst_lookup_tail)
Merging ipsec/master (e3dc847a5f85 vti6: Don't report path MTU below 
IPV6_MIN_MTU.)
Merging netfilter/master (3ef767e5cbd4 Merge branch 'master' of 
git://blackhole.kfki.hu/nf)
Merging ipvs/master (045169816b31 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging wireless-drivers/master (52f5631a4c05 rtlwifi: rtl8192ce: Fix loading 
of incorrect firmware)
Merging mac80211/master (8a96bb837818 mac80211: don't reorder frames with SN 
smaller than SSN)
Merging sound-current/for-linus (34371d236eab ALSA: usb-audio: localize 
function without external linkage)
Merging pci-current/for-linus (afe3e4d11bdf PCI/PME: Restore 
pcie_pme_driver.remove)
Merging driver-core.current/driver-core-linus (49def1853334 Linux 4.10-rc4)
Merging tty.current/tty-linus (49def1853334 Linux 4.10-rc4)
Merging usb.current/usb-linus (d5adbfcd5f7b Linux 4.10-rc7)
Merging usb-gadget-fixes/fixes (efe357f4633a usb: dwc2: host: fix 
Wmaybe-uninitialized warning)
Merging usb-serial-fixes/usb-linus (d07830db1bdb USB: serial: pl2303: add ATEN 
device ID)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (7ce7d89f4883 Linux 4.10-rc1)
Merging staging.current/staging-linus (d5adbfcd5f7b Linux 4.10-rc7)
Merging char-misc.current/char-misc-linus (d5adbfcd5f7b Linux 4.10-rc7)
Merging input-current/for-linus (722c5ac708b4 Input: elan_i2c - add ELAN0605 to 
the ACPI table)
Merging crypto-current/master (7c2cf1c4615c crypto: chcr - Fix key length for 
RFC4106)
Merging ide/master (da095587e6be Revert "ide: Fix interface autodetection in

Re: [Outreachy kernel] [PATCH] staging: xgifb: correct the multiple line dereference to fix coding stye errors

[Joe Perches]

On Wed, 2017-02-22 at 09:46 +0530, Arushi Singhal wrote:
> On Wed, Feb 22, 2017 at 12:12 AM, Joe Perches  wrote:
> 
> > On Tue, 2017-02-21 at 18:40 +0100, Julia Lawall wrote:
> > > 
> > > On Tue, 21 Feb 2017, Arushi Singhal wrote:
> > > 
> > > > Error was reported by checkpatch.pl as
> > > > WARNING: Avoid multiple line dereference...
> > > > if there is boolean operator then it is fixed by Splitting line at
> > > > boolean operator.
> > > 
> > > This is massively execeeding the 80 character boundary, and not for
> > > something trivial like a string.  Maybe the code can be reorganized in
> > > some other way.
> > 
> > The easiest way to do that is to change the test above it
> > to reduce indentation from
> > 
> > if (xgifb_info->display2 == XGIFB_DISP_TV &&
> > xgifb_info->hasVB == HASVB_301) {
> > [code...];
> > }
> > }
> > 
> > to
> > 
> > if (xgifb_info->display2 != XGIFB_DISP_TV ||
> > xgifb_in
> > fo->hasVB != HASVB_301)
> > return;
> > 
> > [code...];
> > }
> > 
> > 
> 
> Hi
> So basically you are saying that cut one word and put the other part of the
> word in the next line.

No, evolution is a horrible email client
that wraps lines oddly sometimes and sends
out different content than it displays in
its on-screen editor.

What I am saying is the block after the test
can be unindented one level by inverting the
test and using return.

It should be:

if (xgifb_info->display2 != XGIFB_DISP_TV ||
xgifb_in> > fo->hasVB != HASVB_301)
return;

[code...];

I sent you a separate attachment privately a
few hours ago but I'll attach it here too.
 drivers/staging/xgifb/XGI_main_26.c | 256 +---
 1 file changed, 92 insertions(+), 164 deletions(-)

diff --git a/drivers/staging/xgifb/XGI_main_26.c b/drivers/staging/xgifb/XGI_main_26.c
index 6930f7eb741b..0df7fb2b8892 100644
--- a/drivers/staging/xgifb/XGI_main_26.c
+++ b/drivers/staging/xgifb/XGI_main_26.c
@@ -731,179 +731,107 @@ static void XGIfb_post_setmode(struct xgifb_video_info *xgifb_info)
 
 	xgifb_reg_and(XGISR, IND_SIS_RAMDAC_CONTROL, ~0x04);
 
-	if (xgifb_info->display2 == XGIFB_DISP_TV &&
-	xgifb_info->hasVB == HASVB_301) {
-		reg = xgifb_reg_get(XGIPART4, 0x01);
+	if (xgifb_info->display2 != XGIFB_DISP_TV ||
+	xgifb_info->hasVB != HASVB_301)
+		return;
 
-		if (reg < 0xB0) { /* Set filter for XGI301 */
-			int filter_tb;
+	reg = xgifb_reg_get(XGIPART4, 0x01);
+	if (reg < 0xB0) { /* Set filter for XGI301 */
+		int filter_tb;
 
-			switch (xgifb_info->video_width) {
-			case 320:
-filter_tb = (xgifb_info->TV_type ==
-	 TVMODE_NTSC) ? 4 : 12;
-break;
-			case 640:
-filter_tb = (xgifb_info->TV_type ==
-	 TVMODE_NTSC) ? 5 : 13;
-break;
-			case 720:
-filter_tb = (xgifb_info->TV_type ==
-	 TVMODE_NTSC) ? 6 : 14;
-break;
-			case 800:
-filter_tb = (xgifb_info->TV_type ==
-	 TVMODE_NTSC) ? 7 : 15;
-break;
-			default:
-filter_tb = 0;
-filter = -1;
-break;
-			}
-			xgifb_reg_or(XGIPART1,
- SIS_CRT2_WENABLE_315,
- 0x01);
+		switch (xgifb_info->video_width) {
+		case 320:
+			filter_tb = xgifb_info->TV_type == TVMODE_NTSC ? 4 : 12;
+			break;
+		case 640:
+			filter_tb = xgifb_info->TV_type == TVMODE_NTSC ? 5 : 13;
+			break;
+		case 720:
+			filter_tb = xgifb_info->TV_type == TVMODE_NTSC ? 6 : 14;
+			break;
+		case 800:
+			filter_tb = xgifb_info->TV_type == TVMODE_NTSC ? 7 : 15;
+			break;
+		default:
+			filter_tb = 0;
+			filter = -1;
+			break;
+		}
+		xgifb_reg_or(XGIPART1, SIS_CRT2_WENABLE_315, 0x01);
 
-			if (xgifb_info->TV_type == TVMODE_NTSC) {
-xgifb_reg_and(XGIPART2, 0x3a, 0x1f);
-
-if (xgifb_info->TV_plug == TVPLUG_SVIDEO) {
-	xgifb_reg_and(XGIPART2, 0x30, 0xdf);
-
-} else if (xgifb_info->TV_plug
-		== TVPLUG_COMPOSITE) {
-	xgifb_reg_or(XGIPART2, 0x30, 0x20);
-
-	switch (xgifb_info->video_width) {
-	case 640:
-		xgifb_reg_set(XGIPART2,
-			  0x35,
-			  0xEB);
-		xgifb_reg_set(XGIPART2,
-			  0x36,
-			  0x04);
-		xgifb_reg_set(XGIPART2,
-			  0x37,
-			  0x25);
-		xgifb_reg_set(XGIPART2,
-			  0x38,
-			  0x18);
-		break;
-	case 720:
-		xgifb_reg_set(XGIPART2,
-			  0x35,
-			  0xEE);
-		xgifb_reg_set(XGIPART2,
-			  0x36,
-			  0x0C);
-		xgifb_reg_set(XGIPART2,
-			  0x37,
-			  0x22);
-		xgifb_reg_set(XGIPART2,
-			  0x38,
-			  0x08);
-		break;
-	case 800:
-		xgifb_reg_set(XGIPART2,
-			  0x35,
-			  0xEB);
-		xgifb_reg_set(XGIPART2,
-			  0x36,
-			  0x15);
-		xgifb_reg_set(XGIPART2,
-			  0x37,
-			  0x25);
-		xgifb_reg_set(XGIPART2,
-			  0x38,
-			  0xF6);
-		break;
-	}
-}
+		if (xgif

Re: [PATCH] gpio: aspeed: Add debounce support

[Joel Stanley]

On Tue, Feb 21, 2017 at 1:10 AM, Andrew Jeffery  wrote:
> Each GPIO in the Aspeed GPIO controller can choose one of four input
> debounce states: to not debounce an input or to select from one of three
> programmable debounce timer values. Each GPIO in a four-bank-set is
> assigned one bit in each of two debounce configuration registers
> dedicated to the set, and selects a debounce state by configuring the
> two bits to select one of the four options.
>
> The limitation on debounce timer values is managed by mapping offsets
> onto a configured timer value and keeping count of the number of users
> a timer has. Timer values are configured on a first-come-first-served
> basis.
>
> A small twist in the hardware design is that the debounce configuration
> register numbering is reversed with respect to the binary representation
> of the debounce timer of interest (i.e. debounce register 1 represents
> bit 1, and debounce register 2 represents bit 0 of the timer numbering).
>
> Open-drain/open-source support also introduced, but merely by deferring
> to the gpiolib emulation (as per the datasheet).
>
> Tested on an AST2500EVB.
>
> Signed-off-by: Andrew Jeffery 

Some questions below. Looks good overall.

> ---
>  drivers/gpio/gpio-aspeed.c | 244 
> -
>  1 file changed, 239 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpio/gpio-aspeed.c b/drivers/gpio/gpio-aspeed.c
> index fb16cc771c0d..164a75272151 100644
> --- a/drivers/gpio/gpio-aspeed.c
> +++ b/drivers/gpio/gpio-aspeed.c


>  struct aspeed_gpio {
> struct gpio_chip chip;
> spinlock_t lock;
> void __iomem *base;
> int irq;
> const struct aspeed_gpio_config *config;
> +
> +   /* Debouncing */
> +   DECLARE_HASHTABLE(offset_timer, 5);

Ohh a hash table. I've not seen one of these in a driver before :)

> +   unsigned int timer_users[3];
> +   struct clk *clk;
>  };
>

> +static int aspeed_gpio_set_debounce(struct gpio_chip *chip, unsigned int 
> offset,
> +   unsigned long usecs)
> +{
> +   const struct aspeed_gpio_bank *bank = to_bank(offset);
> +   struct aspeed_gpio *gpio = gpiochip_get_data(chip);
> +   const u32 mask = GPIO_BIT(offset);
> +   unsigned long flags;
> +   void __iomem *addr;
> +   u32 val;
> +   int rc;
> +
> +   if (!have_debounce(gpio, offset))
> +   return -ENOTSUPP;
> +
> +   if (usecs) {

if (usecs) is the "turn on debounce", and the else is "disable debounce"?

It would be easier to read if we had a enable_debounce and disable_debounce.

> +   struct aspeed_debounce_timer *dt, *newdt;

I thought this was device tree and got really confused. Perhaps 'timer' instead?

> +   u32 requested_cycles;
> +   int i;
> +
> +   /*
> +* TODO: Look at improving these:
> +*
> +* - we always delete users of timers even if the call is for 
> a
> +*   duplicate debounce period for an offset
> +* - we don't reuse struct aspeed_debounce_timer allocations 
> if
> +*   the offset is already using a timer
> +*/
> +
> +   rc = usecs_to_cycles(gpio, usecs, &requested_cycles);
> +   if (rc < 0)
> +   return rc;

Should this produce a warning (as you do below when we're out of timers)?

> +
> +   newdt = devm_kmalloc(chip->parent, sizeof(*dt), GFP_KERNEL);
> +   if (!newdt)
> +   return -ENOMEM;
> +
> +   spin_lock_irqsave(&gpio->lock, flags);
> +
> +   /* Check if the @offset is already using a timer */
> +   hash_for_each_possible(gpio->offset_timer, dt, node, offset) {
> +   if (offset == dt->offset) {
> +   hash_del(&dt->node);
> +   WARN_ON(!gpio->timer_users[dt->timer]);
> +   gpio->timer_users[dt->timer]--;
> +   devm_kfree(chip->parent, dt);
> +   break;
> +   }
> +   }
> +
> +   /*
> +* Check if a timer is already configured for the requested
> +* debounce period. If so, just add @offset as a user of this
> +* timer
> +*/
> +   for (i = 0; i < ARRAY_SIZE(debounce_timers); i++) {
> +   u32 cycles;
> +
> +   addr = gpio->base + debounce_timers[i];
> +   cycles = ioread32(addr);
> +
> +   if (requested_cycles == cycles)
> +   break;
> +   }
> +
> +   /* Otherwise, allocate a timer */

Is "otherwise" in reference to the check above? Is the break above
supposed to be a goto?

> +   

Re: [PATCH] mm: memcontrol: provide shmem statistics

[Balbir Singh]

On Tue, Feb 21, 2017 at 11:43:43AM -0500, Johannes Weiner wrote:
> Cgroups currently don't report how much shmem they use, which can be
> useful data to have, in particular since shmem is included in the
> cache/file item while being reclaimed like anonymous memory.
> 
> Add a counter to track shmem pages during charging and uncharging.
> 
> Reported-by: Chris Down 
> Signed-off-by: Johannes Weiner 
> ---

Makes sense

Acked-by: Balbir Singh 

Re: [PATCH V2 6/7] proc: show MADV_FREE pages info in smaps

[Shaohua Li]

On Wed, Feb 22, 2017 at 11:47:21AM +0900, Minchan Kim wrote:
> On Fri, Feb 03, 2017 at 03:33:22PM -0800, Shaohua Li wrote:
> > Cc: Michal Hocko 
> > Cc: Minchan Kim 
> > Cc: Hugh Dickins 
> > Cc: Johannes Weiner 
> > Cc: Rik van Riel 
> > Cc: Mel Gorman 
> > Cc: Andrew Morton 
> > Signed-off-by: Shaohua Li 
> > ---
> >  fs/proc/task_mmu.c | 8 +++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> > index ee3efb2..8f2423f 100644
> > --- a/fs/proc/task_mmu.c
> > +++ b/fs/proc/task_mmu.c
> > @@ -440,6 +440,7 @@ struct mem_size_stats {
> > unsigned long private_dirty;
> > unsigned long referenced;
> > unsigned long anonymous;
> > +   unsigned long lazyfree;
> > unsigned long anonymous_thp;
> > unsigned long shmem_thp;
> > unsigned long swap;
> > @@ -456,8 +457,11 @@ static void smaps_account(struct mem_size_stats *mss, 
> > struct page *page,
> > int i, nr = compound ? 1 << compound_order(page) : 1;
> > unsigned long size = nr * PAGE_SIZE;
> >  
> > -   if (PageAnon(page))
> > +   if (PageAnon(page)) {
> > mss->anonymous += size;
> > +   if (!PageSwapBacked(page))
> 
> How about this?
> 
>   if (!PageSwapBacked(page) && !dirty && !PageDirty(page))

Yes, already fixed like this.

Thanks,
Shaohua

[PATCH v3] x86/mce: Don't participate in rendezvous process once nmi_shootdown_cpus() was made

[Xunlei Pang]

We met an issue for kdump: after kdump kernel boots up,
and there comes a broadcasted mce in first kernel, the
other cpus remaining in first kernel will enter the old
mce handler of first kernel, then timeout and panic due
to MCE synchronization, finally reset the kdump cpus.

This patch lets cpus stay quiet after nmi_shootdown_cpus(),
so after kdump boots, cpus remaining in 1st kernel should 
not do anything except clearing MCG_STATUS. This is useful
for kdump to let vmcore dumping perform as hard as it can.

Previous efforts:
https://patchwork.kernel.org/patch/6167631/
https://lists.gt.net/linux/kernel/2146557

Cc: Naoya Horiguchi 
Suggested-by: Borislav Petkov 
Signed-off-by: Xunlei Pang 
---
v1->v2:
Using crashing_cpu according to Borislav's suggestion.

v2->v3:
- Used crashing_cpu in mce.c explicitly, not skip crashing_cpu.
- Added some comments.

 arch/x86/include/asm/reboot.h|  1 +
 arch/x86/kernel/cpu/mcheck/mce.c | 12 ++--
 arch/x86/kernel/reboot.c |  5 +++--
 3 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/reboot.h b/arch/x86/include/asm/reboot.h
index 2cb1cc2..fc62ba8 100644
--- a/arch/x86/include/asm/reboot.h
+++ b/arch/x86/include/asm/reboot.h
@@ -15,6 +15,7 @@ struct machine_ops {
 };
 
 extern struct machine_ops machine_ops;
+extern int crashing_cpu;
 
 void native_machine_crash_shutdown(struct pt_regs *regs);
 void native_machine_shutdown(void);
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 8e9725c..1493222 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -49,6 +49,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "mce-internal.h"
 
@@ -1127,9 +1128,16 @@ void do_machine_check(struct pt_regs *regs, long 
error_code)
 * on Intel.
 */
int lmce = 1;
+   int cpu = smp_processor_id();
 
-   /* If this CPU is offline, just bail out. */
-   if (cpu_is_offline(smp_processor_id())) {
+   /*
+* Cases to bail out to avoid rendezvous process timeout:
+* 1)If this CPU is offline.
+* 2)If crashing_cpu was set, e.g. entering kdump,
+*   we need to skip cpus remaining in 1st kernel.
+*/
+   if (cpu_is_offline(cpu) ||
+   (crashing_cpu != -1 && crashing_cpu != cpu)) {
u64 mcgstatus;
 
mcgstatus = mce_rdmsrl(MSR_IA32_MCG_STATUS);
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index e244c19..92ecf4b 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -749,10 +749,11 @@ void machine_crash_shutdown(struct pt_regs *regs)
 #endif
 
 
+/* This keeps a track of which one is crashing cpu. */
+int crashing_cpu = -1;
+
 #if defined(CONFIG_SMP)
 
-/* This keeps a track of which one is crashing cpu. */
-static int crashing_cpu;
 static nmi_shootdown_cb shootdown_callback;
 
 static atomic_t waiting_for_crash_ipi;
-- 
1.8.3.1

Re: [PATCH v4 2/4] phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips

[Vivek Gautam]

Hi Kishon,


On Fri, Jan 27, 2017 at 11:54 AM, Vivek Gautam
 wrote:
>
>
> On 01/26/2017 11:45 PM, Bjorn Andersson wrote:
>>
>> On Tue 24 Jan 01:19 PST 2017, Kishon Vijay Abraham I wrote:
>>>
>>> On Monday 23 January 2017 03:43 PM, Vivek Gautam wrote:

 On Wed, Jan 18, 2017 at 11:33 PM, Bjorn Andersson
>>
>> [..]

 Yes, that's correct. The QMP and QUSB2 phy init sequences are a bunch
 of static values for a particular IP version. These values hardly give a
 meaningful data to put few phy bindings that could be referenced
 to configure the phy further.
>>>
>>> Not really. You can have clearly defined phy binding to give meaningful
>>> data.
>>> Every driver doing the same configuration bloats the driver and these
>>> configuration values are just magic values which hardly can be reviewed
>>> by anyone.
>
> Further more moving this blob to devicetree will not allow us to treat
> the various QMP configurations as one HW block, as there are other
> differences as well.
>
> Like many other drivers it's possible to create a generic version that
> has every bit of logic driven by configuration from devicetree, but
> like
> most of those cases this is not the way we split things.
>
> And this has the side effect of keeping the dts files human readable,
> human understandable and human maintainable.
>>>
>>> right. That's why I recommend having clearly defined bindings.
>>> phy,tx- = 
>>> phy,tx- = 
>>> phy,tx- = 
>>
>> There's no doubt that this table needs to be encoded somewhere, so the
>> question is should we hard code this in a C file or in a DTSI file.
>>
>> Skimming through [1] I see examples of things that differs based on how
>> the specific component is integrated in a SoC or on a particular board -
>> properties that are relevant to a "system integrator".
>>
>> As far as I can tell this blob will, if ever, only be changed by a
>> driver developer and as such it's not carry information about how this
>> component relates to the rest of the system and should as such not be
>> part of the device tree.
>>
>>
>> If there are properties of the hardware that is affected by how the
>> component is integrated in the system I really would like for those to
>> be exposed as human-readable properties that I can understand and alter
>> without deep knowledge about the register map of the hardware block.
>
>
> I am reaching out to our internal teams to get more information
> on different possible phy configurations, based on which the registers
> values are decided.
> This is something that i tried to understand in the past as well, but
> couldn't
> grab much information that time.
> Will come back with relevant information on this.
>

We have started looking into understanding the PHYs on msm and
eventually create a set of generic phy bindings that can serve multiple
platforms.
But this task, I presume, will take its course and will involve multi-party
discussions.

For these QUSB2 and QMP phy drivers, a good amount of work has
already gone in getting these drivers in upstream state.
The common QMP phy driver supports a bunch of controllers on msm
platforms - USB, PCIe and UFS and there are platforms such as DB820c
and others that want to pull in these changes from upstream.
The future phy controllers also depend on these drivers and we don't want
to hold other developers to contribute to these drivers.
So, we wish to not delay these drivers further because of the phy bindings.
I see that there are phys that still program the registers-value pairs for
phy initialization.

We will keep working on the bindings while these patches
make way to upstream.

Can you consider pulling in these drivers?
I can send the next version of these drivers with other comments addressed.
Please let me know your comments.


Regards
Vivek

>
> Regards
> Vivek
>
>>> [1] -> https://www.linuxplumbersconf.org/2016/ocw/proposals/4047
>>
>> Regards,
>> Bjorn
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm"
>> in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
> --
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH V2 1/3] arm64: dts: Add basic DT to support Spreadtrum's SP9860G

[Chunyan Zhang]

Hello Mathieu,

On 二,  2月 21, 2017 at 09:27:44上午 -0700, Mathieu Poirier wrote:
> On Tue, Feb 21, 2017 at 02:55:02PM +0800, Chunyan Zhang wrote:
> > From: Orson Zhai 
> 
> Hello Chunyan,
> 
> > 
> > SC9860G is a 8 cores of A53 SoC with 4G LTE support SoC from Spreadtrum.
> > 
> > According to regular hierarchy of sprd dts, whale2.dtsi contains SoC
> > peripherals IP nodes, sc9860.dtsi contains stuff related to ARM core stuff
> > and sp9860g dts is for the board level.
> > 
> > Signed-off-by: Orson Zhai 
> > Signed-off-by: Chunyan Zhang 
> > ---
> >  arch/arm64/boot/dts/sprd/Makefile |   3 +-
> >  arch/arm64/boot/dts/sprd/sc9860.dtsi  | 531 
> > ++
> >  arch/arm64/boot/dts/sprd/sp9860g-1h10.dts |  56 
> >  arch/arm64/boot/dts/sprd/whale2.dtsi  |  70 
> >  4 files changed, 659 insertions(+), 1 deletion(-)
> >  create mode 100644 arch/arm64/boot/dts/sprd/sc9860.dtsi
> >  create mode 100644 arch/arm64/boot/dts/sprd/sp9860g-1h10.dts
> >  create mode 100644 arch/arm64/boot/dts/sprd/whale2.dtsi
> > 
> > diff --git a/arch/arm64/boot/dts/sprd/Makefile 
> > b/arch/arm64/boot/dts/sprd/Makefile
> > index b658c5e..f0535e6 100644
> > --- a/arch/arm64/boot/dts/sprd/Makefile
> > +++ b/arch/arm64/boot/dts/sprd/Makefile
> > @@ -1,4 +1,5 @@
> > -dtb-$(CONFIG_ARCH_SPRD) += sc9836-openphone.dtb
> > +dtb-$(CONFIG_ARCH_SPRD) += sc9836-openphone.dtb \
> > +   sp9860g-1h10.dtb
> >  
> >  always := $(dtb-y)
> >  subdir-y   := $(dts-dirs)
> > diff --git a/arch/arm64/boot/dts/sprd/sc9860.dtsi 
> > b/arch/arm64/boot/dts/sprd/sc9860.dtsi
> > new file mode 100644
> > index 000..73deb4e
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/sprd/sc9860.dtsi
> > @@ -0,0 +1,531 @@
> > +/*
> > + * Spreadtrum SP9860 SoC DTS file
> > + *
> > + * Copyright (C) 2016, Spreadtrum Communications Inc.
> > + *
> > + * This file is licensed under a dual GPLv2 or X11 license.
> > + */
> > +
> > +#include 
> > +#include "whale2.dtsi"
> > +
> > +/ {
> > +   cpus {
> > +   #address-cells = <2>;
> > +   #size-cells = <0>;
> > +
> > +   cpu-map {
> > +   cluster0 {
> > +   core0 {
> > +   cpu = <&CPU0>;
> > +   };
> > +   core1 {
> > +   cpu = <&CPU1>;
> > +   };
> > +   core2 {
> > +   cpu = <&CPU2>;
> > +   };
> > +   core3 {
> > +   cpu = <&CPU3>;
> > +   };
> > +   };
> > +
> > +   cluster1 {
> > +   core0 {
> > +   cpu = <&CPU4>;
> > +   };
> > +   core1 {
> > +   cpu = <&CPU5>;
> > +   };
> > +   core2 {
> > +   cpu = <&CPU6>;
> > +   };
> > +   core3 {
> > +   cpu = <&CPU7>;
> > +   };
> > +   };
> > +   };
> > +
> > +   CPU0: cpu@53 {
> > +   device_type = "cpu";
> > +   compatible = "arm,cortex-a53", "arm,armv8";
> > +   reg = <0x0 0x53>;
> > +   enable-method = "psci";
> > +   cpu-idle-states = <&CORE_PD &CLUSTER_PD>;
> > +   };
> > +
> > +   CPU1: cpu@530001 {
> > +   device_type = "cpu";
> > +   compatible = "arm,cortex-a53", "arm,armv8";
> > +   reg = <0x0 0x530001>;
> > +   enable-method = "psci";
> > +   cpu-idle-states = <&CORE_PD &CLUSTER_PD>;
> > +   };
> > +
> > +   CPU2: cpu@530002 {
> > +   device_type = "cpu";
> > +   compatible = "arm,cortex-a53", "arm,armv8";
> > +   reg = <0x0 0x530002>;
> > +   enable-method = "psci";
> > +   cpu-idle-states = <&CORE_PD &CLUSTER_PD>;
> > +   };
> > +
> > +   CPU3: cpu@530003 {
> > +   device_type = "cpu";
> > +   compatible = "arm,cortex-a53", "arm,armv8";
> > +   reg = <0x0 0x530003>;
> > +   enable-method = "psci";
> > +   cpu-idle-states = <&CORE_PD &CLUSTER_PD>;
> > +   };
> > +
> > +   CPU4: cpu@530100 {
> > +   device_type = "cpu";
> > +   compatible = "arm,cortex-a53", "arm,armv8";
> > +   reg = <0x0 0x530100>;
> > +   enable-method = "psci";
> > +   cpu-idle-states = <&CORE_PD &CLUSTER_PD>;
> > +   };
> > +
> > +  

Re: [RFC 7/8] fpga-region: add sysfs interface

[Moritz Fischer]

Hi Sundar,

On Tue, Feb 21, 2017 at 7:13 PM, Nadathur, Sundar
 wrote:

>> >>> Is there a standard you are looking at?  Have you seen any use of
>> >>> TLV's in the Linux kernel you could point to?
>
> Here are some examples of TLVs in the Linux kernel:
> http://lxr.free-electrons.com/source/net/ipv6/exthdrs.c <-- includes TLV 
> parsing code
> http://lxr.free-electrons.com/source/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c
> http://lxr.free-electrons.com/source/include/sound/tlv.h
>
> In addition, some protocols like LLDP are defined in terms of TLVs. E.g.
> http://lxr.free-electrons.com/source/drivers/net/ethernet/intel/i40e/i40e_dcb.h?v=4.4

Thanks for the examples, looks interesting. I'll do some reading.

>> >> On Sun, Feb 19, 2017 at 9:00 AM, Alan Tull 
>> wrote:
>> >>> It is worth repeating that libdtc is GPL/BSD with the intent of
>> >>> allowing proprietary code to use libdtc.  So license shouldn't be a 
>> >>> barrier.
> It is better to check with Windows folks before concluding this.

About whether they can link C code? Or whether BSD licensed code is an issue?

> I agree that device enumeration should be separated out from the metadata 
> format considerations.
>
> I got some feedback that not everybody may be familiar with TLVs. To make the 
> proposal more clear and specific, let me add more information here.
> * We represent every datum of interest with its Type (which indicates what it 
> is), a Length (how many bytes it takes) and a Value (its actual value, taking 
> as many bytes as the Length field indicates.)
> * The exact lengths of the Type and Length fields are up to us, but let us 
> say they are 4 bytes each, for concreteness. As an example, say we want to 
> express the function in the FPGA (crypto, compress, etc.) as a UUID (128 bits 
> long) compliant with RFC 4122. We could have a Type of say 0x0050 (4 
> bytes in all) to indicate Function UUIDs, and a Length field of 0x0010 
> (16 bytes) and a value of say 3d8814d8-4ecc-4030-8415-0dea4e5e829a .
> * A Type may indicate that its value is another TLV, thus allowing nested 
> TLVs. The nested TLV may be an array of TLVs (all of same Type) or a 
> structure (TLVs of different Types).
>
> With a Key-Value Pair, if the parser comes across an unknown key (such as 
> when an old parser comes across newer metadata), it would not know how to 
> skip that KVP and move onto the next one. With TLVs, that flexibility is 
> built in. Further, we can use bits in the Type field to indicate that it is 
> mandatory, i.e., if the parser does not understand it, it should error out 
> rather than skip it silently. This degree of forward compatibility is 
> difficult to achieve with other formats.

fdt does this out of the box, too. So far I've seen nothing fdt
couldn't do (or doesn't do let's rather say).

Thanks for clarifying the TLV stuff,

Moritz

Re: [PATCH net-next] virtio-net: switch to use build_skb() for small buffer

[Michael S. Tsirkin]

On Wed, Feb 22, 2017 at 11:17:50AM +0800, Jason Wang wrote:
> 
> 
> On 2017年02月22日 11:06, Michael S. Tsirkin wrote:
> > On Wed, Feb 22, 2017 at 10:58:08AM +0800, Jason Wang wrote:
> > > 
> > > On 2017年02月21日 22:37, Michael S. Tsirkin wrote:
> > > > On Tue, Feb 21, 2017 at 04:46:28PM +0800, Jason Wang wrote:
> > > > > This patch switch to use build_skb() for small buffer which can have
> > > > > better performance for both TCP and XDP (since we can work at page
> > > > > before skb creation). It also remove lots of XDP codes since both
> > > > > mergeable and small buffer use page frag during refill now.
> > > > > 
> > > > >  Before   | After
> > > > > XDP_DROP(xdp1) 64B  :  11.1Mpps | 14.4Mpps
> > > > > 
> > > > > Tested with xdp1/xdp2/xdp_ip_tx_tunnel and netperf.
> > > > > 
> > > > > Signed-off-by: Jason Wang
> > > > Thanks!
> > > > I had a similar patch for mergeable too, though it's trickier there
> > > > as host has a lot of flexibility in sizing buffers.
> > > > Looks like a good intermediate step to me.
> > > Yes, I think it's more tricky for the case of mergeable buffer:
> > > 
> > > 1) we need reserve NET_SKB_PAD + NET_IP_ALIGN for each buffer, this will
> > > break rx frag coalescing
> > > 2) need tailroom for skb_shinfo, so it won't work for all size of packet
> > > 
> > > Thanks
> > Have you seen my prototype?
> 
> Not yet, please give me a pointer.
> 
> >   It works with qemu in practice,
> > just needs to cover a bunch of corner cases.
> 
> Sounds good, if you wish I can help to finalize it.
> 
> Thanks
> 
> > 
> > > > 
> > > > Acked-by: Michael S. Tsirkin
> > > > 


Great! Here it is I think it's on top of 4.9 or so. Issues to address:
- when ring is very small this might cause us not to
  be able to fit even a single packet in the whole queue.
  Limit logic to when ring is big enough?
- If e.g. header is split across many buffers, this won't work
  correctly. Detect and copy?

Could be more issues that I forgot. It might be a good idea to
first finish my buffer ctx hack. Will simplify the logic.


commit 77c177091a7c8473e3f0ed148afa2b4765b8b0f7
Author: Michael S. Tsirkin 
Date:   Sun Feb 21 20:22:31 2016 +0200

virtio_net: switch to build_skb for mrg_rxbuf

For small packets data copy was observed to
take up about 15% CPU time. Switch to build_skb
and avoid the copy when using mergeable rx buffers.

As a bonus, medium-size skbs that fit in a page will be
completely linear.

Of course, we now need to lower the lower bound on packet size,
to make sure a sane number of skbs fits in rx socket buffer.
By how much? I don't know yet.

It might also be useful to prefetch the packet buffer since
net stack will likely use it soon.

TODO: it appears that Linux won't handle correctly the case of first
buffer being very small (or consisting exclusively of virtio header).
This is already the case for current code, so don't bother
testing yet.
TODO: might be unfair to the last packet in a fragment as we include
remaining space if any in its truesize.

Signed-off-by: Michael S. Tsirkin 

diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index b425fa1..a6b996f 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -38,6 +38,8 @@ module_param(gso, bool, 0444);
 
 /* FIXME: MTU in config. */
 #define GOOD_PACKET_LEN (ETH_HLEN + VLAN_HLEN + ETH_DATA_LEN)
+//#define MIN_PACKET_ALLOC GOOD_PACKET_LEN
+#define MIN_PACKET_ALLOC 128
 #define GOOD_COPY_LEN  128
 
 /* RX packet size EWMA. The average packet size is used to determine the packet
@@ -246,6 +248,9 @@ static void *mergeable_ctx_to_buf_address(unsigned long 
mrg_ctx)
 static unsigned long mergeable_buf_to_ctx(void *buf, unsigned int truesize)
 {
unsigned int size = truesize / MERGEABLE_BUFFER_ALIGN;
+
+   BUG_ON((unsigned long)buf & (MERGEABLE_BUFFER_ALIGN - 1));
+   BUG_ON(size - 1 >= MERGEABLE_BUFFER_ALIGN);
return (unsigned long)buf | (size - 1);
 }
 
@@ -354,25 +359,54 @@ static struct sk_buff *receive_big(struct net_device *dev,
return NULL;
 }
 
+#define VNET_SKB_PAD (NET_SKB_PAD + NET_IP_ALIGN)
+#define VNET_SKB_BUG (VNET_SKB_PAD < sizeof(struct virtio_net_hdr_mrg_rxbuf))
+#define VNET_SKB_LEN(len) ((len) - sizeof(struct virtio_net_hdr_mrg_rxbuf))
+#define VNET_SKB_OFF VNET_SKB_LEN(VNET_SKB_PAD)
+
+static struct sk_buff *vnet_build_skb(struct virtnet_info *vi,
+ void *buf,
+ unsigned int len, unsigned int truesize)
+{
+   struct sk_buff *skb = build_skb(buf, truesize);
+
+   if (!skb)
+   return NULL;
+
+   skb_reserve(skb, VNET_SKB_PAD);
+   skb_put(skb, VNET_SKB_LEN(len));
+
+   return skb;
+}
+
 static struct sk_buff *receive_mergeable(struct net_device *dev,
 struct virtnet_info *vi,
 stru

Re: [PATCH] pinctrl: aspeed: Add initial pinconf support

[Joel Stanley]

On Tue, Feb 21, 2017 at 1:08 AM, Andrew Jeffery  wrote:
> Several pinconf parameters have a fairly straight-forward mapping onto
> the Aspeed pin controller. These include management of pull-down bias,
> drive-strength, and some debounce configuration.
>
> Pin biasing largely is managed on a per-GPIO-bank basis, aside from the
> ADC and RMII/RGMII pins. As the bias configuration for each pin in a
> bank maps onto a single per-bank bit, configuration tables are
> introduced to describe the ranges of pins and the supported pinconf
> parameter. The use of tables also helps with the sparse support of
> pinconf properties, and the fact that not all GPIO banks support
> biasing or drive-strength configuration.
>
> Further, as the pin controller uses a consistent approach for bias and
> drive strength configuration at the register level, a second table is
> defined for looking up the the bit-state required to enable or query the
> provided configuration.
>
> Testing for pinctrl-aspeed-g4 was performed on an OpenPOWER Palmetto
> system, and pinctrl-aspeed-g5 on an AST2500EVB. The test method was to
> set the appropriate bits via devmem and verify the result through the
> controller's pinconf-pins debugfs file. This simultaneously validates
> the get() path and half of the set() path. The remainder of the set()
> path was validated by configuring a handful of pins via the devicetree
> with the supported pinconf properties and verifying the appropriate
> registers were touched.
>
> Signed-off-by: Andrew Jeffery 

Looks good. I assume the bindings are generic and don't need any
update for this. Perhaps an update to the example would be helpful.

Some minor comments below.

> ---
>  drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c | 117 +++-
>  drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 153 -
>  drivers/pinctrl/aspeed/pinctrl-aspeed.c| 207 
> +
>  drivers/pinctrl/aspeed/pinctrl-aspeed.h|  28 
>  4 files changed, 503 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c 
> b/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c
> index 7de596e2b9d4..3e8625110136 100644
> --- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c
> +++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c
> @@ -2234,6 +2234,110 @@ static const struct aspeed_pin_function 
> aspeed_g4_functions[] = {
> ASPEED_PINCTRL_FUNC(WDTRST2),
>  };
>
> +static struct aspeed_pin_config aspeed_g4_configs[] = {

I think this could be const.

> +   /* GPIO banks ranges [A, B], [D, J], [M, R] */
> +   { PIN_CONFIG_BIAS_PULL_DOWN, { D6,  D5  }, SCU8C, BIT(16) },
> +   { PIN_CONFIG_BIAS_DISABLE,   { D6,  D5  }, SCU8C, BIT(16) },
> +   { PIN_CONFIG_BIAS_PULL_DOWN, { J21, E18 }, SCU8C, BIT(17) },
> +   { PIN_CONFIG_BIAS_DISABLE,   { J21, E18 }, SCU8C, BIT(17) },

I didn't verify every definition is correct. I wondered why we skipped
bit 18, but it is reserved by the looks.

> +   { PIN_CONFIG_BIAS_PULL_DOWN, { A18, E15 }, SCU8C, BIT(19) },
> +   { PIN_CONFIG_BIAS_DISABLE,   { A18, E15 }, SCU8C, BIT(19) },
> +   { PIN_CONFIG_BIAS_PULL_DOWN, { D15, B14 }, SCU8C, BIT(20) },
> +   { PIN_CONFIG_BIAS_DISABLE,   { D15, B14 }, SCU8C, BIT(20) },

> diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c 
> b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
> index 43221a3c7e23..b22523bdd79b 100644
> --- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
> +++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c

>  static struct pinmux_ops aspeed_g5_pinmux_ops = {
> @@ -2308,16 +2450,25 @@ static struct pinctrl_ops aspeed_g5_pinctrl_ops = {
> .get_group_name = aspeed_pinctrl_get_group_name,
> .get_group_pins = aspeed_pinctrl_get_group_pins,
> .pin_dbg_show = aspeed_pinctrl_pin_dbg_show,
> -   .dt_node_to_map = pinconf_generic_dt_node_to_map_pin,
> +   .dt_node_to_map = pinconf_generic_dt_node_to_map_all,
> .dt_free_map = pinctrl_utils_free_map,
>  };
>
> +static struct pinconf_ops aspeed_g5_conf_ops = {

const here too?

> +   .is_generic = true,
> +   .pin_config_get = aspeed_pin_config_get,
> +   .pin_config_set = aspeed_pin_config_set,
> +   .pin_config_group_get = aspeed_pin_config_group_get,
> +   .pin_config_group_set = aspeed_pin_config_group_set,
> +};

> --- a/drivers/pinctrl/aspeed/pinctrl-aspeed.h
> +++ b/drivers/pinctrl/aspeed/pinctrl-aspeed.h
> @@ -514,6 +514,20 @@ struct aspeed_pin_desc {
> SIG_EXPR_LIST_DECL_SINGLE(gpio, gpio); \
> MS_PIN_DECL_(pin, SIG_EXPR_LIST_PTR(gpio))
>
> +/**
> + * @param The pinconf parameter type
> + * @pins The pin range this config struct covers, [low, high]
> + * @reg The register housing the configuration bits
> + * @mask The mask to select the bits of interest in @reg
> + */
> +struct aspeed_pin_config {
> +   enum pin_config_param param;
> +   unsigned int pins[2];
> +   unsigned int reg;
> +   u32 mask;
> +   u32 value;

Can we s

Re: [PATCH net-next] virtio-net: switch to use build_skb() for small buffer

[Jason Wang]

On 2017年02月22日 11:17, Jason Wang wrote:



On 2017年02月22日 11:06, Michael S. Tsirkin wrote:

On Wed, Feb 22, 2017 at 10:58:08AM +0800, Jason Wang wrote:


On 2017年02月21日 22:37, Michael S. Tsirkin wrote:

On Tue, Feb 21, 2017 at 04:46:28PM +0800, Jason Wang wrote:

This patch switch to use build_skb() for small buffer which can have
better performance for both TCP and XDP (since we can work at page
before skb creation). It also remove lots of XDP codes since both
mergeable and small buffer use page frag during refill now.

 Before   | After
XDP_DROP(xdp1) 64B  :  11.1Mpps | 14.4Mpps

Tested with xdp1/xdp2/xdp_ip_tx_tunnel and netperf.

Signed-off-by: Jason Wang

Thanks!
I had a similar patch for mergeable too, though it's trickier there
as host has a lot of flexibility in sizing buffers.
Looks like a good intermediate step to me.

Yes, I think it's more tricky for the case of mergeable buffer:

1) we need reserve NET_SKB_PAD + NET_IP_ALIGN for each buffer, this 
will

break rx frag coalescing
2) need tailroom for skb_shinfo, so it won't work for all size of 
packet


Thanks

Have you seen my prototype?


Not yet, please give me a pointer.


FYI, I posted a prototype during EWMA discussion in 2013:

https://lists.linuxfoundation.org/pipermail/virtualization/2013-October/025556.html

RE: [PATCH] net: intel: e1000e: use new api ethtool_{get|set}_link_ksettings

[Brown, Aaron F]

> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Philippe Reynes
> Sent: Thursday, January 26, 2017 1:20 PM
> To: Kirsher, Jeffrey T ; da...@davemloft.net
> Cc: intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Philippe Reynes 
> Subject: [PATCH] net: intel: e1000e: use new api
> ethtool_{get|set}_link_ksettings
> 
> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
> 
> As I don't have the hardware, I'd be very pleased if
> someone may test this patch.
> 
> Signed-off-by: Philippe Reynes 
> ---
>  drivers/net/ethernet/intel/e1000e/ethtool.c |   91 ++-
> ---
>  1 files changed, 49 insertions(+), 42 deletions(-)

Tested-by: Aaron Brown 

Re: [PATCH V2 4/6] PM / domain: Register for PM QOS performance notifier

[Viresh Kumar]

On 21-02-17, 16:28, Ulf Hansson wrote:
> A genpd PM domain can have several parents (or to use the genpd
> terminology, masters).
> 
> This is different from allowing a device to be attached to more than
> one PM domains, which is what I think you are referring to. That isn't
> supported.

Thanks for clarifying. Got it now.

-- 
viresh

Re: [GIT PULL] modules updates for 4.11

[Jessica Yu]

+++ Jessica Yu [21/02/17 17:27 -0800]:

Linus,

Please pull below to receive modules updates for the 4.11 merge window.
All small code cleanups this time around. Summary in the tag.

Thanks,

Jessica


I've forgotten to CC lkml (now added to cc), my mistake!


---
The following changes since commit 0c744ea4f77d72b3dcebb7a8f2684633ec79be88:

Linux 4.10-rc2 (2017-01-01 14:31:53 -0800)

are available in the git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/jeyu/linux.git 
tags/modules-for-v4.11

for you to fetch changes up to 0d4ec7849f5a197d46c062a49f47ed326dd0388c:

MAINTAINERS: add tree for modules (2017-02-21 12:35:11 -0800)


Modules updates for v4.11

Summary of modules changes for the 4.11 merge window:

- A few small code cleanups

- Add modules git tree url to MAINTAINERS

Signed-off-by: Jessica Yu 


Arnd Bergmann (1):
modules: mark __inittest/__exittest as __maybe_unused

Jean Delvare (1):
module: Drop redundant declaration of struct module

Jessica Yu (1):
MAINTAINERS: add tree for modules

Joe Lawrence (1):
livepatch/module: print notice of TAINT_LIVEPATCH

Luis R. Rodriguez (1):
module: fix memory leak on early load_module() failures

Peter Zijlstra (1):
module: Optimize search_module_extables()

MAINTAINERS|  1 +
include/linux/module.h |  6 ++
kernel/module.c| 30 +-
3 files changed, 20 insertions(+), 17 deletions(-)

Re: [PATCH net-next] virtio-net: switch to use build_skb() for small buffer

[Jason Wang]

On 2017年02月22日 11:06, Michael S. Tsirkin wrote:

On Wed, Feb 22, 2017 at 10:58:08AM +0800, Jason Wang wrote:


On 2017年02月21日 22:37, Michael S. Tsirkin wrote:

On Tue, Feb 21, 2017 at 04:46:28PM +0800, Jason Wang wrote:

This patch switch to use build_skb() for small buffer which can have
better performance for both TCP and XDP (since we can work at page
before skb creation). It also remove lots of XDP codes since both
mergeable and small buffer use page frag during refill now.

 Before   | After
XDP_DROP(xdp1) 64B  :  11.1Mpps | 14.4Mpps

Tested with xdp1/xdp2/xdp_ip_tx_tunnel and netperf.

Signed-off-by: Jason Wang

Thanks!
I had a similar patch for mergeable too, though it's trickier there
as host has a lot of flexibility in sizing buffers.
Looks like a good intermediate step to me.

Yes, I think it's more tricky for the case of mergeable buffer:

1) we need reserve NET_SKB_PAD + NET_IP_ALIGN for each buffer, this will
break rx frag coalescing
2) need tailroom for skb_shinfo, so it won't work for all size of packet

Thanks

Have you seen my prototype?


Not yet, please give me a pointer.


  It works with qemu in practice,
just needs to cover a bunch of corner cases.


Sounds good, if you wish I can help to finalize it.

Thanks





Acked-by: Michael S. Tsirkin

RE: [RFC 7/8] fpga-region: add sysfs interface

[Nadathur, Sundar]

> -Original Message-
> From: Alan Tull [mailto:delicious.qui...@gmail.com]
> Sent: Tuesday, February 21, 2017 10:33 AM
> To: Moritz Fischer 
> Cc: Nadathur, Sundar ; Yves Vandervennet
> ; Jason Gunthorpe
> ; matthew.gerl...@linux.intel.com;
> linux-kernel ; linux-f...@vger.kernel.org;
> Marek Vašut 
> Subject: Re: [RFC 7/8] fpga-region: add sysfs interface
> 
> On Mon, Feb 20, 2017 at 5:49 PM, Moritz Fischer
>  wrote:
> > Hi Alan,
> >
> > On Sun, Feb 19, 2017 at 3:16 PM, Alan Tull 
> wrote:
> >> On Sun, Feb 19, 2017 at 9:00 AM, Alan Tull 
> wrote:
> >>> On Sat, Feb 18, 2017 at 2:45 PM, Moritz Fischer
> >>>  wrote:
>  On Sat, Feb 18, 2017 at 02:10:43PM -0600, Alan Tull wrote:
> > On Sat, Feb 18, 2017 at 6:45 AM, Nadathur, Sundar
> >  wrote:
> >
> > > Hi all,
> > >Interesting discussion. The discussion so far has brought out many
> concerns such as OS independence. There is an existing format, well-known
> to developers, with widespread support, and which is quite extensible: Type-
> Length-Value triples.
> >>> [...]
>  Are there other users of the format? I have to admit I didn't look
>  very long, but couldn't find any libs / existing code at a first glance.
> >>>
> >>> Is there a standard you are looking at?  Have you seen any use of
> >>> TLV's in the Linux kernel you could point to? 

Here are some examples of TLVs in the Linux kernel:
http://lxr.free-electrons.com/source/net/ipv6/exthdrs.c <-- includes TLV 
parsing code
http://lxr.free-electrons.com/source/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c
 
http://lxr.free-electrons.com/source/include/sound/tlv.h 

In addition, some protocols like LLDP are defined in terms of TLVs. E.g.
http://lxr.free-electrons.com/source/drivers/net/ethernet/intel/i40e/i40e_dcb.h?v=4.4
 

> >> On Sun, Feb 19, 2017 at 9:00 AM, Alan Tull 
> wrote:
> >>> It is worth repeating that libdtc is GPL/BSD with the intent of
> >>> allowing proprietary code to use libdtc.  So license shouldn't be a 
> >>> barrier.
It is better to check with Windows folks before concluding this. 

> >> If we use key/value pairs, we could pass in child device info in one
> >> of the keys.  It could be either a device tree overlay or an ACPI
> >> overlay.  Or could just be left out.  So platforms that aren't
> >> already using DT wouldn't have to.  Platforms that are have a smooth
> >> road to enumeration.
> >
> > I'm not sure if you can bundle up enumeration info *with* the image
> > since you might e.g.
> > load the same image (i.e. same header) into different FPGAs and the
> > required update to the kernel state, i.e. live tree or ACPI would
> > depend entirely on which FPGA you loaded the image into w.r.t busses
> > it's connected to etc.
> >
> > I do think this info cannot be image specific, but needs to be passed
> > in via something external such as a dt overlay.
> 
> Yes, I think you are right about that.
> 
> Thanks!
> Alan

I agree that device enumeration should be separated out from the metadata 
format considerations. 

I got some feedback that not everybody may be familiar with TLVs. To make the 
proposal more clear and specific, let me add more information here.
* We represent every datum of interest with its Type (which indicates what it 
is), a Length (how many bytes it takes) and a Value (its actual value, taking 
as many bytes as the Length field indicates.)  
* The exact lengths of the Type and Length fields are up to us, but let us say 
they are 4 bytes each, for concreteness. As an example, say we want to express 
the function in the FPGA (crypto, compress, etc.) as a UUID (128 bits long) 
compliant with RFC 4122. We could have a Type of say 0x0050 (4 bytes in 
all) to indicate Function UUIDs, and a Length field of 0x0010 (16 bytes) 
and a value of say 3d8814d8-4ecc-4030-8415-0dea4e5e829a . 
* A Type may indicate that its value is another TLV, thus allowing nested TLVs. 
The nested TLV may be an array of TLVs (all of same Type) or a structure (TLVs 
of different Types). 

With a Key-Value Pair, if the parser comes across an unknown key (such as when 
an old parser comes across newer metadata), it would not know how to skip that 
KVP and move onto the next one. With TLVs, that flexibility is built in. 
Further, we can use bits in the Type field to indicate that it is mandatory, 
i.e., if the parser does not understand it, it should error out rather than 
skip it silently. This degree of forward compatibility is difficult to achieve 
with other formats. 

Thanks,
Sundar

Re: [PATCH v20 2/4] mailbox: mediatek: Add Mediatek CMDQ driver

[Horng-Shyang Liao]

On Thu, 2017-02-16 at 21:02 +0530, Jassi Brar wrote:
> On Mon, Feb 6, 2017 at 11:07 AM, Horng-Shyang Liao  
> wrote:
> > Hi Jassi,
> >
> > On Wed, 2017-02-01 at 10:52 +0530, Jassi Brar wrote:
> >> On Thu, Jan 26, 2017 at 2:07 PM, Horng-Shyang Liao  
> >> wrote:
> >> > Hi Jassi,
> >> >
> >> > On Thu, 2017-01-26 at 10:08 +0530, Jassi Brar wrote:
> >> >> On Wed, Jan 4, 2017 at 8:36 AM, HS Liao  wrote:
> >> >>
> >> >> > diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c 
> >> >> > b/drivers/mailbox/mtk-cmdq-mailbox.c
> >> >> > new file mode 100644
> >> >> > index 000..747bcd3
> >> >> > --- /dev/null
> >> >> > +++ b/drivers/mailbox/mtk-cmdq-mailbox.c
> >> >>
> >> >> ...
> >> >>
> >> >> > +static void cmdq_task_exec(struct cmdq_pkt *pkt, struct cmdq_thread 
> >> >> > *thread)
> >> >> > +{
> >> >> > +   struct cmdq *cmdq;
> >> >> > +   struct cmdq_task *task;
> >> >> > +   unsigned long curr_pa, end_pa;
> >> >> > +
> >> >> > +   cmdq = dev_get_drvdata(thread->chan->mbox->dev);
> >> >> > +
> >> >> > +   /* Client should not flush new tasks if suspended. */
> >> >> > +   WARN_ON(cmdq->suspended);
> >> >> > +
> >> >> > +   task = kzalloc(sizeof(*task), GFP_ATOMIC);
> >> >> > +   task->cmdq = cmdq;
> >> >> > +   INIT_LIST_HEAD(&task->list_entry);
> >> >> > +   task->pa_base = dma_map_single(cmdq->mbox.dev, pkt->va_base,
> >> >> > +  pkt->cmd_buf_size, 
> >> >> > DMA_TO_DEVICE);
> >> >> >
> >> >> You seem to parse the requests and responses, that should ideally be
> >> >> done in client driver.
> >> >> Also, we are here in atomic context, can you move it in client driver
> >> >> (before the spin_lock)?
> >> >> Maybe by adding a new 'pa_base' member as well in 'cmdq_pkt'.
> >> >
> >> > will do
> >
> > I agree with moving dma_map_single out from spin_lock.
> >
> > However, mailbox clients cannot map virtual memory to mailbox
> > controller's device for DMA.
> >
> If DMA is a resource used by MBox to transfer data, then yes the
> mapping needs to be done in the Mbox controller driver. To map memory
> outside of spinlock, you could schedule a tasklet in send_data() ?

Hi Jassi,

For CMDQ, the order of CMDQ tasks should be guaranteed.
However, it seems tasklet cannot ensure this requirement.

Quote from Linux Device Drivers 3rd edition ch7.
"void tasklet_schedule(struct tasklet_struct *t);
  Schedule the tasklet for execution. If a tasklet is scheduled again
before it has a chance to run, it runs only once"

May I use workqueue instead of tasklet?

Thanks,
HS

Re: next_tick hang was Re: v4.10-rc8 (-rc6) boot regression on Intel desktop, does not boot after cold boots, boots after reboot

[Frederic Weisbecker]

On Sat, Feb 18, 2017 at 11:23:39AM +0100, Pavel Machek wrote:
> On Sat 2017-02-18 10:39:17, Pavel Machek wrote:
> > Hi!
> > 
> > [I droped some CCs here, you may want to check the CC list].
> > 
> > > > These are different bugs.
> > > > 
> > > > On x60, I see failures doing hotplug/unplug in a loop, or lot of
> > > > suspends. Someone seen it in v4.8-stable etc. Old bug. Rare to hit.
> > > > 
> > > > Desktop machine was failing to boot, and had some fun with
> > > > suspend/resume too. Boot hang was reproducible with right
> > > > procedure. (Hard poweroff, cold boot.). That one was introduced in
> > > > 4.10-rc cycle.
> > > 
> > > Pavel, is there any chance you could apply this patch on top of latest 
> > > linus tree
> > > and send me your resulting dmesg log? This has the two reverted patches 
> > > plus some
> > > debugging code. The amount of printk shouldn't be too big, I tested it 
> > > home without
> > > issue.
> > > 
> > > If you can't manage to dump the dmesg, please try to take a picture of 
> > > your screen
> > > so that I can see the last messages starting with "NEXT_TICK_READ".
> > > 
> > > Thanks!
> > 
> > I guess I can. But I'll only have one 80x25 screen to look at...
> 
> Ok, here it is.

Thanks, I haven't been able to deduce much though, except that the pending 
timer on CPU 0
looks quite far away.

Could you please add "initcall_debug" in your kernel parameters to identify if 
we are blocking in
a specific initcall? If so it should tell us which one.

Thanks!

Re: [PATCH net-next] virtio-net: switch to use build_skb() for small buffer

[Michael S. Tsirkin]

On Wed, Feb 22, 2017 at 10:58:08AM +0800, Jason Wang wrote:
> 
> 
> On 2017年02月21日 22:37, Michael S. Tsirkin wrote:
> > On Tue, Feb 21, 2017 at 04:46:28PM +0800, Jason Wang wrote:
> > > This patch switch to use build_skb() for small buffer which can have
> > > better performance for both TCP and XDP (since we can work at page
> > > before skb creation). It also remove lots of XDP codes since both
> > > mergeable and small buffer use page frag during refill now.
> > > 
> > > Before   | After
> > > XDP_DROP(xdp1) 64B  :  11.1Mpps | 14.4Mpps
> > > 
> > > Tested with xdp1/xdp2/xdp_ip_tx_tunnel and netperf.
> > > 
> > > Signed-off-by: Jason Wang
> > Thanks!
> > I had a similar patch for mergeable too, though it's trickier there
> > as host has a lot of flexibility in sizing buffers.
> > Looks like a good intermediate step to me.
> 
> Yes, I think it's more tricky for the case of mergeable buffer:
> 
> 1) we need reserve NET_SKB_PAD + NET_IP_ALIGN for each buffer, this will
> break rx frag coalescing
> 2) need tailroom for skb_shinfo, so it won't work for all size of packet
> 
> Thanks

Have you seen my prototype? It works with qemu in practice,
just needs to cover a bunch of corner cases.


> > 
> > 
> > Acked-by: Michael S. Tsirkin
> > 

Re: Problem on SCTP

[Xin Long]

On Wed, Feb 22, 2017 at 10:29 AM, Sun Paul  wrote:
> Hi Xin
>
> do you mean we need to patch the kernel?
Yups, pls comment on that bz if it's really needed for your env.
A z-stream kernel may be available for that issue soon.

Thanks.

>
>
>
> On Wed, Feb 22, 2017 at 10:00 AM, Xin Long  wrote:
>> On Wed, Feb 22, 2017 at 9:12 AM, Sun Paul  wrote:
>>> Hi
>>>
>>> the router is actually is a linux running on RHEL6.8
>>> (2.6.32-642.4.2.el6.x86_64). it uses iptables to do SNAT aand DNAT
>>> forward.
>> https://bugzilla.redhat.com/show_bug.cgi?id=1412038
>>
>> sctp_manip_pkt->sctp_compute_cksum:
>> struct sctphdr *sh = sctp_hdr(sub);
>>
>> But in rhel6, skb->transport_header is not yet set at that time.
>> This patch should be backported into rhel6.
>>
>> commit 21d1196a35f5686c4323e42a62fdb4b23b0ab4a3
>> Author: Eric Dumazet 
>> Date:   Mon Jul 15 20:03:19 2013 -0700
>>
>> ipv4: set transport header earlier
>>
>>
>>>
>>> On Tue, Feb 21, 2017 at 11:53 PM, Xin Long  wrote:
 On Tue, Feb 21, 2017 at 12:26 PM, Sun Paul  wrote:
> Hi,
>
> sorry to get back late, the platform is running on KVM. and this
> problem is resolved by moving to VMware environment, however,  a new
> problem is coming out, we noticed that the HB REQ is being ABORT from
> client.
>
>
> 03:32:35.233572 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1)
> [HB REQ] (from server to sctp router)
> 03:32:35.233603 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1)
> [HB REQ] (from sctp router to client)
> 03:32:35.233852 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1)
> [ABORT] (from client to sctp router)
>
> 03:32:37.928679 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1) [HB 
> REQ]
> 03:32:37.928717 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1) [HB 
> REQ]
> 03:32:37.929247 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1) 
> [ABORT]
>
> For the above packet flow, 10.165.250.22 is the server and
> 192.168.2.13 is the client, the server 10.165.250.22 sends HB REQ to
> client 192.168.2.13 through 192.168.2.14 (the SCTP router), and the
> SCTP router change the src address before forward the HB REQ to the
> client.
>
> But somehow the client is ABORT the HB REQ, any idea? is it related to
> the HEARTBEAT information? or the checksum again>?
 The incorrect checksum won't cause ABORT, but the abnormal HB REQ
 could be, if HB information was modified when calculating the checksum
 on router, the ABORT may be caused in client process.

 is your SCTP router linux ? if yes, what's the kernel version ?

>
> On Fri, Jan 13, 2017 at 9:19 PM, Michael Tuexen
>  wrote:
>>> On 13 Jan 2017, at 10:43, Michael Tuexen 
>>>  wrote:
>>>
>>> Your router does NOT change any field in the SCTP packet, but the
>>> SCTP checksum was modified from
>>>   Checksum: 0xbaea49e5 (not verified)
>>> to
>>>   Checksum: 0xa9a86d3f (not verified)
>>> At least one of these is wrong. Read the tracefiles in wireshark and
>>> enable checksum validation and wireshark will tell you which one is
>>> correct. (That is why I asked for .pcap file instead of a .txt).
>>>
>>> My guess is that the initial checksum is correct and your box middlebox
>>> not only changes the destination address and ttl field and header
>>> checksum in the IP-header (which is expected) but also incorrectly the
>>> SCTP checksum. Since no field in the SCTP packet has changed, the 
>>> checksum
>>> must be the same.
>> At the server have a look at the SNMP counters:
>> cat /proc/net/sctp/snmp
>> You should find a line staring with
>> SctpChecksumErrors
>> If the number reported there is positive, the node received packets
>> with checksum errors.
>>
>> Best regards
>> Michael
>>>
>>> Best regards
>>> Michael
 On 13 Jan 2017, at 04:29, Sun Paul  wrote:

 Frame 2: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
   Encapsulation type: Ethernet (1)
   Arrival Time: Jan  6, 2017 16:52:49.662321000 Malay Peninsula 
 Standard Time
   [Time shift for this packet: 0.0 seconds]
   Epoch Time: 1483692769.662321000 seconds
   [Time delta from previous captured frame: 0.000179000 seconds]
   [Time delta from previous displayed frame: 0.000179000 seconds]
   [Time since reference or first frame: 0.000179000 seconds]
   Frame Number: 2
   Frame Length: 98 bytes (784 bits)
   Capture Length: 98 bytes (784 bits)
   [Frame is marked: False]
   [Frame is ignored: False]
   [Protocols in frame: eth:ethertype:ip:sctp]
 Ethernet II, Src: Vmware_81:41:6b (00:50:56:81:41:6b), Dst:
 Vmware_81:a6:a3 (00:50:56:81:a6:a3)
   Destination: Vmware_81:a6:a3 (00:50:56:81:a6:a3)

Re: Free after use in fw_pm_notify()->kill_requests_without_uevent() due pending_fw_head

[Sodagudi Prasad]

On 2017-01-03 07:19, Greg KH wrote:

On Tue, Jan 03, 2017 at 06:44:03AM -0800, Sodagudi Prasad wrote:


Hi All,

Device has crashed due to memory access after free while 
pending_fw_head
list accessed. Kernel 4.4 stable version is used to reproduce this use 
after

free.
--
[ 9031.178428] Unable to handle kernel paging request at virtual 
address

6b6b6b6b6b6b6b6b
[ 9031.178508] pgd = ffc0de9d2000
[ 9031.185888] [6b6b6b6b6b6b6b6b] *pgd=,
*pud=
[ 9031.253045] [ cut here ]
[ 9031.253100] Kernel BUG at ff800864c0a0 [verbose debug info
unavailable]
[ 9031.256860] Internal error: Oops - BUG: 9604 [#1] PREEMPT SMP
[ 9031.263539] Modules linked in:
[ 9031.272708] CPU: 6 PID: 1373 Comm: system_server Tainted: G
WL

4.4.16+ #1
[ 9031.280648] task: ffc0d1a1d700 ti: ffc0d1a2c000 task.ti:
ffc0d1a2c000
[ 9031.287776] PC is at fw_pm_notify+0x84/0x19c
[ 9031.295215] LR is at fw_pm_notify+0x60/0x19c
[ 9031.511559] [] fw_pm_notify+0x84/0x19c
[ 9031.519355] [] notifier_call_chain+0x58/0x8c
[ 9031.524739] [] __blocking_notifier_call_chain+0x54/0x70
[ 9031.530387] [] blocking_notifier_call_chain+0x38/0x44
[ 9031.537243] [] pm_notifier_call_chain+0x28/0x48
[ 9031.543662] [] pm_suspend+0x278/0x674
[ 9031.549906] [] state_store+0x58/0x90
[ 9031.554942] [] kobj_attr_store+0x18/0x28
[ 9031.560154] [] sysfs_kf_write+0x5c/0x68
[ 9031.565620] [] kernfs_fop_write+0x114/0x16c
[ 9031.571092] [] __vfs_write+0x48/0xf0
[ 9031.576816] [] vfs_write+0xb8/0x150
[ 9031.581848] [] SyS_write+0x58/0x94
[ 9031.586973] [] el0_svc_naked+0x24/0x28
---

Kernel panic is observed during device suspend/resume path in the
kill_requests_without_uevent() called from fw_pm_notify().
when pending_list of a firmware_buf is accessed 0x6b(free pattern) 
pattern
observed. Based on this firmware_buf is freed even if firmware_buf is 
part

of
pending_fw_head list.


What are you doing in userspace to trigger this problem?  What kernel
driver is this happening with?
Device continuous suspend and resume is happening here. I think, echo 
mem > /sys/power/state issued here.
It is not clear what driver involved here, because after firmware_buf is 
freed all memory gets filled with 0x6b pattern.




And 4.4.16 is pretty old, can you try 4.9?
We don't have system which runs on new kernels. Looking for possible 
reasons/path, how firmware_buf can get freed when that in 
pending_fw_head list.




thanks,

greg k-h


--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum,

Linux Foundation Collaborative Project

[PATCH v1] clk: rockchip: add pll_wait_lock for pll_enable

[Elaine Zhang]

If pll is power down,when power up pll need wait pll lock.
The reference documents section:
PLL frequency change and lock check

Signed-off-by: Elaine Zhang 
---
 drivers/clk/rockchip/clk-pll.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/clk/rockchip/clk-pll.c b/drivers/clk/rockchip/clk-pll.c
index 6ed605776abd..c4dfd26f37ae 100644
--- a/drivers/clk/rockchip/clk-pll.c
+++ b/drivers/clk/rockchip/clk-pll.c
@@ -268,6 +268,7 @@ static int rockchip_rk3036_pll_enable(struct clk_hw *hw)
 
writel(HIWORD_UPDATE(0, RK3036_PLLCON1_PWRDOWN, 0),
   pll->reg_base + RK3036_PLLCON(1));
+   rockchip_pll_wait_lock(pll);
 
return 0;
 }
@@ -500,6 +501,7 @@ static int rockchip_rk3066_pll_enable(struct clk_hw *hw)
 
writel(HIWORD_UPDATE(0, RK3066_PLLCON3_PWRDOWN, 0),
   pll->reg_base + RK3066_PLLCON(3));
+   rockchip_pll_wait_lock(pll);
 
return 0;
 }
@@ -745,6 +747,7 @@ static int rockchip_rk3399_pll_enable(struct clk_hw *hw)
 
writel(HIWORD_UPDATE(0, RK3399_PLLCON3_PWRDOWN, 0),
   pll->reg_base + RK3399_PLLCON(3));
+   rockchip_rk3399_pll_wait_lock(pll);
 
return 0;
 }
-- 
1.9.1

Re: [PATCH net-next] virtio-net: switch to use build_skb() for small buffer

[Jason Wang]

On 2017年02月21日 22:37, Michael S. Tsirkin wrote:

On Tue, Feb 21, 2017 at 04:46:28PM +0800, Jason Wang wrote:

This patch switch to use build_skb() for small buffer which can have
better performance for both TCP and XDP (since we can work at page
before skb creation). It also remove lots of XDP codes since both
mergeable and small buffer use page frag during refill now.

Before   | After
XDP_DROP(xdp1) 64B  :  11.1Mpps | 14.4Mpps

Tested with xdp1/xdp2/xdp_ip_tx_tunnel and netperf.

Signed-off-by: Jason Wang

Thanks!
I had a similar patch for mergeable too, though it's trickier there
as host has a lot of flexibility in sizing buffers.
Looks like a good intermediate step to me.


Yes, I think it's more tricky for the case of mergeable buffer:

1) we need reserve NET_SKB_PAD + NET_IP_ALIGN for each buffer, this will 
break rx frag coalescing

2) need tailroom for skb_shinfo, so it won't work for all size of packet

Thanks




Acked-by: Michael S. Tsirkin

[PATCH v3] staging: xgifb: function definition argument should also have an identifier name

[Arushi Singhal]

function definition argument like 'struct vb_device_info *','unsigned
long' etc. should also have an identifier name.

Signed-off-by: Arushi Singhal 
---
Changes in v2:
  - By mistake one irrelevant line was added which is removed in this
patch.
  - write the changes done in previous version in correct format.
---
 drivers/staging/xgifb/vb_setmode.h | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/xgifb/vb_setmode.h 
b/drivers/staging/xgifb/vb_setmode.h
index 6f082a7a5a4a..c6317ab00474 100644
--- a/drivers/staging/xgifb/vb_setmode.h
+++ b/drivers/staging/xgifb/vb_setmode.h
@@ -1,14 +1,14 @@
 #ifndef _VBSETMODE_
 #define _VBSETMODE_
 
-void InitTo330Pointer(unsigned char, struct vb_device_info *);
-void XGI_UnLockCRT2(struct vb_device_info *);
-void XGI_LockCRT2(struct vb_device_info *);
-void XGI_DisplayOff(struct xgifb_video_info *,
-   struct xgi_hw_device_info *,
-   struct vb_device_info *);
-void XGI_GetVBType(struct vb_device_info *);
-void XGI_SenseCRT1(struct vb_device_info *);
+void InitTo330Pointer(unsigned char ChipType, struct vb_device_info *pVBInfo);
+void XGI_UnLockCRT2(struct vb_device_info *pVBInfo);
+void XGI_LockCRT2(struct vb_device_info *pVBInfo);
+void XGI_DisplayOff(struct xgifb_video_info *xgifb_info,
+   struct xgi_hw_device_info *pXGIHWDE,
+   struct vb_device_info *pVBInfo);
+void XGI_GetVBType(struct vb_device_info *pVBInfo);
+void XGI_SenseCRT1(struct vb_device_info *pVBInfo);
 unsigned char XGISetModeNew(struct xgifb_video_info *xgifb_info,
struct xgi_hw_device_info *HwDeviceExtension,
unsigned short ModeNo);
@@ -18,6 +18,6 @@ unsigned char XGI_SearchModeID(unsigned short ModeNo,
 unsigned short XGI_GetRatePtrCRT2(struct xgi_hw_device_info *pXGIHWDE,
  unsigned short ModeNo,
  unsigned short ModeIdIndex,
- struct vb_device_info *);
+ struct vb_device_info *pVBInfo);
 
 #endif
-- 
2.11.0

Re: [PATCH] usb: misc: add a missing continue and refactor code

[Gustavo A. R. Silva]

Hi Alan,

Quoting Alan Stern :


On Tue, 21 Feb 2017, Gustavo A. R. Silva wrote:


Code refactoring to make the flow easier to follow and add missing
'continue' for case USB_ENDPOINT_XFER_INT.

Addresses-Coverity-ID: 1248733
Cc: Alan Stern 
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/usb/misc/usbtest.c | 50  
+++---

 1 file changed, 30 insertions(+), 20 deletions(-)

diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index 3525626..8723e33 100644
--- a/drivers/usb/misc/usbtest.c
+++ b/drivers/usb/misc/usbtest.c
@@ -124,6 +124,32 @@ static struct usb_device  
*testdev_to_usbdev(struct usbtest_dev *test)


  
/*-*/


+static inline void try_intr(struct usb_host_endpoint *e,
+   struct usb_host_endpoint *int_in,
+   struct usb_host_endpoint *int_out)
+{
+   if (usb_endpoint_dir_in(&e->desc)) {
+   if (!int_in)
+   int_in = e;
+   } else {
+   if (!int_out)
+   int_out = e;
+   }
+}
+
+static inline void try_iso(struct usb_host_endpoint *e,
+  struct usb_host_endpoint *iso_in,
+  struct usb_host_endpoint *iso_out)
+{
+   if (usb_endpoint_dir_in(&e->desc)) {
+   if (!iso_in)
+   iso_in = e;
+   } else {
+   if (!iso_out)
+   iso_out = e;
+   }
+}
+


This is not at all what I had in mind.  First, it's incorrect (can you
see why?).  Second, by "inline" I meant moving the code to be actually
in-line next to the conditional, not some place else in a separate
subroutine (even if the subroutine is declared inline).



Interesting... let me double check.

I thought it would've been better to have separate inline subroutines  
for those "goto".



Also, the code for the USB_ENDPOINT_XFER_BULK case should look like the
other two.



Do you mean a 'continue' instead of the 'break'?

Thanks for you comments.
--
Gustavo A. R. Silva

Re: [PATCH V2 6/7] proc: show MADV_FREE pages info in smaps

[Minchan Kim]

On Fri, Feb 03, 2017 at 03:33:22PM -0800, Shaohua Li wrote:
> Cc: Michal Hocko 
> Cc: Minchan Kim 
> Cc: Hugh Dickins 
> Cc: Johannes Weiner 
> Cc: Rik van Riel 
> Cc: Mel Gorman 
> Cc: Andrew Morton 
> Signed-off-by: Shaohua Li 
> ---
>  fs/proc/task_mmu.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index ee3efb2..8f2423f 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -440,6 +440,7 @@ struct mem_size_stats {
>   unsigned long private_dirty;
>   unsigned long referenced;
>   unsigned long anonymous;
> + unsigned long lazyfree;
>   unsigned long anonymous_thp;
>   unsigned long shmem_thp;
>   unsigned long swap;
> @@ -456,8 +457,11 @@ static void smaps_account(struct mem_size_stats *mss, 
> struct page *page,
>   int i, nr = compound ? 1 << compound_order(page) : 1;
>   unsigned long size = nr * PAGE_SIZE;
>  
> - if (PageAnon(page))
> + if (PageAnon(page)) {
>   mss->anonymous += size;
> + if (!PageSwapBacked(page))

How about this?

if (!PageSwapBacked(page) && !dirty && !PageDirty(page))

> + mss->lazyfree += size;
> + }
>  
>   mss->resident += size;
>   /* Accumulate the size in pages that have been accessed. */
> @@ -770,6 +774,7 @@ static int show_smap(struct seq_file *m, void *v, int 
> is_pid)
>  "Private_Dirty:  %8lu kB\n"
>  "Referenced: %8lu kB\n"
>  "Anonymous:  %8lu kB\n"
> +"LazyFree:   %8lu kB\n"
>  "AnonHugePages:  %8lu kB\n"
>  "ShmemPmdMapped: %8lu kB\n"
>  "Shared_Hugetlb: %8lu kB\n"
> @@ -788,6 +793,7 @@ static int show_smap(struct seq_file *m, void *v, int 
> is_pid)
>  mss.private_dirty >> 10,
>  mss.referenced >> 10,
>  mss.anonymous >> 10,
> +mss.lazyfree >> 10,
>  mss.anonymous_thp >> 10,
>  mss.shmem_thp >> 10,
>  mss.shared_hugetlb >> 10,
> -- 
> 2.9.3
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org";> em...@kvack.org 

Re: [PATCH] dmaengine: stm32-dma: fix up error dev_err message

[Vinod Koul]

On Tue, Feb 21, 2017 at 06:30:45PM +, Colin King wrote:
> From: Colin Ian King 
> 
> Trivial fix to spelling mistake and make channel plural.

Applied, thanks

-- 
~Vinod

linux-next: build failure after merge of the scsi-mkp tree

[Stephen Rothwell]

Hi Martin,

After merging the scsi-mkp tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

ERROR: ".nvme_fc_unregister_remoteport" [drivers/scsi/lpfc/lpfc.ko] undefined!
ERROR: ".nvme_fc_unregister_localport" [drivers/scsi/lpfc/lpfc.ko] undefined!
ERROR: ".nvmet_fc_rcv_ls_req" [drivers/scsi/lpfc/lpfc.ko] undefined!
ERROR: ".nvmet_fc_rcv_fcp_req" [drivers/scsi/lpfc/lpfc.ko] undefined!
ERROR: ".nvme_fc_register_localport" [drivers/scsi/lpfc/lpfc.ko] undefined!
ERROR: ".nvme_fc_register_remoteport" [drivers/scsi/lpfc/lpfc.ko] undefined!
ERROR: ".nvmet_fc_register_targetport" [drivers/scsi/lpfc/lpfc.ko] undefined!
ERROR: ".nvmet_fc_unregister_targetport" [drivers/scsi/lpfc/lpfc.ko] undefined!

Caused by commit

  462896e1808c ("scsi: lpfc: NVME Initiator: bind to nvme_fc api")

# CONFIG_NVME_FC is not set

Presumably a missing dependency.

I have used the scsi-mkp from next-20170221 for today.

-- 
Cheers,
Stephen Rothwell

Re: [RESEND PATCH] dmaengine: bcm2835: Fix cyclic DMA period splitting

[Vinod Koul]

On Mon, Feb 20, 2017 at 08:01:16PM +0100, Matthias Reichl wrote:
> The code responsible for splitting periods into chunks that
> can be handled by the DMA controller missed to update total_len,
> the number of bytes processed in the current period, when there
> are more chunks to follow.
> 
> Therefore total_len was stuck at 0 and the code didn't work at all.
> This resulted in a wrong control block layout and audio issues because
> the cyclic DMA callback wasn't executing on period boundaries.
> 
> Fix this by adding the missing total_len update.

Applied, thanks

-- 
~Vinod

Re: [PATCH V3 2/2] PCI: handle CRS returned by device after FLR

[Sinan Kaya]

On 2/21/2017 3:51 PM, Alex Williamson wrote:
> On Tue, 21 Feb 2017 12:04:24 -0500
> Sinan Kaya  wrote:
> 
>> Hi Alex,
>>
>> I'm coming back to work on this. 
>>
>> On 10/3/2016 1:37 AM, Sinan Kaya wrote:
>>> An endpoint is allowed to issue CRS following an FLR request to indicate
>>> that it is not ready to accept new requests. Changing the polling mechanism
>>> in FLR wait function to go read the vendor ID instead of the command/status
>>> register. A CRS indication will only be given if the address to be read is
>>> vendor ID.
>>>
>>> Signed-off-by: Sinan Kaya 
>>> ---
>>>  drivers/pci/pci.c | 3 ++-
>>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>>> index c8749b9..7580b00 100644
>>> --- a/drivers/pci/pci.c
>>> +++ b/drivers/pci/pci.c
>>> @@ -3725,7 +3725,8 @@ static void pci_flr_wait(struct pci_dev *dev)
>>>  
>>> do {
>>> msleep(100);
>>> -   pci_read_config_dword(dev, PCI_COMMAND, &id);  
>>
>> Your comment here puzzled me. 
>>
>> https://patchwork.kernel.org/patch/8331851/
>>
>> "Self nak on this one, didn't account for VFs not implementing the first
>> dword.  Thanks,"
>>
>> I'm trying to add Configuration Request Retry Status (CRS) support to FLR
>> with this patch. 
>>
>> Basically, the root port will return 0x0001 only when a config read
>> request is sent to the vendor ID register and CRS visibility is set.
>> The SW needs to poll until this special read ID disappears. See the
>> implementation note on Configuration Request Retry Status in PCIE
>> specification for details.
>>
>> pci_bus_read_dev_vendor_id implements this loop for us.
>>
>> You are saying that there are VFs that do not implement vendor ID register.
>> Can you give some history on this?
> 
> SR-IOV spec rev 1.1, 3.4.1.1 & 3.4.1.2, Vendor ID and Device ID fields
> for the VF return 0x when read.  The "Virtualization Intermediary"
> is supposed to use the vendor ID from the PF and the device ID defined
> in the PF SR-IOV capability.


Interesting. Since lspci was showing the correct vendor id and device id, I
assumed that it is coming from offset 0.

Maybe, the right thing is to figure out if this is a virtual function or not.
If it is a physical function, check the CRS first before reading the command
register in the existing loop.


> 
>>
>>> +   pci_bus_read_dev_vendor_id(dev->bus, dev->devfn, &id,
>>> +  60 * 1000);
>>> } while (i++ < 10 && id == ~0);
> 
> pci_bus_read_dev_vendor_id() seems like it will return false with an
> id value of ~0 for a functional VF, so this loop will spin longer than
> necessary and report an invalid error.  Patch 1/2 from this series
> would cause pci_dev_restore() to be a no-op on VFs.  Thanks,
> 
> Alex
> 
> 


-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

Re: [GIT PULL] gcc-plugins updates for v4.11-rc1

[Linus Torvalds]

On Tue, Feb 21, 2017 at 12:16 PM, Kees Cook  wrote:
>
> Please pull these gcc-plugins changes for v4.11-rc1. This includes two new
> plugins for the upstream kernel: structleak and initify. The structleak
> plugin performs forced initialization of certain structures to avoid
> possible information exposures to userspace. The initify plugin performs
> analysis to find functions and strings that can be marked as __init or
> __exit to reduce the runtime size of the kernel.

I pulled this, but then looked at the patch, and decided to unpull it.

The crazy "__nocapture()" annotations are too ugly to live, and make
no sense. They are basically random noise to some very core header
files. And the "__unverified_nocapture()" ones are worse.

I'm not sure how to fix this issue.

 Linus

[PATCH v2 0/8] ARM64: Initial Marvell IAP140 enablement

[Andreas Färber]

Hello,

This series adds initial support for the Marvell IAP140 SoC (aka PXA1908)
and the Andromeda Box Edge development board.

v2 reuses ARCH_MMP.

Both earlycon and serial are working, but an explicit console=ttyS0,115200n8
is needed; with just "earlycon" and stdout-path the earlycon stops early and
switches to a tty0, long before disabling the bootconsole...

All four CPUs come up, and an initrd can be reached.

However, there are errors about CPUs 1-3 having a zero SYS_CNTFRQ_EL0:

[0.095812] smp: Bringing up secondary CPUs ...
==pxa1908_pmu_core_pwr_on: mpidr = 0x1
==pxa1908_pmu_core_pwr_on: mpidr = 0x2
==pxa1908_pmu_core_pwr_on: mpidr = 0x3
[0.133419] Detected VIPT I-cache on CPU1
[0.133430] CPU features: SANITY CHECK: Unexpected variation in 
SYS_CNTFRQ_EL0. Boot CPU: 0x00018cba80, CPU1: 0x00
[0.133447] Unsupported CPU feature variation.
...
[0.133748] CPU1: Booted secondary processor [410fd032]
[0.165465] Detected VIPT I-cache on CPU2
[0.165474] CPU features: SANITY CHECK: Unexpected variation in 
SYS_CNTFRQ_EL0. Boot CPU: 0x00018cba80, CPU2: 0x00
[0.165505] CPU2: Booted secondary processor [410fd032]
[0.197539] Detected VIPT I-cache on CPU3
[0.197546] CPU features: SANITY CHECK: Unexpected variation in 
SYS_CNTFRQ_EL0. Boot CPU: 0x00018cba80, CPU3: 0x00
[0.197573] CPU3: Booted secondary processor [410fd032]
[0.197625] smp: Brought up 1 node, 4 CPUs
[0.522514] SMP: Total of 4 processors activated.
[0.527212] CPU features: detected feature: 32-bit EL0 Support
[0.533105] CPU: All CPU(s) started at EL2

KVM appears to initialize okay, but was not yet tested with guests.

[0.865255] kvm [1]: 8-bit VMID
[0.868401] kvm [1]: IDMAP page: d23000
[0.872233] kvm [1]: HYP VA range: 8000:
[0.878262] kvm [1]: Hyp mode initialized successfully
[0.883429] kvm [1]: vgic-v2@d1dfc000
[0.887179] kvm [1]: vgic interrupt IRQ1
[0.891120] kvm [1]: virtual timer IRQ4

One limitation is currently the lack of an IAP140 clk driver. Patch 4/4 works
around that for UART0 with a fixed-clock.

A 3.14 based tree is available on GitHub acorn-marvell/brillo_pxa_kernel.

Booting required changes to the vendor U-Boot,
cf. https://en.opensuse.org/HCL:AndromedaBoxEdge

https://github.com/afaerber/linux/commits/edge-next

Have a lot of fun!

Cheers,
Andreas

v1 -> v2:
* Add non-DT documentation
* Use ARCH_MMP instead of ARCH_PXA
* Split off Kconfig cleanups per subsystem
* Drop "mrvl,pxa-uart" and instead implement mmp earlycon
* Add some more DT nodes

Cc: Thomas Petazzoni 
Cc: Gregory Clement 
Cc: i...@andromedabox.org
Cc: devicet...@vger.kernel.org

Andreas Färber (8):
  Documentation: arm: Marvell: Document IAP140
  tty: serial: Suppress deprecated SERIAL_PXA on arm64
  tty: serial: 8250_pxa: Implement mmp earlycon
  sound: soc: pxa: Suppress SND_MMP_SOC for arm64
  ARM64: Prepare Marvell IAP140 aka PXA1908
  Documentation: devicetree: arm: marvell: Document IAP140
  ARM64: dts: marvell: Add IAP140 and Andromeda Box Edge
  ARM64: dts: marvell: iap140-andromeda-box-edge: Add uart0 clock

 Documentation/arm/Marvell/README   |  12 +-
 .../devicetree/bindings/arm/marvell/iap140.txt |  11 +
 arch/arm64/Kconfig.platforms   |   7 +
 arch/arm64/boot/dts/marvell/Makefile   |   3 +
 .../boot/dts/marvell/iap140-andromeda-box-edge.dts |  87 
 arch/arm64/boot/dts/marvell/iap140.dtsi| 241 +
 drivers/tty/serial/8250/8250_pxa.c |   1 +
 drivers/tty/serial/Kconfig |   2 +-
 sound/soc/pxa/Kconfig  |   4 +-
 9 files changed, 364 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/marvell/iap140.txt
 create mode 100644 arch/arm64/boot/dts/marvell/iap140-andromeda-box-edge.dts
 create mode 100644 arch/arm64/boot/dts/marvell/iap140.dtsi

-- 
2.10.2

[PATCH v2 6/8] Documentation: devicetree: arm: marvell: Document IAP140

[Andreas Färber]

Signed-off-by: Andreas Färber 
---
 v1 -> v2:
 * Adopted "marvell" vendor prefix (Thomas)
 * Documented Andromeda Box Edge as example
 
 Documentation/devicetree/bindings/arm/marvell/iap140.txt | 11 +++
 1 file changed, 11 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/marvell/iap140.txt

diff --git a/Documentation/devicetree/bindings/arm/marvell/iap140.txt 
b/Documentation/devicetree/bindings/arm/marvell/iap140.txt
new file mode 100644
index 000..37c6d92
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/marvell/iap140.txt
@@ -0,0 +1,11 @@
+Marvell IAP140 Device Tree Bindings
+---
+
+Boards using a SoC of the Marvell IAP140 family must carry the following
+root node property:
+
+ - compatible :  must contain "marvell,iap140"
+
+Example:
+
+compatible = "marvell,andromeda-box-edge", "marvell,iap140";
-- 
2.10.2

Re: Problem on SCTP

[Sun Paul]

Hi Xin

do you mean we need to patch the kernel?



On Wed, Feb 22, 2017 at 10:00 AM, Xin Long  wrote:
> On Wed, Feb 22, 2017 at 9:12 AM, Sun Paul  wrote:
>> Hi
>>
>> the router is actually is a linux running on RHEL6.8
>> (2.6.32-642.4.2.el6.x86_64). it uses iptables to do SNAT aand DNAT
>> forward.
> https://bugzilla.redhat.com/show_bug.cgi?id=1412038
>
> sctp_manip_pkt->sctp_compute_cksum:
> struct sctphdr *sh = sctp_hdr(sub);
>
> But in rhel6, skb->transport_header is not yet set at that time.
> This patch should be backported into rhel6.
>
> commit 21d1196a35f5686c4323e42a62fdb4b23b0ab4a3
> Author: Eric Dumazet 
> Date:   Mon Jul 15 20:03:19 2013 -0700
>
> ipv4: set transport header earlier
>
>
>>
>> On Tue, Feb 21, 2017 at 11:53 PM, Xin Long  wrote:
>>> On Tue, Feb 21, 2017 at 12:26 PM, Sun Paul  wrote:
 Hi,

 sorry to get back late, the platform is running on KVM. and this
 problem is resolved by moving to VMware environment, however,  a new
 problem is coming out, we noticed that the HB REQ is being ABORT from
 client.


 03:32:35.233572 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1)
 [HB REQ] (from server to sctp router)
 03:32:35.233603 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1)
 [HB REQ] (from sctp router to client)
 03:32:35.233852 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1)
 [ABORT] (from client to sctp router)

 03:32:37.928679 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1) [HB 
 REQ]
 03:32:37.928717 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1) [HB 
 REQ]
 03:32:37.929247 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1) [ABORT]

 For the above packet flow, 10.165.250.22 is the server and
 192.168.2.13 is the client, the server 10.165.250.22 sends HB REQ to
 client 192.168.2.13 through 192.168.2.14 (the SCTP router), and the
 SCTP router change the src address before forward the HB REQ to the
 client.

 But somehow the client is ABORT the HB REQ, any idea? is it related to
 the HEARTBEAT information? or the checksum again>?
>>> The incorrect checksum won't cause ABORT, but the abnormal HB REQ
>>> could be, if HB information was modified when calculating the checksum
>>> on router, the ABORT may be caused in client process.
>>>
>>> is your SCTP router linux ? if yes, what's the kernel version ?
>>>

 On Fri, Jan 13, 2017 at 9:19 PM, Michael Tuexen
  wrote:
>> On 13 Jan 2017, at 10:43, Michael Tuexen 
>>  wrote:
>>
>> Your router does NOT change any field in the SCTP packet, but the
>> SCTP checksum was modified from
>>   Checksum: 0xbaea49e5 (not verified)
>> to
>>   Checksum: 0xa9a86d3f (not verified)
>> At least one of these is wrong. Read the tracefiles in wireshark and
>> enable checksum validation and wireshark will tell you which one is
>> correct. (That is why I asked for .pcap file instead of a .txt).
>>
>> My guess is that the initial checksum is correct and your box middlebox
>> not only changes the destination address and ttl field and header
>> checksum in the IP-header (which is expected) but also incorrectly the
>> SCTP checksum. Since no field in the SCTP packet has changed, the 
>> checksum
>> must be the same.
> At the server have a look at the SNMP counters:
> cat /proc/net/sctp/snmp
> You should find a line staring with
> SctpChecksumErrors
> If the number reported there is positive, the node received packets
> with checksum errors.
>
> Best regards
> Michael
>>
>> Best regards
>> Michael
>>> On 13 Jan 2017, at 04:29, Sun Paul  wrote:
>>>
>>> Frame 2: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
>>>   Encapsulation type: Ethernet (1)
>>>   Arrival Time: Jan  6, 2017 16:52:49.662321000 Malay Peninsula 
>>> Standard Time
>>>   [Time shift for this packet: 0.0 seconds]
>>>   Epoch Time: 1483692769.662321000 seconds
>>>   [Time delta from previous captured frame: 0.000179000 seconds]
>>>   [Time delta from previous displayed frame: 0.000179000 seconds]
>>>   [Time since reference or first frame: 0.000179000 seconds]
>>>   Frame Number: 2
>>>   Frame Length: 98 bytes (784 bits)
>>>   Capture Length: 98 bytes (784 bits)
>>>   [Frame is marked: False]
>>>   [Frame is ignored: False]
>>>   [Protocols in frame: eth:ethertype:ip:sctp]
>>> Ethernet II, Src: Vmware_81:41:6b (00:50:56:81:41:6b), Dst:
>>> Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>   Destination: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>   Address: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>    ..0.     = LG bit: Globally unique
>>> address (factory default)
>>>    ...0     = IG bit: Individual address 
>>> (unicast)
>>>   Source: Vmware_81:41:6b (00:50:56:81:41:6b)
>>

[PATCH v2 4/8] sound: soc: pxa: Suppress SND_MMP_SOC for arm64

[Andreas Färber]

SND_MMP_SOC selects SND_ARM, which is limited to ARM, as well as
MMP_SRAM, which is a non-DT driver in arch/arm/mach-arm/.

Avoid Kconfig warnings by not making this driver available on ARM64.

While at it, tidy the title (Soc -> SoC).

Signed-off-by: Andreas Färber 
---
 v2: new
 
 sound/soc/pxa/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/pxa/Kconfig b/sound/soc/pxa/Kconfig
index 823b5a2..f8e1c06 100644
--- a/sound/soc/pxa/Kconfig
+++ b/sound/soc/pxa/Kconfig
@@ -8,8 +8,8 @@ config SND_PXA2XX_SOC
  to select the audio interfaces to support below.
 
 config SND_MMP_SOC
-   bool "Soc Audio for Marvell MMP chips"
-   depends on ARCH_MMP
+   bool "SoC Audio for Marvell MMP chips"
+   depends on ARCH_MMP && ARM
select MMP_SRAM
select SND_SOC_GENERIC_DMAENGINE_PCM
select SND_ARM
-- 
2.10.2

[PATCH v2 2/8] tty: serial: Suppress deprecated SERIAL_PXA on arm64

[Andreas Färber]

With Marvell IAP140 being enabled as first arm64 MMP platform, don't
make the deprecated SERIAL_PXA option available outside ARM.

Signed-off-by: Andreas Färber 
---
 v1 -> v2: split off
 * Updated for ARCH_MMP
 
 drivers/tty/serial/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 6117ac8..db83085 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -439,7 +439,7 @@ config SERIAL_MPSC_CONSOLE
 
 config SERIAL_PXA
bool "PXA serial port support (DEPRECATED)"
-   depends on ARCH_PXA || ARCH_MMP
+   depends on ARCH_PXA || (ARCH_MMP && ARM)
select SERIAL_CORE
select SERIAL_8250_PXA if SERIAL_8250=y
select SERIAL_PXA_NON8250 if !SERIAL_8250=y
-- 
2.10.2