Re: Staging: speakup - syle fix permissions to octal

[Guenter Roeck]

On 02/04/2017 06:29 AM, Julia Lawall wrote:



On Sat, 4 Feb 2017, Guenter Roeck wrote:


On 02/03/2017 11:27 PM, Joe Perches wrote:

(adding Julia Lawall)

On Fri, 2017-02-03 at 20:44 -0800, Guenter Roeck wrote:

On Sat, Jan 28, 2017 at 07:05:09PM +1300, Derek Robson wrote:

A style fix across whole driver.
changed permissions to octal style, found using checkpatch

Signed-off-by: Derek Robson 


FWIW, I think changes like this are best done using coccinelle.


I think checkpatch does it reasonably well.

Julia?  Can coccinelle do this?

I believe cocinelle doesn't handle the substitution
and octal addition very well when multiple flags
are used.



Why not ? Seems to be quite simple. One just has to list all the variants
being used in the rule.


That ensures that the results can be reproduced and are well defined.
As it is, someone will have to check each line of your patches to ensure
that the conversion is correct.

It would also ensure (hopefully) that we don't end up with constructs
such as


-#define USER_R (S_IFREG|S_IRUGO)
-#define USER_W (S_IFREG|S_IWUGO)
+#define USER_R (S_IFREG|0444)
+#define USER_W (S_IFREG|0666)


which really defeat the purpose of the whole exercise.


Why do you think mixing file specific attributes
with octal permissions is a bad thing?



Just an assumption. My bad. Ultimately, what I think doesn't really
matter, though - because what I think is that the whole "use octals"
is a bad idea to start with.


I don't think I have received yet the message that this is referring to.
But I don't see a problem for Coccinelle a priori.  If there are things
that need to be added together, as long as they are explicit constants,
that can be done in python or ocaml.



Something like

@@
@@

(
- S_IFREG | S_IRUGO | S_IWUGO
+ S_IFREG | 0666
|
- S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH
+ 0644
|
- S_IRUGO|S_IWUSR
+ 0644
|
- S_IWUSR|S_IRUGO
+ 0644
|
- S_IRUGO|S_IWUGO
+ 0666
|
- S_IWUGO|S_IRUGO
+ 0666
|
- S_IRUGO
+ 0444
|
- S_IWUGO
+ 0222
|
- S_IWUSR
+ 0200
)

Odd is that the S_IFREG rule seems to be needed to catch "S_IFREG | S_IRUGO | 
S_IWUGO",
but probably I am missing something as usual ;-).

Guenter

Re: Staging: speakup - syle fix permissions to octal

[Julia Lawall]

On Sat, 4 Feb 2017, Guenter Roeck wrote:

> On 02/04/2017 06:29 AM, Julia Lawall wrote:
> >
> >
> > On Sat, 4 Feb 2017, Guenter Roeck wrote:
> >
> > > On 02/03/2017 11:27 PM, Joe Perches wrote:
> > > > (adding Julia Lawall)
> > > >
> > > > On Fri, 2017-02-03 at 20:44 -0800, Guenter Roeck wrote:
> > > > > On Sat, Jan 28, 2017 at 07:05:09PM +1300, Derek Robson wrote:
> > > > > > A style fix across whole driver.
> > > > > > changed permissions to octal style, found using checkpatch
> > > > > >
> > > > > > Signed-off-by: Derek Robson 
> > > > >
> > > > > FWIW, I think changes like this are best done using coccinelle.
> > > >
> > > > I think checkpatch does it reasonably well.
> > > >
> > > > Julia?  Can coccinelle do this?
> > > >
> > > > I believe cocinelle doesn't handle the substitution
> > > > and octal addition very well when multiple flags
> > > > are used.
> > > >
> > >
> > > Why not ? Seems to be quite simple. One just has to list all the variants
> > > being used in the rule.
> > >
> > > > > That ensures that the results can be reproduced and are well defined.
> > > > > As it is, someone will have to check each line of your patches to
> > > > > ensure
> > > > > that the conversion is correct.
> > > > >
> > > > > It would also ensure (hopefully) that we don't end up with constructs
> > > > > such as
> > > > >
> > > > > > -#define USER_R (S_IFREG|S_IRUGO)
> > > > > > -#define USER_W (S_IFREG|S_IWUGO)
> > > > > > +#define USER_R (S_IFREG|0444)
> > > > > > +#define USER_W (S_IFREG|0666)
> > > > >
> > > > > which really defeat the purpose of the whole exercise.
> > > >
> > > > Why do you think mixing file specific attributes
> > > > with octal permissions is a bad thing?
> > > >
> > >
> > > Just an assumption. My bad. Ultimately, what I think doesn't really
> > > matter, though - because what I think is that the whole "use octals"
> > > is a bad idea to start with.
> >
> > I don't think I have received yet the message that this is referring to.
> > But I don't see a problem for Coccinelle a priori.  If there are things
> > that need to be added together, as long as they are explicit constants,
> > that can be done in python or ocaml.
> >
>
> Something like
>
> @@
> @@
>
> (
> - S_IFREG | S_IRUGO | S_IWUGO
> + S_IFREG | 0666
> |
> - S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH
> + 0644
> |
> - S_IRUGO|S_IWUSR
> + 0644
> |
> - S_IWUSR|S_IRUGO
> + 0644
> |
> - S_IRUGO|S_IWUGO
> + 0666
> |
> - S_IWUGO|S_IRUGO
> + 0666
> |
> - S_IRUGO
> + 0444
> |
> - S_IWUGO
> + 0222
> |
> - S_IWUSR
> + 0200
> )
>
> Odd is that the S_IFREG rule seems to be needed to catch "S_IFREG | S_IRUGO |
> S_IWUGO",
> but probably I am missing something as usual ;-).

The associativity of | is not what you hope for.

julia

Re: [PATCH] One coding style correction.

[Greg KH]

On Sat, Feb 04, 2017 at 02:18:41AM +0300, Victor Vaschenko wrote:
> Signed-off-by: Victor Vaschenko 
> ---
>  drivers/staging/bcm2835-audio/bcm2835-ctl.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

If you are going to ignore my suggestions of how to properly create a
patch that I can apply, well, I can easily ignore your patch :(

Consider this one dropped.

greg k-h

Re: [PATCH] mm, slab: rename kmalloc-node cache to kmalloc-

[Vlastimil Babka]

On 4.2.2017 3:26, kbuild test robot wrote:
> Hi Vlastimil,
> 
> [auto build test WARNING on mmotm/master]
> [also build test WARNING on v4.10-rc6]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]

Hi,

there are no warnings below?

Vlastimil

> 
> url:
> https://github.com/0day-ci/linux/commits/Vlastimil-Babka/mm-slab-rename-kmalloc-node-cache-to-kmalloc-size/20170204-021843
> base:   git://git.cmpxchg.org/linux-mmotm.git master
> config: i386-allmodconfig
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
> make ARCH=i386  allmodconfig
> make ARCH=i386 
> 
> All warnings (new ones prefixed by >>):
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation
> 

Linux 4.4.47

[Greg KH]

I'm announcing the release of the 4.4.47 kernel.

All users of the 4.4 kernel series must upgrade.

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

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

thanks,

greg k-h



 Makefile   |2 -
 drivers/net/ethernet/broadcom/bcmsysport.c |   25 +-
 drivers/net/ethernet/mellanox/mlxsw/pci.h  |8 +++---
 drivers/net/ethernet/mellanox/mlxsw/spectrum.c |1 
 drivers/net/ethernet/mellanox/mlxsw/switchx2.c |1 
 drivers/net/ethernet/renesas/ravb_main.c   |   13 +
 drivers/net/phy/bcm63xx.c  |   21 ++-
 drivers/net/usb/cdc_ether.c|8 ++
 drivers/net/usb/qmi_wwan.c |7 +
 drivers/net/usb/r8152.c|9 ++
 include/linux/tcp.h|7 -
 net/ax25/ax25_subr.c   |2 -
 net/bridge/br_netlink.c|   33 ++---
 net/core/dev.c |4 +--
 net/dsa/slave.c|2 +
 net/ipv4/fib_semantics.c   |   11 +---
 net/ipv4/route.c   |2 -
 net/ipv4/tcp_fastopen.c|3 +-
 net/ipv6/addrconf.c|4 ---
 net/ipv6/route.c   |3 +-
 net/openvswitch/conntrack.c|3 +-
 net/unix/af_unix.c |   27 
 22 files changed, 141 insertions(+), 55 deletions(-)

Alexey Kodanev (1):
  tcp: initialize max window for a new fastopen socket

Arkadi Sharshevsky (2):
  mlxsw: spectrum: Fix memory leak at skb reallocation
  mlxsw: switchx2: Fix memory leak at skb reallocation

Basil Gunn (1):
  ax25: Fix segfault after sock connection timeout

Bjørn Mork (1):
  qmi_wwan/cdc_ether: add device ID for HP lt2523 (Novatel E371) WWAN card

Daniel Gonzalez Cabanelas (1):
  net: phy: bcm63xx: Utilize correct config_intr function

David Ahern (2):
  net: lwtunnel: Handle lwtunnel_fill_encap failure
  net: ipv4: fix table id in getroute response

Elad Raz (1):
  mlxsw: pci: Fix EQE structure definition

Eric Dumazet (1):
  net: fix harmonize_features() vs NETIF_F_HIGHDMA

Florian Fainelli (2):
  net: systemport: Decouple flow control from __bcm_sysport_tx_reclaim
  net: dsa: Bring back device detaching in dsa_slave_suspend()

Greg Kroah-Hartman (1):
  Linux 4.4.47

Ivan Vecera (1):
  bridge: netlink: call br_changelink() during br_dev_newlink()

Kefeng Wang (1):
  ipv6: addrconf: Avoid addrconf_disable_change() using RCU read-side lock

Lance Richardson (1):
  openvswitch: maintain correct checksum state in conntrack actions

Masaru Nagai (1):
  ravb: do not use zero-length alignment DMA descriptor

Shannon Nelson (1):
  tcp: fix tcp_fastopen unaligned access complaints on sparc

WANG Cong (1):
  af_unix: move unix_mknod() out of bindlock

hayeswang (2):
  r8152: fix the sw rx checksum is unavailable
  r8152: don't execute runtime suspend if the tx is not empty



signature.asc
Description: PGP signature

Re: Linux 4.4.47

[Greg KH]

diff --git a/Makefile b/Makefile
index 2dd5cb2fe182..7b233ac7f86c 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 4
 PATCHLEVEL = 4
-SUBLEVEL = 46
+SUBLEVEL = 47
 EXTRAVERSION =
 NAME = Blurry Fish Butt
 
diff --git a/drivers/net/ethernet/broadcom/bcmsysport.c 
b/drivers/net/ethernet/broadcom/bcmsysport.c
index 858106352ce9..8860e74aa28f 100644
--- a/drivers/net/ethernet/broadcom/bcmsysport.c
+++ b/drivers/net/ethernet/broadcom/bcmsysport.c
@@ -732,11 +732,8 @@ static unsigned int __bcm_sysport_tx_reclaim(struct 
bcm_sysport_priv *priv,
unsigned int c_index, last_c_index, last_tx_cn, num_tx_cbs;
unsigned int pkts_compl = 0, bytes_compl = 0;
struct bcm_sysport_cb *cb;
-   struct netdev_queue *txq;
u32 hw_ind;
 
-   txq = netdev_get_tx_queue(ndev, ring->index);
-
/* Compute how many descriptors have been processed since last call */
hw_ind = tdma_readl(priv, TDMA_DESC_RING_PROD_CONS_INDEX(ring->index));
c_index = (hw_ind >> RING_CONS_INDEX_SHIFT) & RING_CONS_INDEX_MASK;
@@ -767,9 +764,6 @@ static unsigned int __bcm_sysport_tx_reclaim(struct 
bcm_sysport_priv *priv,
 
ring->c_index = c_index;
 
-   if (netif_tx_queue_stopped(txq) && pkts_compl)
-   netif_tx_wake_queue(txq);
-
netif_dbg(priv, tx_done, ndev,
  "ring=%d c_index=%d pkts_compl=%d, bytes_compl=%d\n",
  ring->index, ring->c_index, pkts_compl, bytes_compl);
@@ -781,16 +775,33 @@ static unsigned int __bcm_sysport_tx_reclaim(struct 
bcm_sysport_priv *priv,
 static unsigned int bcm_sysport_tx_reclaim(struct bcm_sysport_priv *priv,
   struct bcm_sysport_tx_ring *ring)
 {
+   struct netdev_queue *txq;
unsigned int released;
unsigned long flags;
 
+   txq = netdev_get_tx_queue(priv->netdev, ring->index);
+
spin_lock_irqsave(>lock, flags);
released = __bcm_sysport_tx_reclaim(priv, ring);
+   if (released)
+   netif_tx_wake_queue(txq);
+
spin_unlock_irqrestore(>lock, flags);
 
return released;
 }
 
+/* Locked version of the per-ring TX reclaim, but does not wake the queue */
+static void bcm_sysport_tx_clean(struct bcm_sysport_priv *priv,
+struct bcm_sysport_tx_ring *ring)
+{
+   unsigned long flags;
+
+   spin_lock_irqsave(>lock, flags);
+   __bcm_sysport_tx_reclaim(priv, ring);
+   spin_unlock_irqrestore(>lock, flags);
+}
+
 static int bcm_sysport_tx_poll(struct napi_struct *napi, int budget)
 {
struct bcm_sysport_tx_ring *ring =
@@ -1275,7 +1286,7 @@ static void bcm_sysport_fini_tx_ring(struct 
bcm_sysport_priv *priv,
napi_disable(>napi);
netif_napi_del(>napi);
 
-   bcm_sysport_tx_reclaim(priv, ring);
+   bcm_sysport_tx_clean(priv, ring);
 
kfree(ring->cbs);
ring->cbs = NULL;
diff --git a/drivers/net/ethernet/mellanox/mlxsw/pci.h 
b/drivers/net/ethernet/mellanox/mlxsw/pci.h
index 142f33d978c5..a0fbe00dd690 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/pci.h
+++ b/drivers/net/ethernet/mellanox/mlxsw/pci.h
@@ -206,21 +206,21 @@ MLXSW_ITEM32(pci, eqe, owner, 0x0C, 0, 1);
 /* pci_eqe_cmd_token
  * Command completion event - token
  */
-MLXSW_ITEM32(pci, eqe, cmd_token, 0x08, 16, 16);
+MLXSW_ITEM32(pci, eqe, cmd_token, 0x00, 16, 16);
 
 /* pci_eqe_cmd_status
  * Command completion event - status
  */
-MLXSW_ITEM32(pci, eqe, cmd_status, 0x08, 0, 8);
+MLXSW_ITEM32(pci, eqe, cmd_status, 0x00, 0, 8);
 
 /* pci_eqe_cmd_out_param_h
  * Command completion event - output parameter - higher part
  */
-MLXSW_ITEM32(pci, eqe, cmd_out_param_h, 0x0C, 0, 32);
+MLXSW_ITEM32(pci, eqe, cmd_out_param_h, 0x04, 0, 32);
 
 /* pci_eqe_cmd_out_param_l
  * Command completion event - output parameter - lower part
  */
-MLXSW_ITEM32(pci, eqe, cmd_out_param_l, 0x10, 0, 32);
+MLXSW_ITEM32(pci, eqe, cmd_out_param_l, 0x08, 0, 32);
 
 #endif
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c 
b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
index 3be4a2355ead..cb165c2d4803 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
@@ -390,6 +390,7 @@ static netdev_tx_t mlxsw_sp_port_xmit(struct sk_buff *skb,
dev_kfree_skb_any(skb_orig);
return NETDEV_TX_OK;
}
+   dev_consume_skb_any(skb_orig);
}
 
if (eth_skb_pad(skb)) {
diff --git a/drivers/net/ethernet/mellanox/mlxsw/switchx2.c 
b/drivers/net/ethernet/mellanox/mlxsw/switchx2.c
index d85960cfb694..fb2d9a82ce3d 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/switchx2.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/switchx2.c
@@ -313,6 +313,7 @@ static netdev_tx_t mlxsw_sx_port_xmit(struct sk_buff *skb,
dev_kfree_skb_any(skb_orig);
return NETDEV_TX_OK;
}
+   

[PATCH v3] perf tools arm64: Add support for generating bpf prologue

[He Kuang]

Since HAVE_KPROBES can be enabled in arm64, this patch introduces
regs_query_register_offset() to convert register name to offset for
arm64, so the BPF prologue feature is ready to use.

Signed-off-by: He Kuang 
---
 tools/perf/arch/arm64/Makefile  |  1 +
 tools/perf/arch/arm64/util/dwarf-regs.c | 30 +++---
 2 files changed, 24 insertions(+), 7 deletions(-)

diff --git a/tools/perf/arch/arm64/Makefile b/tools/perf/arch/arm64/Makefile
index 18b1351..eebe1ec 100644
--- a/tools/perf/arch/arm64/Makefile
+++ b/tools/perf/arch/arm64/Makefile
@@ -2,3 +2,4 @@ ifndef NO_DWARF
 PERF_HAVE_DWARF_REGS := 1
 endif
 PERF_HAVE_JITDUMP := 1
+PERF_HAVE_ARCH_REGS_QUERY_REGISTER_OFFSET := 1
diff --git a/tools/perf/arch/arm64/util/dwarf-regs.c 
b/tools/perf/arch/arm64/util/dwarf-regs.c
index d49efeb..f2b49bf 100644
--- a/tools/perf/arch/arm64/util/dwarf-regs.c
+++ b/tools/perf/arch/arm64/util/dwarf-regs.c
@@ -10,17 +10,22 @@
 
 #include 
 #include 
+#include  /* for struct user_pt_regs */
+#include "util.h"
 
 struct pt_regs_dwarfnum {
const char *name;
unsigned int dwarfnum;
+   unsigned int ptregs_offset;
 };
 
-#define STR(s) #s
-#define REG_DWARFNUM_NAME(r, num) {.name = r, .dwarfnum = num}
-#define GPR_DWARFNUM_NAME(num) \
-   {.name = STR(%x##num), .dwarfnum = num}
-#define REG_DWARFNUM_END {.name = NULL, .dwarfnum = 0}
+#define REG_DWARFNUM_NAME(r, num)  \
+   {.name = STR(%)STR(r), .dwarfnum = num, \
+   .ptregs_offset = offsetof(struct user_pt_regs, r)}
+#define GPR_DWARFNUM_NAME(num) \
+   {.name = STR(%x##num), .dwarfnum = num, \
+   .ptregs_offset = offsetof(struct user_pt_regs, regs[num])}
+#define REG_DWARFNUM_END {.name = NULL, .dwarfnum = 0, .ptregs_offset = 0}
 
 /*
  * Reference:
@@ -57,8 +62,9 @@ struct pt_regs_dwarfnum {
GPR_DWARFNUM_NAME(27),
GPR_DWARFNUM_NAME(28),
GPR_DWARFNUM_NAME(29),
-   REG_DWARFNUM_NAME("%lr", 30),
-   REG_DWARFNUM_NAME("%sp", 31),
+   {.name = "%lr", .dwarfnum = 30,
+.ptregs_offset = offsetof(struct user_pt_regs, regs[30])},
+   REG_DWARFNUM_NAME(sp, 31),
REG_DWARFNUM_END,
 };
 
@@ -78,3 +84,13 @@ const char *get_arch_regstr(unsigned int n)
return roff->name;
return NULL;
 }
+
+int regs_query_register_offset(const char *name)
+{
+   const struct pt_regs_dwarfnum *roff;
+
+   for (roff = regdwarfnum_table; roff->name != NULL; roff++)
+   if (!strcmp(roff->name, name))
+   return roff->ptregs_offset;
+   return -EINVAL;
+}
-- 
1.8.5.2

Linux 4.9.8

[Greg KH]

I'm announcing the release of the 4.9.8 kernel.

All users of the 4.9 kernel series must upgrade.

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

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

thanks,

greg k-h



 Makefile|2 
 drivers/net/ethernet/broadcom/bcmsysport.c  |   25 +++--
 drivers/net/ethernet/mellanox/mlx4/en_netdev.c  |5 -
 drivers/net/ethernet/mellanox/mlx5/core/en_rx.c |3 
 drivers/net/ethernet/mellanox/mlxsw/pci.h   |8 -
 drivers/net/ethernet/mellanox/mlxsw/spectrum.c  |1 
 drivers/net/ethernet/mellanox/mlxsw/switchx2.c  |1 
 drivers/net/ethernet/renesas/ravb_main.c|   13 ++
 drivers/net/hyperv/netvsc_drv.c |3 
 drivers/net/macvtap.c   |2 
 drivers/net/phy/bcm63xx.c   |   21 +++-
 drivers/net/tun.c   |2 
 drivers/net/usb/cdc_ether.c |8 +
 drivers/net/usb/qmi_wwan.c  |7 +
 drivers/net/usb/r8152.c |   11 +-
 drivers/net/virtio_net.c|2 
 drivers/net/vxlan.c |2 
 fs/xfs/libxfs/xfs_alloc.c   |  115 +---
 fs/xfs/libxfs/xfs_alloc.h   |2 
 fs/xfs/libxfs/xfs_attr.c|6 -
 fs/xfs/libxfs/xfs_bmap.c|   51 +++---
 fs/xfs/libxfs/xfs_bmap.h|6 +
 fs/xfs/libxfs/xfs_bmap_btree.c  |3 
 fs/xfs/libxfs/xfs_dir2.c|   39 +---
 fs/xfs/libxfs/xfs_dir2.h|8 +
 fs/xfs/libxfs/xfs_inode_buf.c   |   10 +-
 fs/xfs/libxfs/xfs_sb.c  |2 
 fs/xfs/xfs_bmap_util.c  |   28 +++--
 fs/xfs/xfs_buf.c|1 
 fs/xfs/xfs_dquot.c  |4 
 fs/xfs/xfs_iomap.c  |2 
 fs/xfs/xfs_iops.c   |   50 --
 fs/xfs/xfs_linux.h  |6 -
 fs/xfs/xfs_log.c|   12 --
 include/linux/tcp.h |7 +
 include/linux/virtio_net.h  |6 -
 include/net/lwtunnel.h  |   18 ++-
 net/ax25/ax25_subr.c|2 
 net/bridge/br_netlink.c |   33 +++---
 net/core/dev.c  |4 
 net/core/lwtunnel.c |   74 ++-
 net/dsa/slave.c |2 
 net/ipv4/fib_frontend.c |8 +
 net/ipv4/fib_semantics.c|   11 +-
 net/ipv4/ip_tunnel_core.c   |2 
 net/ipv4/route.c|2 
 net/ipv4/tcp_fastopen.c |3 
 net/ipv6/addrconf.c |4 
 net/ipv6/ila/ila_lwt.c  |1 
 net/ipv6/ip6_tunnel.c   |4 
 net/ipv6/route.c|   15 ++-
 net/mpls/af_mpls.c  |   48 +-
 net/mpls/mpls_iptunnel.c|1 
 net/openvswitch/conntrack.c |6 -
 net/packet/af_packet.c  |2 
 net/sched/act_api.c |5 -
 net/unix/af_unix.c  |   27 +++--
 57 files changed, 473 insertions(+), 273 deletions(-)

Alexey Kodanev (1):
  tcp: initialize max window for a new fastopen socket

Amir Goldstein (6):
  xfs: make the ASSERT() condition likely
  xfs: sanity check directory inode di_size
  xfs: add missing include dependencies to xfs_dir2.h
  xfs: replace xfs_mode_to_ftype table with switch statement
  xfs: sanity check inode mode when creating new dentry
  xfs: sanity check inode di_mode

Arkadi Sharshevsky (2):
  mlxsw: spectrum: Fix memory leak at skb reallocation
  mlxsw: switchx2: Fix memory leak at skb reallocation

Arnd Bergmann (1):
  xfs: fix xfs_mode_to_ftype() prototype

Basil Gunn (1):
  ax25: Fix segfault after sock connection timeout

Bjørn Mork (1):
  qmi_wwan/cdc_ether: add device ID for HP lt2523 (Novatel E371) WWAN card

Brian Foster (1):
  xfs: remove racy hasattr check from attr ops

Christoph Hellwig (7):
  xfs: bump up reserved blocks in xfs_alloc_set_aside
  xfs: fix bogus minleft manipulations
  xfs: adjust allocation length in xfs_alloc_space_available
  xfs: don't rely on ->total in xfs_alloc_space_available
  xfs: don't print warnings 

TRADING ACCOUNT

[POISSONNIER Emmanuel]

 Hello ,

We, Amadeus, want to extend our list of suppliers in the purchase of 
computer hardware and electronics ( IT computer ) and are specialized in 
the resale and distribution of computer and electronic equipment. We are 
interested to buy the products you sell and want to place an order With 
you in big quantities


Is it posible for you to give us payment facilities ( 14 , 30 or 60 days 
payment terms ) ?


What do you want for opening our account and credit line request ?.

Best regards

POISSONNIER Emmanuel

AMADEUS
485 ROUTE DU PIN MONTARD
SOPHIA ANTIPOLIS 06410
BIOT- France
REG N° 344496252
VAT N° FR37344496252
TEL +33427865001
FAX +33426078315
www.amadeuss.com
poissonn...@amadeuss.fr

Re: [PATCH 4/5] regulator: core: simplify _regulator_get()

[Mark Brown]

On Fri, Feb 03, 2017 at 01:56:03PM -0800, Dmitry Torokhov wrote:
> The code in _regulator_get() got a bit confusing over time, with control
> flow jumping to a label from couple of places. Let's untangle it a bit.

This is quite hard to review without a concrete description of what the
changes actually are...

> Signed-off-by: Dmitry Torokhov 
> ---
>  drivers/regulator/core.c | 66 
> +---
>  1 file changed, 34 insertions(+), 32 deletions(-)

...it's a fairly large change in core code which is as you say a little
complicated.


signature.asc
Description: PGP signature

Applied "regulator: core: optimize devm_regulator_bulk_get()" to the regulator tree

[Mark Brown]

The patch

   regulator: core: optimize devm_regulator_bulk_get()

has been applied to the regulator tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 3eaeb4756336ad884a2a8eef3ca9e12845fb5391 Mon Sep 17 00:00:00 2001
From: Dmitry Torokhov 
Date: Fri, 3 Feb 2017 15:16:18 -0800
Subject: [PATCH] regulator: core: optimize devm_regulator_bulk_get()

When performing this bulk operation, there is no need to track every supply
individually. It is more efficient to treat entire group as a single
managed resource.

Signed-off-by: Dmitry Torokhov 
Signed-off-by: Mark Brown 
---
 drivers/regulator/devres.c | 45 +
 1 file changed, 25 insertions(+), 20 deletions(-)

diff --git a/drivers/regulator/devres.c b/drivers/regulator/devres.c
index 965d1d31ec8c..784e3bf32210 100644
--- a/drivers/regulator/devres.c
+++ b/drivers/regulator/devres.c
@@ -120,6 +120,18 @@ void devm_regulator_put(struct regulator *regulator)
 }
 EXPORT_SYMBOL_GPL(devm_regulator_put);
 
+struct regulator_bulk_devres {
+   struct regulator_bulk_data *consumers;
+   int num_consumers;
+};
+
+static void devm_regulator_bulk_release(struct device *dev, void *res)
+{
+   struct regulator_bulk_devres *devres = res;
+
+   regulator_bulk_free(devres->num_consumers, devres->consumers);
+}
+
 /**
  * devm_regulator_bulk_get - managed get multiple regulator consumers
  *
@@ -138,29 +150,22 @@ EXPORT_SYMBOL_GPL(devm_regulator_put);
 int devm_regulator_bulk_get(struct device *dev, int num_consumers,
struct regulator_bulk_data *consumers)
 {
-   int i;
+   struct regulator_bulk_devres *devres;
int ret;
 
-   for (i = 0; i < num_consumers; i++)
-   consumers[i].consumer = NULL;
-
-   for (i = 0; i < num_consumers; i++) {
-   consumers[i].consumer = devm_regulator_get(dev,
-  consumers[i].supply);
-   if (IS_ERR(consumers[i].consumer)) {
-   ret = PTR_ERR(consumers[i].consumer);
-   dev_err(dev, "Failed to get supply '%s': %d\n",
-   consumers[i].supply, ret);
-   consumers[i].consumer = NULL;
-   goto err;
-   }
-   }
-
-   return 0;
+   devres = devres_alloc(devm_regulator_bulk_release,
+ sizeof(*devres), GFP_KERNEL);
+   if (!devres)
+   return -ENOMEM;
 
-err:
-   for (i = 0; i < num_consumers && consumers[i].consumer; i++)
-   devm_regulator_put(consumers[i].consumer);
+   ret = regulator_bulk_get(dev, num_consumers, consumers);
+   if (!ret) {
+   devres->consumers = consumers;
+   devres->num_consumers = num_consumers;
+   devres_add(dev, devres);
+   } else {
+   devres_free(devres);
+   }
 
return ret;
 }
-- 
2.11.0

Applied "regulator: core: fix typo in regulator_bulk_disable()" to the regulator tree

[Mark Brown]

The patch

   regulator: core: fix typo in regulator_bulk_disable()

has been applied to the regulator tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From d1642ea717be09039114dad57a8ae08d77f17dfb Mon Sep 17 00:00:00 2001
From: Dmitry Torokhov 
Date: Fri, 3 Feb 2017 15:16:16 -0800
Subject: [PATCH] regulator: core: fix typo in regulator_bulk_disable()

"re-enable" was misspelled as "reename".

Signed-off-by: Dmitry Torokhov 
Signed-off-by: Mark Brown 
---
 drivers/regulator/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index fe05923611ee..867756651544 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -3661,7 +3661,7 @@ int regulator_bulk_disable(int num_consumers,
for (++i; i < num_consumers; ++i) {
r = regulator_enable(consumers[i].consumer);
if (r != 0)
-   pr_err("Failed to reename %s: %d\n",
+   pr_err("Failed to re-enable %s: %d\n",
   consumers[i].supply, r);
}
 
-- 
2.11.0

Re: [PATCH 4/4] regulator: core: make bulk API support optional supplies

[Mark Brown]

On Fri, Feb 03, 2017 at 03:16:19PM -0800, Dmitry Torokhov wrote:
> Make it possible to use the bulk API with optional supplies, by allowing
> the consumer to marking supplies as optional in the regulator_bulk_data.

So, I know I took the version Bjorn sent before (which was subsequently
reverted) but based on further reflection and having seen people trying
to use it I really don't think this is a good idea and that the revert
was the best thing to do.  The idiomatic use of bulk operations is to
treat the entire block of regulators en masse, this is not possible when
some of the regulators are optional.  You *can* peer into the structure
and special case things but it then makes further uses of the bulk API
on the same block of regulators not work which isn't good.

As I said earlier making it easy to just transparently mix optional
regulators in is something I'd expect to see commonly associated with
abuse of the optional API as a mechanism for not implementing sensible
error handling.


signature.asc
Description: PGP signature

Re: [PATCH] sched: Update unlikely to now likely in sched_move_task()

[Peter Zijlstra]

On Fri, Feb 03, 2017 at 03:30:19PM -0500, Steven Rostedt (VMware) wrote:
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index c56fb57..669f23d 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -7989,14 +7989,14 @@ void sched_move_task(struct task_struct *tsk)
>  
>   if (queued)
>   dequeue_task(rq, tsk, DEQUEUE_SAVE | DEQUEUE_MOVE);
> - if (unlikely(running))
> + if (likely(running))
>   put_prev_task(rq, tsk);
>  
>   sched_change_group(tsk, TASK_MOVE_GROUP);
>  
>   if (queued)
>   enqueue_task(rq, tsk, ENQUEUE_RESTORE | ENQUEUE_MOVE);
> - if (unlikely(running))
> + if (likely(running))
>   set_curr_task(rq, tsk);
>  
>   task_rq_unlock(rq, tsk, );


I prefer to simply remove the hint entirely and match all the other
instances of this pattern.

Now if only C wouldn't stink and have a sensible way to express this
pattern without having to copy/paste it all over :/

Applied "ASoC: Drop unnecessary debugfs ifdef" to the asoc tree

[Mark Brown]

The patch

   ASoC: Drop unnecessary debugfs ifdef

has been applied to the asoc tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From d6075c2601800a8a45bf6f7c3d87afa8598779b5 Mon Sep 17 00:00:00 2001
From: Daniel Baluta 
Date: Wed, 1 Feb 2017 15:37:35 +0200
Subject: [PATCH] ASoC: Drop unnecessary debugfs ifdef

This is a relict of 6553bf06a369 ("ASoC: Don't try to register debugfs
entries if the parent does not exist").

Signed-off-by: Daniel Baluta 
Signed-off-by: Mark Brown 
---
 sound/soc/soc-core.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index f1901bb1466e..7728cce019f9 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -4020,8 +4020,6 @@ static void __exit snd_soc_exit(void)
snd_soc_util_exit();
snd_soc_debugfs_exit();
 
-#ifdef CONFIG_DEBUG_FS
-#endif
platform_driver_unregister(_driver);
 }
 module_exit(snd_soc_exit);
-- 
2.11.0

Re: [PATCH v2 4/5] iio: trigger: add support for STM32 EXTI triggers

[Jonathan Cameron]

On 03/02/17 19:40, Linus Walleij wrote:
> On Mon, Jan 30, 2017 at 3:33 PM, Fabrice Gasnier  
> wrote:
> 
>> EXTi[0..15] gpio signal can be routed internally as trigger source for
>> ADC or DAC conversions. Configure them as interrupts to configure
>> trigger path in HW.
>>
>> Note: interrupt handler isn't required here, and corresponding interrupt
>> can be kept masked at exti controller level.
>>
>> Signed-off-by: Fabrice Gasnier 
> 
> But I see nothing STM32-specific about this driver?
> 
> I think we should do everone a service and just create
> drivers/iio/trigger/gpio-trigger.c
> 
> I wondered before why we don't have a generic GPIO IIO trigger,
> it seems like such an intuitive and useful thing to have.
We do, it just got renamed at some point a while back to be
iio-trig-interrupt after it became clear that it didn't need
to be a gpio either - just an interrupt.  Can't remember which
part provided a non gpio interrupt pin and hence drove that
change.  Was quite a while back!
d4fd73bf25c3aafc891ef4443fc744d427ec1df0 specifically in 2013

Handling of the gpio stuff should be handled in the interrupt
description itself.

However, it's a bit different - in that in the below it
would be the equivalent of triggering on the unused exti
interrupt rather than on the end of conversion.

In this case, because of the hardware linkage we can effectively
skip the first interrupt.

Arguably to make this a general purpose trigger we should enable
that interrupt if anything other than the STM devices that can
use it in hardware are hooked on to it.

So this is an interrupt trigger without the interrupt ever
being visible to software.

It might be easy enough to add that support to the generic version
except that linking said trigger requires some register changes
in the STM side. + there is a kicker in the various last bit
of this patch - we need a way to find out if it's the interrupt
we think it is (i.e. an exti interrupt)
> 
> Let's see what Jonathan says.


> 
>> +config IIO_STM32_EXTI_TRIGGER
>> +   tristate "STM32 EXTI Trigger"
>> +   depends on (ARCH_STM32 && OF) || COMPILE_TEST
> 
> config IIO_GPIO_TRIGGER
> depends on GPIOLIB
> 
>> +   select STM32_EXTI
> 
> Isn't the dependency actually the other way around?
> 
> default STM32_EXTI makes more sense, or just put it into the
> defconfig.
> 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/* STM32 has up to 16 EXTI triggers on GPIOs */
>> +#define STM32_MAX_EXTI_TRIGGER 16
> 
> Just don't put any restrictions like this so it can be widely
> reused.
> 
>> +static irqreturn_t stm32_exti_trigger_handler(int irq, void *data)
>> +{
>> +   /* Exti handler shouldn't be invoked, and isn't used */
>> +   return IRQ_HANDLED;
>> +}
> 
> It could be a good idea to capture the timestamp here if we were
> actually using this IRQ.
> 
>> +static int stm32_exti_trigger_probe(struct platform_device *pdev)
>> +{
>> +   int irq, ret;
>> +   char name[8];
>> +   struct gpio_desc *gpio;
>> +   struct iio_trigger *trig;
>> +   unsigned int i;
>> +
>> +   for (i = 0; i < STM32_MAX_EXTI_TRIGGER; i++) {
> 
> Why not just run this until devm_gpiod_get() returns -ERRNO
> or something?
> 
>> +   snprintf(name, sizeof(name), "exti%d", i);
>> +
>> +   gpio = devm_gpiod_get_optional(>dev, name, GPIOD_IN);
> 
> Why would it be optional?
> 
> Either it is there in the device tree or we get -EINVAL or something
> if there is no
> such index in the device tree. We can get -EPROBE_DEEER too, and then
> we should exit silently or just print that deferring is happening.
> 
>> +   if (IS_ERR_OR_NULL(gpio)) {
>> +   if (IS_ERR(gpio)) {
>> +   dev_err(>dev, "gpio %s get error 
>> %ld\n",
>> +   name, PTR_ERR(gpio));
>> +   return PTR_ERR(gpio);
>> +   }
>> +   dev_dbg(>dev, "No %s gpio\n", name);
>> +   continue;
>> +   }
> 
> Good
> 
>> +   irq = gpiod_to_irq(gpio);
>> +   if (irq < 0) {
>> +   dev_err(>dev, "gpio %d to irq failed\n", i);
>> +   return irq;
>> +   }
>> +
>> +   ret = devm_request_irq(>dev, irq,
>> +  stm32_exti_trigger_handler,
>> +  0, dev_name(>dev), pdev);
Hmm. So this is a trick to set the interrupt mapping up inside the device.
The whole thing doesn't really exist.

Rather feels like there ought to be some generic interface for
'I want to pretend I want a particular interrupt but not actually get one'.

But that would only work in this weird case where there is also a real interrupt
associated with it - just one we elect not to use.
>> +   if (ret) {
>> + 

[GIT PULL] Char/Misc driver fixes for 4.10-rc7

[Greg KH]

The following changes since commit 49def1853334396f948dcb4cedb9347abb318df5:

  Linux 4.10-rc4 (2017-01-15 16:21:59 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/ 
tags/char-misc-4.10-rc7

for you to fetch changes up to 433e19cf33d34bb6751c874a9c00980552fe508c:

  Drivers: hv: vmbus: finally fix hv_need_to_signal_on_read() (2017-01-31 
10:59:48 +0100)


Char/misc driver fixes for 4.10-rc7

Here are two bugfixes that resolve some reported issues.  One in the
firmware loader, that should fix the much-reported problem of crashes
with it.  The other is a hyperv fix for a reported regression.

Both have been in linux-next for a week or so with no reported issues.

Signed-off-by: Greg Kroah-Hartman 


Dexuan Cui (1):
  Drivers: hv: vmbus: finally fix hv_need_to_signal_on_read()

Luis R. Rodriguez (1):
  firmware: fix NULL pointer dereference in __fw_load_abort()

 drivers/base/firmware_class.c |  5 +
 drivers/hv/ring_buffer.c  |  1 +
 drivers/net/hyperv/netvsc.c   |  6 ++
 include/linux/hyperv.h| 32 ++--
 4 files changed, 38 insertions(+), 6 deletions(-)

Re: regression for m68k/coldfire

[Laurent Vivier]

Le 04/02/2017 à 03:03, Greg Ungerer a écrit :
> Hi Laurent,
> 
> On 04/02/17 01:22, Laurent Vivier wrote:
>> Le 03/02/2017 à 16:17, Waldemar Brodkorb a écrit :
> [snip]
>>> Btw: Laurent, are you m68k with mmu support are going to be included
>>> upstream? I always carry an old binary for any m68k with mmu testing.
>>
>> I'm working to have the FPU included for now, that will allow to have
>> the linux-user qemu enabled for 680x0 upstream.
>>
>> I have a 68040 MMU implementation that I will send after this step.
>> I didn't have a look to the ColdFire MMU (is there one?), but as 68040
>> is not the same as the 68030 one, I don't expect it works with coldfire.
> 
> There is a ColdFire MMU in some v4 ColdFire parts, for example
> the 547x, 548x, 5441x and 5445x families. It is not compatible with
> the older 68020/86030/68040 MMU. It is supported in mainline Linux -
> at least for the 547x and 548x parts.
> 
> It would be really nice to have support for ColdFire MMU in QEMU :-)

I can work on this. Do you have a Coldfire distro I can install?

Thanks,
Laurent

Re: [PATCH v2 4/6] bus: add driver for the Technologic Systems NBUS

[Linus Walleij]

On Fri, Feb 3, 2017 at 8:47 PM, Sebastien Bourdelin
 wrote:

> This driver implements a GPIOs bit-banged bus, called the NBUS by
> Technologic Systems. It is used to communicate with the peripherals in
> the FPGA on the TS-4600 SoM.
>
> ---
> Changes v1 -> v2:
>   - rebase on master
>   - the driver now populate its child nodes
>   - remove the 'default y' option from the Kconfig
>   - rework the driver to not use singleton anymore (suggested by Linus
>   Walleij)
>   - replace the use of the legacy GPIO API with gpiod (suggested by
>   Linus Walleij)
>   - use the ts vendor prefix for gpios (suggested by Rob Herring)
>
> Signed-off-by: Sebastien Bourdelin 

This is starting to look nice!

More comments:

First, you sprinked "inline" like cinnamon over everything, skip that. The
compiler will inline selectively as it seems fit if you turn on optimization.

> +static DEFINE_MUTEX(ts_nbus_lock);

Move this into struct ts_nbus, initialize the mutex in probe()
and just mutex_lock(_nbus->lock); etc.

> + * the txrx gpio is used by the FPGA to know if the following transactions
> + * should be handled to read or write a value.
> + */
> +static inline void ts_nbus_set_mode(struct ts_nbus *ts_nbus, int mode)

Why inline? Let the compiler decide about that.

> +{
> +   if (mode == TS_NBUS_READ_MODE)

This mode parameter is too complicated. Isn't it just a bool?
(not superimportant)

> +   gpiod_set_value_cansleep(ts_nbus->txrx, 0);
> +   else
> +   gpiod_set_value_cansleep(ts_nbus->txrx, 1);
> +}

You're certainly just using it as a bool.

> +static inline void ts_nbus_set_direction(struct ts_nbus *ts_nbus, int 
> direction)
> +{
> +   int i;
> +
> +   for (i = 0; i < ts_nbus->data->ndescs; i++) {
> +   if (direction == TS_NBUS_DIRECTION_IN)
> +   gpiod_direction_input(ts_nbus->data->desc[i]);
> +   else
> +   gpiod_direction_output(ts_nbus->data->desc[i], 1);

Add a comment here explaining why you driver the line high by default
when setting it to output mode. It certainly makes sense but how
does the electronics work and why?

> +static inline void ts_nbus_reset_bus(struct ts_nbus *ts_nbus)
> +{
> +   int i;
> +   int values[ts_nbus->data->ndescs];
> +
> +   for (i = 0; i < ts_nbus->data->ndescs; i++)
> +   values[i] = 0;
> +
> +   gpiod_set_array_value_cansleep(ts_nbus->data->ndescs,
> +   ts_nbus->data->desc, values);
> +   gpiod_set_value_cansleep(ts_nbus->csn, 0);
> +   gpiod_set_value_cansleep(ts_nbus->strobe, 0);
> +   gpiod_set_value_cansleep(ts_nbus->ale, 0);

Add a comment about the process taken when this bus is reset. We
see what is happening, but why?

> +/*
> + * let the FPGA knows it can process.
> + */
> +static inline void ts_nbus_start_transaction(struct ts_nbus *ts_nbus)

Why inline?

> +{
> +   gpiod_set_value_cansleep(ts_nbus->strobe, 1);
> +}

For example this is a well commented function. We see what is happening
and stobe has an evident name. Nice work!

> +/*
> + * return the byte value read from the data gpios.
> + */
> +static inline u8 ts_nbus_read_byte(struct ts_nbus *ts_nbus)

Why inline?

Then this cannot fail can it?

I think this accessor should be changed to return an error code.

static int ts_nbus_read_byte(struct ts_nbus *ts_nbus, u8 *val);

Then if the return value from the function is != 0 it failed. Simple
to check, just pass a pointer to the value you are getting in
val.

I KNOW I KNOW, not you have to put in error handling everywhere,
what a DRAG! But we usually follow that pattern because...

> +{
> +   struct gpio_descs *gpios = ts_nbus->data;
> +   int i;
> +   u8 value = 0;
> +
> +   for (i = 0; i < gpios->ndescs; i++)

Using gpios->ndescs is a bit overparametrized right? Isn't it
simply 8 bits? Just putting 8 there is fine IMO. All 8 descs
must be available for the thing to work anyway right?

> +   if (gpiod_get_value_cansleep(gpios->desc[i]))

This can fail and you should return an error if < 0...

You are ignoring that right now. That is why the function should
be returning an error code that is usually 0.

> +   value |= 1 << i;

Use:
#include 

value |= BIT(i);

> +/*
> + * set the data gpios accordingly to the byte value.
> + */
> +static inline void ts_nbus_write_byte(struct ts_nbus *ts_nbus, u8 byte)
> +{
> +   struct gpio_descs *gpios = ts_nbus->data;
> +   int i;
> +   int values[gpios->ndescs];
> +
> +   for (i = 0; i < gpios->ndescs; i++)
> +   if (byte & (1 << i))
> +   values[i] = 1;
> +   else
> +   values[i] = 0;
> +
> +   gpiod_set_array_value_cansleep(gpios->ndescs, gpios->desc, values);

This can also fail and you should check the return code and print an error
message if 

[GIT PULL] Staging/IIO driver fixes for 4.10-rc7

[Greg KH]

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/gregkh/staging.git/ 
tags/staging-4.10-rc7

for you to fetch changes up to b17c1bba9cec1727451b906d9a0c209774624873:

  staging: greybus: timesync: validate platform state callback (2017-01-25 
11:36:59 +0100)


Staging/IIO fixes for 4.10-rc7

Here are a few small IIO and one staging driver fix for 4.10-rc7.  They
fix some reported issues with the drivers.

All of them have been in linux-next for a week or so with no reported
issues.

Signed-off-by: Greg Kroah-Hartman 


Alison Schofield (3):
  iio: health: afe4403: retrieve a valid iio_dev in suspend/resume
  iio: health: afe4404: retrieve a valid iio_dev in suspend/resume
  iio: adc: palmas_gpadc: retrieve a valid iio_dev in suspend/resume

Greg Kroah-Hartman (1):
  Merge tag 'iio-fixes-for-4.10b' of git://git.kernel.org/.../jic23/iio 
into staging-linus

John Brooks (1):
  iio: dht11: Use usleep_range instead of msleep for start signal

Matt Ranostay (1):
  iio: health: max30100: fixed parenthesis around FIFO count check

Rui Miguel Silva (1):
  staging: greybus: timesync: validate platform state callback

 drivers/iio/adc/palmas_gpadc.c  | 4 ++--
 drivers/iio/health/afe4403.c| 4 ++--
 drivers/iio/health/afe4404.c| 4 ++--
 drivers/iio/health/max30100.c   | 2 +-
 drivers/iio/humidity/dht11.c| 6 --
 drivers/staging/greybus/timesync_platform.c | 6 ++
 6 files changed, 17 insertions(+), 9 deletions(-)

[GIT PULL] USB driver fixes for 4.10-rc7

[Greg KH]

The following changes since commit 7a308bb3016f57e5be11a677d15b821536419d36:

  Linux 4.10-rc5 (2017-01-22 12:54:15 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ 
tags/usb-4.10-rc7

for you to fetch changes up to 424414947da3dd5cb0d60e4f299f7c51e472ae77:

  Merge tag 'usb-serial-4.10-rc7' of 
git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus 
(2017-02-03 22:19:15 +0100)


USB fixes for 4.10-rc7

Here are some small USB fixes for some reported issues, and the usual
number of new device ids for 4.10-rc7.

All of these, except the last new device id, have been in linux-next for
a while with no reported issues.

Signed-off-by: Greg Kroah-Hartman 


Aleksander Morgado (1):
  USB: serial: qcserial: add Dell DW5570 QDL

Bjørn Mork (1):
  USB: serial: option: add device ID for HP lt2523 (Novatel E371)

Greg Kroah-Hartman (2):
  Merge tag 'usb-serial-4.10-rc6' of 
git://git.kernel.org/.../johan/usb-serial into usb-linus
  Merge tag 'usb-serial-4.10-rc7' of 
git://git.kernel.org/.../johan/usb-serial into usb-linus

Lukáš Lalinský (1):
  USB: Add quirk for WORLDE easykey.25 MIDI keyboard

Marcel J.E. Mol (1):
  USB: serial: pl2303: add ATEN device ID

Tony Lindgren (2):
  usb: musb: Fix host mode error -71 regression
  usb: musb: Fix external abort on non-linefetch for musb_irq_work()

Vincent Pelletier (1):
  usb: gadget: f_fs: Assorted buffer overflow checks.

 drivers/usb/core/quirks.c  |  4 
 drivers/usb/gadget/function/f_fs.c | 13 -
 drivers/usb/musb/musb_core.c   | 26 +-
 drivers/usb/musb/musb_core.h   |  1 -
 drivers/usb/serial/option.c|  1 +
 drivers/usb/serial/pl2303.c|  1 +
 drivers/usb/serial/pl2303.h|  1 +
 drivers/usb/serial/qcserial.c  |  1 +
 8 files changed, 33 insertions(+), 15 deletions(-)

[PATCH v5 3/3] spi: acpi: Initialize modalias from of_compatible

[Dan O'Donovan]

When using devicetree spi_device.modalias is set to the compatible
string with the vendor prefix removed. For SPI devices described via
ACPI the spi_device.modalias string is initialized by acpi_device_hid.
When using ACPI and DT ids this string ends up something like "PRP0001".

Change acpi_register_spi_device to use the of_compatible property if
present. This makes it easier to instantiate spi drivers through ACPI
with DT ids.

Signed-off-by: Dan O'Donovan 
Reviewed-by: Andy Shevchenko 
Reviewed-by: Jarkko Nikula 
Tested-by: Jarkko Nikula 
---
 drivers/spi/spi.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 656dd3e..d9afc32 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1722,13 +1722,15 @@ static acpi_status acpi_register_spi_device(struct 
spi_master *master,
return AE_OK;
}
 
+   acpi_set_modalias(adev, acpi_device_hid(adev),
+ spi->modalias, sizeof(spi->modalias));
+
if (spi->irq < 0)
spi->irq = acpi_dev_gpio_irq_get(adev, 0);
 
acpi_device_set_enumerated(adev);
 
adev->power.flags.ignore_parent = true;
-   strlcpy(spi->modalias, acpi_device_hid(adev), sizeof(spi->modalias));
if (spi_add_device(spi)) {
adev->power.flags.ignore_parent = false;
dev_err(>dev, "failed to add SPI device %s from ACPI\n",
-- 
2.7.4

[PATCH v5 0/3] Init device ids from ACPI of_compatible

[Dan O'Donovan]

When using devicetree, stuff like i2c_client.name or spi_device.modalias
is initialized to the first DT compatible id with the vendor prefix
stripped. Since some drivers rely on this in order to differentiate between
hardware variants, try to replicate it when using ACPI with DT ids.

This also makes it so that the i2c_device_id parameter passed to probe is
non-NULL when matching with ACPI and DT ids.

Tested using ACPI overlays but there is no actual dependency. This series
just extends the PRP0001 feature to be more useful for I2C/SPI.

The patches only touches the ACPI-specific parts of the i2c and spi core.

Here is an example .dsl for an SPI accelerometer connected to minnowboard max:

Device (ACCL)
{
Name (_ADR, Zero)
Name (_HID, "PRP0001")
Name (_UID, One)

Method (_CRS, 0, Serialized)
{
Name (RBUF, ResourceTemplate ()
{
SPISerialBus(1, PolarityLow, FourWireMode, 16,
ControllerInitiated, 100, ClockPolarityLow,
ClockPhaseFirst, "\\_SB.SPI1",)
GpioInt (Edge, ActiveHigh, Exclusive, PullDown, 0x,
 "\\_SB.GPO2", 0x00, ResourceConsumer, , )
{ // Pin list
1
}
})
Return (RBUF)
}
Name (_DSD, Package ()
{
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package ()
{
Package () {"compatible", "st,lis3dh"},
}
})
}

Credit to Leonard Crestez for the original version of this patch set.

Link to v4: http://www.spinics.net/lists/linux-acpi/msg71657.html
Changes:
 * add acpi_set_modalias wrapper to handle fallback to ACPI ID (Mark Brown)

Link to v3: http://www.spinics.net/lists/linux-acpi/msg71531.html
Changes:
 * Minor cosmetic/readability improvements (Andy Shevchenko)

Link to v2: https://lkml.org/lkml/2016/7/13/392
Changes:
 * Use appropriate subject prefix for each subsystem (Mark Brown)
 * Use ACPI info as before if getting OF info fails (Mark Brown)
 * Minor cosmetic/readability improvements (Rafael J. Wysocki)

Link to v1: https://www.spinics.net/lists/linux-acpi/msg66469.html
Changes:
 * Rebase on after acpi overlays got it.
 * Change acpi_of_modalias outlen param to size_t
 * Use {} after else

Dan O'Donovan (3):
  ACPI / bus: Export acpi_of_modalias equiv of of_modalias_node
  i2c: acpi: Initialize info.type from of_compatible
  spi: acpi: Initialize modalias from of_compatible

 drivers/acpi/bus.c  | 42 ++
 drivers/i2c/i2c-core.c  |  3 ++-
 drivers/spi/spi.c   |  4 +++-
 include/acpi/acpi_bus.h |  2 ++
 4 files changed, 49 insertions(+), 2 deletions(-)

-- 
2.7.4

Re: [lkp-robot] [mm, vmscan] 5e56dfbd83: fsmark.files_per_sec -11.1% regression

[Ye Xiaolong]

On 01/26, Michal Hocko wrote:
>On Wed 25-01-17 12:27:06, Ye Xiaolong wrote:
>> On 01/24, Michal Hocko wrote:
>> >On Mon 23-01-17 09:26:44, kernel test robot wrote:
>> >> 
>> >> Greeting,
>> >> 
>> >> FYI, we noticed a -11.1% regression of fsmark.files_per_sec due to commit:
>> >> 
>> >> 
>> >> commit: 5e56dfbd837421b7fa3c6c06018c6701e2704917 ("mm, vmscan: consider 
>> >> eligible zones in get_scan_count")
>> >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
>> >
>> >This is more than unexpected. This patch should be basically noop for
>> >anything but CONFIG_HIGHMEM systems. And your config says this is 64b
>> >kernel. Are those results reproducible? And could you try to compare
>> 
>> Yes, the results are well reproducible, both the commit in question and its
>> parent have ran for 4 times.
>> 
>> >perf profiles before and after the patch.
>> 
>> Here is the perf profiles, 
>
>I do not see any reclaim path in the profile... Could you take a
>snapshot of /proc/vmstat and /proc/zoneinfo before and after the test
>please?

Sorry for the late, just come back from a vacation. Proc data is attached.

Thanks,
Xiaolong

>
>-- 
>Michal Hocko
>SUSE Labs
Before fsmark running

cat /proc/vmstat
nr_free_pages 16149930
nr_zone_inactive_anon 2435
nr_zone_active_anon 20298
nr_zone_inactive_file 169490
nr_zone_active_file 5927
nr_zone_unevictable 0
nr_zone_write_pending 1
nr_mlock 0
nr_slab_reclaimable 12530
nr_slab_unreclaimable 22807
nr_page_table_pages 1341
nr_kernel_stack 14176
nr_bounce 0
nr_zspages 0
numa_hit 426096
numa_miss 0
numa_foreign 0
numa_interleave 216697
numa_local 300230
numa_other 125866
nr_free_cma 50736
nr_inactive_anon 2435
nr_active_anon 20298
nr_inactive_file 169490
nr_active_file 5927
nr_unevictable 0
nr_isolated_anon 0
nr_isolated_file 0
nr_pages_scanned 0
workingset_refault 0
workingset_activate 0
workingset_nodereclaim 0
nr_anon_pages 20493
nr_mapped 4992
nr_file_pages 177920
nr_dirty 1
nr_writeback 0
nr_writeback_temp 0
nr_shmem 2503
nr_shmem_hugepages 0
nr_shmem_pmdmapped 0
nr_anon_transparent_hugepages 6
nr_unstable 0
nr_vmscan_write 0
nr_vmscan_immediate_reclaim 0
nr_dirtied 8
nr_written 7
nr_dirty_threshold 3246583
nr_dirty_background_threshold 1621309
pgpgin 19153
pgpgout 1232013
pswpin 0
pswpout 0
pgalloc_dma 0
pgalloc_dma32 776
pgalloc_normal 471187
pgalloc_movable 0
allocstall_dma 0
allocstall_dma32 0
allocstall_normal 0
allocstall_movable 0
pgskip_dma 0
pgskip_dma32 0
pgskip_normal 0
pgskip_movable 0
pgfree 16797284
pgactivate 6738
pgdeactivate 0
pgfault 125954
pgmajfault 0
pglazyfreed 0
pgrefill 0
pgsteal_kswapd 0
pgsteal_direct 0
pgscan_kswapd 0
pgscan_direct 0
pgscan_direct_throttle 0
zone_reclaim_failed 0
pginodesteal 0
slabs_scanned 0
kswapd_inodesteal 0
kswapd_low_wmark_hit_quickly 0
kswapd_high_wmark_hit_quickly 0
pageoutrun 0
pgrotated 0
drop_pagecache 0
drop_slab 0
numa_pte_updates 0
numa_huge_pte_updates 0
numa_hint_faults 0
numa_hint_faults_local 0
numa_pages_migrated 0
pgmigrate_success 0
pgmigrate_fail 0
compact_migrate_scanned 0
compact_free_scanned 0
compact_isolated 6337
compact_stall 0
compact_fail 0
compact_success 0
compact_daemon_wake 0
compact_daemon_migrate_scanned 0
compact_daemon_free_scanned 0
htlb_buddy_alloc_success 0
htlb_buddy_alloc_fail 0
unevictable_pgs_culled 0
unevictable_pgs_scanned 0
unevictable_pgs_rescued 0
unevictable_pgs_mlocked 0
unevictable_pgs_munlocked 0
unevictable_pgs_cleared 0
unevictable_pgs_stranded 0
thp_fault_alloc 5
thp_fault_fallback 0
thp_collapse_alloc 6
thp_collapse_alloc_failed 0
thp_file_alloc 0
thp_file_mapped 0
thp_split_page 0
thp_split_page_failed 0
thp_deferred_split_page 2
thp_split_pmd 0
thp_zero_page_alloc 0
thp_zero_page_alloc_failed 0
balloon_inflate 0
balloon_deflate 0
balloon_migrate 0
cat /proc/zoneinfo
Node 0, zone  DMA
  per-node stats
  nr_inactive_anon 2216
  nr_active_anon 16566
  nr_inactive_file 84645
  nr_active_file 2972
  nr_unevictable 0
  nr_isolated_anon 0
  nr_isolated_file 0
  nr_pages_scanned 0
  workingset_refault 0
  workingset_activate 0
  workingset_nodereclaim 0
  nr_anon_pages 16760
  nr_mapped3111
  nr_file_pages 89855
  nr_dirty 1
  nr_writeback 0
  nr_writeback_temp 0
  nr_shmem 2238
  nr_shmem_hugepages 0
  nr_shmem_pmdmapped 0
  nr_anon_transparent_hugepages 6
  nr_unstable  0
  nr_vmscan_write 0
  nr_vmscan_immediate_reclaim 0
  nr_dirtied   4
  nr_written   3
  pages free 3961
min  5
low  8
high 11
   node_scanned  0
spanned  4095
present  3983
managed  3961
  nr_free_pages 3961
  nr_zone_inactive_anon 0
  nr_zone_active_anon 0
  nr_zone_inactive_file 0
  nr_zone_active_file 0
  nr_zone_unevictable 0
  nr_zone_write_pending 0
  nr_mlock 0
  nr_slab_reclaimable 0
  nr_slab_unreclaimable 0
  nr_page_table_pages 0
  

Re: [PATCH] clocksource: arm_arch_timer: print timer value at init time

[Daniel Lezcano]

On Mon, Dec 19, 2016 at 09:47:37AM -0800, Olof Johansson wrote:
> This is useful to get an indication of how much time we spent in firmware.
> 
> It's not guaranteed that the timer started at 0 on reset, so it's just
> an approximation, and might very well be invalid on some systems. But
> it's still a useful metric to have access to.

Hi Olof,

[ ... ]

> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -521,6 +521,8 @@ arch_timer_detect_rate(void __iomem *cntbase, struct 
> device_node *np)
>  
>  static void arch_timer_banner(unsigned type)
>  {
> + unsigned long cnt = arch_timer_read_counter();
> +

arch_timer_banner() is called before arch_counter_register() where the
arch_timer_read_counter() function pointer is set.

Perhaps the arch_timer_banner() and arch_counter_register() should be swapped in
arch_timer_common_init().

>   pr_info("Architected %s%s%s timer(s) running at %lu.%02luMHz 
> (%s%s%s).\n",
>type & ARCH_CP15_TIMER ? "cp15" : "",
>type == (ARCH_CP15_TIMER | ARCH_MEM_TIMER) ?  " and " : "",
> @@ -534,6 +536,8 @@ static void arch_timer_banner(unsigned type)
>type & ARCH_MEM_TIMER ?
>   arch_timer_mem_use_virtual ? "virt" : "phys" :
>   "");
> + pr_info("Initial timer value: 0x%lx: %ld.%02lds\n",
> + cnt, cnt/arch_timer_rate, (cnt/(arch_timer_rate/100)) % 100);
>  }
>  

-- 

  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH] wcn36xx: Implement cancel_hw_scan

[Mart Raudsepp]

> In the even that the wcn36xx interface is brought down while a
> hw_scan
> is active we must abort and wait for the ongoing scan to signal
> completion to mac80211.
> 
> Reported-by: Mart Raudsepp 
> Fixes: 886039036c20 ("wcn36xx: Implement firmware assisted scan")
> Signed-off-by: Bjorn Andersson 

Tested-by: Mart Raudsepp 
Please s/even/event/ in commit log

> ---
>  drivers/net/wireless/ath/wcn36xx/main.c| 25
> -
>  drivers/net/wireless/ath/wcn36xx/wcn36xx.h |  1 +
>  2 files changed, 25 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/ath/wcn36xx/main.c
> b/drivers/net/wireless/ath/wcn36xx/main.c
> index a24edf33be93..bb7110f7fc86 100644
> --- a/drivers/net/wireless/ath/wcn36xx/main.c
> +++ b/drivers/net/wireless/ath/wcn36xx/main.c
> @@ -574,6 +574,7 @@ static void wcn36xx_hw_scan_worker(struct
> work_struct *work)
>   struct cfg80211_scan_request *req = wcn->scan_req;
>   u8 channels[WCN36XX_HAL_PNO_MAX_NETW_CHANNELS_EX];
>   struct cfg80211_scan_info scan_info = {};
> + bool aborted = false;
>   int i;
>  
>   wcn36xx_dbg(WCN36XX_DBG_MAC, "mac80211 scan %d channels
> worker\n", req->n_channels);
> @@ -585,6 +586,13 @@ static void wcn36xx_hw_scan_worker(struct
> work_struct *work)
>  
>   wcn36xx_smd_init_scan(wcn, HAL_SYS_MODE_SCAN);
>   for (i = 0; i < req->n_channels; i++) {
> + mutex_lock(>scan_lock);
> + aborted = wcn->scan_aborted;
> + mutex_unlock(>scan_lock);
> +
> + if (aborted)
> + break;
> +
>   wcn->scan_freq = req->channels[i]->center_freq;
>   wcn->scan_band = req->channels[i]->band;
>  
> @@ -596,7 +604,7 @@ static void wcn36xx_hw_scan_worker(struct
> work_struct *work)
>   }
>   wcn36xx_smd_finish_scan(wcn, HAL_SYS_MODE_SCAN);
>  
> - scan_info.aborted = false;
> + scan_info.aborted = aborted;
>   ieee80211_scan_completed(wcn->hw, _info);
>  
>   mutex_lock(>scan_lock);
> @@ -615,6 +623,8 @@ static int wcn36xx_hw_scan(struct ieee80211_hw
> *hw,
>   mutex_unlock(>scan_lock);
>   return -EBUSY;
>   }
> +
> + wcn->scan_aborted = false;
>   wcn->scan_req = _req->req;
>   mutex_unlock(>scan_lock);
>  
> @@ -623,6 +633,18 @@ static int wcn36xx_hw_scan(struct ieee80211_hw
> *hw,
>   return 0;
>  }
>  
> +static void wcn36xx_cancel_hw_scan(struct ieee80211_hw *hw,
> +    struct ieee80211_vif *vif)
> +{
> + struct wcn36xx *wcn = hw->priv;
> +
> + mutex_lock(>scan_lock);
> + wcn->scan_aborted = true;
> + mutex_unlock(>scan_lock);
> +
> + cancel_work_sync(>scan_work);
> +}
> +
>  static void wcn36xx_update_allowed_rates(struct ieee80211_sta *sta,
>    enum nl80211_band band)
>  {
> @@ -1034,6 +1056,7 @@ static const struct ieee80211_ops wcn36xx_ops =
> {
>   .tx = wcn36xx_tx,
>   .set_key= wcn36xx_set_key,
>   .hw_scan= wcn36xx_hw_scan,
> + .cancel_hw_scan = wcn36xx_cancel_hw_scan,
>   .bss_info_changed   = wcn36xx_bss_info_changed,
>   .set_rts_threshold  = wcn36xx_set_rts_threshold,
>   .sta_add= wcn36xx_sta_add,
> diff --git a/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
> b/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
> index 571e9f76da7e..b52b4da9a967 100644
> --- a/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
> +++ b/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
> @@ -220,6 +220,7 @@ struct wcn36xx {
>   int scan_freq;
>   int scan_band;
>   struct mutexscan_lock;
> + boolscan_aborted;
>  
>   /* DXE channels */
>   struct wcn36xx_dxe_ch   dxe_tx_l_ch;/* TX low
> */

Re: Linux 4.9.8

[Greg KH]

diff --git a/Makefile b/Makefile
index da704d903321..1130803ab93c 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 4
 PATCHLEVEL = 9
-SUBLEVEL = 7
+SUBLEVEL = 8
 EXTRAVERSION =
 NAME = Roaring Lionus
 
diff --git a/drivers/net/ethernet/broadcom/bcmsysport.c 
b/drivers/net/ethernet/broadcom/bcmsysport.c
index 25d1eb4933d0..be7ec5a76a54 100644
--- a/drivers/net/ethernet/broadcom/bcmsysport.c
+++ b/drivers/net/ethernet/broadcom/bcmsysport.c
@@ -710,11 +710,8 @@ static unsigned int __bcm_sysport_tx_reclaim(struct 
bcm_sysport_priv *priv,
unsigned int c_index, last_c_index, last_tx_cn, num_tx_cbs;
unsigned int pkts_compl = 0, bytes_compl = 0;
struct bcm_sysport_cb *cb;
-   struct netdev_queue *txq;
u32 hw_ind;
 
-   txq = netdev_get_tx_queue(ndev, ring->index);
-
/* Compute how many descriptors have been processed since last call */
hw_ind = tdma_readl(priv, TDMA_DESC_RING_PROD_CONS_INDEX(ring->index));
c_index = (hw_ind >> RING_CONS_INDEX_SHIFT) & RING_CONS_INDEX_MASK;
@@ -745,9 +742,6 @@ static unsigned int __bcm_sysport_tx_reclaim(struct 
bcm_sysport_priv *priv,
 
ring->c_index = c_index;
 
-   if (netif_tx_queue_stopped(txq) && pkts_compl)
-   netif_tx_wake_queue(txq);
-
netif_dbg(priv, tx_done, ndev,
  "ring=%d c_index=%d pkts_compl=%d, bytes_compl=%d\n",
  ring->index, ring->c_index, pkts_compl, bytes_compl);
@@ -759,16 +753,33 @@ static unsigned int __bcm_sysport_tx_reclaim(struct 
bcm_sysport_priv *priv,
 static unsigned int bcm_sysport_tx_reclaim(struct bcm_sysport_priv *priv,
   struct bcm_sysport_tx_ring *ring)
 {
+   struct netdev_queue *txq;
unsigned int released;
unsigned long flags;
 
+   txq = netdev_get_tx_queue(priv->netdev, ring->index);
+
spin_lock_irqsave(>lock, flags);
released = __bcm_sysport_tx_reclaim(priv, ring);
+   if (released)
+   netif_tx_wake_queue(txq);
+
spin_unlock_irqrestore(>lock, flags);
 
return released;
 }
 
+/* Locked version of the per-ring TX reclaim, but does not wake the queue */
+static void bcm_sysport_tx_clean(struct bcm_sysport_priv *priv,
+struct bcm_sysport_tx_ring *ring)
+{
+   unsigned long flags;
+
+   spin_lock_irqsave(>lock, flags);
+   __bcm_sysport_tx_reclaim(priv, ring);
+   spin_unlock_irqrestore(>lock, flags);
+}
+
 static int bcm_sysport_tx_poll(struct napi_struct *napi, int budget)
 {
struct bcm_sysport_tx_ring *ring =
@@ -1253,7 +1264,7 @@ static void bcm_sysport_fini_tx_ring(struct 
bcm_sysport_priv *priv,
napi_disable(>napi);
netif_napi_del(>napi);
 
-   bcm_sysport_tx_reclaim(priv, ring);
+   bcm_sysport_tx_clean(priv, ring);
 
kfree(ring->cbs);
ring->cbs = NULL;
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c 
b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
index fb8bb027b69c..d223e7cb68ba 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
@@ -1740,8 +1740,11 @@ int mlx4_en_start_port(struct net_device *dev)
/* Process all completions if exist to prevent
 * the queues freezing if they are full
 */
-   for (i = 0; i < priv->rx_ring_num; i++)
+   for (i = 0; i < priv->rx_ring_num; i++) {
+   local_bh_disable();
napi_schedule(>rx_cq[i]->napi);
+   local_bh_enable();
+   }
 
netif_tx_start_all_queues(dev);
netif_device_attach(dev);
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c 
b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
index 33495d88aeb2..e7b2158bb48a 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
@@ -193,6 +193,9 @@ static inline bool mlx5e_rx_cache_put(struct mlx5e_rq *rq,
return false;
}
 
+   if (unlikely(page_is_pfmemalloc(dma_info->page)))
+   return false;
+
cache->page_cache[cache->tail] = *dma_info;
cache->tail = tail_next;
return true;
diff --git a/drivers/net/ethernet/mellanox/mlxsw/pci.h 
b/drivers/net/ethernet/mellanox/mlxsw/pci.h
index d942a3e6fa41..846fd4df7dab 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/pci.h
+++ b/drivers/net/ethernet/mellanox/mlxsw/pci.h
@@ -211,21 +211,21 @@ MLXSW_ITEM32(pci, eqe, owner, 0x0C, 0, 1);
 /* pci_eqe_cmd_token
  * Command completion event - token
  */
-MLXSW_ITEM32(pci, eqe, cmd_token, 0x08, 16, 16);
+MLXSW_ITEM32(pci, eqe, cmd_token, 0x00, 16, 16);
 
 /* pci_eqe_cmd_status
  * Command completion event - status
  */
-MLXSW_ITEM32(pci, eqe, cmd_status, 0x08, 0, 8);
+MLXSW_ITEM32(pci, eqe, cmd_status, 0x00, 0, 8);
 
 /* pci_eqe_cmd_out_param_h
  * Command completion event - output parameter - higher part
  */
-MLXSW_ITEM32(pci, eqe, 

Re: [PATCH v2 1/3] perf tools: Use offset instead of dwarfnum in register table.

[Hekuang]

hi

在 2017/2/3 21:00, Will Deacon 写道:

On Fri, Feb 03, 2017 at 11:06:05AM +, He Kuang wrote:

This patch changes the 'dwarfnum' to 'offset' in register table, so
the index of array becomes the dwarfnum (the index of each register
defined by DWARF) and the "offset" member means the byte-offset of the
register in (user_)pt_regs. This change makes the code consistent with
x86.

Acked-by: Masami Hiramatsu 
Signed-off-by: He Kuang 
---
  tools/perf/arch/arm64/util/dwarf-regs.c | 107 
  1 file changed, 52 insertions(+), 55 deletions(-)

Thanks for splitting this up. Comment below.


diff --git a/tools/perf/arch/arm64/util/dwarf-regs.c 
b/tools/perf/arch/arm64/util/dwarf-regs.c
index d49efeb..090f36b 100644
--- a/tools/perf/arch/arm64/util/dwarf-regs.c
+++ b/tools/perf/arch/arm64/util/dwarf-regs.c
@@ -9,72 +9,69 @@
   */
  
  #include 

+#include  /* for struct user_pt_regs */
  #include 
  
-struct pt_regs_dwarfnum {

+struct pt_regs_offset {
const char *name;
-   unsigned int dwarfnum;
+   int offset;
  };
  
-#define STR(s) #s

-#define REG_DWARFNUM_NAME(r, num) {.name = r, .dwarfnum = num}
-#define GPR_DWARFNUM_NAME(num) \
-   {.name = STR(%x##num), .dwarfnum = num}
-#define REG_DWARFNUM_END {.name = NULL, .dwarfnum = 0}
-
  /*
   * Reference:
   * 
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0057b/IHI0057B_aadwarf64.pdf
   */
-static const struct pt_regs_dwarfnum regdwarfnum_table[] = {
-   GPR_DWARFNUM_NAME(0),
-   GPR_DWARFNUM_NAME(1),
-   GPR_DWARFNUM_NAME(2),
-   GPR_DWARFNUM_NAME(3),
-   GPR_DWARFNUM_NAME(4),
-   GPR_DWARFNUM_NAME(5),
-   GPR_DWARFNUM_NAME(6),
-   GPR_DWARFNUM_NAME(7),
-   GPR_DWARFNUM_NAME(8),
-   GPR_DWARFNUM_NAME(9),
-   GPR_DWARFNUM_NAME(10),
-   GPR_DWARFNUM_NAME(11),
-   GPR_DWARFNUM_NAME(12),
-   GPR_DWARFNUM_NAME(13),
-   GPR_DWARFNUM_NAME(14),
-   GPR_DWARFNUM_NAME(15),
-   GPR_DWARFNUM_NAME(16),
-   GPR_DWARFNUM_NAME(17),
-   GPR_DWARFNUM_NAME(18),
-   GPR_DWARFNUM_NAME(19),
-   GPR_DWARFNUM_NAME(20),
-   GPR_DWARFNUM_NAME(21),
-   GPR_DWARFNUM_NAME(22),
-   GPR_DWARFNUM_NAME(23),
-   GPR_DWARFNUM_NAME(24),
-   GPR_DWARFNUM_NAME(25),
-   GPR_DWARFNUM_NAME(26),
-   GPR_DWARFNUM_NAME(27),
-   GPR_DWARFNUM_NAME(28),
-   GPR_DWARFNUM_NAME(29),
-   REG_DWARFNUM_NAME("%lr", 30),
-   REG_DWARFNUM_NAME("%sp", 31),
-   REG_DWARFNUM_END,
-};
+#define REG_OFFSET_NAME(r, num) {.name = "%" #r, \
+   .offset = offsetof(struct user_pt_regs, regs[num])}

Whilst this works in practice, this is undefined behaviour for "sp", since
you'll go off the end of the regs array.


It's not undefined behaviour here,
struct user_pt_regs {
__u64   regs[31];
__u64   sp;
__u64   pc;
__u64   pstate;
};
user_pt_regs->regs[31] is user_pt_regs->sp and the offset value is correct.


I still think you're better off sticking with the dwarfnum, then just having
a dwarfnum2offset macro that multiplies by the size of a register.

Will
I think add a ptregs_offset field is more suitable and makes the code 
indepent

to struct user_pt_regs layout, for example if the structure changed to this:

struct user_pt_regs {
__u64   sp;
__u64   pc;
__u64   pstate;
__u64   regs[31];
};

The multiply result will be incorrect.
Patch updated and the change is similar to commit "4679bccaa308"
 (perf tools powerpc: Add support for generating bpf prologue)

Please review, thanks.

Re: [PATCH 2/5] regulator: core: have regulator_dev_lookup() return ERR_PTR-encoded errors

[Mark Brown]

On Fri, Feb 03, 2017 at 01:56:01PM -0800, Dmitry Torokhov wrote:

> - return NULL;
> + return r ? r : ERR_PTR(-ENODEV);
>  }

Please write normal conditional statements to keep the code legible.


signature.asc
Description: PGP signature

Re: [PATCH v5 3/3] spi: acpi: Initialize modalias from of_compatible

[Mark Brown]

On Sat, Feb 04, 2017 at 08:00:28AM +, Dan O'Donovan wrote:

> + acpi_set_modalias(adev, acpi_device_hid(adev),
> +   spi->modalias, sizeof(spi->modalias));
> +

The formatting here is really weird (why isn't the third argument on the
line above?) but otherwise

Acked-by: Mark Brown 


signature.asc
Description: PGP signature

[PATCH] mailmap: Change email to new Konsulko email

[Matt Ranostay]

Signed-off-by: Matt Ranostay 
---
 .mailmap | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.mailmap b/.mailmap
index 67dc22ffc9a8..e775f792d436 100644
--- a/.mailmap
+++ b/.mailmap
@@ -109,6 +109,7 @@ Mauro Carvalho Chehab  

 Mauro Carvalho Chehab  
 Matt Ranostay  Matthew Ranostay 

 Matt Ranostay  
+Matt Ranostay  
 Mayuresh Janorkar 
 Michael Buesch 
 Michel Dänzer 
-- 
2.10.2

Re: [PATCH resend 4.9] hw_random: Don't use a stack buffer in add_early_randomness()

[Yisheng Xie]

hi, Matt,
Thanks for your reply.

On 2017/2/4 12:34, Matt Mullins wrote:
> On Sat, Feb 04, 2017 at 11:47:38AM +0800, Yisheng Xie wrote:
>> On 2016/10/18 1:06, Andy Lutomirski wrote:
>>> hw_random carefully avoids using a stack buffer except in
>>> add_early_randomness().  This causes a crash in virtio_rng if
>>> CONFIG_VMAP_STACK=y.
>> I try to understand this patch, but I do not know why it will cause
>> a crash in virtio_rng with CONFIG_VMAP_STACK=y?
>> Could you please give me more info. about it.
> 
> My original report was
> https://lkml.kernel.org/r/20161016002151.ga18...@hydra.tuxags.com.
> 
> The virtio ring APIs use scatterlists to keep track of the buffers, and
> scatterlist requires addresses to be in the kernel direct-mapped address 
> range.
> This is not the case for vmalloc()ed addresses, such as the original on-stack
> "bytes" array when VMAP_STACK=y.
> 
I see, and will check the logic to get more detail about it.

Thanks.
Yisheng Xie

Re: [PATCHv3 03/12] mm: fix handling PTE-mapped THPs in page_referenced()

[Kirill A. Shutemov]

On Thu, Feb 02, 2017 at 04:26:56PM +0100, Michal Hocko wrote:
> On Sun 29-01-17 20:38:49, Kirill A. Shutemov wrote:
> > For PTE-mapped THP page_check_address_transhuge() is not adequate: it
> > cannot find all relevant PTEs, only the first one. It means we can miss
> > some references of the page and it can result in suboptimal decisions by
> > vmscan.
> > 
> > Let's switch it to page_vma_mapped_walk().
> > 
> > I don't think it's subject for stable@: it's not fatal. The only side
> > effect is that THP can be swapped out when it shouldn't.
> 
> Please be more specific about the situation when this happens and how a
> user can recognize this is going on. In other words when should I
> consider backporting this series.

The first you need huge PMD to get split with split_huge_pmd(). It can
happen due to munmap(), mprotect(), mremap(), etc. After split_huge_pmd()
we have THP mapped with bunch of PTEs instead of single PMD.

The bug is that the kernel only sees pte_young() on the PTEs that maps the
first 4k, but not the rest. So if your access pattern touches the THP, but
not the first 4k, the page can be reclaimed unfairly and possibly
re-faulted from swap soon after.

I don't think it's visible to user, except as unneeded swap-out/swap-in in
on rare occasion.

> Also the interface is quite awkward imho. Why cannot we provide a
> callback into page_vma_mapped_walk and call it for each pte/pmd that
> matters to the given page? Wouldn't that be much easier than the loop
> around page_vma_mapped_walk iterator?

I don't agree that interface with call back would be easier. You would
also need to pass down additional context with packing/unpacking it on
both ends. I don't think it makes interface less awkward.

But it's matter of taste.

-- 
 Kirill A. Shutemov

Applied "regulator: core: have _regulator_get() accept get_type argument" to the regulator tree

[Mark Brown]

The patch

   regulator: core: have _regulator_get() accept get_type argument

has been applied to the regulator tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From a8bd42a97741aefa5942605fa87418fc8a6c4169 Mon Sep 17 00:00:00 2001
From: Dmitry Torokhov 
Date: Fri, 3 Feb 2017 13:56:02 -0800
Subject: [PATCH] regulator: core: have _regulator_get() accept get_type
 argument

Instead of separate "exclusive" and "allow_dummy" arguments, that formed 3
valid combinations (normal, exclusive and optional) and an invalid one,
let's accept explicit "get_type", like we did in devm-managed code.

Signed-off-by: Dmitry Torokhov 
Signed-off-by: Mark Brown 
---
 drivers/regulator/core.c | 23 ++-
 drivers/regulator/devres.c   | 21 +
 drivers/regulator/internal.h | 10 ++
 3 files changed, 25 insertions(+), 29 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index b0ee068310c5..206c274c0003 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1580,14 +1580,19 @@ static int regulator_resolve_supply(struct 
regulator_dev *rdev)
 }
 
 /* Internal regulator request function */
-static struct regulator *_regulator_get(struct device *dev, const char *id,
-   bool exclusive, bool allow_dummy)
+struct regulator *_regulator_get(struct device *dev, const char *id,
+enum regulator_get_type get_type)
 {
struct regulator_dev *rdev;
struct regulator *regulator;
const char *devname = NULL;
int ret;
 
+   if (get_type >= MAX_GET_TYPE) {
+   dev_err(dev, "invalid type %d in %s\n", get_type, __func__);
+   return ERR_PTR(-EINVAL);
+   }
+
if (id == NULL) {
pr_err("get() with no identifier\n");
return ERR_PTR(-EINVAL);
@@ -1616,7 +1621,7 @@ static struct regulator *_regulator_get(struct device 
*dev, const char *id,
 * Assume that a regulator is physically present and enabled
 * even if it isn't hooked up and just provide a dummy.
 */
-   if (have_full_constraints() && allow_dummy) {
+   if (have_full_constraints() && get_type == NORMAL_GET) {
pr_warn("%s supply %s not found, using dummy regulator\n",
devname, id);
 
@@ -1624,7 +1629,7 @@ static struct regulator *_regulator_get(struct device 
*dev, const char *id,
get_device(>dev);
goto found;
/* Don't log an error when called from regulator_get_optional() */
-   } else if (!have_full_constraints() || exclusive) {
+   } else if (!have_full_constraints() || get_type == EXCLUSIVE_GET) {
dev_warn(dev, "dummy supplies not allowed\n");
}
 
@@ -1637,7 +1642,7 @@ static struct regulator *_regulator_get(struct device 
*dev, const char *id,
return regulator;
}
 
-   if (exclusive && rdev->open_count) {
+   if (get_type == EXCLUSIVE_GET && rdev->open_count) {
regulator = ERR_PTR(-EBUSY);
put_device(>dev);
return regulator;
@@ -1665,7 +1670,7 @@ static struct regulator *_regulator_get(struct device 
*dev, const char *id,
}
 
rdev->open_count++;
-   if (exclusive) {
+   if (get_type == EXCLUSIVE_GET) {
rdev->exclusive = 1;
 
ret = _regulator_is_enabled(rdev);
@@ -1693,7 +1698,7 @@ static struct regulator *_regulator_get(struct device 
*dev, const char *id,
  */
 struct regulator *regulator_get(struct device *dev, const char *id)
 {
-   return _regulator_get(dev, id, false, true);
+   return _regulator_get(dev, id, NORMAL_GET);
 }
 EXPORT_SYMBOL_GPL(regulator_get);
 
@@ -1720,7 +1725,7 @@ EXPORT_SYMBOL_GPL(regulator_get);
  */
 struct regulator *regulator_get_exclusive(struct device *dev, const char *id)
 {
-   return _regulator_get(dev, id, true, false);
+   return _regulator_get(dev, id, EXCLUSIVE_GET);
 }
 EXPORT_SYMBOL_GPL(regulator_get_exclusive);
 
@@ -1746,7 +1751,7 @@ 

Applied "regulator: core: simplify regulator_bulk_force_disable()" to the regulator tree

[Mark Brown]

The patch

   regulator: core: simplify regulator_bulk_force_disable()

has been applied to the regulator tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From b8c77ff6902baa6ca93ca643bfff2d565801ea30 Mon Sep 17 00:00:00 2001
From: Dmitry Torokhov 
Date: Fri, 3 Feb 2017 15:16:17 -0800
Subject: [PATCH] regulator: core: simplify regulator_bulk_force_disable()

There is no need to have two loops there, we can store error for subsequent
reporting.

Signed-off-by: Dmitry Torokhov 
Signed-off-by: Mark Brown 
---
 drivers/regulator/core.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 206c274c0003..fe05923611ee 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -3687,21 +3687,17 @@ int regulator_bulk_force_disable(int num_consumers,
   struct regulator_bulk_data *consumers)
 {
int i;
-   int ret;
+   int ret = 0;
 
-   for (i = 0; i < num_consumers; i++)
+   for (i = 0; i < num_consumers; i++) {
consumers[i].ret =
regulator_force_disable(consumers[i].consumer);
 
-   for (i = 0; i < num_consumers; i++) {
-   if (consumers[i].ret != 0) {
+   /* Store first error for reporting */
+   if (consumers[i].ret && !ret)
ret = consumers[i].ret;
-   goto out;
-   }
}
 
-   return 0;
-out:
return ret;
 }
 EXPORT_SYMBOL_GPL(regulator_bulk_force_disable);
-- 
2.11.0

Applied "regulator: core: remove dead code in _regulator_get()" to the regulator tree

[Mark Brown]

The patch

   regulator: core: remove dead code in _regulator_get()

has been applied to the regulator tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 7d245afa24b3ed911f6fd90079d70932ac5e5923 Mon Sep 17 00:00:00 2001
From: Dmitry Torokhov 
Date: Fri, 3 Feb 2017 13:56:00 -0800
Subject: [PATCH] regulator: core: remove dead code in _regulator_get()

There is no point in assigning value to 'ret' before calling
regulator_dev_lookup() as it will clobber 'ret' anyway.

Also, let's explicitly return -PROBE_DEFER when try_module_get() fails,
instead of relying that earlier initialization of "regulator" carries
correct value.

Signed-off-by: Dmitry Torokhov 
Signed-off-by: Mark Brown 
---
 drivers/regulator/core.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 04baac9a165b..b0ee068310c5 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1584,7 +1584,7 @@ static struct regulator *_regulator_get(struct device 
*dev, const char *id,
bool exclusive, bool allow_dummy)
 {
struct regulator_dev *rdev;
-   struct regulator *regulator = ERR_PTR(-EPROBE_DEFER);
+   struct regulator *regulator;
const char *devname = NULL;
int ret;
 
@@ -1596,11 +1596,6 @@ static struct regulator *_regulator_get(struct device 
*dev, const char *id,
if (dev)
devname = dev_name(dev);
 
-   if (have_full_constraints())
-   ret = -ENODEV;
-   else
-   ret = -EPROBE_DEFER;
-
rdev = regulator_dev_lookup(dev, id, );
if (rdev)
goto found;
@@ -1656,6 +1651,7 @@ static struct regulator *_regulator_get(struct device 
*dev, const char *id,
}
 
if (!try_module_get(rdev->owner)) {
+   regulator = ERR_PTR(-EPROBE_DEFER);
put_device(>dev);
return regulator;
}
-- 
2.11.0

Re: [PATCH 0/5] DRM OF graph clean-up

[Russell King - ARM Linux]

On Fri, Feb 03, 2017 at 09:36:30PM -0600, Rob Herring wrote:
> The Armada and Rockchip drivers remain oddballs with their own graph 
> parsing. I can't see how the armada driver even can work. There's 
> nothing to instantiate the armada-drm device either in DT or the kernel.

Correct, that's sitting out of tree because it requires either legacy
code in arch/arm/mach-dove at the moment, or stuff for DT.  Each time
that I looked at the DT reserved memory stuff I've ended up giving up
as it always seemed to be half complete, and the documentation was
confusing (seemingly referring to things that weren't merged.)

Maybe that's changed today, but I've not had a chance to look at it
again.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH] scripts/tags.sh: include arch/Kconfig* for tags generation

[Hou Tao]

Kconfig files under arch/ directory are ignored by all_kconfigs(),
so include them for tags generation.

Signed-off-by: Hou Tao 
---
 scripts/tags.sh | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/scripts/tags.sh b/scripts/tags.sh
index df5fa77..d661f2f 100755
--- a/scripts/tags.sh
+++ b/scripts/tags.sh
@@ -128,6 +128,8 @@ all_target_sources()
 
 all_kconfigs()
 {
+   find ${tree}arch/ -maxdepth 1 $ignore \
+  -name "Kconfig*" -not -type l -print;
for arch in $ALLSOURCE_ARCHS; do
find_sources $arch 'Kconfig*'
done
-- 
2.5.0

Applied "regulator: cpcap: Add basic regulator support" to the regulator tree

[Mark Brown]

The patch

   regulator: cpcap: Add basic regulator support

has been applied to the regulator tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 0ad4c07edd413cb64abed217355d51af3649c5a3 Mon Sep 17 00:00:00 2001
From: Tony Lindgren 
Date: Thu, 2 Feb 2017 15:43:57 -0800
Subject: [PATCH] regulator: cpcap: Add basic regulator support

Many Motorola phones like droid 4 are using a custom PMIC called CPCAP
or 6556002. This PMIC is used with several SoCs, I've noticed at least
omap3, omap4 and Tegra2 based Motorola phones and tablets using it.

Cc: devicet...@vger.kernel.org
Cc: Marcel Partap 
Cc: Michael Scott 
Cc: Rob Herring 
Signed-off-by: Tony Lindgren 
Signed-off-by: Mark Brown 
---
 .../bindings/regulator/cpcap-regulator.txt |  34 ++
 drivers/regulator/Kconfig  |   7 +
 drivers/regulator/Makefile |   1 +
 drivers/regulator/cpcap-regulator.c| 464 +
 4 files changed, 506 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
 create mode 100644 drivers/regulator/cpcap-regulator.c

diff --git a/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt 
b/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
new file mode 100644
index ..675f4437ce92
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
@@ -0,0 +1,34 @@
+Motorola CPCAP PMIC voltage regulators
+
+
+Requires node properties:
+- "compatible" value one of:
+"motorola,cpcap-regulator"
+"motorola,mapphone-cpcap-regulator"
+
+Required regulator properties:
+- "regulator-name"
+- "regulator-enable-ramp-delay"
+- "regulator-min-microvolt"
+- "regulator-max-microvolt"
+
+Optional regulator properties:
+- "regulator-boot-on"
+
+See Documentation/devicetree/bindings/regulator/regulator.txt
+for more details about the regulator properties.
+
+Example:
+
+cpcap_regulator: regulator {
+   compatible = "motorola,cpcap-regulator";
+
+   cpcap_regulators: regulators {
+   sw5: SW5 {
+   regulator-min-microvolt = <505>;
+   regulator-max-microvolt = <505>;
+   regulator-enable-ramp-delay = <5>;
+   regulator-boot-on;
+   };
+   };
+};
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 936f7ccc9736..be06eb29c681 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -163,6 +163,13 @@ config REGULATOR_BCM590XX
  BCM590xx PMUs. This will enable support for the software
  controllable LDO/Switching regulators.
 
+config REGULATOR_CPCAP
+   tristate "Motorola CPCAP regulator"
+   depends on MFD_CPCAP
+   help
+ Say y here for CPCAP regulator found on some Motorola phones
+ and tablets such as Droid 4.
+
 config REGULATOR_DA903X
tristate "Dialog Semiconductor DA9030/DA9034 regulators"
depends on PMIC_DA903X
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 14294692beb9..ef7725e2592a 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_REGULATOR_USERSPACE_CONSUMER) += 
userspace-consumer.o
 
 obj-$(CONFIG_REGULATOR_88PM800) += 88pm800.o
 obj-$(CONFIG_REGULATOR_88PM8607) += 88pm8607.o
+obj-$(CONFIG_REGULATOR_CPCAP) += cpcap-regulator.o
 obj-$(CONFIG_REGULATOR_AAT2870) += aat2870-regulator.o
 obj-$(CONFIG_REGULATOR_AB3100) += ab3100.o
 obj-$(CONFIG_REGULATOR_AB8500) += ab8500-ext.o ab8500.o
diff --git a/drivers/regulator/cpcap-regulator.c 
b/drivers/regulator/cpcap-regulator.c
new file mode 100644
index ..cc98aceed1c1
--- /dev/null
+++ b/drivers/regulator/cpcap-regulator.c
@@ -0,0 +1,464 @@
+/*
+ * Motorola CPCAP PMIC regulator driver
+ *
+ * Based on cpcap-regulator.c from Motorola Linux kernel tree
+ * Copyright (C) 2009-2011 Motorola, Inc.
+ *
+ * Rewritten for mainline kernel to use device tree and regmap
+ * Copyright 

Re: [PATCH 5/5] regulator: core: lower severity level of message about using dummy supplies

[Mark Brown]

On Fri, Feb 03, 2017 at 01:56:04PM -0800, Dmitry Torokhov wrote:
> Use of dummy supplies is normal and common occurrence in the kernel, let's
> lower severity from warning to info.

It really shouldn't be either of these things, at least on DT systems.


signature.asc
Description: PGP signature

[PATCH v5 2/3] i2c: acpi: Initialize info.type from of_compatible

[Dan O'Donovan]

When using devicetree i2c_board_info.type is set to the compatible
string with the vendor prefix removed. For I2C devices described via
ACPI the i2c_board_info.type string is set to the ACPI device name. When
using ACPI and DT ids this string ends up something like "PRP0001:00".

If the of_compatible property is present try to use that instead. This
makes it easier to instantiate i2c drivers through ACPI with DT ids.

Signed-off-by: Dan O'Donovan 
Reviewed-by: Andy Shevchenko 
Reviewed-by: Jarkko Nikula 
Tested-by: Jarkko Nikula 
Acked-by: Wolfram Sang 
---
 drivers/i2c/i2c-core.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 583e950..28d2181 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -221,7 +221,8 @@ static int i2c_acpi_get_info(struct acpi_device *adev,
 
acpi_dev_free_resource_list(_list);
 
-   strlcpy(info->type, dev_name(>dev), sizeof(info->type));
+   acpi_set_modalias(adev, dev_name(>dev),
+ info->type, sizeof(info->type));
 
return 0;
 }
-- 
2.7.4

[PATCH v5 1/3] ACPI / bus: Export acpi_of_modalias equiv of of_modalias_node

[Dan O'Donovan]

When using devicetree stuff like i2c_client.name or spi_device.modalias
is initialized to the first DT compatible id with the vendor prefix
stripped. Since some drivers rely on this try to replicate it when using
ACPI with DT ids.

Signed-off-by: Dan O'Donovan 
Reviewed-by: Mika Westerberg 
Reviewed-by: Andy Shevchenko 
Reviewed-by: Jarkko Nikula 
Tested-by: Jarkko Nikula 
---
 drivers/acpi/bus.c  | 42 ++
 include/acpi/acpi_bus.h |  2 ++
 2 files changed, 44 insertions(+)

diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 95855cb..80cb5eb 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -677,6 +677,48 @@ static bool acpi_of_match_device(struct acpi_device *adev,
return false;
 }
 
+static bool acpi_of_modalias(struct acpi_device *adev,
+char *modalias, size_t len)
+{
+   const union acpi_object *of_compatible;
+   const union acpi_object *obj;
+   const char *str, *chr;
+
+   of_compatible = adev->data.of_compatible;
+   if (!of_compatible)
+   return false;
+
+   if (of_compatible->type == ACPI_TYPE_PACKAGE)
+   obj = of_compatible->package.elements;
+   else /* Must be ACPI_TYPE_STRING. */
+   obj = of_compatible;
+
+   str = obj->string.pointer;
+   chr = strchr(str, ',');
+   strlcpy(modalias, chr ? chr + 1 : str, len);
+
+   return true;
+}
+
+/**
+ * acpi_set_modalias - Set modalias using "compatible" property or supplied ID
+ * @adev:  ACPI device object to match
+ * @default_id:ID string to use as default if no compatible string 
found
+ * @modalias:   Pointer to buffer that modalias value will be copied into
+ * @len:   Length of modalias buffer
+ *
+ * This is a counterpart of of_modalias_node() for struct acpi_device objects.
+ * If there is a compatible string for @adev, it will be copied to @modalias
+ * with the vendor prefix stripped; otherwise, @default_id will be used.
+ */
+void acpi_set_modalias(struct acpi_device *adev, const char *default_id,
+  char *modalias, size_t len)
+{
+   if (!acpi_of_modalias(adev, modalias, len))
+   strlcpy(modalias, default_id, len);
+}
+EXPORT_SYMBOL_GPL(acpi_set_modalias);
+
 static bool __acpi_match_device_cls(const struct acpi_device_id *id,
struct acpi_hardware_id *hwid)
 {
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index 4242c31..ef0ae8a 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -522,6 +522,8 @@ void acpi_bus_trim(struct acpi_device *start);
 acpi_status acpi_bus_get_ejd(acpi_handle handle, acpi_handle * ejd);
 int acpi_match_device_ids(struct acpi_device *device,
  const struct acpi_device_id *ids);
+void acpi_set_modalias(struct acpi_device *adev, const char *default_id,
+  char *modalias, size_t len);
 int acpi_create_dir(struct acpi_device *);
 void acpi_remove_dir(struct acpi_device *);
 
-- 
2.7.4

Re: status of "tty: Fix ldisc crash on reopened tty"

[Greg Kroah-Hartman]

On Sat, Feb 04, 2017 at 01:57:19PM +0900, Sergey Senozhatsky wrote:
> Cc Greg
> 
> 
> On (01/24/17 14:19), Sergey Senozhatsky wrote:
> > Hello Peter, Mikulas
> > 
> > just came across this patch https://lkml.org/lkml/2016/5/17/440
> > 
> > Peter, are you still planning to merge it? or is there something
> > that made you change your mind?
> 
> ping

worst email ever...

Please include the patch if you want it applied, especially for
something so old.

thanks,

greg k-h

Re: v4.10-rc6 boot regression on Intel desktop, does not boot after cold boots, boots after reboot

[Pavel Machek]

On Fri 2017-02-03 23:43:09, Pavel Machek wrote:
> On Fri 2017-02-03 16:59:05, Alan Stern wrote:
> > On Fri, 3 Feb 2017, Pavel Machek wrote:
> > 
> > > Hi!
> > > 
> > > > > > Hmm. I moved keyboard between USB ports, and now 4.10-rc6 no longer
> > > > > > boots. v4.6 works ok. Let me try with keyboard unplugged... no, I
> > > > > > could not get it to work. I believe v4.9 and some v4.10-rc's worked,
> > > > > > but I'll have to double check.
> > > > > 
> > > > > But all the kernel versions worked when the keyboard was plugged into
> > > > > its original USB port?
> > > > 
> > > > Aha. So it looks difference is probably in "where is keyboard plugged
> > > > in" but in "reboot" vs. "cold boot". I did not do a cold boot in quite
> > > > a while :-(.
> > > > 
> > > > Booting to grub, then hitting ctrl-alt-del is enough to make it work. 
> > > > Ouch.
> > > > 
> > > > It happens with current Linus' tree.
> > > 
> > > v4.10-rc6-feb3 : broken
> > > v4.9 : ok
> > > (v4.6 : ok)
> > 
> > All I can suggest is git bisect.  :-(  But I agree that the problem is 
> > unlikely to be in the USB layer.
> 
> Yep. I'm hoping PCI people speak up adding printks there should be
> possibility, too.
> 
> (And I guess I should remove you and usb people from the cc-list... in
> the next mails).
> 
> (I verified it happens with 32bit configuration, too, FWIW).

v4.10-rc1 seems to work.

Pavel


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

[PATCH v5 2/8] devicetree: property-units: Add uWh and uAh units

[Liam Breck]

From: Matt Ranostay 

From: Matt Ranostay 

Add entries for microwatt-hours and microamp-hours.

Cc: Rob Herring 
Cc: Mark Rutland 
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Matt Ranostay 
Signed-off-by: Liam Breck 
Acked-by: Sebastian Reichel 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/property-units.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/property-units.txt 
b/Documentation/devicetree/bindings/property-units.txt
index 12278d7..0849618 100644
--- a/Documentation/devicetree/bindings/property-units.txt
+++ b/Documentation/devicetree/bindings/property-units.txt
@@ -25,8 +25,10 @@ Distance
 Electricity
 
 -microamp  : micro amps
+-microamp-hours : micro amp-hours
 -ohms  : Ohms
 -micro-ohms: micro Ohms
+-microwatt-hours: micro Watt-hours
 -microvolt : micro volts
 
 Temperature
-- 
2.9.3

Re: regulator_get_optional() no longer returning NULL?

[Mark Brown]

On Fri, Feb 03, 2017 at 01:51:20PM -0800, Dmitry Torokhov wrote:

> Like I said, I want people to simply check for error/!error and have all
> errors be fatal, and the rest of the checks (when trying to use said
> regulator) should be in form of:

>   if (blah->supply)
>   regulator_enable(supply).

I am very dubious about this sort of pattern, it's fairly rare to get
optional supplies at all and when they're there they tend to be more
clearly described at a higher level than just checking for the
regulator.

> Or even teach regulator_enable() to like NULLs.

We definitely should not do this, we already have far too many problems
with people not writing appropriate error handling code and this just
encourages the "we got an error, set the regulator to NULL" behaviour
that seems to go along with this.  For most of the reasonable use cases
we need explicit handling for the case where the regulator isn't there
so it's not particularly optimising anything.


signature.asc
Description: PGP signature

[PATCH] virtio_mmio: remove virtio_mmio_vq_info

[Christoph Hellwig]

Signed-off-by: Christoph Hellwig 
---
 drivers/virtio/virtio_mmio.c | 52 
 1 file changed, 4 insertions(+), 48 deletions(-)

diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c
index 98adb10025fc..1367aec415bf 100644
--- a/drivers/virtio/virtio_mmio.c
+++ b/drivers/virtio/virtio_mmio.c
@@ -89,22 +89,8 @@ struct virtio_mmio_device {
 
void __iomem *base;
unsigned long version;
-
-   /* a list of queues so we can dispatch IRQs */
-   spinlock_t lock;
-   struct list_head virtqueues;
-};
-
-struct virtio_mmio_vq_info {
-   /* the actual virtqueue */
-   struct virtqueue *vq;
-
-   /* the list node for the virtqueues list */
-   struct list_head node;
 };
 
-
-
 /* Configuration interface */
 
 static u64 vm_get_features(struct virtio_device *vdev)
@@ -286,9 +272,7 @@ static bool vm_notify(struct virtqueue *vq)
 static irqreturn_t vm_interrupt(int irq, void *opaque)
 {
struct virtio_mmio_device *vm_dev = opaque;
-   struct virtio_mmio_vq_info *info;
unsigned long status;
-   unsigned long flags;
irqreturn_t ret = IRQ_NONE;
 
/* Read and acknowledge interrupts */
@@ -301,10 +285,10 @@ static irqreturn_t vm_interrupt(int irq, void *opaque)
}
 
if (likely(status & VIRTIO_MMIO_INT_VRING)) {
-   spin_lock_irqsave(_dev->lock, flags);
-   list_for_each_entry(info, _dev->virtqueues, node)
-   ret |= vring_interrupt(irq, info->vq);
-   spin_unlock_irqrestore(_dev->lock, flags);
+   struct virtqueue *vq;
+
+   list_for_each_entry(vq, _dev->vdev.vqs, list)
+   ret |= vring_interrupt(irq, vq);
}
 
return ret;
@@ -315,14 +299,8 @@ static irqreturn_t vm_interrupt(int irq, void *opaque)
 static void vm_del_vq(struct virtqueue *vq)
 {
struct virtio_mmio_device *vm_dev = to_virtio_mmio_device(vq->vdev);
-   struct virtio_mmio_vq_info *info = vq->priv;
-   unsigned long flags;
unsigned int index = vq->index;
 
-   spin_lock_irqsave(_dev->lock, flags);
-   list_del(>node);
-   spin_unlock_irqrestore(_dev->lock, flags);
-
/* Select and deactivate the queue */
writel(index, vm_dev->base + VIRTIO_MMIO_QUEUE_SEL);
if (vm_dev->version == 1) {
@@ -333,8 +311,6 @@ static void vm_del_vq(struct virtqueue *vq)
}
 
vring_del_virtqueue(vq);
-
-   kfree(info);
 }
 
 static void vm_del_vqs(struct virtio_device *vdev)
@@ -353,9 +329,7 @@ static struct virtqueue *vm_setup_vq(struct virtio_device 
*vdev, unsigned index,
  const char *name)
 {
struct virtio_mmio_device *vm_dev = to_virtio_mmio_device(vdev);
-   struct virtio_mmio_vq_info *info;
struct virtqueue *vq;
-   unsigned long flags;
unsigned int num;
int err;
 
@@ -372,13 +346,6 @@ static struct virtqueue *vm_setup_vq(struct virtio_device 
*vdev, unsigned index,
goto error_available;
}
 
-   /* Allocate and fill out our active queue description */
-   info = kmalloc(sizeof(*info), GFP_KERNEL);
-   if (!info) {
-   err = -ENOMEM;
-   goto error_kmalloc;
-   }
-
num = readl(vm_dev->base + VIRTIO_MMIO_QUEUE_NUM_MAX);
if (num == 0) {
err = -ENOENT;
@@ -420,13 +387,6 @@ static struct virtqueue *vm_setup_vq(struct virtio_device 
*vdev, unsigned index,
writel(1, vm_dev->base + VIRTIO_MMIO_QUEUE_READY);
}
 
-   vq->priv = info;
-   info->vq = vq;
-
-   spin_lock_irqsave(_dev->lock, flags);
-   list_add(>node, _dev->virtqueues);
-   spin_unlock_irqrestore(_dev->lock, flags);
-
return vq;
 
 error_new_virtqueue:
@@ -436,8 +396,6 @@ static struct virtqueue *vm_setup_vq(struct virtio_device 
*vdev, unsigned index,
writel(0, vm_dev->base + VIRTIO_MMIO_QUEUE_READY);
WARN_ON(readl(vm_dev->base + VIRTIO_MMIO_QUEUE_READY));
}
-   kfree(info);
-error_kmalloc:
 error_available:
return ERR_PTR(err);
 }
@@ -516,8 +474,6 @@ static int virtio_mmio_probe(struct platform_device *pdev)
vm_dev->vdev.dev.release = virtio_mmio_release_dev_empty;
vm_dev->vdev.config = _mmio_config_ops;
vm_dev->pdev = pdev;
-   INIT_LIST_HEAD(_dev->virtqueues);
-   spin_lock_init(_dev->lock);
 
vm_dev->base = devm_ioremap(>dev, mem->start, resource_size(mem));
if (vm_dev->base == NULL)
-- 
2.11.0

[Update][PATCH v8 15/15] irqchip: mbigen: Add ACPI support

[Hanjun Guo]

From: Hanjun Guo 

With the preparation of platform msi support and interrupt producer
in DSDT, we can add mbigen ACPI support now.

We are using Interrupt resource type in _CRS methd to indicate number
of irq pins instead of num_pins in DT to avoid _DSD usage in this case.

For mbigen,
Device(MBI0) {
  Name(_HID, "HISI0152")
  Name(_UID, Zero)
  Name(_CRS, ResourceTemplate() {
  Memory32Fixed(ReadWrite, 0xa008, 0x1)
  Interrupt(ResourceProducer,...) {12,14,}
  })
}

For devices,
   Device(COM0) {
  Name(_HID, "ACPIIDxx")
  Name(_UID, Zero)
  Name(_CRS, ResourceTemplate() {
 Memory32Fixed(ReadWrite, 0xb003, 0x1)
 Interrupt(ResourceConsumer,..., "\_SB.MBI0") {12}
  })
}

With the help of platform msi and interrupt producer, then devices
will get the virq from mbigen's irqdomain.

Signed-off-by: Hanjun Guo 
Cc: Lorenzo Pieralisi 
Cc: Ma Jun 
Cc: Marc Zyngier 
Cc: Thomas Gleixner 
---

There are some trailing white spaces in previous
version, send a updated one.

 drivers/irqchip/irq-mbigen.c | 70 ++--
 1 file changed, 67 insertions(+), 3 deletions(-)

diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
index 3756408..e6bb503 100644
--- a/drivers/irqchip/irq-mbigen.c
+++ b/drivers/irqchip/irq-mbigen.c
@@ -16,6 +16,7 @@
  * along with this program.  If not, see .
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -180,7 +181,7 @@ static int mbigen_domain_translate(struct irq_domain *d,
unsigned long *hwirq,
unsigned int *type)
 {
-   if (is_of_node(fwspec->fwnode)) {
+   if (is_of_node(fwspec->fwnode) || is_acpi_device_node(fwspec->fwnode)) {
if (fwspec->param_count != 2)
return -EINVAL;
 
@@ -271,6 +272,54 @@ static int mbigen_of_create_domain(struct platform_device 
*pdev,
return 0;
 }
 
+#ifdef CONFIG_ACPI
+static acpi_status mbigen_acpi_process_resource(struct acpi_resource *ares,
+void *context)
+{
+   struct acpi_resource_extended_irq *ext_irq;
+   u32 *num_irqs = context;
+
+   switch (ares->type) {
+   case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
+   ext_irq = >data.extended_irq;
+   *num_irqs += ext_irq->interrupt_count;
+   break;
+   default:
+   break;
+   }
+
+   return AE_OK;
+}
+
+static int mbigen_acpi_create_domain(struct platform_device *pdev,
+struct mbigen_device *mgn_chip)
+{
+   struct irq_domain *domain;
+   u32 num_msis = 0;
+   acpi_status status;
+
+   status = acpi_walk_resources(ACPI_HANDLE(>dev), METHOD_NAME__CRS,
+mbigen_acpi_process_resource, _msis);
+   if (ACPI_FAILURE(status) || num_msis == 0)
+   return -EINVAL;
+
+   domain = platform_msi_create_device_domain(>dev, num_msis,
+  mbigen_write_msg,
+  _domain_ops,
+  mgn_chip);
+   if (!domain)
+   return -ENOMEM;
+
+   return 0;
+}
+#else
+static inline int mbigen_acpi_create_domain(struct platform_device *pdev,
+   struct mbigen_device *mgn_chip)
+{
+   return -ENODEV;
+}
+#endif
+
 static int mbigen_device_probe(struct platform_device *pdev)
 {
struct mbigen_device *mgn_chip;
@@ -289,9 +338,17 @@ static int mbigen_device_probe(struct platform_device 
*pdev)
if (IS_ERR(mgn_chip->base))
return PTR_ERR(mgn_chip->base);
 
-   err = mbigen_of_create_domain(pdev, mgn_chip);
-   if (err)
+   if (IS_ENABLED(CONFIG_OF) && pdev->dev.of_node)
+   err = mbigen_of_create_domain(pdev, mgn_chip);
+   else if (ACPI_COMPANION(>dev))
+   err = mbigen_acpi_create_domain(pdev, mgn_chip);
+   else
+   err = -EINVAL;
+
+   if (err) {
+   dev_err(>dev, "Failed to create mbi-gen@%p irqdomain", 
mgn_chip->base);
return err;
+   }
 
platform_set_drvdata(pdev, mgn_chip);
return 0;
@@ -303,10 +360,17 @@ static int mbigen_device_probe(struct platform_device 
*pdev)
 };
 MODULE_DEVICE_TABLE(of, mbigen_of_match);
 
+static const struct acpi_device_id mbigen_acpi_match[] = {
+   { "HISI0152", 0 },
+   {}
+};
+MODULE_DEVICE_TABLE(acpi, mbigen_acpi_match);
+
 static struct platform_driver mbigen_platform_driver = {
.driver = {
.name   = "Hisilicon 

Re: status of "tty: Fix ldisc crash on reopened tty"

[Sergey Senozhatsky]

On (02/04/17 09:09), Greg Kroah-Hartman wrote:
> On Sat, Feb 04, 2017 at 01:57:19PM +0900, Sergey Senozhatsky wrote:
> > Cc Greg
> > 
> > 
> > On (01/24/17 14:19), Sergey Senozhatsky wrote:
> > > Hello Peter, Mikulas
> > > 
> > > just came across this patch https://lkml.org/lkml/2016/5/17/440
> > > 
> > > Peter, are you still planning to merge it? or is there something
> > > that made you change your mind?
> > 
> > ping
> 
> worst email ever...

could be. sorry about that.


> Please include the patch if you want it applied, especially for
> something so old.

well, at this point I'm trying to find out why the patch has not been
submitted. may be Peter changed his mind or found something wrong with
the patch... I don't know. I though that questions I asked in my original
email (from 01/24/17) would point that out.


nevertheless, should have written my email in more 'clear' way.
here it comes:

I hit two Oops-es several weeks ago (4.1 LTE kernel) with backtraces
that look similar to the one mentioned in the patch below. I can't
reproduce the issue and can't verify the patch, but it looks reasonable.
since I couldn't test it, I didn't include Peter's patch. I Cc-d you
because you are undoubtedly experienced in TTY layer. Greg, is there any
chance you can take a look at the patch? for you convenience the patch
"included". once again, I personally can't verify it. OTOH, Mikulas
Patocka reported that the patch fixed the issue on his side.

===8<===8<===

>From aab3dd8e4877a5ca9327450dcba5c075f9e8f4c7 Mon Sep 17 00:00:00 2001
From: Peter Hurley 
Date: Sat, 4 Feb 2017 19:12:21 +0900
Subject: [PATCH] tty: Fix ldisc crash on reopened tty

If the tty has been hungup, the ldisc instance may have been destroyed.
Continued input to the tty will be ignored as long as the ldisc instance
is not visible to the flush_to_ldisc kworker. However, when the tty
is reopened and a new ldisc instance is created, the flush_to_ldisc
kworker can obtain an ldisc reference before the new ldisc is
completely initialized. This will likely crash:

 BUG: unable to handle kernel paging request at 2260
 IP: [] n_tty_receive_buf_common+0x6d/0xb80
 PGD 2ab581067 PUD 290c11067 PMD 0
 Oops:  [#1] PREEMPT SMP
 Modules linked in: nls_iso8859_1 ip6table_filter [.]
 CPU: 2 PID: 103 Comm: kworker/u16:1 Not tainted 4.6.0-rc7+wip-xeon+debug 
#rc7+wip
 Hardware name: Dell Inc. Precision WorkStation T5400  /0RW203, BIOS A11 
04/30/2012
 Workqueue: events_unbound flush_to_ldisc
 task: 8802ad16d100 ti: 8802ad31c000 task.ti: 8802ad31c000
 RIP: 0010:[]  [] 
n_tty_receive_buf_common+0x6d/0xb80
 RSP: 0018:8802ad31fc70  EFLAGS: 00010296
 RAX:  RBX: 8802aaddd800 RCX: 0001
 RDX:  RSI: 810db48f RDI: 0246
 RBP: 8802ad31fd08 R08:  R09: 0001
 R10: 8802aadddb28 R11: 0001 R12: 8800ba6da808
 R13: 8802ad18be80 R14: 8800ba6da858 R15: 8800ba6da800
 FS:  () GS:8802b0a0() knlGS:
 CS:  0010 DS:  ES:  CR0: 80050033
 CR2: 2260 CR3: 00028ee5d000 CR4: 06e0
 Stack:
  81531219 8802aadddab8 8802aae0 8802aa78
  0001 8800ba6da858 8800ba6da860 8802ad31fd30
  81885f78 81531219  0002
 Call Trace:
  [] ? flush_to_ldisc+0x49/0xd0
  [] ? mutex_lock_nested+0x2c8/0x430
  [] ? flush_to_ldisc+0x49/0xd0
  [] n_tty_receive_buf2+0x14/0x20
  [] tty_ldisc_receive_buf+0x22/0x50
  [] flush_to_ldisc+0xbe/0xd0
  [] process_one_work+0x1ed/0x6e0
  [] ? process_one_work+0x16f/0x6e0
  [] worker_thread+0x4e/0x490
  [] ? process_one_work+0x6e0/0x6e0
  [] kthread+0xf2/0x110
  [] ? preempt_count_sub+0x4c/0x80
  [] ret_from_fork+0x22/0x50
  [] ? kthread_create_on_node+0x220/0x220
 Code: ff ff e8 27 a0 35 00 48 8d 83 78 05 00 00 c7 45 c0 00 00 00 00 48 89 45 
80 48
   8d 83 e0 05 00 00 48 89 85 78 ff ff ff 48 8b 45 b8 <48> 8b b8 60 22 00 
00 48
   8b 30 89 f8 8b 8b 88 04 00 00 29 f0 8d
 RIP  [] n_tty_receive_buf_common+0x6d/0xb80
  RSP 
 CR2: 2260

Ensure the kworker cannot obtain the ldisc reference until the new ldisc
is completely initialized.

Fixes: 892d1fa7eaae ("tty: Destroy ldisc instance on hangup")
Reported-by: Mikulas Patocka 
Signed-off-by: Peter Hurley 
---
 drivers/tty/tty_ldisc.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/tty/tty_ldisc.c b/drivers/tty/tty_ldisc.c
index 68947f6de5ad..4ee7742dced3 100644
--- a/drivers/tty/tty_ldisc.c
+++ b/drivers/tty/tty_ldisc.c
@@ -669,16 +669,17 @@ int tty_ldisc_reinit(struct tty_struct *tty, int disc)
tty_ldisc_put(tty->ldisc);
}
 
-   /* switch the line discipline */
-   tty->ldisc = ld;
tty_set_termios_ldisc(tty, disc);
-   retval = 

Re: [PATCH] mailmap: Change email to new Konsulko email

[Jonathan Cameron]

On 04/02/17 10:33, Matt Ranostay wrote:
> Signed-off-by: Matt Ranostay 
Applied to the togreg branch of iio.git.  Will probably not hit
until next cycle now though.

Thanks,

Jonathan
> ---
>  .mailmap | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/.mailmap b/.mailmap
> index 67dc22ffc9a8..e775f792d436 100644
> --- a/.mailmap
> +++ b/.mailmap
> @@ -109,6 +109,7 @@ Mauro Carvalho Chehab  
> 
>  Mauro Carvalho Chehab  
>  Matt Ranostay  Matthew Ranostay 
> 
>  Matt Ranostay  
> +Matt Ranostay  
>  Mayuresh Janorkar 
>  Michael Buesch 
>  Michel Dänzer 
> 

Re: [PATCH] Staging: iio: resolver: ad2s1210.c - style fix

[Jonathan Cameron]

On 04/02/17 01:45, Derek Robson wrote:
> Changed symbolic permissions to octal permissions.
> Found using checkpatch
> 
> Signed-off-by: Derek Robson 
Applied.  Thanks,

Jonathan
> ---
>  drivers/staging/iio/resolver/ad2s1210.c | 24 
>  1 file changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/staging/iio/resolver/ad2s1210.c 
> b/drivers/staging/iio/resolver/ad2s1210.c
> index 6b992634f009..90b57c03609c 100644
> --- a/drivers/staging/iio/resolver/ad2s1210.c
> +++ b/drivers/staging/iio/resolver/ad2s1210.c
> @@ -531,36 +531,36 @@ static int ad2s1210_read_raw(struct iio_dev *indio_dev,
>   return ret;
>  }
>  
> -static IIO_DEVICE_ATTR(fclkin, S_IRUGO | S_IWUSR,
> +static IIO_DEVICE_ATTR(fclkin, 0644,
>  ad2s1210_show_fclkin, ad2s1210_store_fclkin, 0);
> -static IIO_DEVICE_ATTR(fexcit, S_IRUGO | S_IWUSR,
> +static IIO_DEVICE_ATTR(fexcit, 0644,
>  ad2s1210_show_fexcit,ad2s1210_store_fexcit, 0);
> -static IIO_DEVICE_ATTR(control, S_IRUGO | S_IWUSR,
> +static IIO_DEVICE_ATTR(control, 0644,
>  ad2s1210_show_control, ad2s1210_store_control, 0);
> -static IIO_DEVICE_ATTR(bits, S_IRUGO | S_IWUSR,
> +static IIO_DEVICE_ATTR(bits, 0644,
>  ad2s1210_show_resolution, ad2s1210_store_resolution, 0);
> -static IIO_DEVICE_ATTR(fault, S_IRUGO | S_IWUSR,
> +static IIO_DEVICE_ATTR(fault, 0644,
>  ad2s1210_show_fault, ad2s1210_clear_fault, 0);
>  
> -static IIO_DEVICE_ATTR(los_thrd, S_IRUGO | S_IWUSR,
> +static IIO_DEVICE_ATTR(los_thrd, 0644,
>  ad2s1210_show_reg, ad2s1210_store_reg,
>  AD2S1210_REG_LOS_THRD);
> -static IIO_DEVICE_ATTR(dos_ovr_thrd, S_IRUGO | S_IWUSR,
> +static IIO_DEVICE_ATTR(dos_ovr_thrd, 0644,
>  ad2s1210_show_reg, ad2s1210_store_reg,
>  AD2S1210_REG_DOS_OVR_THRD);
> -static IIO_DEVICE_ATTR(dos_mis_thrd, S_IRUGO | S_IWUSR,
> +static IIO_DEVICE_ATTR(dos_mis_thrd, 0644,
>  ad2s1210_show_reg, ad2s1210_store_reg,
>  AD2S1210_REG_DOS_MIS_THRD);
> -static IIO_DEVICE_ATTR(dos_rst_max_thrd, S_IRUGO | S_IWUSR,
> +static IIO_DEVICE_ATTR(dos_rst_max_thrd, 0644,
>  ad2s1210_show_reg, ad2s1210_store_reg,
>  AD2S1210_REG_DOS_RST_MAX_THRD);
> -static IIO_DEVICE_ATTR(dos_rst_min_thrd, S_IRUGO | S_IWUSR,
> +static IIO_DEVICE_ATTR(dos_rst_min_thrd, 0644,
>  ad2s1210_show_reg, ad2s1210_store_reg,
>  AD2S1210_REG_DOS_RST_MIN_THRD);
> -static IIO_DEVICE_ATTR(lot_high_thrd, S_IRUGO | S_IWUSR,
> +static IIO_DEVICE_ATTR(lot_high_thrd, 0644,
>  ad2s1210_show_reg, ad2s1210_store_reg,
>  AD2S1210_REG_LOT_HIGH_THRD);
> -static IIO_DEVICE_ATTR(lot_low_thrd, S_IRUGO | S_IWUSR,
> +static IIO_DEVICE_ATTR(lot_low_thrd, 0644,
>  ad2s1210_show_reg, ad2s1210_store_reg,
>  AD2S1210_REG_LOT_LOW_THRD);
>  
> 

[PATCH net-next v5 0/4] net: dsa: Support for pdata in dsa2

[Florian Fainelli]

Hi all,

This is not exactly new, and was sent before, although back then, I did not
have an user of the pre-declared MDIO board information, but now we do. Note
that I have additional changes queued up to have b53 register platform data for
MIPS bcm47xx and bcm63xx.

Yes I know that we should have the Orion platforms eventually be converted to
Device Tree, but until that happens, I don't want any remaining users of the
old "dsa" platform device (hence the previous DTS submissions for ARM/mvebu)
and, there will be platforms out there that most likely won't never see DT
coming their way (BCM47xx is almost 100% sure, BCM63xx maybe not in a distant
future).

We would probably want the whole series to be merged via David Miller's tree
to simplify things.

Thanks!

Changes in v5:

- dropped changes to drivers/base/ because after more than a month, we cannot
  get any answer from Greg KH

Changes in v4:

- Changed device_find_class() to device_find_in_class_name()
- Added kerneldoc above device_find_in_class_name() to explain what it does
  and the calling convention regarding device reference counts
- Changed dev_to_net_device to device_to_net_device() added comments
  about what it does and the caller conventions regarding reference counts

Changes in v3:

- Tested EPROBE_DEFER from a mockup MDIO/DSA switch driver and everything
  is fine, once the driver finally probes we have access to platform data
  as expected

- added comment above dsa_port_is_valid() that port->name is mandatory
  for platform data cases

- added an extra check in dsa_parse_member() for a NULL pdata pointer

- fixed a bunch of checkpatch errors and warnings

Changes in v2:

- Rebased against latest net-next/master

- Moved dev_find_class() to device_find_class() into drivers/base/core.c

- Moved dev_to_net_device into net/core/dev.c

- Utilize dsa_chip_data directly instead of dsa_platform_data

- Augmented dsa_chip_data to be multi-CPU port ready

Changes from last submission (few months back):

- rebased against latest net-next

- do not introduce dsa2_platform_data which was overkill and was meant to
  allow us to do exaclty the same things with platform data and Device Tree
  we use the existing dsa_platform_data instead

- properly register MDIO devices when the MDIO bus is registered and associate
  platform_data with them

- add a change to the Orion platform code to demonstrate how this can be used

Thank you

Florian Fainelli (4):
  net: dsa: Rename and export dev_to_net_device()
  net: dsa: Add support for platform data
  net: phy: Allow pre-declaration of MDIO devices
  ARM: orion: Register DSA switch as a MDIO device

 arch/arm/mach-orion5x/common.c   |   2 +-
 arch/arm/mach-orion5x/common.h   |   4 +-
 arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c |   7 +-
 arch/arm/mach-orion5x/rd88f5181l-ge-setup.c  |   7 +-
 arch/arm/mach-orion5x/rd88f6183ap-ge-setup.c |   7 +-
 arch/arm/mach-orion5x/wnr854t-setup.c|   2 +-
 arch/arm/mach-orion5x/wrt350n-v2-setup.c |   7 +-
 arch/arm/plat-orion/common.c |  25 +--
 arch/arm/plat-orion/include/plat/common.h|   4 +-
 drivers/net/phy/Makefile |   3 +-
 drivers/net/phy/mdio-boardinfo.c |  86 ++
 drivers/net/phy/mdio-boardinfo.h |  19 +
 drivers/net/phy/mdio_bus.c   |   4 ++
 drivers/net/phy/mdio_device.c|  11 +++
 include/linux/mdio.h |   3 +
 include/linux/mod_devicetable.h  |   1 +
 include/linux/phy.h  |  19 +
 include/net/dsa.h|   7 ++
 net/dsa/dsa.c|   5 +-
 net/dsa/dsa2.c   | 102 ++-
 20 files changed, 268 insertions(+), 57 deletions(-)
 create mode 100644 drivers/net/phy/mdio-boardinfo.c
 create mode 100644 drivers/net/phy/mdio-boardinfo.h

-- 
2.9.3

[PATCH net-next v5 4/4] ARM: orion: Register DSA switch as a MDIO device

[Florian Fainelli]

Utilize the ability to pass board specific MDIO bus information towards a
particular MDIO device thus allowing us to provide the per-port switch layout
to the Marvell 88E6XXX switch driver.

Since we would end-up with conflicting registration paths, do not register the
"dsa" platform device anymore.

Note that the MDIO devices registered by code in net/dsa/dsa2.c does not
parse a dsa_platform_data, but directly take a dsa_chip_data (specific
to a single switch chip), so we update the different call sites to pass
this structure down to orion_ge00_switch_init().

Signed-off-by: Florian Fainelli 
---
 arch/arm/mach-orion5x/common.c   |  2 +-
 arch/arm/mach-orion5x/common.h   |  4 ++--
 arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c |  7 +--
 arch/arm/mach-orion5x/rd88f5181l-ge-setup.c  |  7 +--
 arch/arm/mach-orion5x/rd88f6183ap-ge-setup.c |  7 +--
 arch/arm/mach-orion5x/wnr854t-setup.c|  2 +-
 arch/arm/mach-orion5x/wrt350n-v2-setup.c |  7 +--
 arch/arm/plat-orion/common.c | 25 +++--
 arch/arm/plat-orion/include/plat/common.h|  4 ++--
 9 files changed, 29 insertions(+), 36 deletions(-)

diff --git a/arch/arm/mach-orion5x/common.c b/arch/arm/mach-orion5x/common.c
index 04910764c385..83a7ec4c16d0 100644
--- a/arch/arm/mach-orion5x/common.c
+++ b/arch/arm/mach-orion5x/common.c
@@ -105,7 +105,7 @@ void __init orion5x_eth_init(struct 
mv643xx_eth_platform_data *eth_data)
 /*
  * Ethernet switch
  /
-void __init orion5x_eth_switch_init(struct dsa_platform_data *d)
+void __init orion5x_eth_switch_init(struct dsa_chip_data *d)
 {
orion_ge00_switch_init(d);
 }
diff --git a/arch/arm/mach-orion5x/common.h b/arch/arm/mach-orion5x/common.h
index 8a4115bd441d..efeffc6b4ebb 100644
--- a/arch/arm/mach-orion5x/common.h
+++ b/arch/arm/mach-orion5x/common.h
@@ -3,7 +3,7 @@
 
 #include 
 
-struct dsa_platform_data;
+struct dsa_chip_data;
 struct mv643xx_eth_platform_data;
 struct mv_sata_platform_data;
 
@@ -41,7 +41,7 @@ void orion5x_setup_wins(void);
 void orion5x_ehci0_init(void);
 void orion5x_ehci1_init(void);
 void orion5x_eth_init(struct mv643xx_eth_platform_data *eth_data);
-void orion5x_eth_switch_init(struct dsa_platform_data *d);
+void orion5x_eth_switch_init(struct dsa_chip_data *d);
 void orion5x_i2c_init(void);
 void orion5x_sata_init(struct mv_sata_platform_data *sata_data);
 void orion5x_spi_init(void);
diff --git a/arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c 
b/arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c
index dccadf68ea2b..a3c1336d30c9 100644
--- a/arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c
+++ b/arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c
@@ -101,11 +101,6 @@ static struct dsa_chip_data 
rd88f5181l_fxo_switch_chip_data = {
.port_names[7]  = "lan3",
 };
 
-static struct dsa_platform_data __initdata rd88f5181l_fxo_switch_plat_data = {
-   .nr_chips   = 1,
-   .chip   = _fxo_switch_chip_data,
-};
-
 static void __init rd88f5181l_fxo_init(void)
 {
/*
@@ -120,7 +115,7 @@ static void __init rd88f5181l_fxo_init(void)
 */
orion5x_ehci0_init();
orion5x_eth_init(_fxo_eth_data);
-   orion5x_eth_switch_init(_fxo_switch_plat_data);
+   orion5x_eth_switch_init(_fxo_switch_chip_data);
orion5x_uart0_init();
 
mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
diff --git a/arch/arm/mach-orion5x/rd88f5181l-ge-setup.c 
b/arch/arm/mach-orion5x/rd88f5181l-ge-setup.c
index affe5ec825de..252efe29bd1a 100644
--- a/arch/arm/mach-orion5x/rd88f5181l-ge-setup.c
+++ b/arch/arm/mach-orion5x/rd88f5181l-ge-setup.c
@@ -102,11 +102,6 @@ static struct dsa_chip_data rd88f5181l_ge_switch_chip_data 
= {
.port_names[7]  = "lan3",
 };
 
-static struct dsa_platform_data __initdata rd88f5181l_ge_switch_plat_data = {
-   .nr_chips   = 1,
-   .chip   = _ge_switch_chip_data,
-};
-
 static struct i2c_board_info __initdata rd88f5181l_ge_i2c_rtc = {
I2C_BOARD_INFO("ds1338", 0x68),
 };
@@ -125,7 +120,7 @@ static void __init rd88f5181l_ge_init(void)
 */
orion5x_ehci0_init();
orion5x_eth_init(_ge_eth_data);
-   orion5x_eth_switch_init(_ge_switch_plat_data);
+   orion5x_eth_switch_init(_ge_switch_chip_data);
orion5x_i2c_init();
orion5x_uart0_init();
 
diff --git a/arch/arm/mach-orion5x/rd88f6183ap-ge-setup.c 
b/arch/arm/mach-orion5x/rd88f6183ap-ge-setup.c
index 67ee8571b03c..f4f1dbe1d91d 100644
--- a/arch/arm/mach-orion5x/rd88f6183ap-ge-setup.c
+++ b/arch/arm/mach-orion5x/rd88f6183ap-ge-setup.c
@@ -40,11 +40,6 @@ static struct dsa_chip_data rd88f6183ap_ge_switch_chip_data 
= {
.port_names[5]  = "cpu",
 };
 
-static struct dsa_platform_data __initdata rd88f6183ap_ge_switch_plat_data = {
-   .nr_chips  

[PATCH net-next v5 3/4] net: phy: Allow pre-declaration of MDIO devices

[Florian Fainelli]

Allow board support code to collect pre-declarations for MDIO devices by
registering them with mdiobus_register_board_info(). SPI and I2C buses
have a similar feature, we were missing this for MDIO devices, but this
is particularly useful for e.g: MDIO-connected switches which need to
provide their port layout (often board-specific) to a MDIO Ethernet
switch driver.

Signed-off-by: Florian Fainelli 
---
 drivers/net/phy/Makefile |  3 +-
 drivers/net/phy/mdio-boardinfo.c | 86 
 drivers/net/phy/mdio-boardinfo.h | 19 +
 drivers/net/phy/mdio_bus.c   |  4 ++
 drivers/net/phy/mdio_device.c| 11 +
 include/linux/mdio.h |  3 ++
 include/linux/mod_devicetable.h  |  1 +
 include/linux/phy.h  | 19 +
 8 files changed, 145 insertions(+), 1 deletion(-)
 create mode 100644 drivers/net/phy/mdio-boardinfo.c
 create mode 100644 drivers/net/phy/mdio-boardinfo.h

diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index 356859ac7c18..407b0b601ea8 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -1,6 +1,7 @@
 # Makefile for Linux PHY drivers and MDIO bus drivers
 
-libphy-y   := phy.o phy_device.o mdio_bus.o mdio_device.o
+libphy-y   := phy.o phy_device.o mdio_bus.o mdio_device.o \
+  mdio-boardinfo.o
 libphy-$(CONFIG_SWPHY) += swphy.o
 libphy-$(CONFIG_LED_TRIGGER_PHY)   += phy_led_triggers.o
 
diff --git a/drivers/net/phy/mdio-boardinfo.c b/drivers/net/phy/mdio-boardinfo.c
new file mode 100644
index ..6b988f77da08
--- /dev/null
+++ b/drivers/net/phy/mdio-boardinfo.c
@@ -0,0 +1,86 @@
+/*
+ * mdio-boardinfo - Collect pre-declarations for MDIO devices
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "mdio-boardinfo.h"
+
+static LIST_HEAD(mdio_board_list);
+static DEFINE_MUTEX(mdio_board_lock);
+
+/**
+ * mdiobus_setup_mdiodev_from_board_info - create and setup MDIO devices
+ * from pre-collected board specific MDIO information
+ * @mdiodev: MDIO device pointer
+ * Context: can sleep
+ */
+void mdiobus_setup_mdiodev_from_board_info(struct mii_bus *bus)
+{
+   struct mdio_board_entry *be;
+   struct mdio_device *mdiodev;
+   struct mdio_board_info *bi;
+   int ret;
+
+   mutex_lock(_board_lock);
+   list_for_each_entry(be, _board_list, list) {
+   bi = >board_info;
+
+   if (strcmp(bus->id, bi->bus_id))
+   continue;
+
+   mdiodev = mdio_device_create(bus, bi->mdio_addr);
+   if (IS_ERR(mdiodev))
+   continue;
+
+   strncpy(mdiodev->modalias, bi->modalias,
+   sizeof(mdiodev->modalias));
+   mdiodev->bus_match = mdio_device_bus_match;
+   mdiodev->dev.platform_data = (void *)bi->platform_data;
+
+   ret = mdio_device_register(mdiodev);
+   if (ret) {
+   mdio_device_free(mdiodev);
+   continue;
+   }
+   }
+   mutex_unlock(_board_lock);
+}
+
+/**
+ * mdio_register_board_info - register MDIO devices for a given board
+ * @info: array of devices descriptors
+ * @n: number of descriptors provided
+ * Context: can sleep
+ *
+ * The board info passed can be marked with __initdata but be pointers
+ * such as platform_data etc. are copied as-is
+ */
+int mdiobus_register_board_info(const struct mdio_board_info *info,
+   unsigned int n)
+{
+   struct mdio_board_entry *be;
+   unsigned int i;
+
+   be = kcalloc(n, sizeof(*be), GFP_KERNEL);
+   if (!be)
+   return -ENOMEM;
+
+   for (i = 0; i < n; i++, be++, info++) {
+   memcpy(>board_info, info, sizeof(*info));
+   mutex_lock(_board_lock);
+   list_add_tail(>list, _board_list);
+   mutex_unlock(_board_lock);
+   }
+
+   return 0;
+}
diff --git a/drivers/net/phy/mdio-boardinfo.h b/drivers/net/phy/mdio-boardinfo.h
new file mode 100644
index ..00f98163e90e
--- /dev/null
+++ b/drivers/net/phy/mdio-boardinfo.h
@@ -0,0 +1,19 @@
+/*
+ * mdio-boardinfo.h - board info interface internal to the mdio_bus
+ * component
+ */
+
+#ifndef __MDIO_BOARD_INFO_H
+#define __MDIO_BOARD_INFO_H
+
+#include 
+#include 
+
+struct mdio_board_entry {
+   struct list_headlist;
+   struct mdio_board_info  board_info;
+};
+
+void mdiobus_setup_mdiodev_from_board_info(struct mii_bus *bus);
+
+#endif /* __MDIO_BOARD_INFO_H */
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c

[PATCH net-next v5 0/4] net: dsa: Support for pdata in dsa2

[Florian Fainelli]

Hi all,

This is not exactly new, and was sent before, although back then, I did not
have an user of the pre-declared MDIO board information, but now we do. Note
that I have additional changes queued up to have b53 register platform data for
MIPS bcm47xx and bcm63xx.

Yes I know that we should have the Orion platforms eventually be converted to
Device Tree, but until that happens, I don't want any remaining users of the
old "dsa" platform device (hence the previous DTS submissions for ARM/mvebu)
and, there will be platforms out there that most likely won't never see DT
coming their way (BCM47xx is almost 100% sure, BCM63xx maybe not in a distant
future).

We would probably want the whole series to be merged via David Miller's tree
to simplify things.

Thanks!

Changes in v5:

- dropped changes to drivers/base/ because after more than a month, we cannot
  get any answer from Greg KH

- rebased against latest net-next/master

Changes in v4:

- Changed device_find_class() to device_find_in_class_name()
- Added kerneldoc above device_find_in_class_name() to explain what it does
  and the calling convention regarding device reference counts
- Changed dev_to_net_device to device_to_net_device() added comments
  about what it does and the caller conventions regarding reference counts

Changes in v3:

- Tested EPROBE_DEFER from a mockup MDIO/DSA switch driver and everything
  is fine, once the driver finally probes we have access to platform data
  as expected

- added comment above dsa_port_is_valid() that port->name is mandatory
  for platform data cases

- added an extra check in dsa_parse_member() for a NULL pdata pointer

- fixed a bunch of checkpatch errors and warnings

Changes in v2:

- Rebased against latest net-next/master

- Moved dev_find_class() to device_find_class() into drivers/base/core.c

- Moved dev_to_net_device into net/core/dev.c

- Utilize dsa_chip_data directly instead of dsa_platform_data

- Augmented dsa_chip_data to be multi-CPU port ready

Changes from last submission (few months back):

- rebased against latest net-next

- do not introduce dsa2_platform_data which was overkill and was meant to
  allow us to do exaclty the same things with platform data and Device Tree
  we use the existing dsa_platform_data instead

- properly register MDIO devices when the MDIO bus is registered and associate
  platform_data with them

- add a change to the Orion platform code to demonstrate how this can be used

Thank you

Florian Fainelli (4):
  net: dsa: Rename and export dev_to_net_device()
  net: dsa: Add support for platform data
  net: phy: Allow pre-declaration of MDIO devices
  ARM: orion: Register DSA switch as a MDIO device

 arch/arm/mach-orion5x/common.c   |   2 +-
 arch/arm/mach-orion5x/common.h   |   4 +-
 arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c |   7 +-
 arch/arm/mach-orion5x/rd88f5181l-ge-setup.c  |   7 +-
 arch/arm/mach-orion5x/rd88f6183ap-ge-setup.c |   7 +-
 arch/arm/mach-orion5x/wnr854t-setup.c|   2 +-
 arch/arm/mach-orion5x/wrt350n-v2-setup.c |   7 +-
 arch/arm/plat-orion/common.c |  25 +--
 arch/arm/plat-orion/include/plat/common.h|   4 +-
 drivers/net/phy/Makefile |   3 +-
 drivers/net/phy/mdio-boardinfo.c |  86 ++
 drivers/net/phy/mdio-boardinfo.h |  19 +
 drivers/net/phy/mdio_bus.c   |   4 ++
 drivers/net/phy/mdio_device.c|  11 +++
 include/linux/mdio.h |   3 +
 include/linux/mod_devicetable.h  |   1 +
 include/linux/phy.h  |  19 +
 include/net/dsa.h|   7 ++
 net/dsa/dsa.c|   5 +-
 net/dsa/dsa2.c   | 102 ++-
 20 files changed, 268 insertions(+), 57 deletions(-)
 create mode 100644 drivers/net/phy/mdio-boardinfo.c
 create mode 100644 drivers/net/phy/mdio-boardinfo.h

-- 
2.9.3

[PATCH net-next v5 2/4] net: dsa: Add support for platform data

[Florian Fainelli]

Allow drivers to use the new DSA API with platform data. Most of the
code in net/dsa/dsa2.c does not rely so much on device_nodes and can get
the same information from platform_data instead.

We purposely do not support distributed configurations with platform
data, so drivers should be providing a pointer to a 'struct
dsa_chip_data' structure if they wish to communicate per-port layout.

Multiple CPUs port could potentially be supported and dsa_chip_data is
extended to receive up to one reference to an upstream network device
per port described by a dsa_chip_data structure.

dsa_dev_to_net_device() increments the network device's reference count,
so we intentionally call dev_put() to be consistent with the DT-enabled
path, until we have a generic notifier based solution.

Signed-off-by: Florian Fainelli 
---
 include/net/dsa.h |   6 
 net/dsa/dsa2.c| 102 --
 2 files changed, 90 insertions(+), 18 deletions(-)

diff --git a/include/net/dsa.h b/include/net/dsa.h
index 4327b0b03293..4449f22c64ba 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -44,6 +44,11 @@ struct dsa_chip_data {
struct device   *host_dev;
int sw_addr;
 
+   /*
+* Reference to network devices
+*/
+   struct device   *netdev[DSA_MAX_PORTS];
+
/* set to size of eeprom if supported by the switch */
int eeprom_len;
 
@@ -166,6 +171,7 @@ struct dsa_mall_tc_entry {
 struct dsa_port {
struct dsa_switch   *ds;
unsigned intindex;
+   const char  *name;
struct net_device   *netdev;
struct device_node  *dn;
unsigned intageing_time;
diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c
index 9f8cc26be9ea..3a7631f63638 100644
--- a/net/dsa/dsa2.c
+++ b/net/dsa/dsa2.c
@@ -78,19 +78,28 @@ static void dsa_dst_del_ds(struct dsa_switch_tree *dst,
kref_put(>refcount, dsa_free_dst);
 }
 
+/* For platform data configurations, we need to have a valid name argument to
+ * differentiate a disabled port from an enabled one
+ */
 static bool dsa_port_is_valid(struct dsa_port *port)
 {
-   return !!port->dn;
+   return !!(port->dn || port->name);
 }
 
 static bool dsa_port_is_dsa(struct dsa_port *port)
 {
-   return !!of_parse_phandle(port->dn, "link", 0);
+   if (port->name && !strcmp(port->name, "dsa"))
+   return true;
+   else
+   return !!of_parse_phandle(port->dn, "link", 0);
 }
 
 static bool dsa_port_is_cpu(struct dsa_port *port)
 {
-   return !!of_parse_phandle(port->dn, "ethernet", 0);
+   if (port->name && !strcmp(port->name, "cpu"))
+   return true;
+   else
+   return !!of_parse_phandle(port->dn, "ethernet", 0);
 }
 
 static bool dsa_ds_find_port_dn(struct dsa_switch *ds,
@@ -250,10 +259,11 @@ static void dsa_cpu_port_unapply(struct dsa_port *port, 
u32 index,
 static int dsa_user_port_apply(struct dsa_port *port, u32 index,
   struct dsa_switch *ds)
 {
-   const char *name;
+   const char *name = port->name;
int err;
 
-   name = of_get_property(port->dn, "label", NULL);
+   if (port->dn)
+   name = of_get_property(port->dn, "label", NULL);
if (!name)
name = "eth%d";
 
@@ -438,11 +448,16 @@ static int dsa_cpu_parse(struct dsa_port *port, u32 index,
struct net_device *ethernet_dev;
struct device_node *ethernet;
 
-   ethernet = of_parse_phandle(port->dn, "ethernet", 0);
-   if (!ethernet)
-   return -EINVAL;
+   if (port->dn) {
+   ethernet = of_parse_phandle(port->dn, "ethernet", 0);
+   if (!ethernet)
+   return -EINVAL;
+   ethernet_dev = of_find_net_device_by_node(ethernet);
+   } else {
+   ethernet_dev = dsa_dev_to_net_device(ds->cd->netdev[index]);
+   dev_put(ethernet_dev);
+   }
 
-   ethernet_dev = of_find_net_device_by_node(ethernet);
if (!ethernet_dev)
return -EPROBE_DEFER;
 
@@ -545,6 +560,33 @@ static int dsa_parse_ports_dn(struct device_node *ports, 
struct dsa_switch *ds)
return 0;
 }
 
+static int dsa_parse_ports(struct dsa_chip_data *cd, struct dsa_switch *ds)
+{
+   bool valid_name_found = false;
+   unsigned int i;
+
+   for (i = 0; i < DSA_MAX_PORTS; i++) {
+   if (!cd->port_names[i])
+   continue;
+
+   ds->ports[i].name = cd->port_names[i];
+
+   /* Initialize enabled_port_mask now for drv->setup()
+* to have access to a correct value, just like what
+* net/dsa/dsa.c::dsa_switch_setup_one does.
+*/
+   if (!dsa_port_is_cpu(>ports[i]))
+   ds->enabled_port_mask |= 1 << i;
+
+   

[PATCH] net: intel: i40e: 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/intel/i40e/i40e_ethtool.c |  224 ++--
 1 files changed, 133 insertions(+), 91 deletions(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c 
b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
index cc1465a..011f0b8 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
@@ -387,7 +387,7 @@ static void i40e_phy_type_to_ethtool(struct i40e_pf *pf, 
u32 *supported,
  *
  **/
 static void i40e_get_settings_link_up(struct i40e_hw *hw,
- struct ethtool_cmd *ecmd,
+ struct ethtool_link_ksettings *cmd,
  struct net_device *netdev,
  struct i40e_pf *pf)
 {
@@ -395,70 +395,76 @@ static void i40e_get_settings_link_up(struct i40e_hw *hw,
u32 link_speed = hw_link_info->link_speed;
u32 e_advertising = 0x0;
u32 e_supported = 0x0;
+   u32 supported, advertising;
+
+   ethtool_convert_link_mode_to_legacy_u32(,
+   cmd->link_modes.supported);
+   ethtool_convert_link_mode_to_legacy_u32(,
+   cmd->link_modes.advertising);
 
/* Initialize supported and advertised settings based on phy settings */
switch (hw_link_info->phy_type) {
case I40E_PHY_TYPE_40GBASE_CR4:
case I40E_PHY_TYPE_40GBASE_CR4_CU:
-   ecmd->supported = SUPPORTED_Autoneg |
+   supported = SUPPORTED_Autoneg |
  SUPPORTED_4baseCR4_Full;
-   ecmd->advertising = ADVERTISED_Autoneg |
+   advertising = ADVERTISED_Autoneg |
ADVERTISED_4baseCR4_Full;
break;
case I40E_PHY_TYPE_XLAUI:
case I40E_PHY_TYPE_XLPPI:
case I40E_PHY_TYPE_40GBASE_AOC:
-   ecmd->supported = SUPPORTED_4baseCR4_Full;
+   supported = SUPPORTED_4baseCR4_Full;
break;
case I40E_PHY_TYPE_40GBASE_SR4:
-   ecmd->supported = SUPPORTED_4baseSR4_Full;
+   supported = SUPPORTED_4baseSR4_Full;
break;
case I40E_PHY_TYPE_40GBASE_LR4:
-   ecmd->supported = SUPPORTED_4baseLR4_Full;
+   supported = SUPPORTED_4baseLR4_Full;
break;
case I40E_PHY_TYPE_10GBASE_SR:
case I40E_PHY_TYPE_10GBASE_LR:
case I40E_PHY_TYPE_1000BASE_SX:
case I40E_PHY_TYPE_1000BASE_LX:
-   ecmd->supported = SUPPORTED_1baseT_Full;
+   supported = SUPPORTED_1baseT_Full;
if (hw_link_info->module_type[2] &
I40E_MODULE_TYPE_1000BASE_SX ||
hw_link_info->module_type[2] &
I40E_MODULE_TYPE_1000BASE_LX) {
-   ecmd->supported |= SUPPORTED_1000baseT_Full;
+   supported |= SUPPORTED_1000baseT_Full;
if (hw_link_info->requested_speeds &
I40E_LINK_SPEED_1GB)
-   ecmd->advertising |= ADVERTISED_1000baseT_Full;
+   advertising |= ADVERTISED_1000baseT_Full;
}
if (hw_link_info->requested_speeds & I40E_LINK_SPEED_10GB)
-   ecmd->advertising |= ADVERTISED_1baseT_Full;
+   advertising |= ADVERTISED_1baseT_Full;
break;
case I40E_PHY_TYPE_10GBASE_T:
case I40E_PHY_TYPE_1000BASE_T:
case I40E_PHY_TYPE_100BASE_TX:
-   ecmd->supported = SUPPORTED_Autoneg |
+   supported = SUPPORTED_Autoneg |
  SUPPORTED_1baseT_Full |
  SUPPORTED_1000baseT_Full |
  SUPPORTED_100baseT_Full;
-   ecmd->advertising = ADVERTISED_Autoneg;
+   advertising = ADVERTISED_Autoneg;
if (hw_link_info->requested_speeds & I40E_LINK_SPEED_10GB)
-   ecmd->advertising |= ADVERTISED_1baseT_Full;
+   advertising |= ADVERTISED_1baseT_Full;
if (hw_link_info->requested_speeds & I40E_LINK_SPEED_1GB)
-   ecmd->advertising |= ADVERTISED_1000baseT_Full;
+   advertising |= ADVERTISED_1000baseT_Full;
if (hw_link_info->requested_speeds & I40E_LINK_SPEED_100MB)
-   ecmd->advertising |= ADVERTISED_100baseT_Full;
+   advertising |= 

[PATCH net-next v5 1/4] net: dsa: Rename and export dev_to_net_device()

[Florian Fainelli]

In preparation for using this function in net/dsa/dsa2.c, rename the function
to make its scope DSA specific, and export it.

Signed-off-by: Florian Fainelli 
---
 include/net/dsa.h | 1 +
 net/dsa/dsa.c | 5 +++--
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/include/net/dsa.h b/include/net/dsa.h
index 2cb77e64d648..4327b0b03293 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -428,6 +428,7 @@ struct dsa_switch_driver {
 void register_switch_driver(struct dsa_switch_driver *type);
 void unregister_switch_driver(struct dsa_switch_driver *type);
 struct mii_bus *dsa_host_dev_to_mii_bus(struct device *dev);
+struct net_device *dsa_dev_to_net_device(struct device *dev);
 
 static inline bool dsa_uses_tagged_protocol(struct dsa_switch_tree *dst)
 {
diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c
index 619e57a44d1d..5a5f79bbda6f 100644
--- a/net/dsa/dsa.c
+++ b/net/dsa/dsa.c
@@ -486,7 +486,7 @@ struct mii_bus *dsa_host_dev_to_mii_bus(struct device *dev)
 }
 EXPORT_SYMBOL_GPL(dsa_host_dev_to_mii_bus);
 
-static struct net_device *dev_to_net_device(struct device *dev)
+struct net_device *dsa_dev_to_net_device(struct device *dev)
 {
struct device *d;
 
@@ -503,6 +503,7 @@ static struct net_device *dev_to_net_device(struct device 
*dev)
 
return NULL;
 }
+EXPORT_SYMBOL_GPL(dsa_dev_to_net_device);
 
 #ifdef CONFIG_OF
 static int dsa_of_setup_routing_table(struct dsa_platform_data *pd,
@@ -811,7 +812,7 @@ static int dsa_probe(struct platform_device *pdev)
dev = pd->of_netdev;
dev_hold(dev);
} else {
-   dev = dev_to_net_device(pd->netdev);
+   dev = dsa_dev_to_net_device(pd->netdev);
}
if (dev == NULL) {
ret = -EPROBE_DEFER;
-- 
2.9.3

Re: [lkp-robot] [scsi, block] 0dba1314d4: WARNING:at_fs/sysfs/dir.c:#sysfs_warn_dup

[James Bottomley]

On Sat, 2017-02-04 at 12:37 -0800, Dan Williams wrote:
> On Sat, Feb 4, 2017 at 12:36 PM, Dan Williams <
> dan.j.willi...@intel.com> wrote:
> > On Fri, Feb 3, 2017 at 11:09 PM, kernel test robot
> >  wrote:
> > > 
> > > FYI, we noticed the following commit:
> > > 
> > > commit: 0dba1314d4f81115dce711292ec7981d17231064 ("scsi, block:
> > > fix duplicate bdi name registration crashes")
> > > https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block
> > > .git for-4.11/next
> > > 
> > > in testcase: boot
> > > 
> > > on test machine: qemu-system-i386 -enable-kvm -cpu
> > > Haswell,+smep,+smap -m 360M
> > > 
> > > caused below changes (please refer to attached dmesg/kmsg for
> > > entire log/backtrace):
> > > 
> > > 
> > > +--++
> > > +
> > > >  | efa7c9f97e |
> > > > 0dba1314d4 |
> > > +--++
> > > +
> > > > boot_successes   | 0  | 0  
> > > > |
> > > > boot_failures| 6  | 6  
> > > > |
> > > > WARNING:at_include/linux/kref.h:#kobject_get | 6  | 6  
> > > > |
> > > > BUG:workqueue_lockup-pool| 2  |
> > > > |
> > > > WARNING:at_fs/sysfs/dir.c:#sysfs_warn_dup| 0  | 6  
> > > > |
> > > +--++
> > > +
> > > 
> > > 
> > > 
> > > [8.820258] [ cut here ]
> > > [8.821188] WARNING: CPU: 0 PID: 1 at fs/sysfs/dir.c:31
> > > sysfs_warn_dup+0x58/0x70
> > > [8.822994] sysfs: cannot create duplicate filename
> > > '/class/scsi_disk/0:0:0:0'
> > > [8.824567] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW 
> > >   4.10.0-rc5-00097-g0dba131 #1
> > > [8.826275] Hardware name: QEMU Standard PC (i440FX + PIIX,
> > > 1996), BIOS 1.9.3-20161025_171302-gandalf 04/01/2014
> > > [8.828156] Call Trace:
> > > [8.828851]  dump_stack+0x79/0xa4
> > > [8.829628]  __warn+0xd2/0xf0
> > > [8.830372]  ? sysfs_warn_dup+0x58/0x70
> > > [8.831211]  warn_slowpath_fmt+0x36/0x40
> > > [8.832054]  sysfs_warn_dup+0x58/0x70
> > > [8.832865]  sysfs_do_create_link_sd+0x9e/0xb0
> > > [8.833844]  sysfs_create_link+0x20/0x40
> > > [8.834714]  device_add+0x218/0x610
> > > [8.835511]  ? kvasprintf_const+0x49/0x60
> > > [8.836352]  ? kobject_set_name_vargs+0x62/0x80
> > > [8.837253]  sd_probe+0x31a/0x390
> > > [8.838027]  ? _raw_spin_unlock+0x1d/0x30
> > > [8.838884]  driver_probe_device+0x190/0x4a0
> > > [8.839751]  __device_attach_driver+0x6f/0x100
> > > [8.840736]  ? klist_next+0x6e/0x100
> > > [8.841538]  ? __driver_attach+0xf0/0xf0
> > > [8.842383]  bus_for_each_drv+0x47/0x80
> > > [8.843226]  __device_attach+0xa8/0x120
> > > [8.844062]  ? __driver_attach+0xf0/0xf0
> > > [8.844902]  device_initial_probe+0xd/0x10
> > > [8.845754]  bus_probe_device+0x77/0x80
> > > [8.846593]  device_add+0x320/0x610
> > > [8.847387]  scsi_sysfs_add_sdev+0x85/0x2b0
> > > [8.848246]  ? scsi_attach_vpd+0x1f9/0x210
> > > [8.849103]  scsi_probe_and_add_lun+0xd44/0xe70
> > > [8.850021]  __scsi_scan_target+0xd8/0x690
> > > [8.850918]  ? __pm_runtime_resume+0x37/0x80
> > > [8.852124]  scsi_scan_channel+0x8f/0xb0
> > > [8.852977]  scsi_scan_host_selected+0x100/0x180
> > > [8.853885]  do_scsi_scan_host+0x8a/0x90
> > > [8.854733]  scsi_scan_host+0x15a/0x1a0
> > > [8.855562]  sdebug_driver_probe+0x14f/0x3d0
> > > [8.856435]  ? _raw_spin_unlock+0x1d/0x30
> > > [8.857270]  ? devices_kset_move_last+0x71/0xc0
> > > [8.858170]  ? sysfs_create_link+0x20/0x40
> > > [8.859057]  driver_probe_device+0xd4/0x4a0
> > > [8.859924]  __device_attach_driver+0x6f/0x100
> > > [8.860814]  ? klist_next+0x6e/0x100
> > > [8.861619]  ? __driver_attach+0xf0/0xf0
> > > [8.862470]  bus_for_each_drv+0x47/0x80
> > > [8.863298]  __device_attach+0xa8/0x120
> > > [8.864131]  ? __driver_attach+0xf0/0xf0
> > > [8.864975]  device_initial_probe+0xd/0x10
> > > [8.865831]  bus_probe_device+0x77/0x80
> > > [8.866704]  device_add+0x320/0x610
> > > [8.867497]  ? pm_runtime_init+0xea/0xf0
> > > [8.868326]  device_register+0x12/0x20
> > > [8.869146]  sdebug_add_adapter+0xda/0x1e0
> > > [8.870002]  ? driver_register+0x83/0xe0
> > > [8.870847]  scsi_debug_init+0x5a0/0x6eb
> > > [8.871686]  ? kobject_uevent+0xa/0x10
> > > [8.872507]  ? driver_register+0x83/0xe0
> > > [8.873336]  ? scsi_register_driver+0xf/0x20
> > > [8.874218]  ? init_ch_module+0x9d/0x9d
> > > [8.875088]  do_one_initcall+0x7b/0x132
> > > [8.875918]  ? kernel_init_freeable+0xe7/0x188
> > > [8.876807]  kernel_init_freeable+0x10a/0x188
> > > [

Re: [lkp-robot] [scsi, block] 0dba1314d4: WARNING:at_fs/sysfs/dir.c:#sysfs_warn_dup

[Dan Williams]

On Sat, Feb 4, 2017 at 1:04 PM, James Bottomley
 wrote:
> On Sat, 2017-02-04 at 12:37 -0800, Dan Williams wrote:
>> On Sat, Feb 4, 2017 at 12:36 PM, Dan Williams <
>> dan.j.willi...@intel.com> wrote:
>> > On Fri, Feb 3, 2017 at 11:09 PM, kernel test robot
>> >  wrote:
>> > >
>> > > FYI, we noticed the following commit:
>> > >
>> > > commit: 0dba1314d4f81115dce711292ec7981d17231064 ("scsi, block:
>> > > fix duplicate bdi name registration crashes")
>> > > https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block
>> > > .git for-4.11/next
>> > >
>> > > in testcase: boot
>> > >
>> > > on test machine: qemu-system-i386 -enable-kvm -cpu
>> > > Haswell,+smep,+smap -m 360M
>> > >
>> > > caused below changes (please refer to attached dmesg/kmsg for
>> > > entire log/backtrace):
>> > >
>> > >
>> > > +--++
>> > > +
>> > > >  | efa7c9f97e |
>> > > > 0dba1314d4 |
>> > > +--++
>> > > +
>> > > > boot_successes   | 0  | 0
>> > > > |
>> > > > boot_failures| 6  | 6
>> > > > |
>> > > > WARNING:at_include/linux/kref.h:#kobject_get | 6  | 6
>> > > > |
>> > > > BUG:workqueue_lockup-pool| 2  |
>> > > > |
>> > > > WARNING:at_fs/sysfs/dir.c:#sysfs_warn_dup| 0  | 6
>> > > > |
>> > > +--++
>> > > +
>> > >
>> > >
>> > >
>> > > [8.820258] [ cut here ]
>> > > [8.821188] WARNING: CPU: 0 PID: 1 at fs/sysfs/dir.c:31
>> > > sysfs_warn_dup+0x58/0x70
>> > > [8.822994] sysfs: cannot create duplicate filename
>> > > '/class/scsi_disk/0:0:0:0'
>> > > [8.824567] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW
>> > >   4.10.0-rc5-00097-g0dba131 #1
>> > > [8.826275] Hardware name: QEMU Standard PC (i440FX + PIIX,
>> > > 1996), BIOS 1.9.3-20161025_171302-gandalf 04/01/2014
>> > > [8.828156] Call Trace:
>> > > [8.828851]  dump_stack+0x79/0xa4
>> > > [8.829628]  __warn+0xd2/0xf0
>> > > [8.830372]  ? sysfs_warn_dup+0x58/0x70
>> > > [8.831211]  warn_slowpath_fmt+0x36/0x40
>> > > [8.832054]  sysfs_warn_dup+0x58/0x70
>> > > [8.832865]  sysfs_do_create_link_sd+0x9e/0xb0
>> > > [8.833844]  sysfs_create_link+0x20/0x40
>> > > [8.834714]  device_add+0x218/0x610
>> > > [8.835511]  ? kvasprintf_const+0x49/0x60
>> > > [8.836352]  ? kobject_set_name_vargs+0x62/0x80
>> > > [8.837253]  sd_probe+0x31a/0x390
>> > > [8.838027]  ? _raw_spin_unlock+0x1d/0x30
>> > > [8.838884]  driver_probe_device+0x190/0x4a0
>> > > [8.839751]  __device_attach_driver+0x6f/0x100
>> > > [8.840736]  ? klist_next+0x6e/0x100
>> > > [8.841538]  ? __driver_attach+0xf0/0xf0
>> > > [8.842383]  bus_for_each_drv+0x47/0x80
>> > > [8.843226]  __device_attach+0xa8/0x120
>> > > [8.844062]  ? __driver_attach+0xf0/0xf0
>> > > [8.844902]  device_initial_probe+0xd/0x10
>> > > [8.845754]  bus_probe_device+0x77/0x80
>> > > [8.846593]  device_add+0x320/0x610
>> > > [8.847387]  scsi_sysfs_add_sdev+0x85/0x2b0
>> > > [8.848246]  ? scsi_attach_vpd+0x1f9/0x210
>> > > [8.849103]  scsi_probe_and_add_lun+0xd44/0xe70
>> > > [8.850021]  __scsi_scan_target+0xd8/0x690
>> > > [8.850918]  ? __pm_runtime_resume+0x37/0x80
>> > > [8.852124]  scsi_scan_channel+0x8f/0xb0
>> > > [8.852977]  scsi_scan_host_selected+0x100/0x180
>> > > [8.853885]  do_scsi_scan_host+0x8a/0x90
>> > > [8.854733]  scsi_scan_host+0x15a/0x1a0
>> > > [8.855562]  sdebug_driver_probe+0x14f/0x3d0
>> > > [8.856435]  ? _raw_spin_unlock+0x1d/0x30
>> > > [8.857270]  ? devices_kset_move_last+0x71/0xc0
>> > > [8.858170]  ? sysfs_create_link+0x20/0x40
>> > > [8.859057]  driver_probe_device+0xd4/0x4a0
>> > > [8.859924]  __device_attach_driver+0x6f/0x100
>> > > [8.860814]  ? klist_next+0x6e/0x100
>> > > [8.861619]  ? __driver_attach+0xf0/0xf0
>> > > [8.862470]  bus_for_each_drv+0x47/0x80
>> > > [8.863298]  __device_attach+0xa8/0x120
>> > > [8.864131]  ? __driver_attach+0xf0/0xf0
>> > > [8.864975]  device_initial_probe+0xd/0x10
>> > > [8.865831]  bus_probe_device+0x77/0x80
>> > > [8.866704]  device_add+0x320/0x610
>> > > [8.867497]  ? pm_runtime_init+0xea/0xf0
>> > > [8.868326]  device_register+0x12/0x20
>> > > [8.869146]  sdebug_add_adapter+0xda/0x1e0
>> > > [8.870002]  ? driver_register+0x83/0xe0
>> > > [8.870847]  scsi_debug_init+0x5a0/0x6eb
>> > > [8.871686]  ? kobject_uevent+0xa/0x10
>> > > [8.872507]  ? driver_register+0x83/0xe0
>> > > [8.873336]  ? scsi_register_driver+0xf/0x20
>> > > [8.874218]  ? 

Re: [PATCH] iio: adc: handle unknow of_device_id data

[Marek Vasut]

On 02/03/2017 06:01 PM, Arnd Bergmann wrote:
> If we get an unknown 'childmode' value, a number of variables are not
> initialized properly:
> 
> drivers/iio/adc/rcar-gyroadc.c: In function 'rcar_gyroadc_probe':
> drivers/iio/adc/rcar-gyroadc.c:390:5: error: 'num_channels' may be used 
> uninitialized in this function [-Werror=maybe-uninitialized]
> drivers/iio/adc/rcar-gyroadc.c:426:22: error: 'sample_width' may be used 
> uninitialized in this function [-Werror=maybe-uninitialized]
> drivers/iio/adc/rcar-gyroadc.c:428:23: error: 'channels' may be used 
> uninitialized in this function [-Werror=maybe-uninitialized]
> 
> The driver is currently correct, but handling this properly is more robust
> for possible modifications.

Yeah, the OF match will make sure this case is never triggered.
But then again, it triggers kernel ci, so it should be fixed.
Thanks for the patch :)

> There is also a false-positive warning about adcmode being possibly 
> uninitialized,
> but that cannot happen as we also check the 'first' flag:
> 
> drivers/iio/adc/rcar-gyroadc.c:398:26: error: 'adcmode' may be used 
> uninitialized in this function [-Werror=maybe-uninitialized]
> 
> This adds an initialization for 'adcmode' and bails out for any unknown 
> childmode.
> 
> Fixes: 059c53b32329 ("iio: adc: Add Renesas GyroADC driver")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/iio/adc/rcar-gyroadc.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/adc/rcar-gyroadc.c b/drivers/iio/adc/rcar-gyroadc.c
> index 0c44f72c32a8..331ff9a673be 100644
> --- a/drivers/iio/adc/rcar-gyroadc.c
> +++ b/drivers/iio/adc/rcar-gyroadc.c
> @@ -336,7 +336,7 @@ static int rcar_gyroadc_parse_subdevs(struct iio_dev 
> *indio_dev)
>   struct device_node *child;
>   struct regulator *vref;
>   unsigned int reg;
> - unsigned int adcmode, childmode;
> + unsigned int adcmode = -1, childmode;
>   unsigned int sample_width;
>   unsigned int num_channels;
>   int ret, first = 1;
> @@ -366,6 +366,9 @@ static int rcar_gyroadc_parse_subdevs(struct iio_dev 
> *indio_dev)
>   channels = rcar_gyroadc_iio_channels_3;
>   num_channels = ARRAY_SIZE(rcar_gyroadc_iio_channels_3);
>   break;
> + default:
> + dev_err(dev, "unknown device type");

Is this verbose output really needed ?

> + return -EINVAL;
>   }
>  
>   /*
> 


-- 
Best regards,
Marek Vasut

Re: [PATCH] mtd: pmcmsp: use kstrndup instead of kmalloc+strncpy

[Marek Vasut]

On 02/03/2017 10:49 AM, Arnd Bergmann wrote:
> kernelci.org reports a warning for this driver, as it copies a local
> variable into a 'const char *' string:
> 
> drivers/mtd/maps/pmcmsp-flash.c:149:30: warning: passing argument 1 of 
> 'strncpy' discards 'const' qualifier from pointer target type 
> [-Wdiscarded-qualifiers]
> 
> Using kstrndup() simplifies the code and avoids the warning.
> 
> Signed-off-by: Arnd Bergmann 

Acked-by: Marek Vasut 

> ---
>  drivers/mtd/maps/pmcmsp-flash.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/mtd/maps/pmcmsp-flash.c b/drivers/mtd/maps/pmcmsp-flash.c
> index f9fa3fad728e..2051f28ddac6 100644
> --- a/drivers/mtd/maps/pmcmsp-flash.c
> +++ b/drivers/mtd/maps/pmcmsp-flash.c
> @@ -139,15 +139,13 @@ static int __init init_msp_flash(void)
>   }
>  
>   msp_maps[i].bankwidth = 1;
> - msp_maps[i].name = kmalloc(7, GFP_KERNEL);
> + msp_maps[i].name = kstrndup(flash_name, 7, GFP_KERNEL);
>   if (!msp_maps[i].name) {
>   iounmap(msp_maps[i].virt);
>   kfree(msp_parts[i]);
>   goto cleanup_loop;
>   }
>  
> - msp_maps[i].name = strncpy(msp_maps[i].name, flash_name, 7);
> -
>   for (j = 0; j < pcnt; j++) {
>   part_name[5] = '0' + i;
>   part_name[7] = '0' + j;
> 


-- 
Best regards,
Marek Vasut

Re: [PATCH] Documentation: devicetree: Add PHY no lane swap binding

[Florian Fainelli]

Le 02/04/17 à 09:23, Andrew Lunn a écrit :
> On Sat, Feb 04, 2017 at 04:47:47PM +0100, Lukasz Majewski wrote:
>> Add the documentation to avoid PHY lane swapping. This is a boolean
>> entry to notify the phy device drivers that the TX/RX lanes NO need
> 
> that the TX/RX lanes should not be swapped.
> 
>> to be swapped.
>> The use case for this binding mostly happens after wrong HW
>> configuration of PHY IC during bootstrap.
>>
>> Signed-off-by: Lukasz Majewski 
>> ---
>>  Documentation/devicetree/bindings/net/phy.txt | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/net/phy.txt 
>> b/Documentation/devicetree/bindings/net/phy.txt
>> index fb5056b..5e25bc9 100644
>> --- a/Documentation/devicetree/bindings/net/phy.txt
>> +++ b/Documentation/devicetree/bindings/net/phy.txt
>> @@ -39,6 +39,10 @@ Optional Properties:
>>  - enet-phy-lane-swap: If set, indicates the PHY will swap the TX/RX lanes to
>>compensate for the board being designed with the lanes swapped.
>>  
>> +- enet-phy-lane-no-swap: If set, indicates that PHY will disable swap of the
>> +  TX/RX lanes. This binding allows the PHY to work correcly after e.g. wrong
>> +  bootstrap configuration caused by issues in PCB layout design.

s/binding/property/

>> +
> 
> We are leaving it undefined what it means if neither
> enet-phy-lane-no-swap nor enet-phy-lane-swap properties are present.
> Do we want to define this? That the swap should be left untouched by
> the driver?

Since this is a description of the hardware, absence of a properties
should mean that the driver is at freedom to either keep the hardware
defaults, or come up with its own settings that are sensible for that
particular PHY device.

What would you see clarified here?
-- 
Florian

Re: [PATCH] iio: adc: handle unknow of_device_id data

[Arnd Bergmann]

On Sat, Feb 4, 2017 at 10:11 PM, Marek Vasut  wrote:
> On 02/03/2017 06:01 PM, Arnd Bergmann wrote:
>> diff --git a/drivers/iio/adc/rcar-gyroadc.c b/drivers/iio/adc/rcar-gyroadc.c
>> index 0c44f72c32a8..331ff9a673be 100644
>> --- a/drivers/iio/adc/rcar-gyroadc.c
>> +++ b/drivers/iio/adc/rcar-gyroadc.c
>> @@ -336,7 +336,7 @@ static int rcar_gyroadc_parse_subdevs(struct iio_dev 
>> *indio_dev)
>>   struct device_node *child;
>>   struct regulator *vref;
>>   unsigned int reg;
>> - unsigned int adcmode, childmode;
>> + unsigned int adcmode = -1, childmode;
>>   unsigned int sample_width;
>>   unsigned int num_channels;
>>   int ret, first = 1;
>> @@ -366,6 +366,9 @@ static int rcar_gyroadc_parse_subdevs(struct iio_dev 
>> *indio_dev)
>>   channels = rcar_gyroadc_iio_channels_3;
>>   num_channels = ARRAY_SIZE(rcar_gyroadc_iio_channels_3);
>>   break;
>> + default:
>> + dev_err(dev, "unknown device type");
>
> Is this verbose output really needed ?

I don't care much either way, I was just trying to follow what the function does
for the other failure cases. We can probably drop it though, as this
would indicate
a bug in the driver implementation, while the others are about
incorrect DT data.

Arnd

RE: [tip:x86/cpufeature] x86/cpufeature: Enable RING3MWAIT for Knights Mill

[Luc, Piotr]

Hi Thomas,

It looks like there is a typo with the line with 'break' - it should be 
semicolon there.
Could you fix it, please?

Thx,
Piotr

> 
> Signed-off-by: Piotr Luc 
> Cc: piotr@intel.com
> Cc: dave.han...@linux.intel.com
> Link: http://lkml.kernel.org/r/1484918557-15481-6-git-send-email-
> grzegorz.andrejc...@intel.com
> Signed-off-by: Thomas Gleixner 
> 
...
> + case INTEL_FAM6_XEON_PHI_KNL:
> + case INTEL_FAM6_XEON_PHI_KNM:
> + break:
> + default:
...

Re: [PATCH] iio: adc: handle unknow of_device_id data

[Marek Vasut]

On 02/04/2017 10:44 PM, Arnd Bergmann wrote:
> On Sat, Feb 4, 2017 at 10:11 PM, Marek Vasut  wrote:
>> On 02/03/2017 06:01 PM, Arnd Bergmann wrote:
>>> diff --git a/drivers/iio/adc/rcar-gyroadc.c b/drivers/iio/adc/rcar-gyroadc.c
>>> index 0c44f72c32a8..331ff9a673be 100644
>>> --- a/drivers/iio/adc/rcar-gyroadc.c
>>> +++ b/drivers/iio/adc/rcar-gyroadc.c
>>> @@ -336,7 +336,7 @@ static int rcar_gyroadc_parse_subdevs(struct iio_dev 
>>> *indio_dev)
>>>   struct device_node *child;
>>>   struct regulator *vref;
>>>   unsigned int reg;
>>> - unsigned int adcmode, childmode;
>>> + unsigned int adcmode = -1, childmode;
>>>   unsigned int sample_width;
>>>   unsigned int num_channels;
>>>   int ret, first = 1;
>>> @@ -366,6 +366,9 @@ static int rcar_gyroadc_parse_subdevs(struct iio_dev 
>>> *indio_dev)
>>>   channels = rcar_gyroadc_iio_channels_3;
>>>   num_channels = 
>>> ARRAY_SIZE(rcar_gyroadc_iio_channels_3);
>>>   break;
>>> + default:
>>> + dev_err(dev, "unknown device type");
>>
>> Is this verbose output really needed ?
> 
> I don't care much either way, I was just trying to follow what the function 
> does
> for the other failure cases. We can probably drop it though, as this
> would indicate
> a bug in the driver implementation, while the others are about
> incorrect DT data.

I don't really want to pester you too much with minor details, let's
wait for JIC's opinion. If you're resending, please add my Ack,
otherwise consider this patch:

Acked-by: Marek Vasut 

-- 
Best regards,
Marek Vasut

Re: [PATCH] devicetree: Add video bus switch

[Pavel Machek]

Hi!

> > > > +Required properties
> > > > +===
> > > > +
> > > > +compatible : must contain "video-bus-switch"
> > > 
> > > How generic is this? Should we have e.g. nokia,video-bus-switch? And if 
> > > so,
> > > change the file name accordingly.
> > 
> > Generic for "single GPIO controls the switch", AFAICT. But that should
> > be common enough...
> 
> Um, yes. Then... how about: video-bus-switch-gpio? No Nokia prefix.

Ok, done. I also fixed the english a bit.

> > > > +reg: The interface:
> > > > + 0 - port for image signal processor
> > > > + 1 - port for first camera sensor
> > > > + 2 - port for second camera sensor
> > > 
> > > I'd say this must be pretty much specific to the one in N900. You could 
> > > have
> > > more ports. Or you could say that ports beyond 0 are camera sensors. I 
> > > guess
> > > this is good enough for now though, it can be changed later on with the
> > > source if a need arises.
> > 
> > Well, I'd say that selecting between two sensors is going to be the
> > common case. If someone needs more than two, it will no longer be
> > simple GPIO, so we'll have some fixing to do.
> 
> It could be two GPIOs --- that's how the GPIO I2C mux works.
> 
> But I'd be surprised if someone ever uses something like that
> again. ;-)

I'd say.. lets handle that when we see hardware like that.

> > > Btw. was it still considered a problem that the endpoint properties for 
> > > the
> > > sensors can be different? With the g_routing() pad op which is to be 
> > > added,
> > > the ISP driver (should actually go to a framework somewhere) could parse 
> > > the
> > > graph and find the proper endpoint there.
> > 
> > I don't know about g_routing. I added g_endpoint_config method that
> > passes the configuration, and that seems to work for me.
> > 
> > I don't see g_routing in next-20170201 . Is there place to look?
> 
> I think there was a patch by Laurent to LMML quite some time ago. I suppose
> that set will be repicked soonish.
> 
> I don't really object using g_endpoint_config() as a temporary solution; I'd
> like to have Laurent's opinion on that though. Another option is to wait,
> but we've already waited a looong time (as in total).

Laurent, do you have some input here? We have simple "2 cameras
connected to one signal processor" situation here. We need some way of
passing endpoint configuration from the sensors through the switch. I
did this:

> > @@ -415,6 +416,8 @@ struct v4l2_subdev_video_ops {
> >  const struct v4l2_mbus_config *cfg);
> > int (*s_rx_buffer)(struct v4l2_subdev *sd, void *buf,
> >unsigned int *size);
> > +   int (*g_endpoint_config)(struct v4l2_subdev *sd,
> > +   struct v4l2_of_endpoint *cfg);

Google of g_routing tells me:

9) Highly reconfigurable hardware - Julien Beraud

- 44 sub-devices connected with an interconnect.
- As long as formats match, any sub-device could be connected to any
- other sub-device through a link.
- The result is 44 * 44 links at worst.
- A switch sub-device proposed as the solution to model the
- interconnect. The sub-devices are connected to the switch
- sub-devices through the hardware links that connect to the
- interconnect.
- The switch would be controlled through new IOCTLs S_ROUTING and
- G_ROUTING.
- Patches available:
 http://git.linuxtv.org/cgit.cgi/pinchartl/media.git/log/?h=xilinx-wip

but the patches are from 2005. So I guess I'll need some guidance here...

> I'll reply to the other patch containing the code.

Ok, thanks.
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH 1/5] of: introduce of_graph_get_remote_node

[Vladimir Zapolskiy]

Hi Rob,

On 02/04/2017 05:36 AM, Rob Herring wrote:
> The OF graph API leaves too much of the graph walking to clients when
> in many cases the driver doesn't care about accessing the port or
> endpoint nodes. The drivers typically just want the device connected via
> a particular graph connection. of_graph_get_remote_node provides this
> functionality.
> 
> Signed-off-by: Rob Herring 
> ---
>  drivers/of/base.c| 28 
>  include/linux/of_graph.h |  8 
>  2 files changed, 36 insertions(+)
> 
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index d4bea3c797d6..ea18ab16b92c 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -2469,3 +2469,31 @@ struct device_node *of_graph_get_remote_port(const 
> struct device_node *node)
>   return of_get_next_parent(np);
>  }
>  EXPORT_SYMBOL(of_graph_get_remote_port);
> +
> +struct device_node *of_graph_get_remote_node(const struct device_node *node,
> +  int port, int endpoint)

it would be nice to add a short comment that a returned device
node is expected to be dereferenced with of_node_put().

> +{
> + struct device_node *endpoint_node, *remote;
> +
> + endpoint_node = of_graph_get_endpoint_by_regs(node, port, endpoint);
> + if (!endpoint_node) {
> + pr_debug("no valid endpoint (%d, %d) for node %s\n",
> +  port, endpoint, node->full_name);
> + return NULL;
> + }
> +
> + remote = of_graph_get_remote_port_parent(endpoint_node);
> + of_node_put(endpoint);

Typo, here it should be of_node_put(endpoint_node);

> + if (!remote) {
> + pr_debug("no valid remote node\n");
> + return NULL;
> + }
> +
> + if (!of_device_is_available(remote)) {
> + pr_debug("not available for remote node\n");
> + return NULL;
> + }
> +
> + return remote;
> +}
> +EXPORT_SYMBOL(of_graph_get_remote_node);

--
With best wishes,
Vladimir

[tip:timers/core] tick/broadcast: Reduce lock cacheline contention

[tip-bot for Waiman Long]

Commit-ID:  668802c25729a8e3423015c33c05f1c3be3858e9
Gitweb: http://git.kernel.org/tip/668802c25729a8e3423015c33c05f1c3be3858e9
Author: Waiman Long 
AuthorDate: Mon, 30 Jan 2017 12:57:43 -0500
Committer:  Thomas Gleixner 
CommitDate: Sat, 4 Feb 2017 08:54:46 +0100

tick/broadcast: Reduce lock cacheline contention

It was observed that on an Intel x86 system without the ARAT (Always
running APIC timer) feature and with fairly large number of CPUs as
well as CPUs coming in and out of intel_idle frequently, the lock
contention on the tick_broadcast_lock can become significant.

To reduce contention, the lock is put into its own cacheline and all
the cpumask_var_t variables are put into the __read_mostly section.

Running the SP benchmark of the NAS Parallel Benchmarks on a 4-socket
16-core 32-thread Nehalam system, the performance number improved
from 3353.94 Mop/s to 3469.31 Mop/s when this patch was applied on
a 4.9.6 kernel.  This is a 3.4% improvement.

Signed-off-by: Waiman Long 
Cc: "Peter Zijlstra (Intel)" 
Cc: Andrew Morton 
Link: 
http://lkml.kernel.org/r/1485799063-20857-1-git-send-email-long...@redhat.com
Signed-off-by: Thomas Gleixner 

---
 include/linux/cpumask.h  |  7 ++-
 kernel/time/tick-broadcast.c | 15 ---
 2 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
index c717f5e..23c1a6d 100644
--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@ -649,11 +649,15 @@ static inline size_t cpumask_size(void)
  * used. Please use this_cpu_cpumask_var_t in those cases. The direct use
  * of this_cpu_ptr() or this_cpu_read() will lead to failures when the
  * other type of cpumask_var_t implementation is configured.
+ *
+ * Please also note that __cpumask_var_read_mostly can be used to declare
+ * a cpumask_var_t variable itself (not its content) as read mostly.
  */
 #ifdef CONFIG_CPUMASK_OFFSTACK
 typedef struct cpumask *cpumask_var_t;
 
-#define this_cpu_cpumask_var_ptr(x) this_cpu_read(x)
+#define this_cpu_cpumask_var_ptr(x)this_cpu_read(x)
+#define __cpumask_var_read_mostly  __read_mostly
 
 bool alloc_cpumask_var_node(cpumask_var_t *mask, gfp_t flags, int node);
 bool alloc_cpumask_var(cpumask_var_t *mask, gfp_t flags);
@@ -667,6 +671,7 @@ void free_bootmem_cpumask_var(cpumask_var_t mask);
 typedef struct cpumask cpumask_var_t[1];
 
 #define this_cpu_cpumask_var_ptr(x) this_cpu_ptr(x)
+#define __cpumask_var_read_mostly
 
 static inline bool alloc_cpumask_var(cpumask_var_t *mask, gfp_t flags)
 {
diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c
index 3109204..244c935 100644
--- a/kernel/time/tick-broadcast.c
+++ b/kernel/time/tick-broadcast.c
@@ -29,12 +29,13 @@
  */
 
 static struct tick_device tick_broadcast_device;
-static cpumask_var_t tick_broadcast_mask;
-static cpumask_var_t tick_broadcast_on;
-static cpumask_var_t tmpmask;
-static DEFINE_RAW_SPINLOCK(tick_broadcast_lock);
+static cpumask_var_t tick_broadcast_mask __cpumask_var_read_mostly;
+static cpumask_var_t tick_broadcast_on __cpumask_var_read_mostly;
+static cpumask_var_t tmpmask __cpumask_var_read_mostly;
 static int tick_broadcast_forced;
 
+static __cacheline_aligned_in_smp DEFINE_RAW_SPINLOCK(tick_broadcast_lock);
+
 #ifdef CONFIG_TICK_ONESHOT
 static void tick_broadcast_clear_oneshot(int cpu);
 static void tick_resume_broadcast_oneshot(struct clock_event_device *bc);
@@ -517,9 +518,9 @@ void tick_resume_broadcast(void)
 
 #ifdef CONFIG_TICK_ONESHOT
 
-static cpumask_var_t tick_broadcast_oneshot_mask;
-static cpumask_var_t tick_broadcast_pending_mask;
-static cpumask_var_t tick_broadcast_force_mask;
+static cpumask_var_t tick_broadcast_oneshot_mask __cpumask_var_read_mostly;
+static cpumask_var_t tick_broadcast_pending_mask __cpumask_var_read_mostly;
+static cpumask_var_t tick_broadcast_force_mask __cpumask_var_read_mostly;
 
 /*
  * Exposed for debugging: see timer_list.c

[tip:core/debugobjects] debugobjects: Scale thresholds with # of CPUs

[tip-bot for Waiman Long]

Commit-ID:  97dd552eb23c83dbf626a6e84666c7e281375d47
Gitweb: http://git.kernel.org/tip/97dd552eb23c83dbf626a6e84666c7e281375d47
Author: Waiman Long 
AuthorDate: Thu, 5 Jan 2017 15:17:04 -0500
Committer:  Thomas Gleixner 
CommitDate: Sat, 4 Feb 2017 09:01:55 +0100

debugobjects: Scale thresholds with # of CPUs

On a large SMP systems with hundreds of CPUs, the current thresholds
for allocating and freeing debug objects (256 and 1024 respectively)
may not work well. This can cause a lot of needless calls to
kmem_aloc() and kmem_free() on those systems.

To alleviate this thrashing problem, the object freeing threshold
is now increased to "1024 + # of CPUs * 32". Whereas the object
allocation threshold is increased to "256 + # of CPUs * 4". That
should make the debug objects subsystem scale better with the number
of CPUs available in the system.

Signed-off-by: Waiman Long 
Cc: Christian Borntraeger 
Cc: "Du Changbin" 
Cc: Andrew Morton 
Cc: Jan Stancek 
Link: 
http://lkml.kernel.org/r/1483647425-4135-3-git-send-email-long...@redhat.com
Signed-off-by: Thomas Gleixner 

---
 lib/debugobjects.c | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/lib/debugobjects.c b/lib/debugobjects.c
index d78673e..dc78217 100644
--- a/lib/debugobjects.c
+++ b/lib/debugobjects.c
@@ -52,7 +52,10 @@ static int   debug_objects_fixups 
__read_mostly;
 static int debug_objects_warnings __read_mostly;
 static int debug_objects_enabled __read_mostly
= CONFIG_DEBUG_OBJECTS_ENABLE_DEFAULT;
-
+static int debug_objects_pool_size __read_mostly
+   = ODEBUG_POOL_SIZE;
+static int debug_objects_pool_min_level __read_mostly
+   = ODEBUG_POOL_MIN_LEVEL;
 static struct debug_obj_descr  *descr_test  __read_mostly;
 
 /*
@@ -94,13 +97,13 @@ static void fill_pool(void)
struct debug_obj *new;
unsigned long flags;
 
-   if (likely(obj_pool_free >= ODEBUG_POOL_MIN_LEVEL))
+   if (likely(obj_pool_free >= debug_objects_pool_min_level))
return;
 
if (unlikely(!obj_cache))
return;
 
-   while (obj_pool_free < ODEBUG_POOL_MIN_LEVEL) {
+   while (obj_pool_free < debug_objects_pool_min_level) {
 
new = kmem_cache_zalloc(obj_cache, gfp);
if (!new)
@@ -176,7 +179,7 @@ static void free_obj_work(struct work_struct *work)
unsigned long flags;
 
raw_spin_lock_irqsave(_lock, flags);
-   while (obj_pool_free > ODEBUG_POOL_SIZE) {
+   while (obj_pool_free > debug_objects_pool_size) {
obj = hlist_entry(obj_pool.first, typeof(*obj), node);
hlist_del(>node);
obj_pool_free--;
@@ -206,7 +209,7 @@ static void free_object(struct debug_obj *obj)
 * schedule work when the pool is filled and the cache is
 * initialized:
 */
-   if (obj_pool_free > ODEBUG_POOL_SIZE && obj_cache)
+   if (obj_pool_free > debug_objects_pool_size && obj_cache)
sched = 1;
hlist_add_head(>node, _pool);
obj_pool_free++;
@@ -1126,4 +1129,11 @@ void __init debug_objects_mem_init(void)
pr_warn("out of memory.\n");
} else
debug_objects_selftest();
+
+   /*
+* Increase the thresholds for allocating and freeing objects
+* according to the number of possible CPUs available in the system.
+*/
+   debug_objects_pool_size += num_possible_cpus() * 32;
+   debug_objects_pool_min_level += num_possible_cpus() * 4;
 }

[tip:core/debugobjects] debugobjects: Track number of kmem_cache_alloc/kmem_cache_free done

[tip-bot for Waiman Long]

Commit-ID:  c4b73aabd0989d93b82894417ae501690bd1db5e
Gitweb: http://git.kernel.org/tip/c4b73aabd0989d93b82894417ae501690bd1db5e
Author: Waiman Long 
AuthorDate: Thu, 5 Jan 2017 15:17:03 -0500
Committer:  Thomas Gleixner 
CommitDate: Sat, 4 Feb 2017 09:01:54 +0100

debugobjects: Track number of kmem_cache_alloc/kmem_cache_free done

New debugfs stat counters are added to track the numbers of
kmem_cache_alloc() and kmem_cache_free() function calls to get a
sense of how the internal debug objects cache management is performing.

Signed-off-by: Waiman Long 
Cc: Christian Borntraeger 
Cc: "Du Changbin" 
Cc: Andrew Morton 
Cc: Jan Stancek 
Link: 
http://lkml.kernel.org/r/1483647425-4135-2-git-send-email-long...@redhat.com
Signed-off-by: Thomas Gleixner 

---
 lib/debugobjects.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/lib/debugobjects.c b/lib/debugobjects.c
index 04c1ef7..d78673e 100644
--- a/lib/debugobjects.c
+++ b/lib/debugobjects.c
@@ -55,6 +55,12 @@ static int   debug_objects_enabled 
__read_mostly
 
 static struct debug_obj_descr  *descr_test  __read_mostly;
 
+/*
+ * Track numbers of kmem_cache_alloc and kmem_cache_free done.
+ */
+static int debug_objects_alloc;
+static int debug_objects_freed;
+
 static void free_obj_work(struct work_struct *work);
 static DECLARE_WORK(debug_obj_work, free_obj_work);
 
@@ -102,6 +108,7 @@ static void fill_pool(void)
 
raw_spin_lock_irqsave(_lock, flags);
hlist_add_head(>node, _pool);
+   debug_objects_alloc++;
obj_pool_free++;
raw_spin_unlock_irqrestore(_lock, flags);
}
@@ -173,6 +180,7 @@ static void free_obj_work(struct work_struct *work)
obj = hlist_entry(obj_pool.first, typeof(*obj), node);
hlist_del(>node);
obj_pool_free--;
+   debug_objects_freed++;
/*
 * We release pool_lock across kmem_cache_free() to
 * avoid contention on pool_lock.
@@ -758,6 +766,8 @@ static int debug_stats_show(struct seq_file *m, void *v)
seq_printf(m, "pool_min_free :%d\n", obj_pool_min_free);
seq_printf(m, "pool_used :%d\n", obj_pool_used);
seq_printf(m, "pool_max_used :%d\n", obj_pool_max_used);
+   seq_printf(m, "objects_alloc :%d\n", debug_objects_alloc);
+   seq_printf(m, "objects_freed :%d\n", debug_objects_freed);
return 0;
 }
 

Re: [PATCH] KVM: x86: do not save guest-unsupported XSAVE state

[Radim Krčmář]

2017-02-01 16:13-0800, Paolo Bonzini:
> On 01/02/2017 05:19, Radim Krčmář wrote:
>> Saving unsupported state prevents migration when the new host does not
>> support a XSAVE feature of the original host, even if the feature is not
>> exposed to the guest.
>> 
>> We've masked host features with guest-visible features before, with
>> 4344ee981e21 ("KVM: x86: only copy XSAVE state for the supported
>> features") and dropped it when implementing XSAVES.  Do it again.
>> 
>> Fixes: df1daba7d1cb ("KVM: x86: support XSAVES usage in the host")
>> Signed-off-by: Radim Krčmář 
> 
> Cc: sta...@vger.kernel.org
> Reviewed-by: Paolo Bonzini 
> 
> Please apply to kvm/master and send it yourself to Linus since I don't
> have access to my machine this week.

Done, thanks.

[GIT pull] irq fixes for 4.10

[Thomas Gleixner]

Linus,

please pull the latest irq-urgent-for-linus git tree from:

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

This update contains:

  - Prevent double activation of interrupt lines, which causes problems on
certain interrupt controllers

  - Handle the fallout of the above because x86 (ab)uses the activation
function to reconfigure interrupts under the hood. 

Thanks,

tglx

-->
Marc Zyngier (1):
  irqdomain: Avoid activating interrupts more than once

Thomas Gleixner (1):
  x86/irq: Make irq activate operations symmetric


 arch/x86/kernel/apic/io_apic.c |  2 ++
 arch/x86/kernel/hpet.c |  1 +
 include/linux/irq.h| 17 
 kernel/irq/irqdomain.c | 44 --
 4 files changed, 50 insertions(+), 14 deletions(-)

diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 1e35dd06b090..52f352b063fd 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -2117,6 +2117,7 @@ static inline void __init check_timer(void)
if (idx != -1 && irq_trigger(idx))
unmask_ioapic_irq(irq_get_chip_data(0));
}
+   irq_domain_deactivate_irq(irq_data);
irq_domain_activate_irq(irq_data);
if (timer_irq_works()) {
if (disable_timer_pin_1 > 0)
@@ -2138,6 +2139,7 @@ static inline void __init check_timer(void)
 * legacy devices should be connected to IO APIC #0
 */
replace_pin_at_irq_node(data, node, apic1, pin1, apic2, pin2);
+   irq_domain_deactivate_irq(irq_data);
irq_domain_activate_irq(irq_data);
legacy_pic->unmask(0);
if (timer_irq_works()) {
diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
index 85e87b46c318..dc6ba5bda9fc 100644
--- a/arch/x86/kernel/hpet.c
+++ b/arch/x86/kernel/hpet.c
@@ -352,6 +352,7 @@ static int hpet_resume(struct clock_event_device *evt, int 
timer)
} else {
struct hpet_dev *hdev = EVT_TO_HPET_DEV(evt);
 
+   irq_domain_deactivate_irq(irq_get_irq_data(hdev->irq));
irq_domain_activate_irq(irq_get_irq_data(hdev->irq));
disable_irq(hdev->irq);
irq_set_affinity(hdev->irq, cpumask_of(hdev->cpu));
diff --git a/include/linux/irq.h b/include/linux/irq.h
index e79875574b39..39e3254e5769 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -184,6 +184,7 @@ struct irq_data {
  *
  * IRQD_TRIGGER_MASK   - Mask for the trigger type bits
  * IRQD_SETAFFINITY_PENDING- Affinity setting is pending
+ * IRQD_ACTIVATED  - Interrupt has already been activated
  * IRQD_NO_BALANCING   - Balancing disabled for this IRQ
  * IRQD_PER_CPU- Interrupt is per cpu
  * IRQD_AFFINITY_SET   - Interrupt affinity was set
@@ -202,6 +203,7 @@ struct irq_data {
 enum {
IRQD_TRIGGER_MASK   = 0xf,
IRQD_SETAFFINITY_PENDING= (1 <<  8),
+   IRQD_ACTIVATED  = (1 <<  9),
IRQD_NO_BALANCING   = (1 << 10),
IRQD_PER_CPU= (1 << 11),
IRQD_AFFINITY_SET   = (1 << 12),
@@ -312,6 +314,21 @@ static inline bool irqd_affinity_is_managed(struct 
irq_data *d)
return __irqd_to_state(d) & IRQD_AFFINITY_MANAGED;
 }
 
+static inline bool irqd_is_activated(struct irq_data *d)
+{
+   return __irqd_to_state(d) & IRQD_ACTIVATED;
+}
+
+static inline void irqd_set_activated(struct irq_data *d)
+{
+   __irqd_to_state(d) |= IRQD_ACTIVATED;
+}
+
+static inline void irqd_clr_activated(struct irq_data *d)
+{
+   __irqd_to_state(d) &= ~IRQD_ACTIVATED;
+}
+
 #undef __irqd_to_state
 
 static inline irq_hw_number_t irqd_to_hwirq(struct irq_data *d)
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 8c0a0ae43521..b59e6768c5e9 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -1346,6 +1346,30 @@ void irq_domain_free_irqs_parent(struct irq_domain 
*domain,
 }
 EXPORT_SYMBOL_GPL(irq_domain_free_irqs_parent);
 
+static void __irq_domain_activate_irq(struct irq_data *irq_data)
+{
+   if (irq_data && irq_data->domain) {
+   struct irq_domain *domain = irq_data->domain;
+
+   if (irq_data->parent_data)
+   __irq_domain_activate_irq(irq_data->parent_data);
+   if (domain->ops->activate)
+   domain->ops->activate(domain, irq_data);
+   }
+}
+
+static void __irq_domain_deactivate_irq(struct irq_data *irq_data)
+{
+   if (irq_data && irq_data->domain) {
+   struct irq_domain *domain = irq_data->domain;
+
+   if (domain->ops->deactivate)
+   domain->ops->deactivate(domain, 

[tip:x86/cpufeature] x86/msr: Add MSR_MISC_FEATURE_ENABLES and RING3MWAIT bit

[tip-bot for Grzegorz Andrejczuk]

Commit-ID:  ae47eda905e61ef6ba0b6f79b967c9de15ca4f8e
Gitweb: http://git.kernel.org/tip/ae47eda905e61ef6ba0b6f79b967c9de15ca4f8e
Author: Grzegorz Andrejczuk 
AuthorDate: Fri, 20 Jan 2017 14:22:33 +0100
Committer:  Thomas Gleixner 
CommitDate: Sat, 4 Feb 2017 08:51:09 +0100

x86/msr: Add MSR_MISC_FEATURE_ENABLES and RING3MWAIT bit

Define new MSR MISC_FEATURE_ENABLES (0x140).

On supported CPUs if bit 1 of this MSR is set, then calling MONITOR and
MWAIT instructions outside of ring 0 will not cause invalid-opcode
exception.

The MSR MISC_FEATURE_ENABLES is not yet documented in the SDM. Here is the
relevant documentation:

Hex   Dec  Name Scope
140H  320  MISC_FEATURE_ENABLES Thread
   0Reserved
   1If set to 1, the MONITOR and MWAIT instructions do not
cause invalid-opcode exceptions when executed with CPL > 0
or in virtual-8086 mode. If MWAIT is executed when CPL > 0
or in virtual-8086 mode, and if EAX indicates a C-state
other than C0 or C1, the instruction operates as if EAX
indicated the C-state C1.
   63:2 Reserved

Signed-off-by: Grzegorz Andrejczuk 
Cc: piotr@intel.com
Cc: dave.han...@linux.intel.com
Link: 
http://lkml.kernel.org/r/1484918557-15481-2-git-send-email-grzegorz.andrejc...@intel.com
Signed-off-by: Thomas Gleixner 

---
 arch/x86/include/asm/msr-index.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 710273c..00293a9 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -543,6 +543,11 @@
 #define MSR_IA32_MISC_ENABLE_IP_PREF_DISABLE_BIT   39
 #define MSR_IA32_MISC_ENABLE_IP_PREF_DISABLE   (1ULL << 
MSR_IA32_MISC_ENABLE_IP_PREF_DISABLE_BIT)
 
+/* MISC_FEATURE_ENABLES non-architectural features */
+#define MSR_MISC_FEATURE_ENABLES   0x0140
+
+#define MSR_MISC_FEATURE_ENABLES_RING3MWAIT_BIT1
+
 #define MSR_IA32_TSC_DEADLINE  0x06E0
 
 /* P4/Xeon+ specific */

[tip:x86/cpufeature] x86/elf: Add HWCAP2 to expose ring 3 MONITOR/MWAIT

[tip-bot for Grzegorz Andrejczuk]

Commit-ID:  0274f9551eff55dbd63b5f5f3efe30fe5d4c801c
Gitweb: http://git.kernel.org/tip/0274f9551eff55dbd63b5f5f3efe30fe5d4c801c
Author: Grzegorz Andrejczuk 
AuthorDate: Fri, 20 Jan 2017 14:22:34 +0100
Committer:  Thomas Gleixner 
CommitDate: Sat, 4 Feb 2017 08:51:09 +0100

x86/elf: Add HWCAP2 to expose ring 3 MONITOR/MWAIT

Introduce ELF_HWCAP2 variable for x86 and reserve its bit 0 to expose the
ring 3 MONITOR/MWAIT.

HWCAP variables contain bitmasks which can be used by userspace
applications to detect which instruction sets are supported by CPU.  On x86
architecture information about CPU capabilities can be checked via CPUID
instructions, unfortunately presence of ring 3 MONITOR/MWAIT feature cannot
be checked this way. ELF_HWCAP cannot be used as well, because on x86 it is
set to CPUID[1].EDX which means that all bits are reserved there.

HWCAP2 approach was chosen because it reuses existing solution present
in other architectures, so only minor modifications are required to the
kernel and userspace applications. When ELF_HWCAP2 is defined
kernel maps it to AT_HWCAP2 during the start of the application.
This way the ring 3 MONITOR/MWAIT feature can be detected using getauxval()
API in a simple and fast manner. ELF_HWCAP2 type is u32 to be consistent
with x86 ELF_HWCAP type.

Signed-off-by: Grzegorz Andrejczuk 
Cc: piotr@intel.com
Cc: dave.han...@linux.intel.com
Link: 
http://lkml.kernel.org/r/1484918557-15481-3-git-send-email-grzegorz.andrejc...@intel.com
Signed-off-by: Thomas Gleixner 

---
 arch/x86/include/asm/elf.h | 9 +
 arch/x86/include/uapi/asm/hwcap2.h | 7 +++
 arch/x86/kernel/cpu/common.c   | 3 +++
 3 files changed, 19 insertions(+)

diff --git a/arch/x86/include/asm/elf.h b/arch/x86/include/asm/elf.h
index e7f155c..9d49c18 100644
--- a/arch/x86/include/asm/elf.h
+++ b/arch/x86/include/asm/elf.h
@@ -258,6 +258,15 @@ extern int force_personality32;
 
 #define ELF_HWCAP  (boot_cpu_data.x86_capability[CPUID_1_EDX])
 
+extern u32 elf_hwcap2;
+
+/*
+ * HWCAP2 supplies mask with kernel enabled CPU features, so that
+ * the application can discover that it can safely use them.
+ * The bits are defined in uapi/asm/hwcap2.h.
+ */
+#define ELF_HWCAP2 (elf_hwcap2)
+
 /* This yields a string that ld.so will use to load implementation
specific libraries for optimization.  This is more specific in
intent than poking at uname or /proc/cpuinfo.
diff --git a/arch/x86/include/uapi/asm/hwcap2.h 
b/arch/x86/include/uapi/asm/hwcap2.h
new file mode 100644
index 000..0bd2be5
--- /dev/null
+++ b/arch/x86/include/uapi/asm/hwcap2.h
@@ -0,0 +1,7 @@
+#ifndef _ASM_X86_HWCAP2_H
+#define _ASM_X86_HWCAP2_H
+
+/* MONITOR/MWAIT enabled in Ring 3 */
+#define HWCAP2_RING3MWAIT  (1 << 0)
+
+#endif
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 9bab7a8..f879429 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -51,6 +52,8 @@
 
 #include "cpu.h"
 
+u32 elf_hwcap2 __read_mostly;
+
 /* all of these masks are initialized in setup_cpu_local_masks() */
 cpumask_var_t cpu_initialized_mask;
 cpumask_var_t cpu_callout_mask;

[tip:x86/cpufeature] x86/cpufeature: Add RING3MWAIT to CPU features

[tip-bot for Grzegorz Andrejczuk]

Commit-ID:  1d12d0ef0194ccc4dcebed3d96bb2301b26fc3ee
Gitweb: http://git.kernel.org/tip/1d12d0ef0194ccc4dcebed3d96bb2301b26fc3ee
Author: Grzegorz Andrejczuk 
AuthorDate: Fri, 20 Jan 2017 14:22:35 +0100
Committer:  Thomas Gleixner 
CommitDate: Sat, 4 Feb 2017 08:51:09 +0100

x86/cpufeature: Add RING3MWAIT to CPU features

Add software-defined CPUID bit for the non-architectural ring 3
MONITOR/MWAIT feature.

Signed-off-by: Grzegorz Andrejczuk 
Cc: piotr@intel.com
Cc: dave.han...@linux.intel.com
Link: 
http://lkml.kernel.org/r/1484918557-15481-4-git-send-email-grzegorz.andrejc...@intel.com
Signed-off-by: Thomas Gleixner 

---
 arch/x86/include/asm/cpufeatures.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/cpufeatures.h 
b/arch/x86/include/asm/cpufeatures.h
index d9d7136..56e5184 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -100,7 +100,7 @@
 #define X86_FEATURE_XTOPOLOGY  ( 3*32+22) /* cpu topology enum extensions */
 #define X86_FEATURE_TSC_RELIABLE ( 3*32+23) /* TSC is known to be reliable */
 #define X86_FEATURE_NONSTOP_TSC( 3*32+24) /* TSC does not stop in C 
states */
-/* free, was #define X86_FEATURE_CLFLUSH_MONITOR ( 3*32+25) * "" clflush reqd 
with monitor */
+#define X86_FEATURE_RING3MWAIT ( 3*32+25) /* ring 3 MONITOR/MWAIT */
 #define X86_FEATURE_EXTD_APICID( 3*32+26) /* has extended APICID (8 
bits) */
 #define X86_FEATURE_AMD_DCM ( 3*32+27) /* multi-node processor */
 #define X86_FEATURE_APERFMPERF ( 3*32+28) /* APERFMPERF */

[tip:x86/cpufeature] x86/cpufeature: Enable RING3MWAIT for Knights Landing

[tip-bot for Grzegorz Andrejczuk]

Commit-ID:  e16fd002afe2b16d828bbf738b8a81a185fe9272
Gitweb: http://git.kernel.org/tip/e16fd002afe2b16d828bbf738b8a81a185fe9272
Author: Grzegorz Andrejczuk 
AuthorDate: Fri, 20 Jan 2017 14:22:36 +0100
Committer:  Thomas Gleixner 
CommitDate: Sat, 4 Feb 2017 08:51:09 +0100

x86/cpufeature: Enable RING3MWAIT for Knights Landing

Enable ring 3 MONITOR/MWAIT for Intel Xeon Phi x200 codenamed Knights
Landing.

Presence of this feature cannot be detected automatically (by reading any
other MSR) therefore it is required to explicitly check for the family and
model of the CPU before attempting to enable it.

Signed-off-by: Grzegorz Andrejczuk 
Cc: piotr@intel.com
Cc: dave.han...@linux.intel.com
Link: 
http://lkml.kernel.org/r/1484918557-15481-5-git-send-email-grzegorz.andrejc...@intel.com
Signed-off-by: Thomas Gleixner 

---
 Documentation/admin-guide/kernel-parameters.txt |  4 +++
 arch/x86/kernel/cpu/intel.c | 37 +
 2 files changed, 41 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index be7c0d9..cfbb3fc 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3563,6 +3563,10 @@
rhash_entries=  [KNL,NET]
Set number of hash buckets for route cache
 
+   ring3mwait=disable
+   [KNL] Disable ring 3 MONITOR/MWAIT feature on supported
+   CPUs.
+
ro  [KNL] Mount root device read-only on boot
 
rodata= [KNL]
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index 203f860..da2401a 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -15,6 +15,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #ifdef CONFIG_X86_64
 #include 
@@ -62,6 +64,39 @@ void check_mpx_erratum(struct cpuinfo_x86 *c)
}
 }
 
+static bool ring3mwait_disabled __read_mostly;
+
+static int __init ring3mwait_disable(char *__unused)
+{
+   ring3mwait_disabled = true;
+   return 0;
+}
+__setup("ring3mwait=disable", ring3mwait_disable);
+
+static void probe_xeon_phi_r3mwait(struct cpuinfo_x86 *c)
+{
+   /*
+* Ring 3 MONITOR/MWAIT feature cannot be detected without
+* cpu model and family comparison.
+*/
+   if (c->x86 != 6 || c->x86_model != INTEL_FAM6_XEON_PHI_KNL)
+   return;
+
+   if (ring3mwait_disabled) {
+   msr_clear_bit(MSR_MISC_FEATURE_ENABLES,
+ MSR_MISC_FEATURE_ENABLES_RING3MWAIT_BIT);
+   return;
+   }
+
+   msr_set_bit(MSR_MISC_FEATURE_ENABLES,
+   MSR_MISC_FEATURE_ENABLES_RING3MWAIT_BIT);
+
+   set_cpu_cap(c, X86_FEATURE_RING3MWAIT);
+
+   if (c == _cpu_data)
+   ELF_HWCAP2 |= HWCAP2_RING3MWAIT;
+}
+
 static void early_init_intel(struct cpuinfo_x86 *c)
 {
u64 misc_enable;
@@ -560,6 +595,8 @@ static void init_intel(struct cpuinfo_x86 *c)
detect_vmx_virtcap(c);
 
init_intel_energy_perf(c);
+
+   probe_xeon_phi_r3mwait(c);
 }
 
 #ifdef CONFIG_X86_32

[tip:x86/cpufeature] x86/cpufeature: Enable RING3MWAIT for Knights Mill

[tip-bot for Piotr Luc]

Commit-ID:  2fc70d88d85d55e85bad7fde0ee71f79e22bfa3f
Gitweb: http://git.kernel.org/tip/2fc70d88d85d55e85bad7fde0ee71f79e22bfa3f
Author: Piotr Luc 
AuthorDate: Fri, 20 Jan 2017 14:22:37 +0100
Committer:  Thomas Gleixner 
CommitDate: Sat, 4 Feb 2017 08:51:10 +0100

x86/cpufeature: Enable RING3MWAIT for Knights Mill

Enable ring 3 MONITOR/MWAIT for Intel Xeon Phi codenamed Knights Mill. We
can't guarantee that this (KNM) will be the last CPU model that needs this
hack.  But, we do recognize that this is far from optimal, and there is an
effort to ensure we don't keep doing extending this hack forever.

Signed-off-by: Piotr Luc 
Cc: piotr@intel.com
Cc: dave.han...@linux.intel.com
Link: 
http://lkml.kernel.org/r/1484918557-15481-6-git-send-email-grzegorz.andrejc...@intel.com
Signed-off-by: Thomas Gleixner 

---
 arch/x86/kernel/cpu/intel.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index da2401a..74f30f9 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -79,8 +79,15 @@ static void probe_xeon_phi_r3mwait(struct cpuinfo_x86 *c)
 * Ring 3 MONITOR/MWAIT feature cannot be detected without
 * cpu model and family comparison.
 */
-   if (c->x86 != 6 || c->x86_model != INTEL_FAM6_XEON_PHI_KNL)
+   if (c->x86 != 6)
return;
+   switch (c->x86_model) {
+   case INTEL_FAM6_XEON_PHI_KNL:
+   case INTEL_FAM6_XEON_PHI_KNM:
+   break:
+   default:
+   return;
+   }
 
if (ring3mwait_disabled) {
msr_clear_bit(MSR_MISC_FEATURE_ENABLES,

Re: [PATCH v2 1/2] net: phy: dp83867: Port mirroring support in the DP83867 TI's PHY driver

[Andrew Lunn]

On Sat, Feb 04, 2017 at 05:02:11PM +0100, Lukasz Majewski wrote:
> This patch adds support for enabling or disabling the port mirroring 
> (at CFG4 register) feature of the DP83867 TI's PHY device.

As we discussed before, "port mirroring" is bad naming. Yes, we should
use it, because that is what the datasheet calls this feature. But the
commit message should also contain a description of what this means,
and reference that the linux name for this concept is lane swapping.

> +enum {

Maybe give the 0 value a name. DP83867_PORT_MIRROING_KEEP?

> + DP83867_PORT_MIRROING_EN = 1,
> + DP83867_PORT_MIRROING_DIS,
> +};
> +

That extra enum value can then make this more obvious:
  
if (dp83867->port_mirroring != DP83867_PORT_MIRROING_KEEP)
dp83867_config_port_mirroring(phydev);

On the first reading of the patch, i though you were setting mirroring
on/off under all conditions, but in fact you don't. This makes it
clearer.

Thanks
Andrew

Re: [PATCH 5/5] regulator: core: lower severity level of message about using dummy supplies

[Dmitry Torokhov]

On Sat, Feb 04, 2017 at 12:48:19PM +0100, Mark Brown wrote:
> On Fri, Feb 03, 2017 at 01:56:04PM -0800, Dmitry Torokhov wrote:
> > Use of dummy supplies is normal and common occurrence in the kernel, let's
> > lower severity from warning to info.
> 
> It really shouldn't be either of these things, at least on DT systems.

But it definitely happens on ACPI systems for drivers for peripherals
that we share between both x86 and ARM.

-- 
Dmitry

Re: [PATCH 0/7] Implement generic regulator constraints parsing for ACPI and OF

[Mark Brown]

On Thu, Jan 26, 2017 at 11:35:55AM +0100, Rafael J. Wysocki wrote:

> but that doesn't work if drivers expect to be able to control regulators 
> directly
> (which BTW isn't an good idea overall IMO, because that may need to be done
> differently on different platforms even without ACPI AFAICS).

We've really not encountered anything that has any issues here outside
of what's supported in the constraints already (basically what voltages
can be set and if the supply can be turned on and off).  I'd be pretty
surprised if we did TBH, it's hard to do something radically different
with a single piece of silicon which is the abstraction level we tend to
be operating at if we are controlling regulators.  AFAICT a higher level
of abstraction is generally going to go along with physically hiding the
regulators even in a DT world.


signature.asc
Description: PGP signature

[tip:x86/cleanups] x86/traps: Get rid of unnecessary preempt_disable/preempt_enable_no_resched

[tip-bot for Alexander Kuleshov]

Commit-ID:  07d495dae20717b00881798ef812f7aa53ca0eb3
Gitweb: http://git.kernel.org/tip/07d495dae20717b00881798ef812f7aa53ca0eb3
Author: Alexander Kuleshov 
AuthorDate: Mon, 28 Nov 2016 13:50:57 +0600
Committer:  Thomas Gleixner 
CommitDate: Sat, 4 Feb 2017 09:36:59 +0100

x86/traps: Get rid of unnecessary preempt_disable/preempt_enable_no_resched

Exception handlers which may run on IST stack call ist_enter() at the start
of execution and ist_exit() in the end. ist_enter() disables preemption
unconditionally and ist_exit() enables it.

So the extra preempt_disable/enable() pairs nested inside the
ist_enter/exit() regions are pointless and can be removed.

Signed-off-by: Alexander Kuleshov 
Cc: Tony Luck 
Cc: Jianyu Zhan 
Cc: Paul Gortmaker 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Link: http://lkml.kernel.org/r/20161128075057.7724-1-kuleshovm...@gmail.com
Signed-off-by: Thomas Gleixner 

---
 arch/x86/kernel/traps.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index bf0c6d0..1dc86ee 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -563,11 +563,9 @@ dotraplinkage void notrace do_int3(struct pt_regs *regs, 
long error_code)
 * as we may switch to the interrupt stack.
 */
debug_stack_usage_inc();
-   preempt_disable();
cond_local_irq_enable(regs);
do_trap(X86_TRAP_BP, SIGTRAP, "int3", regs, error_code, NULL);
cond_local_irq_disable(regs);
-   preempt_enable_no_resched();
debug_stack_usage_dec();
 exit:
ist_exit(regs);
@@ -742,14 +740,12 @@ dotraplinkage void do_debug(struct pt_regs *regs, long 
error_code)
debug_stack_usage_inc();
 
/* It's safe to allow irq's after DR6 has been saved */
-   preempt_disable();
cond_local_irq_enable(regs);
 
if (v8086_mode(regs)) {
handle_vm86_trap((struct kernel_vm86_regs *) regs, error_code,
X86_TRAP_DB);
cond_local_irq_disable(regs);
-   preempt_enable_no_resched();
debug_stack_usage_dec();
goto exit;
}
@@ -769,7 +765,6 @@ dotraplinkage void do_debug(struct pt_regs *regs, long 
error_code)
if (tsk->thread.debugreg6 & (DR_STEP | DR_TRAP_BITS) || user_icebp)
send_sigtrap(tsk, regs, error_code, si_code);
cond_local_irq_disable(regs);
-   preempt_enable_no_resched();
debug_stack_usage_dec();
 
 exit:

[tip:x86/cleanups] x86/pci-calgary: Fix iommu_free() comparison of unsigned expression >= 0

[tip-bot for Nikola Pajkovsky]

Commit-ID:  68dee8e2f2cacc54d038394e70d22411dee89da2
Gitweb: http://git.kernel.org/tip/68dee8e2f2cacc54d038394e70d22411dee89da2
Author: Nikola Pajkovsky 
AuthorDate: Tue, 15 Nov 2016 09:47:49 +0100
Committer:  Thomas Gleixner 
CommitDate: Sat, 4 Feb 2017 09:27:06 +0100

x86/pci-calgary: Fix iommu_free() comparison of unsigned expression >= 0

commit 8fd524b355da ("x86: Kill bad_dma_address variable") has killed
bad_dma_address variable and used instead of macro DMA_ERROR_CODE
which is always zero. Since dma_addr is unsigned, the statement

   dma_addr >= DMA_ERROR_CODE

is always true, and not needed.

arch/x86/kernel/pci-calgary_64.c: In function ‘iommu_free’:
arch/x86/kernel/pci-calgary_64.c:299:2: warning: comparison of unsigned 
expression >= 0 is always true [-Wtype-limits]
  if (unlikely((dma_addr >= DMA_ERROR_CODE) && (dma_addr < badend))) {

Fixes: 8fd524b355da ("x86: Kill bad_dma_address variable")
Signed-off-by: Nikola Pajkovsky 
Cc: io...@lists.linux-foundation.org
Cc: Jon Mason 
Cc: Muli Ben-Yehuda 
Link: 
http://lkml.kernel.org/r/7612c0f9dd7c1290407dbf8e809def922006920b.1479161177.git.npajkov...@suse.cz
Signed-off-by: Thomas Gleixner 

---
 arch/x86/kernel/pci-calgary_64.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/pci-calgary_64.c b/arch/x86/kernel/pci-calgary_64.c
index 5d400ba..d475179 100644
--- a/arch/x86/kernel/pci-calgary_64.c
+++ b/arch/x86/kernel/pci-calgary_64.c
@@ -296,7 +296,7 @@ static void iommu_free(struct iommu_table *tbl, dma_addr_t 
dma_addr,
 
/* were we called with bad_dma_address? */
badend = DMA_ERROR_CODE + (EMERGENCY_PAGES * PAGE_SIZE);
-   if (unlikely((dma_addr >= DMA_ERROR_CODE) && (dma_addr < badend))) {
+   if (unlikely(dma_addr < badend)) {
WARN(1, KERN_ERR "Calgary: driver tried unmapping bad DMA "
   "address 0x%Lx\n", dma_addr);
return;

[PATCH] bcm2835-audio: One coding style correction in bcm2835-ctl.c.

[Victor Vaschenko]

Just one coding style correction in bcm2835-ctl.c.

Signed-off-by: Victor Vaschenko 
---
 drivers/staging/bcm2835-audio/bcm2835-ctl.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/bcm2835-audio/bcm2835-ctl.c 
b/drivers/staging/bcm2835-audio/bcm2835-ctl.c
index 164daa4..bfb7e9f 100644
--- a/drivers/staging/bcm2835-audio/bcm2835-ctl.c
+++ b/drivers/staging/bcm2835-audio/bcm2835-ctl.c
@@ -164,8 +164,7 @@ static int snd_bcm2835_ctl_put(struct snd_kcontrol 
*kcontrol,
.get = snd_bcm2835_ctl_get,
.put = snd_bcm2835_ctl_put,
.count = 1,
-   .tlv =
-   {.p = snd_bcm2835_db_scale}
+   .tlv = {.p = snd_bcm2835_db_scale}
},
{
.iface = SNDRV_CTL_ELEM_IFACE_MIXER,
-- 
1.9.1

[tip:core/debugobjects] debugobjects: Reduce contention on the global pool_lock

[tip-bot for Waiman Long]

Commit-ID:  6d2fea9837a584e706edad9b4b52833e31396736
Gitweb: http://git.kernel.org/tip/6d2fea9837a584e706edad9b4b52833e31396736
Author: Waiman Long 
AuthorDate: Thu, 5 Jan 2017 15:17:05 -0500
Committer:  Thomas Gleixner 
CommitDate: Sat, 4 Feb 2017 09:01:55 +0100

debugobjects: Reduce contention on the global pool_lock

On a large SMP system with many CPUs, the global pool_lock may become
a performance bottleneck as all the CPUs that need to allocate or
free debug objects have to take the lock. That can sometimes cause
soft lockups like:

 NMI watchdog: BUG: soft lockup - CPU#35 stuck for 22s! [rcuos/1:21]
 ...
 RIP: 0010:[]  []
_raw_spin_unlock_irqrestore+0x3b/0x60
 ...
 Call Trace:
  [] free_object+0x81/0xb0
  [] debug_check_no_obj_freed+0x193/0x220
  [] ? trace_hardirqs_on_caller+0xf9/0x1c0
  [] ? file_free_rcu+0x36/0x60
  [] kmem_cache_free+0xd2/0x380
  [] ? fput+0x90/0x90
  [] file_free_rcu+0x36/0x60
  [] rcu_nocb_kthread+0x1b3/0x550
  [] ? rcu_nocb_kthread+0x101/0x550
  [] ? sync_exp_work_done.constprop.63+0x50/0x50
  [] kthread+0x101/0x120
  [] ? trace_hardirqs_on_caller+0xf9/0x1c0
  [] ret_from_fork+0x22/0x50

To reduce the amount of contention on the pool_lock, the actual
kmem_cache_free() of the debug objects will be delayed if the pool_lock
is busy. This will temporarily increase the amount of free objects
available at the free pool when the system is busy. As a result,
the number of kmem_cache allocation and freeing is reduced.

To further reduce the lock operations free debug objects in batches of
four.

Signed-off-by: Waiman Long 
Cc: Christian Borntraeger 
Cc: "Du Changbin" 
Cc: Andrew Morton 
Cc: Jan Stancek 
Link: 
http://lkml.kernel.org/r/1483647425-4135-4-git-send-email-long...@redhat.com
Signed-off-by: Thomas Gleixner 

---
 lib/debugobjects.c | 31 ++-
 1 file changed, 22 insertions(+), 9 deletions(-)

diff --git a/lib/debugobjects.c b/lib/debugobjects.c
index dc78217..5476bbe 100644
--- a/lib/debugobjects.c
+++ b/lib/debugobjects.c
@@ -172,25 +172,38 @@ alloc_object(void *addr, struct debug_bucket *b, struct 
debug_obj_descr *descr)
 
 /*
  * workqueue function to free objects.
+ *
+ * To reduce contention on the global pool_lock, the actual freeing of
+ * debug objects will be delayed if the pool_lock is busy. We also free
+ * the objects in a batch of 4 for each lock/unlock cycle.
  */
+#define ODEBUG_FREE_BATCH  4
 static void free_obj_work(struct work_struct *work)
 {
-   struct debug_obj *obj;
+   struct debug_obj *objs[ODEBUG_FREE_BATCH];
unsigned long flags;
+   int i;
 
-   raw_spin_lock_irqsave(_lock, flags);
-   while (obj_pool_free > debug_objects_pool_size) {
-   obj = hlist_entry(obj_pool.first, typeof(*obj), node);
-   hlist_del(>node);
-   obj_pool_free--;
-   debug_objects_freed++;
+   if (!raw_spin_trylock_irqsave(_lock, flags))
+   return;
+   while (obj_pool_free >= debug_objects_pool_size + ODEBUG_FREE_BATCH) {
+   for (i = 0; i < ODEBUG_FREE_BATCH; i++) {
+   objs[i] = hlist_entry(obj_pool.first,
+ typeof(*objs[0]), node);
+   hlist_del([i]->node);
+   }
+
+   obj_pool_free -= ODEBUG_FREE_BATCH;
+   debug_objects_freed += ODEBUG_FREE_BATCH;
/*
 * We release pool_lock across kmem_cache_free() to
 * avoid contention on pool_lock.
 */
raw_spin_unlock_irqrestore(_lock, flags);
-   kmem_cache_free(obj_cache, obj);
-   raw_spin_lock_irqsave(_lock, flags);
+   for (i = 0; i < ODEBUG_FREE_BATCH; i++)
+   kmem_cache_free(obj_cache, objs[i]);
+   if (!raw_spin_trylock_irqsave(_lock, flags))
+   return;
}
raw_spin_unlock_irqrestore(_lock, flags);
 }

[GIT PULL] KVM fixes for v4.10-rc7

[Radim Krčmář]

Linus,

The following changes since commit 566cf877a1fcb6d6dc0126b076aad062054c2637:

  Linux 4.10-rc6 (2017-01-29 14:25:17 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus

for you to fetch changes up to 00c87e9a70a17b355b81c36adedf05e84f54e10d:

  KVM: x86: do not save guest-unsupported XSAVE state (2017-02-03 18:43:08 
+0100)


KVM fix for v4.10-rc7

Fix a regression that prevented migration between hosts with different
XSAVE features even if the missing features were not used by the guest
(for stable).


Radim Krčmář (1):
  KVM: x86: do not save guest-unsupported XSAVE state

 arch/x86/kvm/x86.c | 1 +
 1 file changed, 1 insertion(+)

[tip:x86/mm] x86/mm/pat: Use rb_entry()

[tip-bot for Geliang Tang]

Commit-ID:  1013fe32a63d1139b1b32049ea46c0c462738d8b
Gitweb: http://git.kernel.org/tip/1013fe32a63d1139b1b32049ea46c0c462738d8b
Author: Geliang Tang 
AuthorDate: Mon, 19 Dec 2016 22:35:57 +0800
Committer:  Thomas Gleixner 
CommitDate: Sat, 4 Feb 2017 17:18:00 +0100

x86/mm/pat: Use rb_entry()

To make the code clearer, use rb_entry() instead of open coding it

Signed-off-by: Geliang Tang 
Cc: Masahiro Yamada 
Cc: Toshi Kani 
Cc: Paul Gortmaker 
Link: 
http://lkml.kernel.org/r/974a91cd4ed2d04c92e4faa4765077e38f248d6b.1482157956.git.geliangt...@gmail.com
Signed-off-by: Thomas Gleixner 

---
 arch/x86/mm/pat_rbtree.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/x86/mm/pat_rbtree.c b/arch/x86/mm/pat_rbtree.c
index 159b52c..d76485b 100644
--- a/arch/x86/mm/pat_rbtree.c
+++ b/arch/x86/mm/pat_rbtree.c
@@ -47,7 +47,7 @@ static u64 get_subtree_max_end(struct rb_node *node)
 {
u64 ret = 0;
if (node) {
-   struct memtype *data = container_of(node, struct memtype, rb);
+   struct memtype *data = rb_entry(node, struct memtype, rb);
ret = data->subtree_max_end;
}
return ret;
@@ -79,7 +79,7 @@ static struct memtype *memtype_rb_lowest_match(struct rb_root 
*root,
struct memtype *last_lower = NULL;
 
while (node) {
-   struct memtype *data = container_of(node, struct memtype, rb);
+   struct memtype *data = rb_entry(node, struct memtype, rb);
 
if (get_subtree_max_end(node->rb_left) > start) {
/* Lowest overlap if any must be on left side */
@@ -121,7 +121,7 @@ static struct memtype *memtype_rb_match(struct rb_root 
*root,
 
node = rb_next(>rb);
if (node)
-   match = container_of(node, struct memtype, rb);
+   match = rb_entry(node, struct memtype, rb);
else
match = NULL;
}
@@ -150,7 +150,7 @@ static int memtype_rb_check_conflict(struct rb_root *root,
 
node = rb_next(>rb);
while (node) {
-   match = container_of(node, struct memtype, rb);
+   match = rb_entry(node, struct memtype, rb);
 
if (match->start >= end) /* Checked all possible matches */
goto success;
@@ -181,7 +181,7 @@ static void memtype_rb_insert(struct rb_root *root, struct 
memtype *newdata)
struct rb_node *parent = NULL;
 
while (*node) {
-   struct memtype *data = container_of(*node, struct memtype, rb);
+   struct memtype *data = rb_entry(*node, struct memtype, rb);
 
parent = *node;
if (data->subtree_max_end < newdata->end)
@@ -270,7 +270,7 @@ int rbt_memtype_copy_nth_element(struct memtype *out, 
loff_t pos)
}
 
if (node) { /* pos == i */
-   struct memtype *this = container_of(node, struct memtype, rb);
+   struct memtype *this = rb_entry(node, struct memtype, rb);
*out = *this;
return 0;
} else {

RE: [PATCH 1/1] Drivers: hv: Fix the bug in generating the guest ID

[KY Srinivasan]

> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Saturday, February 4, 2017 7:58 AM
> To: KY Srinivasan 
> Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org;
> o...@aepfle.de; a...@canonical.com; vkuzn...@redhat.com;
> jasow...@redhat.com; leann.ogasaw...@canonical.com
> Subject: Re: [PATCH 1/1] Drivers: hv: Fix the bug in generating the guest ID
> 
> On Sat, Feb 04, 2017 at 08:46:23AM -0700, k...@exchange.microsoft.com
> wrote:
> > From: K. Y. Srinivasan 
> >
> > Fix the bug in the generation of the guest ID. Without this fix
> > the host side telemetry code is broken.
> >
> > Signed-off-by: K. Y. Srinivasan 
> 
> If it's broken, does that mean this should go to the stable kernels?
> What commit caused the breakage?

Commit 352c9624242d5836ad8a960826183011367871a4 introduced the bug.
The stable kernels are fine.

Thanks,

K. Y
> 
> thanks,
> 
> greg k-h

Re: [lkp-robot] [mm/memblock] cc4a913fa5: WARNING:at_mm/memblock.c:#__next_mem_pfn_range

[Wei Yang]

On Fri, Feb 03, 2017 at 09:44:49AM +0800, kernel test robot wrote:
>
>FYI, we noticed the following commit:
>
>commit: cc4a913fa513cdac8777c2714e6388465691faf8 ("mm/memblock: switch to use 
>NUMA_NO_NODE instead of MAX_NUMNODES in for_each_mem_pfn_range()")
>url: 
>https://github.com/0day-ci/linux/commits/Wei-Yang/mm-memblock-use-NUMA_NO_NODE-instead-of-MAX_NUMNODES-as-default-node_id/20170127-100339
>
>
>in testcase: trinity
>with following parameters:
>
>   runtime: 300s
>
>test-description: Trinity is a linux system call fuzz tester.
>test-url: http://codemonkey.org.uk/projects/trinity/
>
>
>on test machine: qemu-system-i386 -enable-kvm -m 256M
>
>caused below changes (please refer to attached dmesg/kmsg for entire 
>log/backtrace):
>
>
>++++
>|| 2d1ec173d5 | cc4a913fa5 |
>++++
>| boot_successes | 6  | 0  |
>| boot_failures  | 0  | 8  |
>| WARNING:at_mm/memblock.c:#__next_mem_pfn_range | 0  | 8  |
>| calltrace:SyS_open | 0  | 8  |
>++++
>
>
>
>[0.00] initial memory mapped: [mem 0x-0x083f]
>[0.00] Base memory trampoline at [8009b000] 9b000 size 16384
>[0.00] [ cut here ]
>[0.00] WARNING: CPU: 0 PID: 0 at mm/memblock.c:1088 
>__next_mem_pfn_range+0x5e/0x16e
>[0.00] Usage of MAX_NUMNODES is deprecated. Use NUMA_NO_NODE instead
>[0.00] Modules linked in:
>[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 
>4.9.0-rc6-00135-gcc4a913 #1
>[0.00] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
>1.9.3-20161025_171302-gandalf 04/01/2014
>[0.00]  87511ec0 86e241ad 8743bde0 8743bde0 87511ed8 86c48c2a 0440 
>11a426ae
>[0.00]  87511f5c 87511f54 87511ef4 86c48c68 0009  87511eec 
>8743bde0
>[0.00]  87511f08 87511f1c 875eadb9 8743bd80 0440 8743bde0 87511f5c 
>87511f54
>[0.00] Call Trace:
>[0.00]  [<86e241ad>] dump_stack+0x76/0xa9
>[0.00]  [<86c48c2a>] __warn+0xba/0xd0
>[0.00]  [<86c48c68>] warn_slowpath_fmt+0x28/0x30
>[0.00]  [<875eadb9>] __next_mem_pfn_range+0x5e/0x16e
>[0.00]  [<875a84e6>] init_range_memory_mapping+0x3e/0x177
>[0.00]  [<875e9fea>] ? memblock_find_in_range+0x3c/0x95
>[0.00]  [<875a87c4>] init_mem_mapping+0x1a5/0x260
>[0.00]  [<87594e3a>] setup_arch+0x7c0/0xb82
>[0.00]  [<86c973b2>] ? vprintk_default+0x12/0x20
>[0.00]  [<8758dcd8>] start_kernel+0x5b/0x40f
>[0.00]  [<8758d2c8>] i386_start_kernel+0xaf/0xc7
>[0.00] ---[ end trace  ]---
>[0.00] BRK [0x07ea3000, 0x07ea3fff] PGTABLE
>[0.00] RAMDISK: [mem 0x0f4f1000-0x0ffc]
>
>
>To reproduce:
>
>git clone 
> git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
>cd lkp-tests
>bin/lkp qemu -k  job-script  # job-script is attached in this 
> email
>

Hi, Xiaolong

Thanks for your test.

The warning on __next_mem_pfn_range() is expected. While the real problem
seems to be in the 8250 serial port driver. At least which complains in dmesg.

I am trying to reproduce this, while looks your guest is a 32-bit version. So
do I have to use a 32-bit guest or you have a 64-bit version test environment?

>
>
>Thanks,
>Xiaolong

>#
># Automatically generated file; DO NOT EDIT.
># Linux/i386 4.9.0-rc6 Kernel Configuration
>#
># CONFIG_64BIT is not set
>CONFIG_X86_32=y
>CONFIG_X86=y
>CONFIG_INSTRUCTION_DECODER=y
>CONFIG_OUTPUT_FORMAT="elf32-i386"
>CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
>CONFIG_LOCKDEP_SUPPORT=y
>CONFIG_STACKTRACE_SUPPORT=y
>CONFIG_MMU=y
>CONFIG_ARCH_MMAP_RND_BITS_MIN=8
>CONFIG_ARCH_MMAP_RND_BITS_MAX=16
>CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
>CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
>CONFIG_NEED_SG_DMA_LENGTH=y
>CONFIG_GENERIC_ISA_DMA=y
>CONFIG_GENERIC_BUG=y
>CONFIG_GENERIC_HWEIGHT=y
>CONFIG_ARCH_MAY_HAVE_PC_FDC=y
>CONFIG_RWSEM_XCHGADD_ALGORITHM=y
>CONFIG_GENERIC_CALIBRATE_DELAY=y
>CONFIG_ARCH_HAS_CPU_RELAX=y
>CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
>CONFIG_HAVE_SETUP_PER_CPU_AREA=y
>CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
>CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
>CONFIG_ARCH_HIBERNATION_POSSIBLE=y
>CONFIG_ARCH_SUSPEND_POSSIBLE=y
>CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
>CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
>CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
>CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
>CONFIG_X86_32_SMP=y
>CONFIG_X86_32_LAZY_GS=y
>CONFIG_ARCH_SUPPORTS_UPROBES=y
>CONFIG_FIX_EARLYCON_MEM=y
>CONFIG_DEBUG_RODATA=y
>CONFIG_PGTABLE_LEVELS=2
>CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
>CONFIG_IRQ_WORK=y

Re: [lkp-robot] [mm/memblock] cc4a913fa5: WARNING:at_mm/memblock.c:#__next_mem_pfn_range

[Wei Yang]

On Fri, Feb 03, 2017 at 09:44:49AM +0800, kernel test robot wrote:
>
>FYI, we noticed the following commit:
>
>commit: cc4a913fa513cdac8777c2714e6388465691faf8 ("mm/memblock: switch to use 
>NUMA_NO_NODE instead of MAX_NUMNODES in for_each_mem_pfn_range()")
>url: 
>https://github.com/0day-ci/linux/commits/Wei-Yang/mm-memblock-use-NUMA_NO_NODE-instead-of-MAX_NUMNODES-as-default-node_id/20170127-100339
>

Hmm... The commit itself is to switch the MAX_NUMNODES to NUMA_NO_NODE and
warning the potential users. And no functional change.

So the warning itself is the reason for the failure?

>
>in testcase: trinity
>with following parameters:
>
>   runtime: 300s
>
>test-description: Trinity is a linux system call fuzz tester.
>test-url: http://codemonkey.org.uk/projects/trinity/
>
>
>on test machine: qemu-system-i386 -enable-kvm -m 256M
>
>caused below changes (please refer to attached dmesg/kmsg for entire 
>log/backtrace):
>
>
>++++
>|| 2d1ec173d5 | cc4a913fa5 |
>++++
>| boot_successes | 6  | 0  |
>| boot_failures  | 0  | 8  |
>| WARNING:at_mm/memblock.c:#__next_mem_pfn_range | 0  | 8  |
>| calltrace:SyS_open | 0  | 8  |
>++++
>
>
>
>[0.00] initial memory mapped: [mem 0x-0x083f]
>[0.00] Base memory trampoline at [8009b000] 9b000 size 16384
>[0.00] [ cut here ]
>[0.00] WARNING: CPU: 0 PID: 0 at mm/memblock.c:1088 
>__next_mem_pfn_range+0x5e/0x16e
>[0.00] Usage of MAX_NUMNODES is deprecated. Use NUMA_NO_NODE instead
>[0.00] Modules linked in:
>[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 
>4.9.0-rc6-00135-gcc4a913 #1
>[0.00] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
>1.9.3-20161025_171302-gandalf 04/01/2014
>[0.00]  87511ec0 86e241ad 8743bde0 8743bde0 87511ed8 86c48c2a 0440 
>11a426ae
>[0.00]  87511f5c 87511f54 87511ef4 86c48c68 0009  87511eec 
>8743bde0
>[0.00]  87511f08 87511f1c 875eadb9 8743bd80 0440 8743bde0 87511f5c 
>87511f54
>[0.00] Call Trace:
>[0.00]  [<86e241ad>] dump_stack+0x76/0xa9
>[0.00]  [<86c48c2a>] __warn+0xba/0xd0
>[0.00]  [<86c48c68>] warn_slowpath_fmt+0x28/0x30
>[0.00]  [<875eadb9>] __next_mem_pfn_range+0x5e/0x16e
>[0.00]  [<875a84e6>] init_range_memory_mapping+0x3e/0x177
>[0.00]  [<875e9fea>] ? memblock_find_in_range+0x3c/0x95
>[0.00]  [<875a87c4>] init_mem_mapping+0x1a5/0x260
>[0.00]  [<87594e3a>] setup_arch+0x7c0/0xb82
>[0.00]  [<86c973b2>] ? vprintk_default+0x12/0x20
>[0.00]  [<8758dcd8>] start_kernel+0x5b/0x40f
>[0.00]  [<8758d2c8>] i386_start_kernel+0xaf/0xc7
>[0.00] ---[ end trace  ]---
>[0.00] BRK [0x07ea3000, 0x07ea3fff] PGTABLE
>[0.00] RAMDISK: [mem 0x0f4f1000-0x0ffc]
>
>
>To reproduce:
>
>git clone 
> git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
>cd lkp-tests
>bin/lkp qemu -k  job-script  # job-script is attached in this 
> email
>
>
>
>Thanks,
>Xiaolong

>#
># Automatically generated file; DO NOT EDIT.
># Linux/i386 4.9.0-rc6 Kernel Configuration
>#
># CONFIG_64BIT is not set
>CONFIG_X86_32=y
>CONFIG_X86=y
>CONFIG_INSTRUCTION_DECODER=y
>CONFIG_OUTPUT_FORMAT="elf32-i386"
>CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
>CONFIG_LOCKDEP_SUPPORT=y
>CONFIG_STACKTRACE_SUPPORT=y
>CONFIG_MMU=y
>CONFIG_ARCH_MMAP_RND_BITS_MIN=8
>CONFIG_ARCH_MMAP_RND_BITS_MAX=16
>CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
>CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
>CONFIG_NEED_SG_DMA_LENGTH=y
>CONFIG_GENERIC_ISA_DMA=y
>CONFIG_GENERIC_BUG=y
>CONFIG_GENERIC_HWEIGHT=y
>CONFIG_ARCH_MAY_HAVE_PC_FDC=y
>CONFIG_RWSEM_XCHGADD_ALGORITHM=y
>CONFIG_GENERIC_CALIBRATE_DELAY=y
>CONFIG_ARCH_HAS_CPU_RELAX=y
>CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
>CONFIG_HAVE_SETUP_PER_CPU_AREA=y
>CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
>CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
>CONFIG_ARCH_HIBERNATION_POSSIBLE=y
>CONFIG_ARCH_SUSPEND_POSSIBLE=y
>CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
>CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
>CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
>CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
>CONFIG_X86_32_SMP=y
>CONFIG_X86_32_LAZY_GS=y
>CONFIG_ARCH_SUPPORTS_UPROBES=y
>CONFIG_FIX_EARLYCON_MEM=y
>CONFIG_DEBUG_RODATA=y
>CONFIG_PGTABLE_LEVELS=2
>CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
>CONFIG_IRQ_WORK=y
>CONFIG_BUILDTIME_EXTABLE_SORT=y
>CONFIG_THREAD_INFO_IN_TASK=y
>
>#
># General setup
>#
>CONFIG_INIT_ENV_ARG_LIMIT=32
>CONFIG_CROSS_COMPILE=""
># CONFIG_COMPILE_TEST is 

[tip:x86/cpufeature 6/6] arch/x86/kernel/cpu/intel.c:87:8: error: expected ';' before ':' token

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
x86/cpufeature
head:   2fc70d88d85d55e85bad7fde0ee71f79e22bfa3f
commit: 2fc70d88d85d55e85bad7fde0ee71f79e22bfa3f [6/6] x86/cpufeature: Enable 
RING3MWAIT for Knights Mill
config: i386-randconfig-x004-201705 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 2fc70d88d85d55e85bad7fde0ee71f79e22bfa3f
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   arch/x86/kernel/cpu/intel.c: In function 'probe_xeon_phi_r3mwait':
>> arch/x86/kernel/cpu/intel.c:87:8: error: expected ';' before ':' token
  break:
   ^

vim +87 arch/x86/kernel/cpu/intel.c

81   */
82  if (c->x86 != 6)
83  return;
84  switch (c->x86_model) {
85  case INTEL_FAM6_XEON_PHI_KNL:
86  case INTEL_FAM6_XEON_PHI_KNM:
  > 87  break:
88  default:
89  return;
90  }

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


.config.gz
Description: application/gzip

Re: rtlwifi: rtl8192c_common: "BUG: KASAN: slab-out-of-bounds"

[Dmitry Osipenko]

Seems the problem is caused by rtl92c_dm_*() casting .priv to "struct
rtl_pci_priv", while it is "struct rtl_usb_priv".


-- 
Dmitry

Re: Potential issues (security and otherwise) with the current cgroup-bpf API

[Andy Lutomirski]

On Fri, Feb 3, 2017 at 3:21 PM, Alexei Starovoitov
 wrote:
> On Fri, Feb 03, 2017 at 01:07:39PM -0800, Andy Lutomirski wrote:
>>
>> Is there any plan to address this?  If not, I'll try to write that
>> patch this weekend.
>
> yes. I'm working on 'disallow program override' flag.
> It got stalled, because netns discussion got stalled.
> Later today will send a patch for dev_id+inode and
> will continue on the flag patch.
>

Would it make sense to try to document what your proposal does before
writing the code?  I don't yet see how to get semantics that are both
simple and sensible with a "disallow override" flag.

I *do* see how to get simple, sensible semantics with an approach
where all the programs in scope for the cgroup in question get called.
If needed, I can imagine a special "overridable" program that would
not be run if the socket in question is bound to a descendent cgroup
that also has an "overridable" program but would still let all the
normal hierarchical programs in scope get called.

Re: [RFC] [PATCH] audit: log module name on init_module

[Richard Guy Briggs]

On 2017-02-03 19:18, Paul Moore wrote:
> On Tue, Jan 31, 2017 at 3:02 PM, Richard Guy Briggs  wrote:
> > On 2017-01-31 11:07, Paul Moore wrote:
> >> On Tue, Jan 31, 2017 at 7:36 AM, Richard Guy Briggs  
> >> wrote:
> >> > On 2017-01-31 06:59, Paul Moore wrote:
> >> >> On Thu, Jan 26, 2017 at 4:21 PM, Richard Guy Briggs  
> >> >> wrote:
> >> >> > This adds a new auxiliary record MODULE_INIT to the SYSCALL event.
> >> >> >
> >> >> > We get finit_module for free since it made most sense to hook this in 
> >> >> > to
> >> >> > load_module().
> >> >> >
> >> >> > https://github.com/linux-audit/audit-kernel/issues/7
> >> >> > https://github.com/linux-audit/audit-kernel/wiki/RFE-Module-load-record-format
> >> >>
> >> >> Consistency nit: capitalize the first letter in the wiki page words
> >> >> (see the existing RFE pages)
> >> >>
> >> >> > Signed-off-by: Richard Guy Briggs 
> >> >> > ---
> >> >> >  include/linux/audit.h  |   12 
> >> >> >  include/uapi/linux/audit.h |1 +
> >> >> >  kernel/audit.h |3 +++
> >> >> >  kernel/auditsc.c   |   20 
> >> >> >  kernel/module.c|5 -
> >> >> >  5 files changed, 40 insertions(+), 1 deletions(-)
> >> >> >
> >> >> > diff --git a/include/linux/audit.h b/include/linux/audit.h
> >> >> > index 2be99b2..7bb23d5 100644
> >> >> > --- a/include/linux/audit.h
> >> >> > +++ b/include/linux/audit.h
> >> >> > @@ -360,6 +360,7 @@ extern int __audit_log_bprm_fcaps(struct 
> >> >> > linux_binprm *bprm,
> >> >> >   const struct cred *old);
> >> >> >  extern void __audit_log_capset(const struct cred *new, const struct 
> >> >> > cred *old);
> >> >> >  extern void __audit_mmap_fd(int fd, int flags);
> >> >> > +extern void __audit_module_init(char *name);
> >> >> >
> >> >> >  static inline void audit_ipc_obj(struct kern_ipc_perm *ipcp)
> >> >> >  {
> >> >> > @@ -450,6 +451,12 @@ static inline void audit_mmap_fd(int fd, int 
> >> >> > flags)
> >> >> > __audit_mmap_fd(fd, flags);
> >> >> >  }
> >> >> >
> >> >> > +static inline void audit_module_init(char *name)
> >> >> > +{
> >> >> > +   if (!audit_dummy_context())
> >> >> > +   __audit_module_init(name);
> >> >> > +}
> >> >>
> >> >> More on this below, but I was expecting the function above to named
> >> >> audit_log_kern_module(), or something similar.
> >> >
> >> > Ok fair enough, I had mis-understood your previous point.
> >>
> >> I probably could have been more specific too.
> >>
> >> > Any comment on the new record format?
> >>
> >> Not really, it's just the single field so it's kinda hard to have
> >> anything meaningful to say.  We obviously need to worry about the
> >> field name, but I'll let Steve speak to that as that likely means more
> >> to him than it does to me.  From my perspective, "name" seems
> >> perfectly reasonable, especially since it is in the context of a
> >> module specific record (no real worries about it being ambiguous).
> >
> > Do you see a need to include module initialization arguments?  It sounds
> > potentially useful to me, but also potentially bandwidth-consuming.  I
> > have a prototype patch to add the args as one encoded field.  Along with
> > the addition of this field is the concern about message lengths and
> > buffer allocations since it is an encoded field that would need twice
> > the length of the argment text to store in the message.
> 
> Argument filtering is surely going to be a mess, just look at the
> related execve() stuff.  Unless there is a hard requirement I say skip
> the argument logging for now, we can always add it later.

I *did* look at execve, which is why I was apprehensive.  :-/

> paul moore

- RGB

--
Richard Guy Briggs 
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635

Re: [PATCH] Documentation: devicetree: Add PHY no lane swap binding

[Andrew Lunn]

On Sat, Feb 04, 2017 at 04:47:47PM +0100, Lukasz Majewski wrote:
> Add the documentation to avoid PHY lane swapping. This is a boolean
> entry to notify the phy device drivers that the TX/RX lanes NO need

that the TX/RX lanes should not be swapped.

> to be swapped.
> The use case for this binding mostly happens after wrong HW
> configuration of PHY IC during bootstrap.
> 
> Signed-off-by: Lukasz Majewski 
> ---
>  Documentation/devicetree/bindings/net/phy.txt | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/net/phy.txt 
> b/Documentation/devicetree/bindings/net/phy.txt
> index fb5056b..5e25bc9 100644
> --- a/Documentation/devicetree/bindings/net/phy.txt
> +++ b/Documentation/devicetree/bindings/net/phy.txt
> @@ -39,6 +39,10 @@ Optional Properties:
>  - enet-phy-lane-swap: If set, indicates the PHY will swap the TX/RX lanes to
>compensate for the board being designed with the lanes swapped.
>  
> +- enet-phy-lane-no-swap: If set, indicates that PHY will disable swap of the
> +  TX/RX lanes. This binding allows the PHY to work correcly after e.g. wrong
> +  bootstrap configuration caused by issues in PCB layout design.
> +

We are leaving it undefined what it means if neither
enet-phy-lane-no-swap nor enet-phy-lane-swap properties are present.
Do we want to define this? That the swap should be left untouched by
the driver?

Andrew

Re: [PATCH net-next 6/6] net: dsa: introduce bridge notifier

[Andrew Lunn]

> +#define DSA_NOTIFIER_BRIDGE_JOIN 1
> +#define DSA_NOTIFIER_BRIDGE_LEAVE2

Hi Vivien

Is one notifier per event sufficient?

I've not looked at what actually needs to happen when a port joins a
bridge, in a D in DSA setup. Do we need to both enable the flow of
frames around the switch fabric, but also block those frames going out
ports they should not? Do we need a first notifier to put in place
the blocks, and then a second notifier to enable the flow of packets?

What we don't want is a window of time during the fabric setup as a
whole is inconsistent, and frames a leaking out ports they should not.

  Andrew

Re: [PATCH] sigaltstack: support SS_AUTODISARM for CONFIG_COMPAT

[Stas Sergeev]

04.02.2017 20:32, Andy Lutomirski пишет:

On Sat, Feb 4, 2017 at 4:07 AM, Stas Sergeev  wrote:

Currently SS_AUTODISARM is not supported in compatibility
mode, but does not return -EINVAL either. This makes dosemu
built with -m32 on x86_64 to crash. Also the kernel's sigaltstack
selftest fails if compiled with -m32.

This patch adds the needed support. It also improves the
selftest output a little (%i changed to %x for bitmasks).

Signed-off-by: Stas Sergeev 


Spurious newline.

Is this a problem? :)


   Also, should this be cc:stable?

It doesn't match the stable submission criteries AFAICS.
Can we declare it "obviously correct" and the problem
it fixes "critical"? If so, I'll need to strip the %i -> %x
change from it as it doesn't pass the stable submission
guidelines.


diff --git a/include/linux/compat.h b/include/linux/compat.h
index 6360939..d8535a4 100644
--- a/include/linux/compat.h
+++ b/include/linux/compat.h
@@ -711,8 +711,10 @@ int __compat_save_altstack(compat_stack_t __user *, 
unsigned long);
 compat_stack_t __user *__uss = uss; \
 struct task_struct *t = current; \
 put_user_ex(ptr_to_compat((void __user *)t->sas_ss_sp), 
&__uss->ss_sp); \
-   put_user_ex(sas_ss_flags(sp), &__uss->ss_flags); \
+   put_user_ex(t->sas_ss_flags, &__uss->ss_flags); \

Should the sas_ss_flags() helper be deleted, perhaps?  This code seems
a bit odd -- it no longer does the on_sig_stack(sp) check..  (It
matches the non-compat code.)


sas_ss_flags() is still used in sigaltstack() code and
in signal delivery code, so why do you think it should
be removed? It is needed to return the correct status
via sigaltstack() and for deciding whether to switch stacks.
But saving and restoring to/from uc_stack must be done
with raw flags. I don't think we need to check on_sig_stack()
when saving to uc_stack, or do we?

Re: Staging: speakup - syle fix permissions to octal

[Julia Lawall]

On Fri, 3 Feb 2017, Joe Perches wrote:

> (adding Julia Lawall)
>
> On Fri, 2017-02-03 at 20:44 -0800, Guenter Roeck wrote:
> > On Sat, Jan 28, 2017 at 07:05:09PM +1300, Derek Robson wrote:
> > > A style fix across whole driver.
> > > changed permissions to octal style, found using checkpatch
> > >
> > > Signed-off-by: Derek Robson 
> >
> > FWIW, I think changes like this are best done using coccinelle.
>
> I think checkpatch does it reasonably well.
>
> Julia?  Can coccinelle do this?
>
> I believe cocinelle doesn't handle the substitution
> and octal addition very well when multiple flags
> are used.

OK, finally received.  I think that Guenter's solution is a good one,
because the rule-writer knows better than Coccinelle what people find to
be intelligible.

julia

>
> > That ensures that the results can be reproduced and are well defined.
> > As it is, someone will have to check each line of your patches to ensure
> > that the conversion is correct.
> >
> > It would also ensure (hopefully) that we don't end up with constructs
> > such as
> >
> > > -#define USER_R (S_IFREG|S_IRUGO)
> > > -#define USER_W (S_IFREG|S_IWUGO)
> > > +#define USER_R (S_IFREG|0444)
> > > +#define USER_W (S_IFREG|0666)
> >
> > which really defeat the purpose of the whole exercise.
>
> Why do you think mixing file specific attributes
> with octal permissions is a bad thing?
>
> $ git log -1 f90774e1fd2700d
> commit f90774e1fd2700de4a6e0d62866d34a26c544bd0
> Author: Joe Perches 
> Date:   Tue Oct 11 13:51:47 2016 -0700
>
> checkpatch: look for symbolic permissions and suggest octal instead
>
> S_ uses should be avoided where octal is more intelligible.
>
> Linus didst say:
>
> : It's *much* easier to parse and understand the octal numbers, while the
> : symbolic macro names are just random line noise and hard as hell to
> : understand.  You really have to think about it.
> :
> : So we should rather go the other way: convert existing bad symbolic
> : permission bit macro use to just use the octal numbers.
> :
> : The symbolic names are good for the *other* bits (ie sticky bit, and the
> : inode mode _type_ numbers etc), but for the permission bits, the 
> symbolic
> : names are just insane crap.  Nobody sane should ever use them.  Not in 
> the
> : kernel, not in user space.
> 
> (http://lkml.kernel.org/r/ca+55afw5v23t-zvdzp-mmd_eyxf8wbafwwb59934fv7g21u...@mail.gmail.com)
>
> Link: 
> http://lkml.kernel.org/r/7232ef011d05a92f4caa86a5e9830d87966a2eaf.1470180926.git@perches.com
> Signed-off-by: Joe Perches 
> Cc: Linus Torvalds 
> Signed-off-by: Andrew Morton 
> Signed-off-by: Linus Torvalds 
>

[PATCH V2] audit: log module name on init_module

[Richard Guy Briggs]

This adds a new auxiliary record MODULE_INIT to the SYSCALL event.

We get finit_module for free since it made most sense to hook this in to
load_module().

https://github.com/linux-audit/audit-kernel/issues/7
https://github.com/linux-audit/audit-kernel/wiki/RFE-Module-load-record-format

Signed-off-by: Richard Guy Briggs 
---
 include/linux/audit.h  |   12 
 include/uapi/linux/audit.h |1 +
 kernel/audit.h |3 +++
 kernel/auditsc.c   |   14 ++
 kernel/module.c|5 -
 5 files changed, 34 insertions(+), 1 deletions(-)

diff --git a/include/linux/audit.h b/include/linux/audit.h
index 2be99b2..aba3a26 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -360,6 +360,7 @@ extern int __audit_log_bprm_fcaps(struct linux_binprm *bprm,
  const struct cred *old);
 extern void __audit_log_capset(const struct cred *new, const struct cred *old);
 extern void __audit_mmap_fd(int fd, int flags);
+extern void __audit_log_kern_module(char *name);
 
 static inline void audit_ipc_obj(struct kern_ipc_perm *ipcp)
 {
@@ -450,6 +451,12 @@ static inline void audit_mmap_fd(int fd, int flags)
__audit_mmap_fd(fd, flags);
 }
 
+static inline void audit_log_kern_module(char *name)
+{
+   if (!audit_dummy_context())
+   __audit_log_kern_module(name);
+}
+
 extern int audit_n_rules;
 extern int audit_signals;
 #else /* CONFIG_AUDITSYSCALL */
@@ -561,6 +568,11 @@ static inline void audit_log_capset(const struct cred *new,
 { }
 static inline void audit_mmap_fd(int fd, int flags)
 { }
+
+static inline void audit_log_kern_module(char *name)
+{
+}
+
 static inline void audit_ptrace(struct task_struct *t)
 { }
 #define audit_n_rules 0
diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
index 3f24110..3c02bb2 100644
--- a/include/uapi/linux/audit.h
+++ b/include/uapi/linux/audit.h
@@ -111,6 +111,7 @@
 #define AUDIT_PROCTITLE1327/* Proctitle emit event */
 #define AUDIT_FEATURE_CHANGE   1328/* audit log listing feature changes */
 #define AUDIT_REPLACE  1329/* Replace auditd if this packet 
unanswerd */
+#define AUDIT_KERN_MODULE  1330/* Kernel Module events */
 
 #define AUDIT_AVC  1400/* SE Linux avc denial or grant */
 #define AUDIT_SELINUX_ERR  1401/* Internal SE Linux Errors */
diff --git a/kernel/audit.h b/kernel/audit.h
index 431444c..144b7eb 100644
--- a/kernel/audit.h
+++ b/kernel/audit.h
@@ -199,6 +199,9 @@ struct audit_context {
struct {
int argc;
} execve;
+   struct {
+   char*name;
+   } module;
};
int fds[2];
struct audit_proctitle proctitle;
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index bb5f504..bde3aac 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -1268,6 +1268,11 @@ static void show_special(struct audit_context *context, 
int *call_panic)
case AUDIT_EXECVE: {
audit_log_execve_info(context, );
break; }
+   case AUDIT_KERN_MODULE:
+   audit_log_format(ab, "name=");
+   audit_log_untrustedstring(ab, context->module.name);
+   kfree(context->module.name);
+   break;
}
audit_log_end(ab);
 }
@@ -2368,6 +2373,15 @@ void __audit_mmap_fd(int fd, int flags)
context->type = AUDIT_MMAP;
 }
 
+void __audit_log_kern_module(char *name)
+{
+   struct audit_context *context = current->audit_context;
+
+   context->module.name = kmalloc(strlen(name) + 1, GFP_KERNEL);
+   strcpy(context->module.name, name);
+   context->type = AUDIT_KERN_MODULE;
+}
+
 static void audit_log_task(struct audit_buffer *ab)
 {
kuid_t auid, uid;
diff --git a/kernel/module.c b/kernel/module.c
index 529efae..5432dbe 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -61,6 +61,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "module-internal.h"
 
@@ -3593,6 +3594,8 @@ static int load_module(struct load_info *info, const char 
__user *uargs,
goto free_copy;
}
 
+   audit_log_kern_module(mod->name);
+
/* Reserve our place in the list. */
err = add_unformed_module(mod);
if (err)
@@ -3681,7 +3684,7 @@ static int load_module(struct load_info *info, const char 
__user *uargs,
   mod->name, after_dashes);
}
 
-   /* Link in to syfs. */
+   /* Link in to sysfs. */
err = mod_sysfs_setup(mod, info, mod->kp, mod->num_kp);
if (err < 0)
goto coming_cleanup;
-- 
1.7.1

[PATCH v2 2/5] regulator: core: have regulator_dev_lookup() return ERR_PTR-encoded errors

[Dmitry Torokhov]

Instead of returning both regulator_dev structure as return value and
auxiliary error code in 'ret' argument, let's switch to using ERR_PTR
encoded values. This makes it more obvious what is going on at call sites.

Also, let's not unlock the mutex in the middle of a loop, but rather break
out and have single unlock path.

Signed-off-by: Dmitry Torokhov 
---

V2: replaced "return r ? r : ERR_PTR(-ENODEV);" with expanded "if"
statement.

 drivers/regulator/core.c |   42 +++---
 1 file changed, 23 insertions(+), 19 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index b0ee068310c5..a39268bcab56 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1455,12 +1455,14 @@ static struct regulator_dev 
*regulator_lookup_by_name(const char *name)
  * lookup could succeed in the future.
  *
  * If successful, returns a struct regulator_dev that corresponds to the name
- * @supply and with the embedded struct device refcount incremented by one,
- * or NULL on failure. The refcount must be dropped by calling put_device().
+ * @supply and with the embedded struct device refcount incremented by one.
+ * The refcount must be dropped by calling put_device().
+ * On failure one of the following ERR-PTR-encoded values is returned:
+ * -ENODEV if lookup fails permanently, -EPROBE_DEFER if lookup could succeed
+ * in the future.
  */
 static struct regulator_dev *regulator_dev_lookup(struct device *dev,
- const char *supply,
- int *ret)
+ const char *supply)
 {
struct regulator_dev *r;
struct device_node *node;
@@ -1476,16 +1478,12 @@ static struct regulator_dev 
*regulator_dev_lookup(struct device *dev,
r = of_find_regulator_by_node(node);
if (r)
return r;
-   *ret = -EPROBE_DEFER;
-   return NULL;
-   } else {
+
/*
-* If we couldn't even get the node then it's
-* not just that the device didn't register
-* yet, there's no node and we'll never
-* succeed.
+* We have a node, but there is no device.
+* assume it has not registered yet.
 */
-   *ret = -ENODEV;
+   return ERR_PTR(-EPROBE_DEFER);
}
}
 
@@ -1506,13 +1504,16 @@ static struct regulator_dev 
*regulator_dev_lookup(struct device *dev,
 
if (strcmp(map->supply, supply) == 0 &&
get_device(>regulator->dev)) {
-   mutex_unlock(_list_mutex);
-   return map->regulator;
+   r = map->regulator;
+   break;
}
}
mutex_unlock(_list_mutex);
 
-   return NULL;
+   if (r)
+   return r;
+
+   return ERR_PTR(-ENODEV);
 }
 
 static int regulator_resolve_supply(struct regulator_dev *rdev)
@@ -1529,8 +1530,10 @@ static int regulator_resolve_supply(struct regulator_dev 
*rdev)
if (rdev->supply)
return 0;
 
-   r = regulator_dev_lookup(dev, rdev->supply_name, );
-   if (!r) {
+   r = regulator_dev_lookup(dev, rdev->supply_name);
+   if (IS_ERR(r)) {
+   ret = PTR_ERR(r);
+
if (ret == -ENODEV) {
/*
 * No supply was specified for this regulator and
@@ -1596,10 +1599,11 @@ static struct regulator *_regulator_get(struct device 
*dev, const char *id,
if (dev)
devname = dev_name(dev);
 
-   rdev = regulator_dev_lookup(dev, id, );
-   if (rdev)
+   rdev = regulator_dev_lookup(dev, id);
+   if (!IS_ERR(rdev))
goto found;
 
+   ret = PTR_ERR(rdev);
regulator = ERR_PTR(ret);
 
/*