Re: [PATCH] xen/pci: Bubble up error and fix description.

[Juergen Gross]

On 06/12/16 15:28, Konrad Rzeszutek Wilk wrote:
> The function is never called under PV guests, and only shows up
> when MSI (or MSI-X) cannot be allocated. Convert the message
> to include the error value.
> 
> Signed-off-by: Konrad Rzeszutek Wilk 

Reviewed-by: Juergen Gross 

> ---
>  arch/x86/pci/xen.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
> index bedfab9..e1fb269 100644
> --- a/arch/x86/pci/xen.c
> +++ b/arch/x86/pci/xen.c
> @@ -264,8 +264,8 @@ static int xen_hvm_setup_msi_irqs(struct pci_dev *dev, 
> int nvec, int type)
>   return 0;
>  
>  error:
> - dev_err(>dev,
> - "Xen PCI frontend has not registered MSI/MSI-X support!\n");
> + dev_err(>dev, "Failed to create MSI%s! ret=%d!\n",
> + type == PCI_CAP_ID_MSI ? "" : "-X", irq);
>   return irq;
>  }
>  
> 

Re: [PATCH 00/10] vtime: Delay cputime accounting to tick

[Frederic Weisbecker]

On Tue, Dec 06, 2016 at 03:20:55PM +1100, Paul Mackerras wrote:
> On Tue, Dec 06, 2016 at 03:32:13AM +0100, Frederic Weisbecker wrote:
> > This follows up Martin Schwidefsky's patch which propose to delay
> > cputime accounting to the tick in order to minimize the calls to
> > account_system_time() and alikes as these functions can carry quite some
> > overhead:
> > 
> > http://lkml.kernel.org/r/2016112728.13a0a3db@mschwide
> > 
> > The set includes Martin's patch, rebased on top of tip:sched/core and
> > latest s390 changes, and extends it to the other implementations of
> > CONFIG_VIRT_CPU_ACCOUNTING_NATIVE (powerpc and ia64) along with a few
> > core changes to adapt the whole.
> > 
> > Only built-tested though as I don't have access to any of these archs.
> 
> The patches look reasonable at a quick look.  I assume that to test
> them, we would want to run a guest in an overcommitted system, so as
> to get some steal time.  Do you have any more specific suggestions as
> to what to run as a test?  Just run some benchmark and see if the
> user/system/irq times look reasonable?  Or do you have something more
> quantitative?

So I guess we want to test both correctness and performance.

To check correctness I use two little programs, one that does a userspace
loop:

int main(int argc, char **argv)
{
while (1);
return 0;
}


And another that does a kernelspace loop. The latter
is not 100% kernel loop but spends most of its time in
kernel mode.

int main(int argc, char **argv)
{
void *addr = sbrk(0);

while (1) {
brk(addr + 4096);
brk(addr);
}
return 0;
}

Testing idle time just consist in checking the difference between two
cat /proc/stat in a given timelapse for an idle CPU.

For irqs it gets harder. There you just need to check if the numbers are
reasonable.

Now in order to measure performance, I think you need a workload that either
does a lot of guest/host switch or does a lot of IRQs. Maybe just something
that involves networking. Then comparing stime, hardirq and softirq should
show some better nummbers. In order to increase the effect, you can set a very
low HZ value (100?).

Thanks.

Re: FUSE: regression when clearing setuid bits on chown

[Miklos Szeredi]

On Tue, Dec 06, 2016 at 07:13:25AM -0500, Jeff Layton wrote:

> Should we be checking that the latest i_mode even has these bits before
> sending down the mode change?

Fixed, see updated patch below.

It also fixes a bug in the previous patch where in case of "-rwsrwSr-x" it would
clear the sgid bit without execute.

> 
> > > + attr->ia_mode = inode->i_mode & ~(S_ISUID | S_ISGID);
> > +   attr->ia_valid |= ATTR_MODE;
> > }
> > }
> > if (!attr->ia_valid)
> 
> Yeah that is quite a bit simpler.
> 
> That said...if either ATTR_KILL flag is set, then we're going to end up
> clearing both bits in the new mode. I guess that's ok since we always
> want to clear them both, and we'll only have one set and not the other
> if one of the mode bits was set and not the other.
> 
> But...I'm starting to wonder if we really need two flags for this. Would
> be be better served with a single ATTR_KILL_SUID_SGID flag? I wonder if
> that would simplify some of the logic in the whole setuid clearing
> morass.

Yeah, that would be a nice little cleanup.

Thanks,
Miklos
---

From: Miklos Szeredi 
Subject: fuse: fix clearing suid, sgid for chown()

Basically, the pjdfstests set the ownership of a file to 06555, and then
chowns it (as root) to a new uid/gid. Prior to commit a09f99eddef4 ("fuse:
fix killing s[ug]id in setattr"), fuse would send down a setattr with both
the uid/gid change and a new mode.  Now, it just sends down the uid/gid
change.

Technically this is NOTABUG, since POSIX doesn't _require_ that we clear
these bits for a privileged process, but Linux (wisely) has done that and I
think we don't want to change that behavior here.

This is caused by the use of should_remove_suid(), which will always return
0 when the process has CAP_FSETID.

In fact we really don't need to be calling should_remove_suid() at all,
since we've already been indicated that we should remove the suid, we just
don't want to use a (very) stale mode for that.

This patch should fix the above as well as simplify the logic.

Reported-by: Jeff Layton  
Signed-off-by: Miklos Szeredi 
Fixes: a09f99eddef4 ("fuse: fix killing s[ug]id in setattr")
Cc: 
---
 fs/fuse/dir.c |7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

--- a/fs/fuse/dir.c
+++ b/fs/fuse/dir.c
@@ -1739,8 +1739,6 @@ static int fuse_setattr(struct dentry *e
 * This should be done on write(), truncate() and chown().
 */
if (!fc->handle_killpriv) {
-   int kill;
-
/*
 * ia_mode calculation may have used stale i_mode.
 * Refresh and recalculate.
@@ -1750,12 +1748,11 @@ static int fuse_setattr(struct dentry *e
return ret;
 
attr->ia_mode = inode->i_mode;
-   kill = should_remove_suid(entry);
-   if (kill & ATTR_KILL_SUID) {
+   if (inode->i_mode & S_ISUID) {
attr->ia_valid |= ATTR_MODE;
attr->ia_mode &= ~S_ISUID;
}
-   if (kill & ATTR_KILL_SGID) {
+   if ((inode->i_mode & (S_ISGID | S_IXGRP)) == (S_ISGID | 
S_IXGRP)) {
attr->ia_valid |= ATTR_MODE;
attr->ia_mode &= ~S_ISGID;
}

Re: [PATCH] perf: check that objdump correctly works

[Arnaldo Carvalho de Melo]

Em Thu, Dec 01, 2016 at 01:04:35AM +0100, Alexis Berlemont escreveu:
> Hi,
> 
> In perf todo list, there was an entry regarding objdump:
> 
> * Check if the objdump call in annotate worked or not, providing a
>   popup window telling it didn't work, to test, just uninstall
>   binutils or otherwise remove objdump from the path.
> 
> The patch below tries to fulfill that point.

Thanks for working on this, will try and process it ASAP.

- Arnaldo
 
> Alexis.
> 
> Alexis Berlemont (1):
>   perf annotate: check that objdump correctly works
> 
>  tools/perf/util/annotate.c | 79 
> +-
>  tools/perf/util/annotate.h |  3 ++
>  2 files changed, 81 insertions(+), 1 deletion(-)
> 
> -- 
> 2.10.2

Re: FUSE: regression when clearing setuid bits on chown

[Jeff Layton]

On Tue, 2016-12-06 at 15:39 +0100, Miklos Szeredi wrote:
> On Tue, Dec 06, 2016 at 07:13:25AM -0500, Jeff Layton wrote:
> 
> > 
> > Should we be checking that the latest i_mode even has these bits before
> > sending down the mode change?
> 
> Fixed, see updated patch below.
> 
> It also fixes a bug in the previous patch where in case of "-rwsrwSr-x" it 
> would
> clear the sgid bit without execute.
> 
> > 
> > 
> > > 
> > > > 
> > > > +   attr->ia_mode = inode->i_mode & ~(S_ISUID | 
> > > > S_ISGID);
> > > + attr->ia_valid |= ATTR_MODE;
> > >   }
> > >   }
> > >   if (!attr->ia_valid)
> > 
> > Yeah that is quite a bit simpler.
> > 
> > That said...if either ATTR_KILL flag is set, then we're going to end up
> > clearing both bits in the new mode. I guess that's ok since we always
> > want to clear them both, and we'll only have one set and not the other
> > if one of the mode bits was set and not the other.
> > 
> > But...I'm starting to wonder if we really need two flags for this. Would
> > be be better served with a single ATTR_KILL_SUID_SGID flag? I wonder if
> > that would simplify some of the logic in the whole setuid clearing
> > morass.
> 
> Yeah, that would be a nice little cleanup.
> 
> Thanks,
> Miklos
> ---
> 
> From: Miklos Szeredi 
> Subject: fuse: fix clearing suid, sgid for chown()
> 
> Basically, the pjdfstests set the ownership of a file to 06555, and then
> chowns it (as root) to a new uid/gid. Prior to commit a09f99eddef4 ("fuse:
> fix killing s[ug]id in setattr"), fuse would send down a setattr with both
> the uid/gid change and a new mode.  Now, it just sends down the uid/gid
> change.
> 
> Technically this is NOTABUG, since POSIX doesn't _require_ that we clear
> these bits for a privileged process, but Linux (wisely) has done that and I
> think we don't want to change that behavior here.
> 
> This is caused by the use of should_remove_suid(), which will always return
> 0 when the process has CAP_FSETID.
> 
> In fact we really don't need to be calling should_remove_suid() at all,
> since we've already been indicated that we should remove the suid, we just
> don't want to use a (very) stale mode for that.
> 
> This patch should fix the above as well as simplify the logic.
> 
> Reported-by: Jeff Layton  
> Signed-off-by: Miklos Szeredi 
> Fixes: a09f99eddef4 ("fuse: fix killing s[ug]id in setattr")
> Cc: 
> ---
>  fs/fuse/dir.c |7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 
> --- a/fs/fuse/dir.c
> +++ b/fs/fuse/dir.c
> @@ -1739,8 +1739,6 @@ static int fuse_setattr(struct dentry *e
>* This should be done on write(), truncate() and chown().
>*/
>   if (!fc->handle_killpriv) {

One more thing too. I don't think we really want to monkey with the mode
at all if there is a request to set the mode already in the request. So
maybe this should be:

    if (!fc->handle_killpriv && !(attr->ia_mode & ATTR_MODE))

Granted that won't generally happen from normal process context, but we
could have knfsd in here too and I think that's possible from there.

> - int kill;
> -
>   /*
>* ia_mode calculation may have used stale i_mode.
>* Refresh and recalculate.
> @@ -1750,12 +1748,11 @@ static int fuse_setattr(struct dentry *e
>   return ret;
>  
>   attr->ia_mode = inode->i_mode;
> - kill = should_remove_suid(entry);
> - if (kill & ATTR_KILL_SUID) {
> + if (inode->i_mode & S_ISUID) {
>   attr->ia_valid |= ATTR_MODE;
>   attr->ia_mode &= ~S_ISUID;
>   }
> - if (kill & ATTR_KILL_SGID) {
> + if ((inode->i_mode & (S_ISGID | S_IXGRP)) == (S_ISGID | 
> S_IXGRP)) {
>   attr->ia_valid |= ATTR_MODE;
>   attr->ia_mode &= ~S_ISGID;
>   }

Looks good otherwise!
-- 
Jeff Layton 

Re: [PATCH v2 0/4] net: hix5hd2_gmac: add tx sg feature and reset/clock control signals

[David Miller]

From: Dongpo Li 
Date: Mon, 5 Dec 2016 21:27:57 +0800

> The "hix5hd2" is SoC name, add the generic ethernet driver compatible string.
> The "hisi-gemac-v1" is the basic version and "hisi-gemac-v2" adds
> the SG/TXCSUM/TSO/UFO features.
> This patch set only adds the SG(scatter-gather) driver for transmitting,
> the drivers of other features will be submitted later.
> 
> Add the MAC reset control signals and clock signals.
> We make these signals optional to be backward compatible with
> the hix5hd2 SoC.
> 
> Changes in v2:
> - Make the compatible string changes be a separate patch and
> the most specific string come first than the generic string
> as advised by Rob.
> - Make the MAC reset control signals and clock signals optional
> to be backward compatible with the hix5hd2 SoC.
> - Change the compatible string and give the clock a specific name
> in hix5hd2 dts file.

Series applied to net-next, thanks.

[PATCH 00/10] virtio: sparse fixes

[Michael S. Tsirkin]

I run latest sparse from git on virtio drivers
(turns out the version I had was rather outdated).
This patchset fixes a couple of bugs this uncovered,
and adds some annotations to make it sparse-clean.
In particular, endian-ness is often tricky,
so this patchset enabled endian-ness checks for sparse
builds.

Michael S. Tsirkin (10):
  virtio_console: drop unused config fields
  drm/virtio: fix endianness in primary_plane_update
  drm/virtio: fix lock context imbalance
  drm/virtio: annotate virtio_gpu_queue_ctrl_buffer_locked
  vhost: make interval tree static inline
  vhost: add missing __user annotations
  vsock/virtio: add a missing __le annotation
  vsock/virtio: mark an internal function static
  vsock/virtio: fix src/dst cid format
  virtio: enable endian checks for sparse builds

 drivers/char/virtio_console.c   | 14 +++---
 drivers/gpu/drm/virtio/virtgpu_plane.c  |  4 ++--
 drivers/gpu/drm/virtio/virtgpu_vq.c |  6 +-
 drivers/vhost/vhost.c   | 12 ++--
 net/vmw_vsock/virtio_transport.c|  2 +-
 net/vmw_vsock/virtio_transport_common.c | 16 
 drivers/block/Makefile  |  1 +
 drivers/char/Makefile   |  1 +
 drivers/char/hw_random/Makefile |  2 ++
 drivers/gpu/drm/virtio/Makefile |  1 +
 drivers/net/Makefile|  3 +++
 drivers/net/caif/Makefile   |  1 +
 drivers/rpmsg/Makefile  |  1 +
 drivers/s390/virtio/Makefile|  2 ++
 drivers/scsi/Makefile   |  1 +
 drivers/vhost/Makefile  |  1 +
 drivers/virtio/Makefile |  3 +++
 net/9p/Makefile |  1 +
 net/packet/Makefile |  1 +
 net/vmw_vsock/Makefile  |  2 ++
 20 files changed, 50 insertions(+), 25 deletions(-)

-- 
MST

[PATCH 09/10] vsock/virtio: fix src/dst cid format

[Michael S. Tsirkin]

These fields are 64 bit, using le32_to_cpu and friends
on these will not do the right thing.
Fix this up.

Cc: sta...@vger.kernel.org
Signed-off-by: Michael S. Tsirkin 
---
 net/vmw_vsock/virtio_transport_common.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/net/vmw_vsock/virtio_transport_common.c 
b/net/vmw_vsock/virtio_transport_common.c
index 6120384..22e99c4 100644
--- a/net/vmw_vsock/virtio_transport_common.c
+++ b/net/vmw_vsock/virtio_transport_common.c
@@ -606,9 +606,9 @@ static int virtio_transport_reset_no_sock(struct 
virtio_vsock_pkt *pkt)
return 0;
 
pkt = virtio_transport_alloc_pkt(, 0,
-le32_to_cpu(pkt->hdr.dst_cid),
+le64_to_cpu(pkt->hdr.dst_cid),
 le32_to_cpu(pkt->hdr.dst_port),
-le32_to_cpu(pkt->hdr.src_cid),
+le64_to_cpu(pkt->hdr.src_cid),
 le32_to_cpu(pkt->hdr.src_port));
if (!pkt)
return -ENOMEM;
@@ -823,7 +823,7 @@ virtio_transport_send_response(struct vsock_sock *vsk,
struct virtio_vsock_pkt_info info = {
.op = VIRTIO_VSOCK_OP_RESPONSE,
.type = VIRTIO_VSOCK_TYPE_STREAM,
-   .remote_cid = le32_to_cpu(pkt->hdr.src_cid),
+   .remote_cid = le64_to_cpu(pkt->hdr.src_cid),
.remote_port = le32_to_cpu(pkt->hdr.src_port),
.reply = true,
};
@@ -863,9 +863,9 @@ virtio_transport_recv_listen(struct sock *sk, struct 
virtio_vsock_pkt *pkt)
child->sk_state = SS_CONNECTED;
 
vchild = vsock_sk(child);
-   vsock_addr_init(>local_addr, le32_to_cpu(pkt->hdr.dst_cid),
+   vsock_addr_init(>local_addr, le64_to_cpu(pkt->hdr.dst_cid),
le32_to_cpu(pkt->hdr.dst_port));
-   vsock_addr_init(>remote_addr, le32_to_cpu(pkt->hdr.src_cid),
+   vsock_addr_init(>remote_addr, le64_to_cpu(pkt->hdr.src_cid),
le32_to_cpu(pkt->hdr.src_port));
 
vsock_insert_connected(vchild);
@@ -904,9 +904,9 @@ void virtio_transport_recv_pkt(struct virtio_vsock_pkt *pkt)
struct sock *sk;
bool space_available;
 
-   vsock_addr_init(, le32_to_cpu(pkt->hdr.src_cid),
+   vsock_addr_init(, le64_to_cpu(pkt->hdr.src_cid),
le32_to_cpu(pkt->hdr.src_port));
-   vsock_addr_init(, le32_to_cpu(pkt->hdr.dst_cid),
+   vsock_addr_init(, le64_to_cpu(pkt->hdr.dst_cid),
le32_to_cpu(pkt->hdr.dst_port));
 
trace_virtio_transport_recv_pkt(src.svm_cid, src.svm_port,
-- 
MST

[PATCH 01/10] virtio_console: drop unused config fields

[Michael S. Tsirkin]

struct ports_device includes a config field including the whole
virtio_console_config, but only max_nr_ports in there is ever updated or
used. The rest is unused and in fact does not even mirror the
device config. Drop everything except max_nr_ports,
saving some memory.

Signed-off-by: Michael S. Tsirkin 
---
 drivers/char/virtio_console.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index 5649234..8b00e79 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -152,8 +152,8 @@ struct ports_device {
spinlock_t c_ivq_lock;
spinlock_t c_ovq_lock;
 
-   /* The current config space is stored here */
-   struct virtio_console_config config;
+   /* max. number of ports this device can hold */
+   u32 max_nr_ports;
 
/* The virtio device we're associated with */
struct virtio_device *vdev;
@@ -1649,11 +1649,11 @@ static void handle_control_message(struct virtio_device 
*vdev,
break;
}
if (virtio32_to_cpu(vdev, cpkt->id) >=
-   portdev->config.max_nr_ports) {
+   portdev->max_nr_ports) {
dev_warn(>vdev->dev,
"Request for adding port with "
"out-of-bound id %u, max. supported id: %u\n",
-   cpkt->id, portdev->config.max_nr_ports - 1);
+   cpkt->id, portdev->max_nr_ports - 1);
break;
}
add_port(portdev, virtio32_to_cpu(vdev, cpkt->id));
@@ -1894,7 +1894,7 @@ static int init_vqs(struct ports_device *portdev)
u32 i, j, nr_ports, nr_queues;
int err;
 
-   nr_ports = portdev->config.max_nr_ports;
+   nr_ports = portdev->max_nr_ports;
nr_queues = use_multiport(portdev) ? (nr_ports + 1) * 2 : 2;
 
vqs = kmalloc(nr_queues * sizeof(struct virtqueue *), GFP_KERNEL);
@@ -2047,13 +2047,13 @@ static int virtcons_probe(struct virtio_device *vdev)
}
 
multiport = false;
-   portdev->config.max_nr_ports = 1;
+   portdev->max_nr_ports = 1;
 
/* Don't test MULTIPORT at all if we're rproc: not a valid feature! */
if (!is_rproc_serial(vdev) &&
virtio_cread_feature(vdev, VIRTIO_CONSOLE_F_MULTIPORT,
 struct virtio_console_config, max_nr_ports,
->config.max_nr_ports) == 0) {
+>max_nr_ports) == 0) {
multiport = true;
}
 
-- 
MST

[PATCH 10/10] virtio: enable endian checks for sparse builds

[Michael S. Tsirkin]

__CHECK_ENDIAN__ isn't on by default presumably because
it triggers too many sparse warnings for correct code.
But virtio is now clean of these warnings, and
we want to keep it this way - enable this for
sparse builds.

Signed-off-by: Michael S. Tsirkin 
---

It seems that there should be a better way to do it,
but this works too.

 drivers/block/Makefile  | 1 +
 drivers/char/Makefile   | 1 +
 drivers/char/hw_random/Makefile | 2 ++
 drivers/gpu/drm/virtio/Makefile | 1 +
 drivers/net/Makefile| 3 +++
 drivers/net/caif/Makefile   | 1 +
 drivers/rpmsg/Makefile  | 1 +
 drivers/s390/virtio/Makefile| 2 ++
 drivers/scsi/Makefile   | 1 +
 drivers/vhost/Makefile  | 1 +
 drivers/virtio/Makefile | 3 +++
 net/9p/Makefile | 1 +
 net/packet/Makefile | 1 +
 net/vmw_vsock/Makefile  | 2 ++
 14 files changed, 21 insertions(+)

diff --git a/drivers/block/Makefile b/drivers/block/Makefile
index 1e9661e..597481c 100644
--- a/drivers/block/Makefile
+++ b/drivers/block/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_BLK_DEV_OSD) += osdblk.o
 obj-$(CONFIG_BLK_DEV_UMEM) += umem.o
 obj-$(CONFIG_BLK_DEV_NBD)  += nbd.o
 obj-$(CONFIG_BLK_DEV_CRYPTOLOOP) += cryptoloop.o
+CFLAGS_virtio_blk.o += -D__CHECK_ENDIAN__
 obj-$(CONFIG_VIRTIO_BLK)   += virtio_blk.o
 
 obj-$(CONFIG_BLK_DEV_SX8)  += sx8.o
diff --git a/drivers/char/Makefile b/drivers/char/Makefile
index 6e6c244..a99467d 100644
--- a/drivers/char/Makefile
+++ b/drivers/char/Makefile
@@ -6,6 +6,7 @@ obj-y   += mem.o random.o
 obj-$(CONFIG_TTY_PRINTK)   += ttyprintk.o
 obj-y  += misc.o
 obj-$(CONFIG_ATARI_DSP56K) += dsp56k.o
+CFLAGS_virtio_console.o += -D__CHECK_ENDIAN__
 obj-$(CONFIG_VIRTIO_CONSOLE)   += virtio_console.o
 obj-$(CONFIG_RAW_DRIVER)   += raw.o
 obj-$(CONFIG_SGI_SNSC) += snsc.o snsc_event.o
diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
index 5f52b1e..a2b0931 100644
--- a/drivers/char/hw_random/Makefile
+++ b/drivers/char/hw_random/Makefile
@@ -17,6 +17,8 @@ obj-$(CONFIG_HW_RANDOM_IXP4XX) += ixp4xx-rng.o
 obj-$(CONFIG_HW_RANDOM_OMAP) += omap-rng.o
 obj-$(CONFIG_HW_RANDOM_OMAP3_ROM) += omap3-rom-rng.o
 obj-$(CONFIG_HW_RANDOM_PASEMI) += pasemi-rng.o
+CFLAGS_virtio_transport.o += -D__CHECK_ENDIAN__
+CFLAGS_virtio-rng.o += -D__CHECK_ENDIAN__
 obj-$(CONFIG_HW_RANDOM_VIRTIO) += virtio-rng.o
 obj-$(CONFIG_HW_RANDOM_TX4939) += tx4939-rng.o
 obj-$(CONFIG_HW_RANDOM_MXC_RNGA) += mxc-rnga.o
diff --git a/drivers/gpu/drm/virtio/Makefile b/drivers/gpu/drm/virtio/Makefile
index 3fb8eac..1162366 100644
--- a/drivers/gpu/drm/virtio/Makefile
+++ b/drivers/gpu/drm/virtio/Makefile
@@ -3,6 +3,7 @@
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
 
 ccflags-y := -Iinclude/drm
+ccflags-y += -D__CHECK_ENDIAN__
 
 virtio-gpu-y := virtgpu_drv.o virtgpu_kms.o virtgpu_drm_bus.o virtgpu_gem.o \
virtgpu_fb.o virtgpu_display.o virtgpu_vq.o virtgpu_ttm.o \
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 7336cbd..3f587de 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_EQUALIZER) += eql.o
 obj-$(CONFIG_IFB) += ifb.o
 obj-$(CONFIG_MACSEC) += macsec.o
 obj-$(CONFIG_MACVLAN) += macvlan.o
+CFLAGS_macvtap.o += -D__CHECK_ENDIAN__
 obj-$(CONFIG_MACVTAP) += macvtap.o
 obj-$(CONFIG_MII) += mii.o
 obj-$(CONFIG_MDIO) += mdio.o
@@ -20,8 +21,10 @@ obj-$(CONFIG_NETCONSOLE) += netconsole.o
 obj-$(CONFIG_PHYLIB) += phy/
 obj-$(CONFIG_RIONET) += rionet.o
 obj-$(CONFIG_NET_TEAM) += team/
+CFLAGS_tun.o += -D__CHECK_ENDIAN__
 obj-$(CONFIG_TUN) += tun.o
 obj-$(CONFIG_VETH) += veth.o
+CFLAGS_virtio_net.o += -D__CHECK_ENDIAN__
 obj-$(CONFIG_VIRTIO_NET) += virtio_net.o
 obj-$(CONFIG_VXLAN) += vxlan.o
 obj-$(CONFIG_GENEVE) += geneve.o
diff --git a/drivers/net/caif/Makefile b/drivers/net/caif/Makefile
index 9bbd453..d1a922c 100644
--- a/drivers/net/caif/Makefile
+++ b/drivers/net/caif/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_CAIF_HSI) += caif_hsi.o
 
 # Virtio interface
 obj-$(CONFIG_CAIF_VIRTIO) += caif_virtio.o
+CFLAGS_caif_virtio.o += -D__CHECK_ENDIAN__
diff --git a/drivers/rpmsg/Makefile b/drivers/rpmsg/Makefile
index ae9c913..23c8b66 100644
--- a/drivers/rpmsg/Makefile
+++ b/drivers/rpmsg/Makefile
@@ -1,3 +1,4 @@
 obj-$(CONFIG_RPMSG)+= rpmsg_core.o
 obj-$(CONFIG_RPMSG_QCOM_SMD)   += qcom_smd.o
 obj-$(CONFIG_RPMSG_VIRTIO) += virtio_rpmsg_bus.o
+CFLAGS_virtio_rpmsg_bus.o  += -D__CHECK_ENDIAN__
diff --git a/drivers/s390/virtio/Makefile b/drivers/s390/virtio/Makefile
index df40692..270ada5 100644
--- a/drivers/s390/virtio/Makefile
+++ b/drivers/s390/virtio/Makefile
@@ -6,6 +6,8 @@
 # it under the terms of the GNU General Public License (version 2 only)
 # as published by the Free Software Foundation.
 
+CFLAGS_virtio_ccw.o += -D__CHECK_ENDIAN__
+CFLAGS_kvm_virtio.o += -D__CHECK_ENDIAN__
 

[PATCH 03/10] drm/virtio: fix lock context imbalance

[Michael S. Tsirkin]

When virtio_gpu_free_vbufs exits due to list empty, it does not
drop the free_vbufs lock that it took.
list empty is not expected to happen anyway, but it can't hurt to fix
this and drop the lock.

Signed-off-by: Michael S. Tsirkin 
---
 drivers/gpu/drm/virtio/virtgpu_vq.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c 
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 5a0f8a7..2f0c2f9 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -109,8 +109,10 @@ void virtio_gpu_free_vbufs(struct virtio_gpu_device *vgdev)
 
spin_lock(>free_vbufs_lock);
for (i = 0; i < count; i++) {
-   if (WARN_ON(list_empty(>free_vbufs)))
+   if (WARN_ON(list_empty(>free_vbufs))) {
+   spin_unlock(>free_vbufs_lock);
return;
+   }
vbuf = list_first_entry(>free_vbufs,
struct virtio_gpu_vbuffer, list);
list_del(>list);
-- 
MST

Re: [PATCH 2/2] ASoC: atmel: tse850: rely on the ssc to register as a cpu dai by itself

[Rob Herring]

On Thu, Dec 01, 2016 at 12:59:09PM +0100, Peter Rosin wrote:
> Signed-off-by: Peter Rosin 
> ---
>  .../bindings/sound/axentia,tse850-pcm5142.txt  |  5 ++---
>  sound/soc/atmel/tse850-pcm5142.c   | 23 
> +++---
>  2 files changed, 5 insertions(+), 23 deletions(-)
> 
> diff --git 
> a/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt 
> b/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt
> index 5b9b38f578bb..fd12ecb35b5c 100644
> --- a/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt
> +++ b/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt
> @@ -2,8 +2,7 @@ Devicetree bindings for the Axentia TSE-850 audio complex
>  
>  Required properties:
>- compatible: "axentia,tse850-pcm5142"
> -  - axentia,ssc-controller: The phandle of the atmel SSC controller used as
> -cpu dai.
> +  - axentia,cpu-dai: The phandle of the cpu dai.

You are breaking backwards compatibility with old DTBs. You either need 
to not do that or explain in the commit why that is okay.

Rob

Re: [PATCH] drm/panel: simple: Check against num_timings when setting preferred for timing

[Thierry Reding]

On Mon, Oct 24, 2016 at 09:21:15PM +0800, Chen-Yu Tsai wrote:
> In the loop on .timings, we should check .num_timings to see if it's the
> only mode specified, not .num_modes, which should be used with .modes.
> 
> Fixes: cda553725c92 ("drm/panel: simple: Set appropriate mode type")
> Signed-off-by: Chen-Yu Tsai 
> ---
>  drivers/gpu/drm/panel/panel-simple.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied, thanks.

Thierry


signature.asc
Description: PGP signature

Re: [PATCH resend 0/8] irda: w83977af_ir: Neatening

[David Miller]

From: Joe Perches 
Date: Mon,  5 Dec 2016 11:00:40 -0800

> On top of Arnd's overly long udelay patch because I noticed a
> misindented block.

Joe, this doesn't apply cleanly to net-next, please respin.

Thank you.

Re: [PATCH v2] ACPI/IORT: Make dma masks set-up IORT specific

[Joerg Roedel]

On Tue, Dec 06, 2016 at 02:20:11PM +, Lorenzo Pieralisi wrote:
>  drivers/acpi/arm64/iort.c | 22 ++
>  drivers/acpi/scan.c   | 14 +-
>  include/linux/acpi_iort.h |  2 ++
>  3 files changed, 25 insertions(+), 13 deletions(-)

Applied, thanks.

Re: [PATCH] dts: sun8i-h3: correct UART3 pin definitions

[Maxime Ripard]

Hi Jorik,

On Sun, Dec 04, 2016 at 01:29:48PM +0100, jo...@kippendief.biz wrote:
> From: Jorik Jonker 
> 
> In a previous commit, I made a copy/paste error in the pinmux
> definitions of UART3: PG{13,14} instead of PA{13,14}. This commit takes
> care of that. I have tested this commit on Orange Pi PC and Orange Pi
> Plus, and it works for these boards.
> 
> Fixes: e3d11d3c45c5 ("dts: sun8i-h3: add pinmux definitions for
> UART2-3")
> 
> Signed-off-by: Jorik Jonker 

Thanks!

This looks like a late fix for the current release which comes to an
end. Can you resend it with a...@kernel.org as a recipient, so that the
ARM SoC maintainers can apply it directly?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH v3 0/2] perf: measure page fault duration in perf trace

[Arnaldo Carvalho de Melo]

Em Tue, Dec 06, 2016 at 12:40:06AM +0100, Alexis Berlemont escreveu:
> Alexis Berlemont wrote:
> > Hi,
> > 
> > Here is another attempt to make the perf-trace subcommand print the
> > page fault durations.
> > 
> > This solution is based on static tracepoints and it was necessary to
> > add 2 more tracepoints. I understood that adding tracepoints is a
> > questionable solution; I can try something else if someone has another
> > idea.
> >
> 
> Could you indicate me a way to improve these patches so as to move
> forward ?

I have to test this, and review PeterZ latest comment about it, to see
if all is well with him by now, Peter?

- Arnaldo
 
> Regards,
> 
> Alexis.
> 
> > Alexis.
> > 
> > Alexis Berlemont (2):
> >   perf, x86-mm: declare page-faults tracepoints like irq-vectors ones
> >   perf: add page fault duration measures in perf trace
> > 
> >  arch/x86/include/asm/trace/exceptions.h |  17 ++-
> >  arch/x86/mm/fault.c |  17 ++-
> >  tools/perf/Documentation/perf-trace.txt |   4 +-
> >  tools/perf/builtin-trace.c  | 231 
> > 
> >  4 files changed, 238 insertions(+), 31 deletions(-)
> > 
> > -- 
> > 2.10.2
> > 

Re: [PATCH v4 0/2] perf probe: add sdt probes arguments into the uprobe cmd string

[Arnaldo Carvalho de Melo]

Em Tue, Dec 06, 2016 at 12:42:45AM +0100, Alexis Berlemont escreveu:
> Alexis Berlemont wrote:
> > Hi Arnaldo,
> > 
> > Here is another patch set which fixes the issues you noticed.
> >
> 
> Could you indicate me a way to improve these patches so as to move
> forward ?

Masami, Hemant, are you guys ok with this? Can I have your Acked-by or
Tested-by, etc?

- Arnaldo
 
> Regards,
> 
> Alexis.
> 
> > Thank you.
> > 
> > Alexis.
> > 
> > Alexis Berlemont (2):
> >   perf sdt: add scanning of sdt probles arguments
> >   perf probe: add sdt probes arguments into the uprobe cmd string
> > 
> >  tools/perf/arch/x86/util/perf_regs.c |  18 
> >  tools/perf/util/perf_regs.c  |   4 +
> >  tools/perf/util/perf_regs.h  |  13 +++
> >  tools/perf/util/probe-file.c | 169 
> > ++-
> >  tools/perf/util/symbol-elf.c |  25 +-
> >  tools/perf/util/symbol.h |   1 +
> >  6 files changed, 224 insertions(+), 6 deletions(-)
> > 
> > -- 
> > 2.10.2
> > 

RE: [PATCH V2 15/15] hyperv: Add a function to detect if the device is a vmbus dev

[KY Srinivasan]

> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Tuesday, December 6, 2016 2:54 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; Haiyang Zhang
> 
> Subject: Re: [PATCH V2 15/15] hyperv: Add a function to detect if the device
> is a vmbus dev
> 
> On Sat, Dec 03, 2016 at 12:34:42PM -0800, k...@exchange.microsoft.com
> wrote:
> > From: Haiyang Zhang 
> >
> > On Hyper-V, every VF interface has a corresponding synthetic
> > interface managed by netvsc that share the same MAC
> > address. netvsc registers for netdev events to manage this
> > association. Currently we use the MAC address to manage this
> > association but going forward, we want to use a serial number that
> > the host publishes. To do this we need functionality similar
> > to dev_is_pci() for the vmbus devices. Implement such a function.
> >
> > This function will be used in subsequent patches to netvsc and in the
> > interest of eliminating cross tree dependencies, this patch is being
> > submitted first.
> 
> As I stated before, I want to see those patches before I will take this
> one...

Thanks Greg; we will send you the patches.

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

Re: [PATCH] serial: mxs-auart: support CMSPAR termios cflag

[Wolfgang Ocker]

On Tue, 2016-12-06 at 14:36 +0100, Stefan Wahren wrote:
> Hi Wolfgang,
> 
> > --- a/drivers/tty/serial/mxs-auart.c
> > +++ b/drivers/tty/serial/mxs-auart.c
> > @@ -95,6 +95,7 @@
> >  #define AUART_LINECTRL_BAUD_DIVFRAC_SHIFT  8
> >  #define AUART_LINECTRL_BAUD_DIVFRAC_MASK   0x3f00
> >  #define AUART_LINECTRL_BAUD_DIVFRAC(v) (((v) & 0x3f) << 8)
> > +#define AUART_LINECTRL_SPS (1 << 7)
> >  #define AUART_LINECTRL_WLEN_MASK   0x0060
> >  #define AUART_LINECTRL_WLEN(v) (((v) & 0x3) << 5)
> >  #define AUART_LINECTRL_FEN (1 << 4)
> > @@ -1010,10 +1011,12 @@ static void mxs_auart_settermios(struct uart_port
> > *u,
> > ctrl |= AUART_LINECTRL_WLEN(bm);
> > 
> > /* parity */
> > -   if (cflag & PARENB) {
> > +   if (cflag & (PARENB|CMSPAR)) {
> 
> does it make sense to enable stick parity in case parity is disabled?
> 
> The i.MX28 reference manual doesn't describe this case explicit.

Thanks Stefan for the hint. I think it's okay on the hardware side since the
PEN bit is always set and therefore it can not happen that SPS is set but not
PEN.

But on the termios side it makes sense to require PARENB to be set in c_cflag
if CMSPAR is requested.

So I will provide an updated patch soon.

Wolfgang

Re: [PATCH V3 01/11] megaraid_sas: Add new pci device Ids for SAS3.5 Generic Megaraid Controllers

[Tomas Henzl]

On 5.12.2016 17:27, Sasikumar Chandrasekaran wrote:
> This patch contains new pci device ids for SAS3.5 Generic Megaraid Controllers
>
> Signed-off-by: Sasikumar Chandrasekaran 
> ---
>  drivers/scsi/megaraid/megaraid_sas.h| 11 ++-
>  drivers/scsi/megaraid/megaraid_sas_base.c   | 20 ++-
>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 30 
> ++---
>  3 files changed, 52 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
> b/drivers/scsi/megaraid/megaraid_sas.h
> index 0d2625b..f24ce88 100644
> --- a/drivers/scsi/megaraid/megaraid_sas.h
> +++ b/drivers/scsi/megaraid/megaraid_sas.h
> @@ -56,6 +56,14 @@
>  #define PCI_DEVICE_ID_LSI_INTRUDER_240x00cf
>  #define PCI_DEVICE_ID_LSI_CUTLASS_52 0x0052
>  #define PCI_DEVICE_ID_LSI_CUTLASS_53 0x0053
> +#define PCI_DEVICE_ID_LSI_MECTOR 0x00D4
> +#define PCI_DEVICE_ID_LSI_VENTURA0x0014
> +#define PCI_DEVICE_ID_LSI_CRUSADER   0x0015

Nack.

This is not good, my test system panics instead of booting.
megaraid_sas :02:0e.0: RDPQ mode: (disabled)
BUG: unable to handle kernel paging request at 1e78
IP: [] megasas_issue_init_mfi+0x171/0x270 [megaraid_sas]


you are already having a device with same device value in your pci_table  
(PCI_DEVICE_ID_DELL_PERC5 is also 0x15), so fix the switch in  
megasas_probe_one.

Cheers,
tomash


(when sending new fixed versions, please add to the changed patches a text 
explaining
what was changed in which version, like so - 
www.spinics.net/lists/linux-scsi/msg102122.html)


>  
> @@ -5723,6 +5732,15 @@ static int megasas_probe_one(struct pci_dev *pdev,
>   instance->pdev = pdev;
>  
>   switch (instance->pdev->device) {
> + case PCI_DEVICE_ID_LSI_VENTURA:
> + case PCI_DEVICE_ID_LSI_MARLIN:
> + case PCI_DEVICE_ID_LSI_MECTOR:
> + case PCI_DEVICE_ID_LSI_CRUSADER:
> + case PCI_DEVICE_ID_LSI_HARPOON:
> + case PCI_DEVICE_ID_LSI_TOMCAT:
> + case PCI_DEVICE_ID_LSI_VENTURA_4PORT:
> + case PCI_DEVICE_ID_LSI_CRUSADER_4PORT:
> +  instance->is_ventura = true;
>   case PCI_DEVICE_ID_LSI_FUSION:
>   case PCI_DEVICE_ID_LSI_PLASMA:
>   case PCI_DEVICE_ID_LSI_INVADER:

[PATCH 1/1] mtd: spi-nor: improve macronix_quad_enable()

[Cyrille Pitchen]

The patch checks whether the Quad Enable bit is already set in the Status
Register. If so, the function exits immediately with a successful return
code.

Signed-off-by: Cyrille Pitchen 
Reviewed-by: Jagan Teki 
---
 drivers/mtd/spi-nor/spi-nor.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index da7cd69d4857..1fd32b991eb7 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -1216,6 +1216,9 @@ static int macronix_quad_enable(struct spi_nor *nor)
val = read_sr(nor);
if (val < 0)
return val;
+   if (val & SR_QUAD_EN_MX)
+   return 0;
+
write_enable(nor);
 
write_sr(nor, val | SR_QUAD_EN_MX);
-- 
2.7.4

Re: [PATCH v4 1/7] MFD: add bindings for STM32 General Purpose Timer driver

[Benjamin Gaignard]

[snip]
>
> I'm not going to push too hard, but I still thing "advanced-control"
> would suit better, since this is not *just* a timer.  In fact, the
> parent device (the MFD) doesn't have any timer functionality.  That's
> what "timer@0" does.
>
> The IP is called "Advanced Control" in the datasheet, no?

In datasheet only timers 1 and 8 are called "advanced-control" timers
Timers 2 to 5 and 9 to 14 are called "general purpose" timers.
Timers 6 and 7 are named "basic" timers.

I have ask around in ST and it seems that "general purpose" name was the
best to describe all the timers, so I would like to keep using it.

>
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-gptimer";
>> + reg = <0x4001 0x400>;
>> + clocks = < 0 160>;
>> + clock-names = "clk_int";
>> +
>> + pwm@0 {
>> + compatible = "st,stm32-pwm";
>> + pinctrl-0   = <_pins>;
>> + pinctrl-names   = "default";
>> + };
>> +
>> + timer@0 {
>> + compatible = "st,stm32-timer-trigger";
>> + reg = <0>;
>> + };
>> + };
>
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH] dts: sun8i-h3: correct UART3 pin definitions

[Maxime Ripard]

Hi Arnd, Olof,

On Tue, Dec 06, 2016 at 03:27:10PM +0100, jo...@kippendief.biz wrote:
> From: Jorik Jonker 
> 
> In a previous commit, I made a copy/paste error in the pinmux
> definitions of UART3: PG{13,14} instead of PA{13,14}. This commit takes
> care of that. I have tested this commit on Orange Pi PC and Orange Pi
> Plus, and it works for these boards.
> 
> Fixes: e3d11d3c45c5 ("dts: sun8i-h3: add pinmux definitions for
> UART2-3")
> 
> Signed-off-by: Jorik Jonker 

Could you please queue that patch for 4.9, with
Acked-by: Maxime Ripard 

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH] perf/x86: Fix exclusion of BTS and LBR for Goldmont

[Andi Kleen]

> > -   if (x86_pmu.lbr_pt_coexist)
> > +   if (what == x86_lbr_exclusive_pt && x86_pmu.lbr_pt_coexist)
> > return 0;
> 
> This would also allow PT & BTS at the same time, is that a supported
> configuration?

Yes it is on Goldmont.

-Andi

Re: [PATCH v3 1/2] ARM: dts: da850-lcdk: add the dumb-vga-dac node

[Sekhar Nori]

On Tuesday 06 December 2016 06:32 PM, Bartosz Golaszewski wrote:
> 2016-12-05 13:49 GMT+01:00 Tomi Valkeinen :
>> On 29/11/16 13:57, Bartosz Golaszewski wrote:
>>> Add the dumb-vga-dac node to the board DT together with corresponding
>>> ports and vga connector. This allows to retrieve the edid info from
>>> the display automatically.
>>>
>>
>> It's a bit difficult to follow this as there's been so many patches
>> going around. But I take the above is the LCDC node in the base da850
>> dtsi file? In that case, what is the display_in supposed to present?
>> It's the first node in the "display chain", so it has no input.
>>
>> Also, don't touch da850.dtsi here, just add the "ports" node in the
>> da850-lcdk.dts file.
>>
>> If the da850.dtsi has not been merged yet, I'd change the name of the
>> lcdc node to something else than "display". It's rather vague. If it's
>> named "lcdc", reading da850-lcdk.dts becomes much easier, as you'll
>> refer to "lcdc".
>>
> 
> The node is already in Sekhar's branch.

The node name should be 'display' as thats the ePAPR 1.1 generic name
recommendation. The label is also set to 'display' though and that can
be changed to lcdc.

A pre-patch to fix that before we modify the node further is welcome.

Thanks,
Sekhar

Re: [PATCH v2 04/11] locking/ww_mutex: Set use_ww_ctx even when locking without a context

[Peter Zijlstra]

On Thu, Dec 01, 2016 at 03:06:47PM +0100, Nicolai Hähnle wrote:
> +++ b/include/linux/ww_mutex.h
> @@ -222,11 +222,7 @@ extern int __must_check 
> __ww_mutex_lock_interruptible(struct ww_mutex *lock,
>   */
>  static inline int ww_mutex_lock(struct ww_mutex *lock, struct ww_acquire_ctx 
> *ctx)
>  {
> - if (ctx)
> - return __ww_mutex_lock(lock, ctx);
> -
> - mutex_lock(>base);
> - return 0;
> + return __ww_mutex_lock(lock, ctx);
>  }
>  
>  /**
> @@ -262,10 +258,7 @@ static inline int ww_mutex_lock(struct ww_mutex *lock, 
> struct ww_acquire_ctx *ct
>  static inline int __must_check ww_mutex_lock_interruptible(struct ww_mutex 
> *lock,
>  struct 
> ww_acquire_ctx *ctx)
>  {
> - if (ctx)
> - return __ww_mutex_lock_interruptible(lock, ctx);
> - else
> - return mutex_lock_interruptible(>base);
> + return __ww_mutex_lock_interruptible(lock, ctx);
>  }
>  

After this the entire point of __ww_mutex_lock*() is gone, right? Might
as well rename them to ww_mutex_lock() and remove this pointless
wrapper.

Re: [PATCH net-next] tools: hv: Enable network manager for bonding scripts on RHEL

[David Miller]

From: Haiyang Zhang 
Date: Fri,  2 Dec 2016 15:55:38 -0800

> From: Haiyang Zhang 
> 
> We found network manager is necessary on RHEL to make the synthetic
> NIC, VF NIC bonding operations handled automatically. So, enabling
> network manager here.
> 
> Signed-off-by: Haiyang Zhang 
> Reviewed-by: K. Y. Srinivasan 

Applied, thanks.

Re: [PATCH] vfio/pci: Support error recovery

[Alex Williamson]

On Tue, 6 Dec 2016 14:11:03 +0800
Cao jin  wrote:

> On 12/06/2016 12:17 AM, Alex Williamson wrote:
> > On Mon, 5 Dec 2016 13:52:03 +0800
> > Cao jin  wrote:
> >   
> >> On 12/04/2016 11:30 PM, Alex Williamson wrote:  
> >>> On Sun, 4 Dec 2016 20:16:42 +0800
> >>> Cao jin  wrote:
> >>> 
>  On 12/01/2016 10:55 PM, Alex Williamson wrote:
> > On Thu, 1 Dec 2016 21:40:00 +0800  
> 
> >>> If an AER fault occurs and the user doesn't do a reset, what
> >>> happens when that device is released and a host driver tries to make
> >>> use of it?  The user makes no commitment to do a reset and there are
> >>> only limited configurations where we even allow the user to perform a
> >>> reset.
> >>> 
> >>
> >> Limited? Do you mean the things __pci_dev_reset() can do?  
> >
> > I mean that there are significant device and guest configuration
> > restrictions in order to support AER.  For instance, all the functions
> > of the slot need to appear in a PCI-e topology in the guest with all
> > the functions in the right place such that a guest bus reset translates
> > into a host bus reset.  The physical functions cannot be split between
> > guests even if IOMMU isolation would otherwise allow it.  The user
> > needs to explicitly enable AER support for the devices.  A VM need to
> > be specifically configured for AER support in order to set any sort of
> > expectations of a guest directed bus reset, let alone a guarantee that
> > it will happen.  So all the existing VMs, where functions are split
> > between guests, or the topology isn't exactly right, or AER isn't
> > enabled see a regression from the above change as the device is no
> > longer reset.
> >   
> 
>  I am not clear why set these restrictions in the current design. I take
>  a glance at older versions of qemu's patchset, their thoughts is:
>  translate a guest bus reset into a host bus reset(Which is
>  unreasonable[*] to me). And I guess, that's the *cause* of these
>  restrictions?  Is there any other stories behind these restrictions?
> 
>  [*] In physical world, set bridge's secondary bus reset would send
>  hot-reset TLP to all functions below, trigger every device's reset
>  separately. Emulated device should behave the same, means just using
>  each device's DeviceClass->reset method.
> >>>
> >>> Are you trying to say that an FLR is equivalent to a link reset?
> >>
> >> No.  Look at old versions patchset, there is one names "vote the
> >> function 0 to do host bus reset when aer occurred"[1], that is what I
> >> called "translate guest link reset to host link reset", and what I think
> >> unreasonable(and I think it also does it wrongly).  So in v10 version of
> >> mine, I dropped it.
> >>
> >> [1]https://lists.gnu.org/archive/html/qemu-devel/2016-05/msg02987.html
> >>
> >> If "translate guest link reset to host link reset" is right, I can
> >> understand these restrictions[2][3].
> >>
> >> [2]. All physical functions in a single card must be assigned to the VM
> >>  with AER enabled on each and configured on the same virtual bus.
> >> [3]. Don't place other devices under the virtual bus in [2], no matter
> >>  physical, emulated, or paravirtual, even if other device
> >>  supporting AER signaling
> >>
> >> Certain device's FLR calls its DeviceClass->reset method; link reset
> >> calls DeviceClass->reset of each device which on the bus. So, apparently
> >> they have difference.  But if there is only 1 vfio-pci device under the
> >> virtual pci bus,  I think FLR can be equivalent to a link reset, right?  
> > 
> > No.  An FLR resets the device while a secondary bus reset does a reset
> > of the link and the device.  AER errors are sometimes issues with the
> > link, not the device.  If we were to perform only an FLR, we're not
> > performing the same reset as would be done on bare metal.
> >
> 
> Thanks for you explanation, it does helps, except the last sentence, I
> think I understand it now: fatal error implies there may be link issue
> exists(pci express spec: 6.2.2.2.1), so, should do link reset for fatal
> error(that is what and why aer core does). And so, in patch[1] above,
> qemu does a link reset when seeing secondary bus reset bit of virtual
> bus got set. is it right?

QEMU is only going to do a bus reset if the guest is participating in
AER recovery AND QEMU supports AER recovery AND the guest topology
configuration allows the guest bus reset to induce a host bus reset.
vfio does not know that QEMU is the user and cannot assume the user
will perform a bus reset.  We need to give the user the ability to
recover from an AER, but not rely on the user to do so.  We cannot
assume the user's intention or capabilities.  Thanks,

Alex

Re: [PATCH V2 03/13] perf/x86: output sampling overhead

[Peter Zijlstra]

On Tue, Dec 06, 2016 at 03:02:20PM +, Liang, Kan wrote:
> 
> 
> > On Fri, Dec 02, 2016 at 04:19:11PM -0500, kan.li...@intel.com wrote:
> > > From: Kan Liang 
> > >
> > > On x86, NMI handler is the most important part which brings overhead
> > > for sampling. Adding a pmu specific overhead type
> > > PERF_PMU_SAMPLE_OVERHEAD for it.
> > >
> > > For other architectures which may don't have NMI, the overhead type
> > > can be reused.
> > >
> > > Signed-off-by: Kan Liang 
> > > ---
> > >  arch/x86/events/core.c  | 17 -
> > >  arch/x86/events/perf_event.h|  2 ++
> > >  include/uapi/linux/perf_event.h |  1 +
> > >  3 files changed, 19 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c index
> > > 9d4bf3a..de40f96 100644
> > > --- a/arch/x86/events/core.c
> > > +++ b/arch/x86/events/core.c
> > > @@ -1397,6 +1397,9 @@ static void x86_pmu_del(struct perf_event
> > > *event, int flags)
> > >
> > >   perf_event_update_userpage(event);
> > >
> > > + if ((flags & PERF_EF_LOG) && cpuc->nmi_overhead.nr)
> > > + perf_log_overhead(event, PERF_PMU_SAMPLE_OVERHEAD,
> > > +>nmi_overhead);
> > > +
> > >  do_del:
> > >   if (x86_pmu.del) {
> > >   /*
> > 
> > That's not at all mentioned in the changelog, and it clearly isn't
> > nmi_overhead.
> 
> Here it only records the overhead, not calculate.

It doesn't record anything, it generates the output. And it doesn't
explain why that needs to be in pmu::del(), in general that's a horrible
thing to do.

Re: Tearing down DMA transfer setup after DMA client has finished

[Mason]

On 06/12/2016 14:14, Måns Rullgård wrote:

> Mason wrote:
> 
>> On 06/12/2016 06:12, Vinod Koul wrote:
>>
>>> On Tue, Nov 29, 2016 at 07:25:02PM +0100, Mason wrote:
>>>
 Is there a way to write a driver within the existing framework?
>>>
>>> I think so, looking back at comments from Russell, I do tend to agree with
>>> that. Is there a specific reason why sbox can't be tied to alloc and free
>>> channels?
>>
>> Here's a recap of the situation.
>>
>> The "SBOX+MBUS" HW is used in several iterations of the tango SoC:
>>
>> tango3
>>   2 memory channels available
>>   6 devices ("clients"?) may request an MBUS channel
>>
>> tango4 (one more channel)
>>   3 memory channels available
>>   7 devices may request an MBUS channel :
>> NFC0, NFC1, SATA0, SATA1, memcpy, (IDE0, IDE1)
>>
>> Notes:
>> The current NFC driver supports only one controller.
> 
> I consider that a bug.

Meh. The two controller blocks share the I/O pins to the outside
world, so it's not possible to have two concurrent accesses.
Moreover, the current NAND framework does not currently support
such a setup. (I discussed this with the maintainer.)


>> IDE is mostly obsolete at this point.
>>
>> tango5 (SATA gets own dedicated MBUS channel pair)
>>   3 memory channels available
>>   5 devices may request an MBUS channel :
>> NFC0, NFC1, memcpy, (IDE0, IDE1)
> 
> Some of the chip variants can also use this DMA engine for PCI devices.

Note: PCI support was dropped with tango4.


>> If I understand the current DMA driver (written by Mans), client
>> drivers are instructed to use a specific channel in the DT, and
>> the DMA driver muxes access to that channel.
> 
> Almost.  The DT indicates the sbox ID of each device.  The driver
> multiplexes requests from all devices across all channels.

Thanks for pointing that out. I misremembered the DT.
So a client's DT node specifies the client's SBOX port.
And the DMA node specifies all available MBUS channels.

So when an interrupt fires, the DMA driver (re)uses that
channel for the next transfer in line?


>> The DMA driver manages a per-channel queue of outstanding DMA transfer
>> requests, and a new transfer is started from within the DMA ISR
>> (modulo the fact that the interrupt does not signal completion of the
>> transfer, as explained else-thread).
> 
> We need to somehow let the device driver signal the dma driver when a
> transfer has been fully completed.  Currently the only post-transfer
> interaction between the dma engine and the device driver is through the
> descriptor callback, which is not suitable for this purpose.

The callback is called from vchan_complete() right?
Is that running from interrupt context?

What's the relationship between vchan_complete() and
tangox_dma_irq() -- does one call the other? Are they
asynchronous?


> This is starting to look like one of those situations where someone just
> needs to implement a solution, or we'll be forever bickering about
> hypotheticals.

I can give that a shot (if you're busy with real work).


>> What you're proposing, Vinod, is to make a channel exclusive
>> to a driver, as long as the driver has not explicitly released
>> the channel, via dma_release_channel(), right?
> 
> That's not going to work very well.  Device drivers typically request
> dma channels in their probe functions or when the device is opened.
> This means that reserving one of the few channels there will inevitably
> make some other device fail to operate.

This is true for tango3. Less so for tango4. And no longer
an issue for tango5.


> Doing a request/release per transfer really doesn't fit with the
> intended usage of the dmaengine api.  For starters, what should a driver
> do if all the channels are currently busy?

Why can't we queue channel requests the same way we queue
transfer requests?


> Since the hardware actually does support multiplexing the dma channels,
> I think it would be misguided to deliberately cripple the software
> support in order to shoehorn it into an incomplete model of how hardware
> ought to work.  While I agree it would be nicer if all hardware actually
> did work that way, this isn't the reality we're living in.

I agree with you that it would be nice to have a general solution,
since the HW supports it.

Regards.

Re: [PATCH v2 04/11] locking/ww_mutex: Set use_ww_ctx even when locking without a context

[Peter Zijlstra]

On Thu, Dec 01, 2016 at 03:06:47PM +0100, Nicolai Hähnle wrote:

> @@ -640,10 +640,11 @@ __mutex_lock_common(struct mutex *lock, long state, 
> unsigned int subclass,
>   struct mutex_waiter waiter;
>   unsigned long flags;
>   bool first = false;
> - struct ww_mutex *ww;
>   int ret;
>  
> - if (use_ww_ctx) {
> + if (use_ww_ctx && ww_ctx) {
> + struct ww_mutex *ww;
> +
>   ww = container_of(lock, struct ww_mutex, base);
>   if (unlikely(ww_ctx == READ_ONCE(ww->ctx)))
>   return -EALREADY;

So I don't see the point of removing *ww from the function scope, we can
still compute that container_of() even if !ww_ctx, right? That would
safe a ton of churn below, adding all those struct ww_mutex declarations
and container_of() casts.

(and note that the container_of() is a fancy NO-OP because base is the
first member).

> @@ -656,8 +657,12 @@ __mutex_lock_common(struct mutex *lock, long state, 
> unsigned int subclass,
>   mutex_optimistic_spin(lock, ww_ctx, use_ww_ctx, false)) {
>   /* got the lock, yay! */
>   lock_acquired(>dep_map, ip);
> - if (use_ww_ctx)
> + if (use_ww_ctx && ww_ctx) {
> + struct ww_mutex *ww;
> +
> + ww = container_of(lock, struct ww_mutex, base);
>   ww_mutex_set_context_fastpath(ww, ww_ctx);
> + }
>   preempt_enable();
>   return 0;
>   }
> @@ -702,7 +707,7 @@ __mutex_lock_common(struct mutex *lock, long state, 
> unsigned int subclass,
>   goto err;
>   }
>  
> - if (use_ww_ctx && ww_ctx->acquired > 0) {
> + if (use_ww_ctx && ww_ctx && ww_ctx->acquired > 0) {
>   ret = __ww_mutex_lock_check_stamp(lock, ww_ctx);
>   if (ret)
>   goto err;
> @@ -742,8 +747,12 @@ __mutex_lock_common(struct mutex *lock, long state, 
> unsigned int subclass,
>   /* got the lock - cleanup and rejoice! */
>   lock_acquired(>dep_map, ip);
>  
> - if (use_ww_ctx)
> + if (use_ww_ctx && ww_ctx) {
> + struct ww_mutex *ww;
> +
> + ww = container_of(lock, struct ww_mutex, base);
>   ww_mutex_set_context_slowpath(ww, ww_ctx);
> + }
>  
>   spin_unlock_mutex(>wait_lock, flags);
>   preempt_enable();

All that then reverts to:

-   if (use_ww_ctx)
+   if (use_ww_ctx && ww_ctx)

Re: scsi: use-after-free in bio_copy_from_iter

[Dmitry Vyukov]

On Tue, Dec 6, 2016 at 4:38 PM, Johannes Thumshirn  wrote:
> On Tue, Dec 06, 2016 at 10:43:57AM +0100, Dmitry Vyukov wrote:
>> On Tue, Dec 6, 2016 at 10:32 AM, Johannes Thumshirn  
>> wrote:
>> > On Mon, Dec 05, 2016 at 07:03:39PM +, Al Viro wrote:
>> >> On Mon, Dec 05, 2016 at 04:17:53PM +0100, Johannes Thumshirn wrote:
>> >> > 633 hp = >header;
>> >> > [...]
>> >> > 646 hp->dxferp = (char __user *)buf + cmd_size;
>> >>
>> >> > So the memory for hp->dxferp comes from:
>> >> > 633 hp = >header;
>> >>
>> >> 
>> >>
>> >> > >From my debug instrumentation I see that the dxferp ends up in the
>> >> > iovec_iter's kvec->iov_base and the faulting address is always dxferp + 
>> >> > n *
>> >> > 4k with n in [1, 16] (and we're copying 16 4k pages from the iovec into 
>> >> > the
>> >> > bio).
>> >>
>> >> _Address_ of hp->dxferp comes from that assignment; the value is 'buf'
>> >> argument of sg_write() + small offset.  In this case, it should point
>> >> inside a pipe buffer, which is, indeed, at a kernel address.  Who'd
>> >> allocated srp is irrelevant.
>> >
>> > Yes I realized that as well when I had enough distance between me and the
>> > code...
>> >
>> >>
>> >> And if you end up dereferencing more than one page worth there, you do 
>> >> have
>> >> a problem - pipe buffers are not going to be that large.  Could you slap
>> >>   WARN_ON((size_t)input_size > count);
>> >> right after the calculation of input_size in sg_write() and see if it 
>> >> triggers
>> >> on your reproducer?
>> >
>> > I did and it didn't trigger. What triggers is (as expected) a
>> > WARN_ON((size_t)mxsize > count);
>> > We have count at 80 and mxsize (which ends in hp->dxfer_len) at 65499. But 
>> > the
>> > 65499 bytes are the len of the data we're suppost to be copying in via the
>> > iov. I'm still rather confused what's happening here, sorry.
>>
>>
>> I think the critical piece here is some kind of race or timing
>> condition. Note that the test program executes all of
>> memfd_create/write/open/sendfile twice. Second time the calls race
>> with each other, but they also can race with the first execution of
>> the calls.
>
> FWIW I've just run the reproducer once instead of looping it to check how it
> would normally behave and it bailes out at:
>
> 604 if (count < (SZ_SG_HEADER + 6))
> 605 return -EIO;/* The minimum scsi command length is 6 
> bytes. */
>
> That means, weren't going down the copy_form_iter() road at all. Usually, but
> sometimes we do. And then we try to copy 16 pages from the pipe buffer (is
> this correct?).
> The reproducer does: sendfile("/dev/sg0", memfd, offset_in_memfd, 0x1);
>
> I don't see how we get there? Could it be random data from the mmap() we point
> the memfd to?
>
> This bug is confusing to be honest.


Where does this count come from? What address in the user program? Is
it 0x20012fxx?
One possibility for non-deterministically changing inputs is that this part:

  case 2:
NONFAILING(*(uint32_t*)0x20012fd8 = (uint32_t)0x28);
NONFAILING(*(uint32_t*)0x20012fdc = (uint32_t)0x);
NONFAILING(*(uint64_t*)0x20012fe0 = (uint64_t)0x0);
NONFAILING(*(uint64_t*)0x20012fe8 = (uint64_t)0x993f);
NONFAILING(*(uint64_t*)0x20012ff0 = (uint64_t)0xa8b);
NONFAILING(*(uint32_t*)0x20012ff8 = (uint32_t)0xff);
r[9] = syscall(__NR_write, r[2], 0x20012fd8ul, 0x28ul, 0, 0,
   0, 0, 0, 0);

runs concurrently with this part:

  case 0:
r[0] =
syscall(__NR_mmap, 0x2000ul, 0x13000ul, 0x3ul,
0x32ul, 0xul, 0x0ul, 0, 0, 0);

So all of the input data to the write, or a subset of the input data,
can be zeros.

[PATCH 05/10] vhost: make interval tree static inline

[Michael S. Tsirkin]

vhost_umem_interval_tree is only used locally within vhost.c, mark it
static. As some functions generated go unused, this triggers warnings
unless we also mark it inline.

Signed-off-by: Michael S. Tsirkin 
---
 drivers/vhost/vhost.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index c6f2d89..7331ef3 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -49,7 +49,7 @@ enum {
 
 INTERVAL_TREE_DEFINE(struct vhost_umem_node,
 rb, __u64, __subtree_last,
-START, LAST, , vhost_umem_interval_tree);
+START, LAST, static inline, vhost_umem_interval_tree);
 
 #ifdef CONFIG_VHOST_CROSS_ENDIAN_LEGACY
 static void vhost_disable_cross_endian(struct vhost_virtqueue *vq)
-- 
MST

Re: [PATCH] uapi glibc compat: fix outer guard of net device flags enum

[David Miller]

From: Mikko Rapeli 
Date: Mon, 5 Dec 2016 19:34:02 +0200

> On Sat, Dec 03, 2016 at 05:31:45PM +0100, Jonas Gorski wrote:
>> Fix a wrong condition preventing the higher net device flags
>> IFF_LOWER_UP etc to be defined if net/if.h is included before
>> linux/if.h.
>> 
>> The comment makes it clear the intention was to allow partial
>> definition with either parts.
>> 
>> This fixes compilation of userspace programs trying to use
>> IFF_LOWER_UP, IFF_DORMANT or IFF_ECHO.
>> 
>> Fixes: 4a91cb61bb99 ("uapi glibc compat: fix compile errors when glibc 
>> net/if.h included before linux/if.h")
>> Signed-off-by: Jonas Gorski 
> 
> Reviewed-by: Mikko Rapeli 
> 
> Yep, sorry about the logic error. Thanks for the fix!

Applied.

Jonas, please properly put net...@vger.kernel.org on the CC: for networking
patches in the future.

Thank you.

Re: [PATCH v3 4/9] bus: fsl-mc: dpio: add frame descriptor and scatter/gather APIs

[Laurentiu Tudor]

On 12/05/2016 10:52 PM, Dan Carpenter wrote:
> On Fri, Dec 02, 2016 at 12:12:14PM +, Laurentiu Tudor wrote:
>>> +static inline bool dpaa2_sg_is_final(const struct dpaa2_sg_entry *sg)
>>> +{
>>> +   return !!(le16_to_cpu(sg->format_offset) >> SG_FINAL_FLAG_SHIFT);
>>
>> In other places in this file we don't use the '!!' to convert to bool. Maybe 
>> we should drop it here too.
> 
> I like the explicit "!!".  I think it makes the code more obvious since
> all the information is on one line.
> 

That's fine too, as long as we're doing it consistently in all the places.

---
Best Regards, Laurentiu

Re: usb/gadget: use-after-free in gadgetfs_setup

[Andrey Konovalov]

On Tue, Dec 6, 2016 at 1:28 PM, Andrey Konovalov  wrote:
> On Mon, Dec 5, 2016 at 8:31 PM, Alan Stern  wrote:
>> On Mon, 5 Dec 2016, Andrey Konovalov wrote:
>>
>>> Hi!
>>>
>>> I've got the following error report while running the syzkaller fuzzer.
>>>
>>> On commit 3c49de52d5647cda8b42c4255cf8a29d1e22eff5 (Dec 2).
>>>
>>> BUG: KASAN: use-after-free in gadgetfs_setup+0x208a/0x20e0 at addr
>>> 88003dfe5bf2
>>> Read of size 2 by task syz-executor0/22994
>>> CPU: 3 PID: 22994 Comm: syz-executor0 Not tainted 4.9.0-rc7+ #16
>>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>>>  88006df06a18 81f96aba e0528500 11000dbe0cd6
>>>  ed000dbe0cce 88006df068f0 41b58ab3 8598b4c8
>>>  81f96828 11000dbe0ccd 88006df06708 88006df06748
>>> Call Trace:
>>>   [  201.343209]  [< inline >] __dump_stack lib/dump_stack.c:15
>>>   [  201.343209]  [] dump_stack+0x292/0x398
>>> lib/dump_stack.c:51
>>>  [] kasan_object_err+0x1c/0x70 mm/kasan/report.c:159
>>>  [< inline >] print_address_description mm/kasan/report.c:197
>>>  [] kasan_report_error+0x1f0/0x4e0 mm/kasan/report.c:286
>>>  [< inline >] kasan_report mm/kasan/report.c:306
>>>  [] __asan_report_load_n_noabort+0x3a/0x40
>>> mm/kasan/report.c:337
>>>  [< inline >] config_buf drivers/usb/gadget/legacy/inode.c:1298
>>>  [] gadgetfs_setup+0x208a/0x20e0
>>> drivers/usb/gadget/legacy/inode.c:1368
>>>  [] dummy_timer+0x11f0/0x36d0
>>> drivers/usb/gadget/udc/dummy_hcd.c:1858
>>>  [] call_timer_fn+0x241/0x800 kernel/time/timer.c:1308
>>>  [< inline >] expire_timers kernel/time/timer.c:1348
>>>  [] __run_timers+0xa06/0xec0 kernel/time/timer.c:1641
>>>  [] run_timer_softirq+0x21/0x80 kernel/time/timer.c:1654
>>>  [] __do_softirq+0x2fb/0xb63 kernel/softirq.c:284
>>>  [< inline >] invoke_softirq kernel/softirq.c:364
>>>  [] irq_exit+0x19e/0x1d0 kernel/softirq.c:405
>>>  [< inline >] exiting_irq arch/x86/include/asm/apic.h:659
>>>  [] smp_apic_timer_interrupt+0x7b/0xa0
>>> arch/x86/kernel/apic/apic.c:960
>>>  [] apic_timer_interrupt+0x8c/0xa0
>>> arch/x86/entry/entry_64.S:489
>>>   [  201.343209]  [] ?
>>> _raw_spin_unlock_irqrestore+0x119/0x1a0
>>>  [] try_to_wake_up+0x174/0x1160 kernel/sched/core.c:2099
>>>  [< inline >] wake_up_process kernel/sched/core.c:2165
>>>  [] wake_up_q+0x8a/0xe0 kernel/sched/core.c:469
>>>  [] futex_wake+0x5be/0x6c0 kernel/futex.c:1453
>>>  [] do_futex+0x11bd/0x1f00 kernel/futex.c:3219
>>>  [< inline >] SYSC_futex kernel/futex.c:3275
>>>  [] SyS_futex+0x2fc/0x400 kernel/futex.c:3243
>>>  [] entry_SYSCALL_64_fastpath+0x1f/0xc2
>>
>> Can you test whether the patch below fixes this problem?
>
> Hi Alan,
>
> Yes, I believe it does.
> It also seems to fix the warnings in dummy_free_request() I've been getting.

It seems that I was wrong. Still see both use-after-free and warnings.

>
> Thanks!
>
>>
>> Alan Stern
>>
>>
>>
>> Index: usb-4.x/drivers/usb/gadget/legacy/inode.c
>> ===
>> --- usb-4.x.orig/drivers/usb/gadget/legacy/inode.c
>> +++ usb-4.x/drivers/usb/gadget/legacy/inode.c
>> @@ -1762,6 +1762,10 @@ dev_config (struct file *fd, const char
>> }
>> spin_unlock_irq(>lock);
>>
>> +   /* Registered but not yet bound to a UDC driver? */
>> +   if (dev->gadget_registered)
>> +   return -EIO;
>> +
>> if (len < (USB_DT_CONFIG_SIZE + USB_DT_DEVICE_SIZE + 4))
>> return -EINVAL;
>>
>>

Re: [PATCH v2 02/11] locking/ww_mutex: Re-check ww->ctx in the inner optimistic spin loop

[Waiman Long]

On 12/06/2016 10:06 AM, Peter Zijlstra wrote:
> On Thu, Dec 01, 2016 at 03:06:45PM +0100, Nicolai Hähnle wrote:
>> +++ b/kernel/locking/mutex.c
>> @@ -350,7 +350,8 @@ ww_mutex_set_context_slowpath(struct ww_mutex *lock,
>>   * access and not reliable.
>>   */
>>  static noinline
>> -bool mutex_spin_on_owner(struct mutex *lock, struct task_struct *owner)
>> +bool mutex_spin_on_owner(struct mutex *lock, struct task_struct *owner,
>> + bool use_ww_ctx, struct ww_acquire_ctx *ww_ctx)
>>  {
>>  bool ret = true;
>>  
>> @@ -373,6 +374,28 @@ bool mutex_spin_on_owner(struct mutex *lock, struct 
>> task_struct *owner)
>>  break;
>>  }
>>  
>> +if (use_ww_ctx && ww_ctx->acquired > 0) {
>> +struct ww_mutex *ww;
>> +
>> +ww = container_of(lock, struct ww_mutex, base);
>> +
>> +/*
>> + * If ww->ctx is set the contents are undefined, only
>> + * by acquiring wait_lock there is a guarantee that
>> + * they are not invalid when reading.
>> + *
>> + * As such, when deadlock detection needs to be
>> + * performed the optimistic spinning cannot be done.
>> + *
>> + * Check this in every inner iteration because we may
>> + * be racing against another thread's ww_mutex_lock.
>> + */
>> +if (READ_ONCE(ww->ctx)) {
>> +ret = false;
>> +break;
>> +}
>> +}
>> +
>>  cpu_relax();
>>  }
>>  rcu_read_unlock();
> Aside from the valid question about mutex_can_spin_on_owner() there's
> another 'problem' here, mutex_spin_on_owner() is marked noinline, so all
> the use_ww_ctx stuff doesn't 'work' here.

The mutex_spin_on_owner() function was originally marked noinline
because it could be a major consumer of CPU cycles in a contended lock.
Having it shown separately in the perf output will help the users have a
better understanding of what is consuming all the CPU cycles. So I would
still like to keep it this way.

If you have concern about additional latency for non-ww_mutex calls, one
alternative can be:

diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
index 0afa998..777338d 100644
--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c
@@ -349,9 +349,9 @@ static __always_inline void ww_mutex_lock_acquired(struct ww
  * Look out! "owner" is an entirely speculative pointer
  * access and not reliable.
  */
-static noinline
-bool mutex_spin_on_owner(struct mutex *lock, struct task_struct *owner,
-bool use_ww_ctx, struct ww_acquire_ctx *ww_ctx)
+static __always_inline
+bool __mutex_spin_on_owner(struct mutex *lock, struct task_struct *owner,
+  const bool use_ww_ctx, struct ww_acquire_ctx *ww_ctx)
 {
bool ret = true;
 
@@ -403,6 +403,19 @@ bool mutex_spin_on_owner(struct mutex *lock, struct task_st
return ret;
 }
 
+static noinline
+bool mutex_spin_on_owner(struct mutex *lock, struct task_struct *owner)
+{
+   return __mutex_spin_on_owner(lock, owner, false, NULL);
+}
+
+static noinline
+bool ww_mutex_spin_on_owner(struct mutex *lock, struct task_struct *owner,
+   struct ww_acquire_ctx *ww_ctx)
+{
+   return __mutex_spin_on_owner(lock, owner, true, ww_ctx);
+}
+
 /*
  * Initial check for entering the mutex spinning loop
  */
@@ -489,13 +502,17 @@ static bool mutex_optimistic_spin(struct mutex *lock,
 */
owner = __mutex_owner(lock);
if (owner) {
+   bool spin_ok;
+
if (waiter && owner == task) {
smp_mb(); /* ACQUIRE */
break;
}
 
-   if (!mutex_spin_on_owner(lock, owner, use_ww_ctx,
-ww_ctx))
+   spin_ok = use_ww_ctx
+   ? ww_mutex_spin_on_owner(lock, owner, ww_ctx)
+   : mutex_spin_on_owner(lock, owner);
+   if (!spin_ok)
goto fail_unlock;
}
 

[PATCH] dts: sun8i-h3: correct UART3 pin definitions

[jorik]

From: Jorik Jonker 

In a previous commit, I made a copy/paste error in the pinmux
definitions of UART3: PG{13,14} instead of PA{13,14}. This commit takes
care of that. I have tested this commit on Orange Pi PC and Orange Pi
Plus, and it works for these boards.

Fixes: e3d11d3c45c5 ("dts: sun8i-h3: add pinmux definitions for
UART2-3")

Signed-off-by: Jorik Jonker 
---
 arch/arm/boot/dts/sun8i-h3.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 75a8654..f4ba088 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -410,7 +410,7 @@
};
 
uart3_pins: uart3 {
-   allwinner,pins = "PG13", "PG14";
+   allwinner,pins = "PA13", "PA14";
allwinner,function = "uart3";
allwinner,drive = ;
allwinner,pull = ;
-- 
2.9.3

RE: [PATCH V2 04/13] perf/core: output multiplexing overhead

[Liang, Kan]

> On Fri, Dec 02, 2016 at 04:19:12PM -0500, kan.li...@intel.com wrote:
> > From: Kan Liang 
> >
> > Multiplexing overhead is one of the key overhead when the number of
> > events is more than available counters.
> >
> > The multiplexing overhead PERF_CORE_MUX_OVERHEAD is a common
> overhead
> > type.
> >
> 
> > diff --git a/include/uapi/linux/perf_event.h
> > b/include/uapi/linux/perf_event.h index fe7b1fb..355086f 100644
> > --- a/include/uapi/linux/perf_event.h
> > +++ b/include/uapi/linux/perf_event.h
> > @@ -999,6 +999,7 @@ struct perf_branch_entry {
> >   */
> >  enum perf_record_overhead_type {
> > PERF_CORE_OVERHEAD   = 0,
> > +   PERF_CORE_MUX_OVERHEAD   = 0,
> 
> '0' already had a name ?!

PERF_CORE_OVERHEAD is only used to indicate the start of core
overhead type.
I will use comment line to replace PERF_CORE_OVERHEAD. 

Thanks,
Kan

Re: [PATCH v4 6/7] IIO: add STM32 timer trigger driver

[Benjamin Gaignard]

[snip]
>> +
>> +static const char * const triggers0[] = {
>> + TIM1_TRGO, TIM1_CH1, TIM1_CH2, TIM1_CH3, TIM1_CH4, NULL,
>> +};
>> +
>> +static const char * const triggers1[] = {
>> + TIM2_TRGO, TIM2_CH1, TIM2_CH2, TIM2_CH3, TIM2_CH4, NULL,
>> +};
>> +
>> +static const char * const triggers2[] = {
>> + TIM3_TRGO, TIM3_CH1, TIM3_CH2, TIM3_CH3, TIM3_CH4, NULL,
>> +};
>> +
>> +static const char * const triggers3[] = {
>> + TIM4_TRGO, TIM4_CH1, TIM4_CH2, TIM4_CH3, TIM4_CH4, NULL,
>> +};
>> +
>> +static const char * const triggers4[] = {
>> + TIM5_TRGO, TIM5_CH1, TIM5_CH2, TIM5_CH3, TIM5_CH4, NULL,
>> +};
>> +
>> +static const char * const triggers5[] = {
>> + TIM6_TRGO, NULL,
>> +};
>> +
>> +static const char * const triggers6[] = {
>> + TIM7_TRGO, NULL,
>> +};
>> +
>> +static const char * const triggers7[] = {
>> + TIM8_TRGO, TIM8_CH1, TIM8_CH2, TIM8_CH3, TIM8_CH4, NULL,
>> +};
>> +
>> +static const char * const triggers8[] = {
>> + TIM9_TRGO, TIM9_CH1, TIM9_CH2, NULL,
>> +};
>> +
>> +static const char * const triggers9[] = {
>> + TIM12_TRGO, TIM12_CH1, TIM12_CH2, NULL,
>> +};
>> +
>> +static const void *triggers_table[] = {
>> + triggers0,
>> + triggers1,
>> + triggers2,
>> + triggers3,
>> + triggers4,
>> + triggers5,
>> + triggers6,
>> + triggers7,
>> + triggers8,
>> + triggers9,
>> +};
>
> What about:
>
> static const char * const triggers[][] = {
> { TIM1_TRGO, TIM1_CH1, TIM1_CH2, TIM1_CH3, TIM1_CH4, NULL },
> { TIM2_TRGO, TIM2_CH1, TIM2_CH2, TIM2_CH3, TIM2_CH4, NULL },
> { TIM3_TRGO, TIM3_CH1, TIM3_CH2, TIM3_CH3, TIM3_CH4, NULL },
> { TIM4_TRGO, TIM4_CH1, TIM4_CH2, TIM4_CH3, TIM4_CH4, NULL },
> { TIM5_TRGO, TIM5_CH1, TIM5_CH2, TIM5_CH3, TIM5_CH4, NULL },
> { TIM6_TRGO, NULL },
> { TIM7_TRGO, NULL },
> { TIM8_TRGO, TIM8_CH1, TIM8_CH2, TIM8_CH3, TIM8_CH4, NULL },
> { TIM9_TRGO, TIM9_CH1, TIM9_CH2, NULL },
> { TIM12_TRGO, TIM12_CH1, TIM12_CH2, NULL }
> };

I can't because the second dimension of the array isn't fix.
I could have between 2 and 6 elements per row... to create a dual dimension
array I would have to add NULL entries like that:

#define MAX_TRIGGERS 6

static const void *triggers_table[][MAX_TRIGGERS] = {
{ TIM1_TRGO, TIM1_CH1, TIM1_CH2, TIM1_CH3, TIM1_CH4, NULL,},
{ TIM2_TRGO, TIM2_CH1, TIM2_CH2, TIM2_CH3, TIM2_CH4, NULL,},
{ TIM3_TRGO, TIM3_CH1, TIM3_CH2, TIM3_CH3, TIM3_CH4, NULL,},
{ TIM4_TRGO, TIM4_CH1, TIM4_CH2, TIM4_CH3, TIM4_CH4, NULL,},
{ TIM5_TRGO, TIM5_CH1, TIM5_CH2, TIM5_CH3, TIM5_CH4, NULL,},
{ TIM6_TRGO, NULL, NULL, NULL, NULL, NULL,},
{ TIM7_TRGO, NULL, NULL, NULL, NULL, NULL,},
{ TIM8_TRGO, TIM8_CH1, TIM8_CH2, TIM8_CH3, TIM8_CH4, NULL,},
{ TIM9_TRGO, TIM9_CH1, TIM9_CH2, NULL, NULL, NULL,},
{ TIM12_TRGO, TIM12_CH1, TIM12_CH2, NULL,  NULL, NULL,},
};

>> +static const char * const valids0[] = {
>> + TIM5_TRGO, TIM2_TRGO, TIM4_TRGO, TIM3_TRGO, NULL,
>> +};
>> +
>> +static const char * const valids1[] = {
>> + TIM1_TRGO, TIM8_TRGO, TIM3_TRGO, TIM4_TRGO, NULL,
>> +};
>> +
>> +static const char * const valids2[] = {
>> + TIM1_TRGO, TIM8_TRGO, TIM5_TRGO, TIM4_TRGO, NULL,
>> +};
>> +
>> +static const char * const valids3[] = {
>> + TIM1_TRGO, TIM2_TRGO, TIM3_TRGO, TIM8_TRGO, NULL,
>> +};
>> +
>> +static const char *const valids4[] = {
>> + TIM2_TRGO, TIM3_TRGO, TIM4_TRGO, TIM8_TRGO, NULL,
>> +};
>> +
>> +static const char * const valids7[] = {
>> + TIM1_TRGO, TIM2_TRGO, TIM4_TRGO, TIM5_TRGO, NULL,
>> +};
>> +
>> +static const char * const valids8[] = {
>> + TIM2_TRGO, TIM3_TRGO, NULL,
>> +};
>> +
>> +static const char * const valids9[] = {
>> + TIM4_TRGO, TIM5_TRGO, NULL,
>> +};
>> +
>> +static const void *valids_table[] = {
>> + valids0,
>> + valids1,
>> + valids2,
>> + valids3,
>> + valids4,
>> + NULL,
>> + NULL,
>> + valids7,
>> + valids8,
>> + valids9,
>> +};
>
> Same here.
>
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH] vfio/pci: Support error recovery

[Alex Williamson]

On Tue, 6 Dec 2016 18:46:04 +0800
Cao jin  wrote:

> On 12/06/2016 12:59 PM, Alex Williamson wrote:
> > On Tue, 6 Dec 2016 05:55:28 +0200
> > "Michael S. Tsirkin"  wrote:
> >   
> >> On Mon, Dec 05, 2016 at 09:17:30AM -0700, Alex Williamson wrote:  
> >>> If you're going to take the lead for these AER patches, I would
> >>> certainly suggest that understanding the reasoning behind the bus reset
> >>> behavior is a central aspect to this series.  This effort has dragged
> >>> out for nearly two years and I apologize, but I don't really have a lot
> >>> of patience for rehashing some of these issues if you're not going to
> >>> read the previous discussions or consult with your colleagues to
> >>> understand how we got to this point.  If you want to challenge some of
> >>> the design points, that's great, it could use some new eyes, but please
> >>> understand how we got here first.
> >>
> >> Well I'm guessing Cao jin here isn't the only one not
> >> willing to plough through all historical versions of the patchset
> >> just to figure out the motivation for some code.
> >>
> >> Including a summary of a high level architecture couldn't hurt.
> >>
> >> Any chance of writing such?  Alternatively, we can try to build it as
> >> part of this thread.  Shouldn't be hard as it seems somewhat
> >> straight-forward on the surface:
> >>
> >> - detect link error on the host, don't reset link as we would normally do  
> > 
> > This is actually a new approach that I'm not sure I agree with.  By
> > skipping the host directed link reset, vfio is taking responsibility
> > for doing this, but then we just assume the user will do it.  I have
> > issues with this.
> > 
> > The previous approach was to use the error detected notifier to block
> > access to the device, allowing the host to perform the link reset.  A
> > subsequent notification in the AER process released the user access
> > which allowed the user AER process to proceed.  This did result in both
> > a host directed and a guest directed link reset, but other than
> > coordinating the blocking of the user process during host reset, that
> > hasn't been brought up as an issue previously.
> >   
> 
> Tests on previous versions didn't bring up issues as I find, I think
> that is because we didn't test it completely. As I know, before August
> of this year, we didn't have cable connected to NIC, let alone
> connecting NIC to gateway.

Lack of testing has been a significant issue throughout the development
of this series.

> Even if I fixed the guest oops issue in igb driver that Alex found in
> v9, v9 still cannot work in my test. And in my test, disable link
> reset(in host) in aer core for vfio-pci is the most significant step to
> get my test passed.

But is it the correct step?  I'm not convinced.  Why did blocking guest
access not work?  How do you plan to manage vfio taking the
responsibility to perform a bus reset when you don't know whether QEMU
is the user of the device or whether the user supports AER recovery?
 
> >> - report link error to guest
> >> - detect link reset request from guest
> >> - reset link on host
> >>
> >> Since link reset will reset all devices behind it, for this to work we
> >> need same set of devices behind the link in host and guest.  Enforcing
> >> this would be nice to have.  
> > 
> > This is a pretty significant complication and I think it's a
> > requirement.  This is the heart of why we have an AER vfio-pci device
> > option and why we require that QEMU should fail to initialize the
> > device if AER is enabled in an incompatible configuration.  If a user
> > cannot be sure that AER is enabled on a device, it's pointless to
> > bother implementing it, though honestly I question the value of it in
> > the VM altogether given configuration requirements (ie. are users
> > going to accept the reason that all the ports of a device need to be
> > assigned to a single guest for guest-based AER recovery when they were
> > previously able to assign each port to a separate VM?).
> >
> >> - as link now might end up in bad state, reset
> >>   it when device is unassigned  
> > 
> > This is also a new aspect for the approach here, previously we allowed
> > the host directed link reset so we could assume the device was
> > sufficiently recovered.  In the proposal here, the AER core skips any
> > devices bound to vfio-pci, but vfio can't guarantee that we can do a
> > bus reset on them.  PCI bus isolation is not accounted for in DMA
> > isolation, which is the basis for IOMMU groups.  A bus can host
> > multiple IOMMU groups, each of which may have a different user.  Only
> > in a very specific configuration can vfio do a bus reset.
> >
> >> Any details I missed?  
> > 
> > AIUI, the critical feature is that the guest needs to be able to reset
> > the device link, all the other design elements play out from the
> > logical expansion of that feature.  It means that a guest bus reset
> > 

Re: Tearing down DMA transfer setup after DMA client has finished

[Måns Rullgård]

Mason  writes:

> On 06/12/2016 14:14, Måns Rullgård wrote:
>
>> Mason wrote:
>> 
>>> On 06/12/2016 06:12, Vinod Koul wrote:
>>>
 On Tue, Nov 29, 2016 at 07:25:02PM +0100, Mason wrote:

> Is there a way to write a driver within the existing framework?

 I think so, looking back at comments from Russell, I do tend to agree with
 that. Is there a specific reason why sbox can't be tied to alloc and free
 channels?
>>>
>>> Here's a recap of the situation.
>>>
>>> The "SBOX+MBUS" HW is used in several iterations of the tango SoC:
>>>
>>> tango3
>>>   2 memory channels available
>>>   6 devices ("clients"?) may request an MBUS channel
>>>
>>> tango4 (one more channel)
>>>   3 memory channels available
>>>   7 devices may request an MBUS channel :
>>> NFC0, NFC1, SATA0, SATA1, memcpy, (IDE0, IDE1)
>>>
>>> Notes:
>>> The current NFC driver supports only one controller.
>> 
>> I consider that a bug.
>
> Meh. The two controller blocks share the I/O pins to the outside
> world, so it's not possible to have two concurrent accesses.

OK, you failed to mention that part.  Why are there two controllers at
all if only one or the other can be used?

>>> If I understand the current DMA driver (written by Mans), client
>>> drivers are instructed to use a specific channel in the DT, and
>>> the DMA driver muxes access to that channel.
>> 
>> Almost.  The DT indicates the sbox ID of each device.  The driver
>> multiplexes requests from all devices across all channels.
>
> Thanks for pointing that out. I misremembered the DT.
> So a client's DT node specifies the client's SBOX port.
> And the DMA node specifies all available MBUS channels.
>
> So when an interrupt fires, the DMA driver (re)uses that
> channel for the next transfer in line?

Correct.

>>> The DMA driver manages a per-channel queue of outstanding DMA transfer
>>> requests, and a new transfer is started from within the DMA ISR
>>> (modulo the fact that the interrupt does not signal completion of the
>>> transfer, as explained else-thread).
>> 
>> We need to somehow let the device driver signal the dma driver when a
>> transfer has been fully completed.  Currently the only post-transfer
>> interaction between the dma engine and the device driver is through the
>> descriptor callback, which is not suitable for this purpose.
>
> The callback is called from vchan_complete() right?
> Is that running from interrupt context?

It runs from a tasklet which is almost the same thing.

> What's the relationship between vchan_complete() and
> tangox_dma_irq() -- does one call the other? Are they
> asynchronous?
>
>> This is starting to look like one of those situations where someone just
>> needs to implement a solution, or we'll be forever bickering about
>> hypotheticals.
>
> I can give that a shot (if you're busy with real work).

I have an idea I'd like to try out over the weekend.  If I don't come
back with something by next week, go for it.

>>> What you're proposing, Vinod, is to make a channel exclusive
>>> to a driver, as long as the driver has not explicitly released
>>> the channel, via dma_release_channel(), right?
>> 
>> That's not going to work very well.  Device drivers typically request
>> dma channels in their probe functions or when the device is opened.
>> This means that reserving one of the few channels there will inevitably
>> make some other device fail to operate.
>
> This is true for tango3. Less so for tango4. And no longer
> an issue for tango5.
>
>> Doing a request/release per transfer really doesn't fit with the
>> intended usage of the dmaengine api.  For starters, what should a driver
>> do if all the channels are currently busy?
>
> Why can't we queue channel requests the same way we queue
> transfer requests?

That's in effect what we're doing.  Calling it by another name doesn't
really solve anything.

-- 
Måns Rullgård

Re: [PATCH v2 05/11] locking/ww_mutex: Add waiters in stamp order

[Peter Zijlstra]

On Thu, Dec 01, 2016 at 03:06:48PM +0100, Nicolai Hähnle wrote:
> +static inline int __sched
> +__ww_mutex_add_waiter(struct mutex_waiter *waiter,
> +   struct mutex *lock,
> +   struct ww_acquire_ctx *ww_ctx)
> +{
> + struct mutex_waiter *cur;
> +
> + if (!ww_ctx) {
> + list_add_tail(>list, >wait_list);
> + return 0;
> + }
> +
> + /*
> +  * Add the waiter before the first waiter with a higher stamp.
> +  * Waiters without a context are skipped to avoid starving
> +  * them.
> +  */
> + list_for_each_entry(cur, >wait_list, list) {
> + if (!cur->ww_ctx)
> + continue;
> +
> + if (__ww_mutex_stamp_after(ww_ctx, cur->ww_ctx)) {
> + /* Back off immediately if necessary. */
> + if (ww_ctx->acquired > 0) {
> +#ifdef CONFIG_DEBUG_MUTEXES
> + struct ww_mutex *ww;
> +
> + ww = container_of(lock, struct ww_mutex, base);
> + DEBUG_LOCKS_WARN_ON(ww_ctx->contending_lock);
> + ww_ctx->contending_lock = ww;
> +#endif
> + return -EDEADLK;
> + }
> +
> + continue;
> + }
> +
> + list_add_tail(>list, >list);
> + return 0;
> + }
> +
> + list_add_tail(>list, >wait_list);
> + return 0;
> +}

So you keep the list in order of stamp, and in general stamps come in,
in-order. That is, barring races on concurrent ww_mutex_lock(), things
are already ordered.

So it doesn't make sense to scan the entire list forwards, that's almost
guarantees you scan the entire list every single time.

Or am I reading this wrong? Which in itself is a hint a comment might be
in place.

Re: [PATCH] net: stmmac: clear reset value of snps,wr_osr_lmt/snps,rd_osr_lmt before writing

[David Miller]

From: Niklas Cassel 
Date: Mon, 5 Dec 2016 18:12:54 +0100

> From: Niklas Cassel 
> 
> WR_OSR_LMT and RD_OSR_LMT have a reset value of 1.
> Since the reset value wasn't cleared before writing, the value in the
> register would be incorrect if specifying an uneven value for
> snps,wr_osr_lmt/snps,rd_osr_lmt.
> 
> Zero is a valid value for the properties, since the databook specifies:
> maximum outstanding requests = WR_OSR_LMT + 1.
> 
> We do not want to change the behavior for existing users when the
> property is missing. Therefore, default to 1 if the property is missing,
> since that is the same as the reset value.
> 
> Signed-off-by: Niklas Cassel 

Applied, thank you.

[PATCH 08/10] vsock/virtio: mark an internal function static

[Michael S. Tsirkin]

virtio_transport_alloc_pkt is only used locally, make it static.

Signed-off-by: Michael S. Tsirkin 
---
 net/vmw_vsock/virtio_transport_common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/vmw_vsock/virtio_transport_common.c 
b/net/vmw_vsock/virtio_transport_common.c
index a53b3a1..6120384 100644
--- a/net/vmw_vsock/virtio_transport_common.c
+++ b/net/vmw_vsock/virtio_transport_common.c
@@ -32,7 +32,7 @@ static const struct virtio_transport 
*virtio_transport_get_ops(void)
return container_of(t, struct virtio_transport, transport);
 }
 
-struct virtio_vsock_pkt *
+static struct virtio_vsock_pkt *
 virtio_transport_alloc_pkt(struct virtio_vsock_pkt_info *info,
   size_t len,
   u32 src_cid,
-- 
MST

[PATCH 06/10] vhost: add missing __user annotations

[Michael S. Tsirkin]

Several vhost functions were missing __user annotations
on pointers, causing sparse warnings. Fix this up.

Signed-off-by: Michael S. Tsirkin 
---
 drivers/vhost/vhost.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 7331ef3..ba7db68 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -719,7 +719,7 @@ static int memory_access_ok(struct vhost_dev *d, struct 
vhost_umem *umem,
 static int translate_desc(struct vhost_virtqueue *vq, u64 addr, u32 len,
  struct iovec iov[], int iov_size, int access);
 
-static int vhost_copy_to_user(struct vhost_virtqueue *vq, void *to,
+static int vhost_copy_to_user(struct vhost_virtqueue *vq, void __user *to,
  const void *from, unsigned size)
 {
int ret;
@@ -749,7 +749,7 @@ static int vhost_copy_to_user(struct vhost_virtqueue *vq, 
void *to,
 }
 
 static int vhost_copy_from_user(struct vhost_virtqueue *vq, void *to,
-   void *from, unsigned size)
+   void __user *from, unsigned size)
 {
int ret;
 
@@ -783,7 +783,7 @@ static int vhost_copy_from_user(struct vhost_virtqueue *vq, 
void *to,
 }
 
 static void __user *__vhost_get_user(struct vhost_virtqueue *vq,
-void *addr, unsigned size)
+void __user *addr, unsigned size)
 {
int ret;
 
@@ -934,8 +934,8 @@ static int umem_access_ok(u64 uaddr, u64 size, int access)
return 0;
 }
 
-int vhost_process_iotlb_msg(struct vhost_dev *dev,
-   struct vhost_iotlb_msg *msg)
+static int vhost_process_iotlb_msg(struct vhost_dev *dev,
+  struct vhost_iotlb_msg *msg)
 {
int ret = 0;
 
-- 
MST

[PATCH 04/10] drm/virtio: annotate virtio_gpu_queue_ctrl_buffer_locked

[Michael S. Tsirkin]

virtio_gpu_queue_ctrl_buffer_locked is called with ctrlq.qlock taken, it
releases and acquires this lock.  This causes a sparse warning.  Add
appropriate annotations for sparse context checking.

Signed-off-by: Michael S. Tsirkin 
---
 drivers/gpu/drm/virtio/virtgpu_vq.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c 
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 2f0c2f9..a6e2ce4 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -297,6 +297,8 @@ void virtio_gpu_dequeue_cursor_func(struct work_struct 
*work)
 
 static int virtio_gpu_queue_ctrl_buffer_locked(struct virtio_gpu_device *vgdev,
   struct virtio_gpu_vbuffer *vbuf)
+   __releases(>ctrlq.qlock)
+   __acquires(>ctrlq.qlock)
 {
struct virtqueue *vq = vgdev->ctrlq.vq;
struct scatterlist *sgs[3], vcmd, vout, vresp;
-- 
MST

[PATCH] x86/irq: Add additional unhandled IRQ debug information

[Prarit Bhargava]

The current unhandled IRQ warning doesn't output enough information on x86 to
determine which device issued an interrupt.  For example,

irq 16: nobody cared (try booting with the "irqpoll" option)
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.9.0-rc6+ #19
Hardware name: Hewlett-Packard HP Z820 Workstation/158B, BIOS J63 v03.90 
06/01/2016
 88041f803eb0 81337a95 880418607200 88041860729c
 88041f803ed8 810db845 880418607200 
 0010 88041f803f10 810dbb9f 880418607200
Call Trace:
   [] dump_stack+0x63/0x8e
 [] __report_bad_irq+0x35/0xd0
 [] note_interrupt+0x20f/0x260
 [] handle_irq_event_percpu+0x45/0x60
 [] handle_irq_event+0x2c/0x50
 [] handle_fasteoi_irq+0x8a/0x150
 [] handle_irq+0xab/0x130
 [] ? atomic_notifier_call_chain+0x1a/0x20
 [] ? __exit_idle+0x2d/0x30
 [] do_IRQ+0x4d/0xd0
 [] common_interrupt+0x82/0x82
   [] ? cpuidle_enter_state+0xc1/0x280
 [] ? cpuidle_enter_state+0xb4/0x280
 [] cpuidle_enter+0x17/0x20
 [] call_cpuidle+0x23/0x40
 [] cpu_startup_entry+0x149/0x240
 [] rest_init+0x77/0x80
 [] start_kernel+0x495/0x4a2
 [] ? set_init_arg+0x55/0x55
 [] ? early_idt_handler_array+0x120/0x120
 [] x86_64_start_reservations+0x2a/0x2c
 [] x86_64_start_kernel+0x13d/0x14c
handlers:
[] usb_hcd_irq
Disabling IRQ #16

The unhandled interrupt is issued against IRQ 16, however, in many cases the
handlers listed do not have anything to do with the device that has issued the
interrupt.

This patch adds weak function arch_irq_debug(), and adds an x86 specific
definition.  The x86 version dumps the following information: the status
of the IO APIC pin line associated with the IRQ, the state of the CPU's
LAPIC, and the PCI devices which have their interrupt set.

This information is output:

Additional x86 information on IRQ #16 ...
IRQ16 maps to APIC0 PIN16 : pin10, enabled , level, low , V(10), IRR(1), S(1), 
remapped, I(98013),  Z(0)
This CPU APIC ID is 0, and cpu id is 0.
CPU 0 LAPIC IRR dump:
APIC IRR 7 (IRQs 255 to 224) = 0x20008000  [ 239 253 ]
APIC IRR 6 (IRQs 223 to 192) = 0x0
APIC IRR 5 (IRQs 191 to 160) = 0x0
APIC IRR 4 (IRQs 159 to 128) = 0x0
APIC IRR 3 (IRQs 127 to 96) = 0x0
APIC IRR 2 (IRQs 95 to 64) = 0x0
APIC IRR 1 (IRQs 63 to 32) = 0x0
APIC IRR 0 (IRQs 31 to 0) = 0x0
Disabling IRQ #16
PCI devices with INTERRUPT STATUS set (bit 3 of PCI_STATUS register):
possible unhandled irq source :00:16.0: pin = 1
possible unhandled irq source :05:00.0: pin = 1

Signed-off-by: Prarit Bhargava 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x...@kernel.org
Cc: Rui Wang 
Cc: Paul Gortmaker 
Cc: Denys Vlasenko 
Cc: Borislav Petkov 
Cc: Aaron Lu 
---
 arch/x86/include/asm/io_apic.h |2 ++
 arch/x86/kernel/apic/io_apic.c |   70 ++--
 arch/x86/kernel/irq.c  |   66 +
 kernel/irq/spurious.c  |9 ++
 4 files changed, 123 insertions(+), 24 deletions(-)

diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index 6cbf2cfb3f8a..fecc301f8be2 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -195,6 +195,7 @@ static inline unsigned int io_apic_read(unsigned int apic, 
unsigned int reg)
 extern void setup_ioapic_dest(void);
 extern int IO_APIC_get_PCI_irq_vector(int bus, int devfn, int pin);
 extern void print_IO_APICs(void);
+extern void print_IRQ_to_pin_mapping(unsigned int irq);
 #else  /* !CONFIG_X86_IO_APIC */
 
 #define IO_APIC_IRQ(x) 0
@@ -203,6 +204,7 @@ static inline unsigned int io_apic_read(unsigned int apic, 
unsigned int reg)
 static inline void ioapic_insert_resources(void) { }
 static inline int arch_early_ioapic_init(void) { return 0; }
 static inline void print_IO_APICs(void) {}
+static inline print_IRQ_to_pin_mapping(unsigned int irq) {}
 #define gsi_top (NR_IRQS_LEGACY)
 static inline int mp_find_ioapic(u32 gsi) { return 0; }
 static inline int mp_map_gsi_to_irq(u32 gsi, unsigned int flags,
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 48e6d84f173e..ff86bd140d18 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -1247,34 +1247,30 @@ void ioapic_zap_locks(void)
raw_spin_lock_init(_lock);
 }
 
-static void io_apic_print_entries(unsigned int apic, unsigned int nr_entries)
+static void io_apic_print_entry(unsigned int apic, int entry_no)
 {
-   int i;
char buf[256];
struct IO_APIC_route_entry entry;
struct IR_IO_APIC_route_entry *ir_entry = (void *)
 
-   printk(KERN_DEBUG "IOAPIC %d:\n", apic);
-   for (i = 0; i <= nr_entries; i++) {
-   entry = ioapic_read_entry(apic, i);
-   snprintf(buf, sizeof(buf),
-" pin%02x, %s, 

Re: linux-next: build failure after merge of the sound-asoc tree

[Mark Brown]

On Tue, Dec 06, 2016 at 12:55:38PM +, Lee Jones wrote:
> On Tue, 06 Dec 2016, Mark Brown wrote:
> > On Tue, Dec 06, 2016 at 12:41:15AM +, Kuninori Morimoto wrote:

> > >   8ca9edc837932469b81b8b47ea43a074b6add970
> > >   ("mfd: davinci_voicecodec: Tidyup header difinitions")

> > Reverted.  Lee, there is actually a dependency here...

> No idea what you're talking about.

You were saying there were no dependencies for the ASoC bit of
Morimoto-san's cq9vc series.

> Are you going to allude to the patch you reverted?

The one Stephen identified.

> I assume you wish for me to pick it up?

Or if you could send me a pull request for the MFD bits.


signature.asc
Description: PGP signature

Re: [PATCH v4 01/18 -cleanup] perf build: Check LLVM version in feature check

[Arnaldo Carvalho de Melo]

Em Tue, Dec 06, 2016 at 07:22:30AM +, Wang Nan escreveu:
> Cancel builtin llvm and clang support when LLVM version is
> less than 3.9.0: following commits uses newer API.
> 
> Since Clang/LLVM's API is not guaranteed to be stable,
> add a test-llvm-version.cpp feature checker, issue warning if
> LLVM found in compiling environment is not tested yet.

Ok, did a few clarifications in the warning message and tested it with a
f25 kit, i.e. clang/LLVM 3.8, all seems ok now, please see:

https://git.kernel.org/cgit/linux/kernel/git/acme/linux.git/commit/?h=perf/core=464cf82b6c9304e981f3af831ca8ab608e862687

For my case, I end up getting this message:

  Makefile.config:807: No suitable libLLVM found, disabling builtin clang and 
LLVM support. Please install llvm-dev(el) (>= 3.9.0)

Please holler if it is in any way misleading or erroneous.

- Arnaldo
 
> Signed-off-by: Wang Nan 
> Cc: Alexei Starovoitov 
> Cc: Arnaldo Carvalho de Melo 
> Cc: He Kuang 
> Cc: Jiri Olsa 
> Cc: Joe Stringer 
> Cc: Zefan Li 
> Cc: pi3or...@163.com
> ---
>  tools/build/feature/Makefile  |  8 ++--
>  tools/build/feature/test-llvm-version.cpp | 11 +++
>  tools/build/feature/test-llvm.cpp |  5 +
>  tools/perf/Makefile.config|  8 ++--
>  4 files changed, 28 insertions(+), 4 deletions(-)
>  create mode 100644 tools/build/feature/test-llvm-version.cpp
> 
> diff --git a/tools/build/feature/Makefile b/tools/build/feature/Makefile
> index 303196c..b564a2e 100644
> --- a/tools/build/feature/Makefile
> +++ b/tools/build/feature/Makefile
> @@ -231,14 +231,18 @@ $(OUTPUT)test-jvmti.bin:
>   $(BUILD)
>  
>  $(OUTPUT)test-llvm.bin:
> - $(BUILDXX) -std=gnu++11 \
> + $(BUILDXX) -std=gnu++11 \
>   -I$(shell $(LLVM_CONFIG) --includedir)  \
>   -L$(shell $(LLVM_CONFIG) --libdir)  \
>   $(shell $(LLVM_CONFIG) --libs Core BPF) \
>   $(shell $(LLVM_CONFIG) --system-libs)
>  
> +$(OUTPUT)test-llvm-version.bin:
> + $(BUILDXX) -std=gnu++11 \
> + -I$(shell $(LLVM_CONFIG) --includedir)
> +
>  $(OUTPUT)test-clang.bin:
> - $(BUILDXX) -std=gnu++11 \
> + $(BUILDXX) -std=gnu++11 \
>   -I$(shell $(LLVM_CONFIG) --includedir)  \
>   -L$(shell $(LLVM_CONFIG) --libdir)  \
>   -Wl,--start-group -lclangBasic -lclangDriver\
> diff --git a/tools/build/feature/test-llvm-version.cpp 
> b/tools/build/feature/test-llvm-version.cpp
> new file mode 100644
> index 000..896d317
> --- /dev/null
> +++ b/tools/build/feature/test-llvm-version.cpp
> @@ -0,0 +1,11 @@
> +#include 
> +#include "llvm/Config/llvm-config.h"
> +
> +#define NUM_VERSION (((LLVM_VERSION_MAJOR) << 16) + (LLVM_VERSION_MINOR << 
> 8) + LLVM_VERSION_PATCH)
> +#define pass int main() {printf("%x\n", NUM_VERSION); return 0;}
> +
> +#if NUM_VERSION >= 0x030900
> +pass
> +#else
> +# error This LLVM is not tested yet.
> +#endif
> diff --git a/tools/build/feature/test-llvm.cpp 
> b/tools/build/feature/test-llvm.cpp
> index d8d2cee..455a332 100644
> --- a/tools/build/feature/test-llvm.cpp
> +++ b/tools/build/feature/test-llvm.cpp
> @@ -1,5 +1,10 @@
>  #include "llvm/Support/ManagedStatic.h"
>  #include "llvm/Support/raw_ostream.h"
> +#define NUM_VERSION (((LLVM_VERSION_MAJOR) << 16) + (LLVM_VERSION_MINOR << 
> 8) + LLVM_VERSION_PATCH)
> +
> +#if NUM_VERSION < 0x030900
> +# error "LLVM version too low"
> +#endif
>  int main()
>  {
>   llvm::errs() << "Hello World!\n";
> diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
> index 09c2a98..2f4d5b0 100644
> --- a/tools/perf/Makefile.config
> +++ b/tools/perf/Makefile.config
> @@ -802,12 +802,13 @@ ifdef LIBCLANGLLVM
>  msg := $(warning No g++ found, disable clang and llvm support. Please 
> install g++)
>else
>  $(call feature_check,llvm)
> +$(call feature_check,llvm-version)
>  ifneq ($(feature-llvm), 1)
> -  msg := $(warning No libLLVM found, disable clang and llvm support. 
> Please install llvm-dev)
> +  msg := $(warning No libLLVM found, disable clang and llvm support. 
> Please install llvm-dev (>= 3.9.0))
>  else
>$(call feature_check,clang)
>ifneq ($(feature-clang), 1)
> -msg := $(warning No libclang found, disable clang and llvm support. 
> Please install libclang-dev)
> +msg := $(warning No libclang found, disable clang and llvm support. 
> Please install libclang-dev (>= 3.9.0))
>else
>  CFLAGS += -DHAVE_LIBCLANGLLVM_SUPPORT
>  CXXFLAGS += -DHAVE_LIBCLANGLLVM_SUPPORT -I$(shell $(LLVM_CONFIG) 
> --includedir)
> @@ -816,6 +817,9 @@ ifdef 

[PATCH v2] ACPI/IORT: Make dma masks set-up IORT specific

[Lorenzo Pieralisi]

The introduction of acpi_dma_configure() allows to configure DMA
and related IOMMU for any device that is DMA capable. To achieve
that goal it ensures DMA masks are set-up to sane default values
before proceeding with IOMMU and DMA ops configuration.

On x86/ia64 systems, through acpi_bind_one(), acpi_dma_configure() is
called for every device that has an ACPI companion, in that every device
is considered DMA capable on x86/ia64 systems (ie acpi_get_dma_attr() API),
which has the side effect of initializing dma masks also for
pseudo-devices (eg CPUs and memory nodes) and potentially for devices
whose dma masks were not set-up before the acpi_dma_configure() API was
introduced, which may have noxious side effects.

Therefore, in preparation for IORT firmware specific DMA masks set-up,
wrap the default DMA masks set-up in acpi_dma_configure() inside an IORT
specific wrapper that reverts to a NOP on x86/ia64 systems, restoring the
default expected behaviour on x86/ia64 systems and keeping DMA default
masks set-up on IORT based (ie ARM) arch configurations.

Signed-off-by: Lorenzo Pieralisi 
Acked-by: Will Deacon 
Acked-by: Rafael J. Wysocki 
Reviewed-by: Hanjun Guo 
Tested-by: Hanjun Guo 
Cc: Will Deacon 
Cc: Hanjun Guo 
Cc: Bjorn Helgaas 
Cc: Robin Murphy 
Cc: Tomasz Nowicki 
Cc: Joerg Roedel 
Cc: "Rafael J. Wysocki" 
Cc: Sricharan R 
---
Hi Joerg,

as discussed please apply it to your arm/smmu branch (and consequently
to -next) in order to get this queued along with the rest of the ACPI IORT
SMMU series for v4.10.

Thank you !
Lorenzo

v1 -> v2
- Added review tags

 drivers/acpi/arm64/iort.c | 22 ++
 drivers/acpi/scan.c   | 14 +-
 include/linux/acpi_iort.h |  2 ++
 3 files changed, 25 insertions(+), 13 deletions(-)

diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 47bace8..e0d2e6e 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -547,6 +547,28 @@ static const struct iommu_ops *iort_iommu_xlate(struct 
device *dev,
 }
 
 /**
+ * iort_set_dma_mask - Set-up dma mask for a device.
+ *
+ * @dev: device to configure
+ */
+void iort_set_dma_mask(struct device *dev)
+{
+   /*
+* Set default coherent_dma_mask to 32 bit.  Drivers are expected to
+* setup the correct supported mask.
+*/
+   if (!dev->coherent_dma_mask)
+   dev->coherent_dma_mask = DMA_BIT_MASK(32);
+
+   /*
+* Set it to coherent_dma_mask by default if the architecture
+* code has not set it.
+*/
+   if (!dev->dma_mask)
+   dev->dma_mask = >coherent_dma_mask;
+}
+
+/**
  * iort_iommu_configure - Set-up IOMMU configuration for a device.
  *
  * @dev: device to configure
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 80698d3..93b00cf 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1380,19 +1380,7 @@ void acpi_dma_configure(struct device *dev, enum 
dev_dma_attr attr)
 {
const struct iommu_ops *iommu;
 
-   /*
-* Set default coherent_dma_mask to 32 bit.  Drivers are expected to
-* setup the correct supported mask.
-*/
-   if (!dev->coherent_dma_mask)
-   dev->coherent_dma_mask = DMA_BIT_MASK(32);
-
-   /*
-* Set it to coherent_dma_mask by default if the architecture
-* code has not set it.
-*/
-   if (!dev->dma_mask)
-   dev->dma_mask = >coherent_dma_mask;
+   iort_set_dma_mask(dev);
 
iommu = iort_iommu_configure(dev);
 
diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
index dcb2b60..77e0809 100644
--- a/include/linux/acpi_iort.h
+++ b/include/linux/acpi_iort.h
@@ -35,6 +35,7 @@ bool iort_node_match(u8 type);
 u32 iort_msi_map_rid(struct device *dev, u32 req_id);
 struct irq_domain *iort_get_device_domain(struct device *dev, u32 req_id);
 /* IOMMU interface */
+void iort_set_dma_mask(struct device *dev);
 const struct iommu_ops *iort_iommu_configure(struct device *dev);
 #else
 static inline void acpi_iort_init(void) { }
@@ -45,6 +46,7 @@ static inline struct irq_domain 
*iort_get_device_domain(struct device *dev,
u32 req_id)
 { return NULL; }
 /* IOMMU interface */
+static inline void iort_set_dma_mask(struct device *dev) { }
 static inline
 const struct iommu_ops *iort_iommu_configure(struct device *dev)
 { return NULL; }
-- 
2.10.0

Re: [PATCH 2/3] crypto: brcm: Add Broadcom SPU driver

[Mark Rutland]

On Wed, Nov 30, 2016 at 03:07:32PM -0500, Rob Rice wrote:
> +static const struct of_device_id bcm_spu_dt_ids[] = {
> + {
> + .compatible = "brcm,spum-crypto",
> + .data = _ns2_types,
> + },
> + {
> + .compatible = "brcm,spum-nsp-crypto",
> + .data = _nsp_types,
> + },
> + {
> + .compatible = "brcm,spu2-crypto",
> + .data = _types,
> + },
> + {
> + .compatible = "brcm,spu2-v2-crypto",
> + .data = _v2_types,
> + },

These last two weren't in the binding document.

> + { /* sentinel */ }
> +};
> +
> +MODULE_DEVICE_TABLE(of, bcm_spu_dt_ids);
> +
> +static int spu_dt_read(struct platform_device *pdev)
> +{
> + struct device *dev = >dev;
> + struct spu_hw *spu = _priv.spu;
> + struct device_node *dn = pdev->dev.of_node;
> + struct resource *spu_ctrl_regs;
> + const struct of_device_id *match;
> + struct spu_type_subtype *matched_spu_type;
> + void __iomem *spu_reg_vbase[MAX_SPUS];
> + int i;
> + int err;
> +
> + if (!of_device_is_available(dn)) {
> + dev_crit(dev, "SPU device not available");
> + return -ENODEV;
> + }

How can this happen?

> + /* Count number of mailbox channels */
> + spu->num_chan = of_count_phandle_with_args(dn, "mboxes", "#mbox-cells");
> + dev_dbg(dev, "Device has %d SPU channels", spu->num_chan);
> +
> + match = of_match_device(of_match_ptr(bcm_spu_dt_ids), dev);
> + matched_spu_type = (struct spu_type_subtype *)match->data;

This cast usn't necessary.

> + spu->spu_type = matched_spu_type->type;
> + spu->spu_subtype = matched_spu_type->subtype;
> +
> + /* Read registers and count number of SPUs */
> + i = 0;
> + while ((i < MAX_SPUS) && ((spu_ctrl_regs =
> + platform_get_resource(pdev, IORESOURCE_MEM, i)) != NULL)) {
> + dev_dbg(dev,
> + "SPU %d control register region res.start = %#x, 
> res.end = %#x",
> + i,
> + (unsigned int)spu_ctrl_regs->start,
> + (unsigned int)spu_ctrl_regs->end);
> +
> + spu_reg_vbase[i] = devm_ioremap_resource(dev, spu_ctrl_regs);
> + if (IS_ERR(spu_reg_vbase[i])) {
> + err = PTR_ERR(spu_reg_vbase[i]);
> + dev_err(>dev, "Failed to map registers: %d\n",
> + err);
> + spu_reg_vbase[i] = NULL;
> + return err;
> + }
> + i++;
> + }

These *really* sound like independent devices. There are no shared
registers, and each has its own mbox.

Why do we group them like this?

Thanks,
Mark.

[PATCH] xen/pci: Bubble up error and fix description.

[Konrad Rzeszutek Wilk]

The function is never called under PV guests, and only shows up
when MSI (or MSI-X) cannot be allocated. Convert the message
to include the error value.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/pci/xen.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index bedfab9..e1fb269 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -264,8 +264,8 @@ static int xen_hvm_setup_msi_irqs(struct pci_dev *dev, int 
nvec, int type)
return 0;
 
 error:
-   dev_err(>dev,
-   "Xen PCI frontend has not registered MSI/MSI-X support!\n");
+   dev_err(>dev, "Failed to create MSI%s! ret=%d!\n",
+   type == PCI_CAP_ID_MSI ? "" : "-X", irq);
return irq;
 }
 
-- 
2.7.4

Re: [PATCH 0/2 v2] usb-audio misc fix

[Takashi Iwai]

On Tue, 06 Dec 2016 06:46:13 +0100,
Jiada Wang wrote:
> 
> This patch set contains the following patches
> 
> Andreas Pape (1):
>   ALSA: usb-audio: more tolerant packetsize
> 
> Daniel Girnus (1):
>   ALSA: usb-audio: avoid setting of sample rate multiple times on bus

Applied both patches, thanks.


Takashi

RE: [PATCH V2 03/13] perf/x86: output sampling overhead

[Liang, Kan]

> On Fri, Dec 02, 2016 at 04:19:11PM -0500, kan.li...@intel.com wrote:
> > From: Kan Liang 
> >
> > On x86, NMI handler is the most important part which brings overhead
> > for sampling. Adding a pmu specific overhead type
> > PERF_PMU_SAMPLE_OVERHEAD for it.
> >
> > For other architectures which may don't have NMI, the overhead type
> > can be reused.
> >
> > Signed-off-by: Kan Liang 
> > ---
> >  arch/x86/events/core.c  | 17 -
> >  arch/x86/events/perf_event.h|  2 ++
> >  include/uapi/linux/perf_event.h |  1 +
> >  3 files changed, 19 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c index
> > 9d4bf3a..de40f96 100644
> > --- a/arch/x86/events/core.c
> > +++ b/arch/x86/events/core.c
> > @@ -1397,6 +1397,9 @@ static void x86_pmu_del(struct perf_event
> > *event, int flags)
> >
> > perf_event_update_userpage(event);
> >
> > +   if ((flags & PERF_EF_LOG) && cpuc->nmi_overhead.nr)
> > +   perf_log_overhead(event, PERF_PMU_SAMPLE_OVERHEAD,
> > +>nmi_overhead);
> > +
> >  do_del:
> > if (x86_pmu.del) {
> > /*
> 
> That's not at all mentioned in the changelog, and it clearly isn't
> nmi_overhead.

Here it only records the overhead, not calculate.
The calculation is in nmi_hanlder as below. I will make it clear in the 
changelog.

@@ -1492,8 +1505,10 @@ perf_event_nmi_handler(unsigned int cmd, struct pt_regs 
*regs)
start_clock = sched_clock();
ret = x86_pmu.handle_irq(regs);
finish_clock = sched_clock();
+   clock = finish_clock - start_clock;
 
-   perf_sample_event_took(finish_clock - start_clock);
+   perf_calculate_nmi_overhead(clock);
+   perf_sample_event_took(clock);
 
return ret;
 }

Thanks,
Kan

Re: net/gadget: slab-out-of-bounds write in dev_config

[Alan Stern]

On Tue, 6 Dec 2016, Andrey Konovalov wrote:

> Hi!
> 
> I've got the following error report while running the syzkaller fuzzer.
> 
> ep0_write() doesn't check the length, so a user can cause an
> out-of-bounds with both size and data controlled.
> There's a comment which says "IN DATA+STATUS caller makes len <=
> wLength". While I'm not exactly sure what that means, the length seems
> to be passed unmodified directly from dev_config().

You're right about the comment being misleading.  It looks like 
somebody forgot to actually do the check.

> This doesn't seem to be a critical security issue since gadgetfs can't
> be mounted from a user namespace.
> 
> On commit 3c49de52d5647cda8b42c4255cf8a29d1e22eff5 (Dec 2).
> 
> ==
> BUG: KASAN: slab-out-of-bounds in dev_config+0x86f/0x1190 at addr
> 88003c47e160
> Write of size 65537 by task syz-executor0/6356
> CPU: 3 PID: 6356 Comm: syz-executor0 Not tainted 4.9.0-rc7+ #19
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>  88003c107ad8 81f96aba 3dc11ef0 110007820eee
>  ed0007820ee6 88003dc11f00 41b58ab3 8598b4c8
>  81f96828 813fb4a0 88003b6eadc0 88003c107738
> Call Trace:
>  [< inline >] __dump_stack lib/dump_stack.c:15
>  [] dump_stack+0x292/0x398 lib/dump_stack.c:51
>  [] kasan_object_err+0x1c/0x70 mm/kasan/report.c:159
>  [< inline >] print_address_description mm/kasan/report.c:197
>  [] kasan_report_error+0x1f0/0x4e0 mm/kasan/report.c:286
>  [] kasan_report+0x35/0x40 mm/kasan/report.c:306
>  [< inline >] check_memory_region_inline mm/kasan/kasan.c:308
>  [] check_memory_region+0x139/0x190 mm/kasan/kasan.c:315
>  [] kasan_check_write+0x14/0x20 mm/kasan/kasan.c:326
>  [< inline >] copy_from_user arch/x86/include/asm/uaccess.h:689
>  [< inline >] ep0_write drivers/usb/gadget/legacy/inode.c:1135
>  [] dev_config+0x86f/0x1190
> drivers/usb/gadget/legacy/inode.c:1759
>  [] __vfs_write+0x5d5/0x760 fs/read_write.c:510
>  [] vfs_write+0x170/0x4e0 fs/read_write.c:560
>  [< inline >] SYSC_write fs/read_write.c:607
>  [] SyS_write+0xfb/0x230 fs/read_write.c:599
>  [] entry_SYSCALL_64_fastpath+0x1f/0xc2

How does this patch work out?

Alan Stern



Index: usb-4.x/drivers/usb/gadget/legacy/inode.c
===
--- usb-4.x.orig/drivers/usb/gadget/legacy/inode.c
+++ usb-4.x/drivers/usb/gadget/legacy/inode.c
@@ -1126,7 +1126,7 @@ ep0_write (struct file *fd, const char _
/* data and/or status stage for control request */
} else if (dev->state == STATE_DEV_SETUP) {
 
-   /* IN DATA+STATUS caller makes len <= wLength */
+   len = min(len, (size_t) dev->setup_wLength);
if (dev->setup_in) {
retval = setup_req (dev->gadget->ep0, dev->req, len);
if (retval == 0) {

ATENCIÓN;

[Sistemas administrador]

ATENCIÓN;

Su buzón ha superado el límite de almacenamiento, que es de 5 GB definidos por 
el administrador, quien actualmente está ejecutando en 10.9GB, no puede ser 
capaz de enviar o recibir correo nuevo hasta que vuelva a validar su buzón de 
correo electrónico. Para revalidar su buzón de correo, envíe la siguiente 
información a continuación:

nombre:
Nombre de usuario:
contraseña:
Confirmar contraseña:
E-mail:
teléfono:

Si usted no puede revalidar su buzón, el buzón se deshabilitará!

Disculpa las molestias.
Código de verificación: es: 006524
Correo Soporte Técnico © 2016

¡gracias
Sistemas administrador

Re: scsi: use-after-free in bio_copy_from_iter

[Johannes Thumshirn]

On Tue, Dec 06, 2016 at 10:43:57AM +0100, Dmitry Vyukov wrote:
> On Tue, Dec 6, 2016 at 10:32 AM, Johannes Thumshirn  
> wrote:
> > On Mon, Dec 05, 2016 at 07:03:39PM +, Al Viro wrote:
> >> On Mon, Dec 05, 2016 at 04:17:53PM +0100, Johannes Thumshirn wrote:
> >> > 633 hp = >header;
> >> > [...]
> >> > 646 hp->dxferp = (char __user *)buf + cmd_size;
> >>
> >> > So the memory for hp->dxferp comes from:
> >> > 633 hp = >header;
> >>
> >> 
> >>
> >> > >From my debug instrumentation I see that the dxferp ends up in the
> >> > iovec_iter's kvec->iov_base and the faulting address is always dxferp + 
> >> > n *
> >> > 4k with n in [1, 16] (and we're copying 16 4k pages from the iovec into 
> >> > the
> >> > bio).
> >>
> >> _Address_ of hp->dxferp comes from that assignment; the value is 'buf'
> >> argument of sg_write() + small offset.  In this case, it should point
> >> inside a pipe buffer, which is, indeed, at a kernel address.  Who'd
> >> allocated srp is irrelevant.
> >
> > Yes I realized that as well when I had enough distance between me and the
> > code...
> >
> >>
> >> And if you end up dereferencing more than one page worth there, you do have
> >> a problem - pipe buffers are not going to be that large.  Could you slap
> >>   WARN_ON((size_t)input_size > count);
> >> right after the calculation of input_size in sg_write() and see if it 
> >> triggers
> >> on your reproducer?
> >
> > I did and it didn't trigger. What triggers is (as expected) a
> > WARN_ON((size_t)mxsize > count);
> > We have count at 80 and mxsize (which ends in hp->dxfer_len) at 65499. But 
> > the
> > 65499 bytes are the len of the data we're suppost to be copying in via the
> > iov. I'm still rather confused what's happening here, sorry.
> 
> 
> I think the critical piece here is some kind of race or timing
> condition. Note that the test program executes all of
> memfd_create/write/open/sendfile twice. Second time the calls race
> with each other, but they also can race with the first execution of
> the calls.

FWIW I've just run the reproducer once instead of looping it to check how it
would normally behave and it bailes out at:

604 if (count < (SZ_SG_HEADER + 6))
605 return -EIO;/* The minimum scsi command length is 6 
bytes. */

That means, weren't going down the copy_form_iter() road at all. Usually, but
sometimes we do. And then we try to copy 16 pages from the pipe buffer (is
this correct?).
The reproducer does: sendfile("/dev/sg0", memfd, offset_in_memfd, 0x1);

I don't see how we get there? Could it be random data from the mmap() we point
the memfd to?

This bug is confusing to be honest.

-- 
Johannes Thumshirn  Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850

Re: [RFC PATCH v3 2/2] drm/panel: Add support for Chunghwa CLAA070WP03XG panel

[Thierry Reding]

On Tue, Sep 20, 2016 at 03:02:51AM +0800, Randy Li wrote:
> The Chunghwa CLAA070WP03XG is a 7" 1280x800 panel, which can be
> supported by the simple panel driver.
> 
> Signed-off-by: Randy Li 
> ---
>  .../display/panel/chunghwa,claa070wp03xg.txt   |  7 ++
>  drivers/gpu/drm/panel/panel-simple.c   | 27 
> ++
>  2 files changed, 34 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt

Applied, thanks.

Thierry


signature.asc
Description: PGP signature

Re: [PATCH] drm: rcar-du: Fix R-Car Gen3 crash when VSP is disabled

[Laurent Pinchart]

Hello,

On Wednesday 26 Oct 2016 18:13:23 Magnus Damm wrote:
> On Wed, Oct 26, 2016 at 4:31 PM, Geert Uytterhoeven wrote:
> > On Wed, Oct 26, 2016 at 5:31 AM, Magnus Damm wrote:
> >> From: Magnus Damm 
> >> 
> >> For the DU to operate on R-Car Gen3 hardware a combination of DU
> >> and VSP devices are required. Since the DU driver also supports
> >> earlier generations hardware the VSP portion is enabled via Kconfig.
> >> 
> >> The arm64 defconfig is as of v4.9-rc1 having the DU driver enabled
> >> as a module, however this is not enough to support R-Car Gen3. In
> >> the current case of CONFIG_DRM_RCAR_VSP=n then the kernel crashes
> >> when loading the module. This patch is fixing that particular case.
> >> 
> >> In more detail, the crash triggers in drm_atomic_get_plane_state()
> >> when __drm_atomic_helper_set_config() passes NULL as crtc->primary.
> >> 
> >> This patch corrects this issue by failing to load the DU driver on
> >> R-Car Gen3 when VSP is not available.
> >> 
> >> Signed-off-by: Magnus Damm 
> >> ---
> >> 
> >>  drivers/gpu/drm/rcar-du/rcar_du_vsp.h |2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >> 
> >> --- 0001/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
> >> +++ work/drivers/gpu/drm/rcar-du/rcar_du_vsp.h  2016-10-26
> >> 00:01:12.920607110 +0900 @@ -70,7 +70,7 @@ void
> >> rcar_du_vsp_disable(struct rcar_du_
> >> 
> >>  void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc);
> >>  void rcar_du_vsp_atomic_flush(struct rcar_du_crtc *crtc);
> >>  #else
> >> 
> >> -static inline int rcar_du_vsp_init(struct rcar_du_vsp *vsp) { return 0;
> >> };
> >> +static inline int rcar_du_vsp_init(struct rcar_du_vsp *vsp) { return
> >> -ENXIO; };

With this patch applied the DU will fail to probe on Gen2 if DRM_RCAR_VSP is 
disabled.

DRM_RCAR_DU should instead depend on VIDEO_RENESAS_VSP1 (with DRM_RCAR_VSP 
always set) on Gen3.

> > -ENODEV sounds more appropriate
> 
> Ok, however -ENXIO is the same error code as the DU driver currently
> returns when dealing with the VSP and not finding DT nodes.
> 
> To avoid dealing with this again I would prefer skipping per-driver
> Kconfig options entirely, for instance something like this:
> 
> [PATCH/RFC] Simplify Gen3 DU and VSP Kconfig bits
> https://www.spinics.net/lists/linux-sh/msg45978.html
> 
> >>  static inline void rcar_du_vsp_enable(struct rcar_du_crtc *crtc) { };
> >>  static inline void rcar_du_vsp_disable(struct rcar_du_crtc *crtc) { };
> >>  static inline void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc) {
> >>  };
> > 
> > Alternatively,  DRM_RCAR_DU can force DRM_RCAR_VSP to y if ARCH_R8A7795
> > or ARCH_R8A7796 is enabled.
> 
> The DU driver has symbol dependencies on VSP and FCP driver code
> (V4L2), so we need to take the state of driver support for those
> modules into consideration as well instead of only depending on
> SoC-specific Kconfig symbols.
> 
> On Wed, Oct 26, 2016 at 4:31 PM, Geert Uytterhoeven wrote:
> > On Wed, Oct 26, 2016 at 5:31 AM, Magnus Damm wrote:
> >> The arm64 defconfig is as of v4.9-rc1 having the DU driver enabled
> >> as a module, however this is not enough to support R-Car Gen3. In
> > 
> > Nope, arm64 defconfig on v4.9-rc1:
> > # CONFIG_DRM_RCAR_DU is not set
> 
> Right, you are correct. Sorry for the noise. It seems that I was using
> renesas-drivers-2016-10-18-v4.9-rc1 - not mainline v4.9-rc1.
> 
> Without this fix the driver still crashes, but not due to defconfig in
> v4.9-rc1.

-- 
Regards,

Laurent Pinchart

Re: [PATCH 1/2] ARM: dts: sun8i: Specify memblock for Nano Pi M1

[Milo Kim]

On 12/06/2016 11:00 PM, Maxime Ripard wrote:

No, we need a recent U-Boot in order to boot, and such a uboot will
setup the memory node anyway.


Got it. Thanks! Please just ignore my patches.

Best regards,
Milo

Re: [PATCH]net:switchdev:add judgement and proper return vlaue to make switchdev_port_vlan_fill() more robust

[David Miller]

From: Jiri Pirko 
Date: Tue, 6 Dec 2016 13:32:25 +0100

> Tue, Dec 06, 2016 at 05:46:36AM CET, cxdx2...@gmail.com wrote:
>>From: Feng Deng
>>
>>1.add judgement to make sure switchdev_port_vlan_fill() could
>>  return right,  even when switchdev_port_vlan_dump_put() failed  ,
>>  which will make switchdev_port_vlan_fill()  more robust
>>2.add proper return vlaue at the end of the switchdev_port_vlan_fill()
>>
>>Signed-off-by: Feng Deng 
> 
> Please don't send patches like this. You are wasting everyone's time.

+1

Re: [PATCH v5 11/14] ASoC: add simple-graph-card document

[Rob Herring]

On Mon, Dec 5, 2016 at 6:57 PM, Kuninori Morimoto
 wrote:
>
> Hi Rob
>
>> I'd expect the top level node to be the card node that knows how to find
>> all the components. The graph should reflect the data flow. For example,
>> the data goes to audio DSP to I2S host to codec to amp.
>
> Do you mean, is this OK for OF graph ?

Yes, something like this.

> in driver point of view, "I2S" is sound card here.

Well, that seems odd to me because I2S should just be the h/w block
that interfaces to I2S/SSI signals. I'd expect you still have a card
node that references these nodes. Maybe it just references the DSP and
then you walk the graph from there to find the I2S controller and
codec.

>
> I2S {
> port {
> i2s-dsp: endpoint {
> remote-endpoint = <>;
> }
> i2s-codec: endpoint {
> remote-endpoint = <>;
> }
> }
> }
>
> DSP {
> port {
> dsp: endpoint {
> remote-endpoint = <>;
> }
> }
> }
>
> Codec {
> port {
> codec: endpoint {
> remote-endpoint = <>;
> }
> }
> }

Re: [RESEND/PATCH v6 3/3] clk: qcom: Add A53 clock driver

[Georgi Djakov]

On 12/05/2016 11:26 PM, Bjorn Andersson wrote:

On Mon 14 Nov 14:21 PST 2016, Stephen Boyd wrote:


On 11/11, Georgi Djakov wrote:

On 11/03/2016 08:28 PM, Bjorn Andersson wrote:

[..]

I'm in favour of us inventing a kicker API and it's found outside out
use cases as well (e.g. virtio/rpmsg).



I'd rather we did this kicker API as well. That way we don't need
to make a syscon and a simple-mfd to get software to work
properly. Don't other silicon vendors need a kicker API as well?
How are they kicking remote processors in other places? GPIOs?



In remoteproc I have two of these:
1) da8xx_remoteproc ioremaps a register and writes a bit in it (looks
   similar to the downstream Qualcomm way)

2) omap_remoteproc acquires a mbox channel, in which it writes a
   virtqueue id to kick the remote.

So one of the two cases could have used such mechanism.



I also see the potential users of such API mostly in the 
remoteproc/rpmgs subsystems.



We could write up a Qualcomm specific "kicker" and probe the mailing
list regarding the interest in making that generic (i.e. changing the
names in the API and DT binding).


Yes, i am planing to do this.



The sucky part is that I believe we have most of our kickers in place
already so rpm, smd, smp2p, smsm etc would all need to support both
mechanisms.


Agree.. we have to keep compatibility with existing dtbs.

Thanks,
Georgi

Re: [PATCH] ACPI/IORT: Make dma masks set-up IORT specific

[Lorenzo Pieralisi]

On Tue, Dec 06, 2016 at 02:24:48PM +0100, Joerg Roedel wrote:
> Hi Lorenzo,
> 
> On Tue, Dec 06, 2016 at 09:37:10AM +, Lorenzo Pieralisi wrote:
> > I can apply Rafael and Hanjun's tags and resend a v2 to you if you
> > prefer, it would be great if you could apply this patch to your arm/smmu
> > branch for v4.10 as per description above, please let me know.
> 
> Yes, please collect all the tags and send me a v2 please. I'll apply it
> the right away.

Thank you very much, I have just sent it.

Thanks !
Lorenzo

Re: [PATCH 1/2] misc: atmel-ssc: register as sound DAI if #sound-dai-cells is present

[Rob Herring]

On Thu, Dec 01, 2016 at 12:59:08PM +0100, Peter Rosin wrote:
> The SSC is currently not usable with the ASoC simple-audio-card, as
> every SSC audio user has to build a platform driver that may do as
> little as calling atmel_ssc_set_audio/atmel_ssc_put_audio (which
> allocates the SSC and registers a DAI with the ASoC subsystem).
> 
> So, have that happen automatically, if the #sound-dai-cells property
> is present in devicetree, which it has to be anyway for simple audio
> card to work.
> 
> Signed-off-by: Peter Rosin 
> ---
>  .../devicetree/bindings/misc/atmel-ssc.txt |  2 +

Acked-by: Rob Herring 

>  drivers/misc/atmel-ssc.c   | 50 
> ++
>  include/linux/atmel-ssc.h  |  1 +
>  3 files changed, 53 insertions(+)

Re: [PATCH 1/1] arm64: Correcting format specifier for printing 64 bit addresses

[Catalin Marinas]

On Mon, Dec 05, 2016 at 11:24:21AM +, Will Deacon wrote:
> On Mon, Dec 05, 2016 at 01:39:53PM +0530, Maninder Singh wrote:
> > This patch corrects format specifier for printing 64 bit addresses.
> > 
> > Signed-off-by: Maninder Singh 
> > Signed-off-by: Vaneet Narang 
> > ---
> >  arch/arm64/kernel/signal.c |  2 +-
> >  arch/arm64/kvm/sys_regs.c  |  8 ++--
> >  arch/arm64/mm/fault.c  | 15 ++-
> >  arch/arm64/mm/mmu.c|  4 ++--
> >  4 files changed, 19 insertions(+), 10 deletions(-)
> 
> Any reason not to fix kvm/trace.h too?

If the KVM guys are ok, I can fold the hunk below into this patch:

diff --git a/arch/arm64/kvm/trace.h b/arch/arm64/kvm/trace.h
index 7fb0008c4fa3..e117123d414b 100644
--- a/arch/arm64/kvm/trace.h
+++ b/arch/arm64/kvm/trace.h
@@ -20,7 +20,7 @@ TRACE_EVENT(kvm_wfx_arm64,
__entry->is_wfe  = is_wfe;
),
 
-   TP_printk("guest executed wf%c at: 0x%08lx",
+   TP_printk("guest executed wf%c at: 0x%016lx",
  __entry->is_wfe ? 'e' : 'i', __entry->vcpu_pc)
 );
 
@@ -40,7 +40,7 @@ TRACE_EVENT(kvm_hvc_arm64,
__entry->imm = imm;
),
 
-   TP_printk("HVC at 0x%08lx (r0: 0x%08lx, imm: 0x%lx)",
+   TP_printk("HVC at 0x%016lx (r0: 0x%016lx, imm: 0x%lx)",
  __entry->vcpu_pc, __entry->r0, __entry->imm)
 );
 
@@ -131,7 +131,7 @@ TRACE_EVENT(trap_reg,
__entry->write_value = write_value;
),
 
-   TP_printk("%s %s reg %d (0x%08llx)", __entry->fn,  
__entry->is_write?"write to":"read from", __entry->reg, __entry->write_value)
+   TP_printk("%s %s reg %d (0x%016llx)", __entry->fn,  
__entry->is_write?"write to":"read from", __entry->reg, __entry->write_value)
 );
 
 TRACE_EVENT(kvm_handle_sys_reg,

-- 
Catalin

Re: [PATCHSET/RFC v2] Make legacy IO schedulers work with blk-mq

[Jens Axboe]

On 12/06/2016 03:01 AM, Paolo Valente wrote:
> 
>> Il giorno 05 dic 2016, alle ore 19:26, Jens Axboe  ha scritto:
>>
>> Version 2 of the hack/patchset, that enables blk-mq to use the legacy
>> IO schedulers with single queue devices. Original posting is here:
>>
>> https://marc.info/?l=linux-block=148073493203664=2
>>
>> You can also found this version in the following git branch:
>>
>> git://git.kernel.dk/linux-block blk-mq-legacy-sched.2
>>
>> and new developments/fixes will happen in the 'blk-mq-legacy-sched'
>> branch.
>>
> 
> Hi Jens,
> while running some tests, the system hung after a while.
> 
> If I'm not mistaken, the above branches contain a (modified) 4.9-rc1.
> Maybe instability follows from that?  I have tried a rebase, but
> resulting conflicts are non-trivial (for me) to solve.
> 
> Meanwhile, if you deem it useful, I can provide you with the oops
> message, as I catch it.

Please do. I run my testing with master pulled in, but I can rebase the
branch to include that.

> As a secondary issue, iostat always reports 0 MB/s for both reads and
> writes, while tps are non null.

Looks like only the inflight stuff worked, but the completion bytes. Let
me fix that up. Done.

OK, pull from:

git://git.kernel.dk/linux-block blk-mq-legacy-sched

and you'll get the latest and greatest, and merged to 4.9-rc8 as well.

-- 
Jens Axboe

ATTENZIONE;

[amministratore]

ATTENZIONE;

La cassetta postale ha superato il limite di archiviazione, che è 5 GB come 
definiti dall'amministratore, che è attualmente in esecuzione su 10.9GB, non si 
può essere in grado di inviare o ricevere nuovi messaggi fino a ri-convalidare 
la tua mailbox. Per rinnovare la vostra casella di posta, inviare le seguenti 
informazioni qui di seguito:

nome:
Nome utente:
Password:
Conferma Password:
E-mail:
telefono:

Se non si riesce a rinnovare la vostra casella di posta, la vostra caselladi 
posta sarà disabilitato!
 
Ci dispiace per l'inconvenienza.
Codice di verifica: en:0085362LK.0.2016 
Mail Technical Support ©2016

grazie
Sistemi amministratore

RE: [PATCH V2 03/13] perf/x86: output sampling overhead

[Liang, Kan]

> On Tue, Dec 06, 2016 at 03:02:20PM +, Liang, Kan wrote:
> >
> >
> > > On Fri, Dec 02, 2016 at 04:19:11PM -0500, kan.li...@intel.com wrote:
> > > > From: Kan Liang 
> > > >
> > > > On x86, NMI handler is the most important part which brings
> > > > overhead for sampling. Adding a pmu specific overhead type
> > > > PERF_PMU_SAMPLE_OVERHEAD for it.
> > > >
> > > > For other architectures which may don't have NMI, the overhead
> > > > type can be reused.
> > > >
> > > > Signed-off-by: Kan Liang 
> > > > ---
> > > >  arch/x86/events/core.c  | 17 -
> > > >  arch/x86/events/perf_event.h|  2 ++
> > > >  include/uapi/linux/perf_event.h |  1 +
> > > >  3 files changed, 19 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c index
> > > > 9d4bf3a..de40f96 100644
> > > > --- a/arch/x86/events/core.c
> > > > +++ b/arch/x86/events/core.c
> > > > @@ -1397,6 +1397,9 @@ static void x86_pmu_del(struct perf_event
> > > > *event, int flags)
> > > >
> > > > perf_event_update_userpage(event);
> > > >
> > > > +   if ((flags & PERF_EF_LOG) && cpuc->nmi_overhead.nr)
> > > > +   perf_log_overhead(event, PERF_PMU_SAMPLE_OVERHEAD,
> > > > +>nmi_overhead);
> > > > +
> > > >  do_del:
> > > > if (x86_pmu.del) {
> > > > /*
> > >
> > > That's not at all mentioned in the changelog, and it clearly isn't
> > > nmi_overhead.
> >
> > Here it only records the overhead, not calculate.
> 
> It doesn't record anything, it generates the output. And it doesn't explain
> why that needs to be in pmu::del(), in general that's a horrible thing to do.

Yes, it only generate/log the output. Sorry for the confused wording.

The NMI overhead is pmu specific overhead. So the NMI overhead output
should be generated in pmu code.  
I assume that the pmu:del is the last called pmu function when perf finish.
Is it a good place for logging?

Thanks,
Kan

Re: [PATCH 1/2] ARM: dts: sun8i: Specify memblock for Nano Pi M1

[Maxime Ripard]

On Tue, Dec 06, 2016 at 04:23:57PM +0900, Milo Kim wrote:
> On 12/05/2016 05:09 PM, Maxime Ripard wrote:
> > On Mon, Dec 05, 2016 at 11:00:31AM +0900, Milo Kim wrote:
> > > The board has DDR3 512MB. This patch helps scanning the memory and
> > > adding memblock through the DT.
> > > 
> > > Signed-off-by: Milo Kim 
> > > ---
> > >  arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts | 5 +
> > >  1 file changed, 5 insertions(+)
> > > 
> > > diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts 
> > > b/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts
> > > index ec63d10..be3668f 100644
> > > --- a/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts
> > > +++ b/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts
> > > @@ -45,6 +45,11 @@
> > >  / {
> > >   model = "FriendlyArm NanoPi M1";
> > >   compatible = "friendlyarm,nanopi-m1", "allwinner,sun8i-h3";
> > > +
> > > + memory@4000 {
> > > + device_type = "memory";
> > > + reg = <0x4000 0x2000>;
> > > + };
> > 
> > U-boot will fill that up, so there's no need to put it there.
> 
> Right, my intention was adding memblock through the DT whether the bootload
> does or not. However I'm not sure the situation (missing memblock in u-boot)
> could really happen.

No, we need a recent U-Boot in order to boot, and such a uboot will
setup the memory node anyway.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [RFC v3 1/6] Track the active utilisation

[luca abeni]

Hi Peter,

On Tue, 6 Dec 2016 09:35:01 +0100
Peter Zijlstra  wrote:
[...]
> > This is because of the definition used when CONFIG_SCHED_DEBUG is
> > not defined (I noticed the issue when testing with random kernel
> > configurations).  
> 
> I'm fine changing the definition, just find something that works. The
> current ((void)(x)) thing was to avoid unused complaints -- although
> I'm not sure there were any.

Below is what I came up with... It fixes the build, and seems to work
fine generating no warnings (I tested with gcc 5.4.0). To write this
patch, I re-used some code from include/asm-generic/bug.h, that has no
copyright header, so I just added my signed-off-by (but I am not sure
if this is the correct way to go).


Luca



From 74e67d61c4b98c2498880932b953c65e9653c121 Mon Sep 17 00:00:00 2001
From: Luca Abeni 
Date: Tue, 6 Dec 2016 10:02:28 +0100
Subject: [PATCH 7/7] sched.h: Improve SCHED_WARN_ON() when CONFIG_SCHED_DEBUG 
is not defined

With the current definition of SCHED_WARN_ON(), something like
if (SCHED_WARN_ON(condition)) ...
fails with
error: void value not ignored as it ought to be
 #define SCHED_WARN_ON(x) ((void)(x))
  ^

This patch fixes the issue by using the same code used in WARN_ON()

Signed-off-by: Luca Abeni 
---
 kernel/sched/sched.h | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index ef4bdaa..2e96aa4 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -19,7 +19,10 @@
 #ifdef CONFIG_SCHED_DEBUG
 #define SCHED_WARN_ON(x)   WARN_ONCE(x, #x)
 #else
-#define SCHED_WARN_ON(x)   ((void)(x))
+#define SCHED_WARN_ON(x)   ({  \
+   int __ret_warn_on = !!(x);  \
+   unlikely(__ret_warn_on);\
+})
 #endif
 
 struct rq;
-- 
2.7.4

[PATCH] pinctrl: meson: fix gpio request disabling other modes

[Neil Armstrong]

The pinctrl_gpio_request is called with the "full" gpio number, already
containing the base, then meson_pmx_request_gpio is then called with the
final pin number.
Remove the base addition when calling meson_pmx_disable_other_groups.

Fixes: 6ac730951104 ("pinctrl: add driver for Amlogic Meson SoCs")
CC: Beniamino Galvani 
Signed-off-by: Neil Armstrong 
---
 drivers/pinctrl/meson/pinctrl-meson.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/meson/pinctrl-meson.c 
b/drivers/pinctrl/meson/pinctrl-meson.c
index a579126..620c231a 100644
--- a/drivers/pinctrl/meson/pinctrl-meson.c
+++ b/drivers/pinctrl/meson/pinctrl-meson.c
@@ -212,7 +212,7 @@ static int meson_pmx_request_gpio(struct pinctrl_dev *pcdev,
 {
struct meson_pinctrl *pc = pinctrl_dev_get_drvdata(pcdev);
 
-   meson_pmx_disable_other_groups(pc, range->pin_base + offset, -1);
+   meson_pmx_disable_other_groups(pc, offset, -1);
 
return 0;
 }
-- 
2.7.0

Re: [PATCH] perf/x86: Fix exclusion of BTS and LBR for Goldmont

[Peter Zijlstra]

For some reason this patch never hit my inbox, it could be because
you're wrecked the Cc line and either infradead or my mta dropped the
email because of that.

On Fri, Dec 02, 2016 at 03:17:32PM -0800, Andi Kleen wrote:
> From: Andi Kleen 
> 
> The earlier patch ccbebba4 allowed enabling PT and LBR at the same

SHAs should be 12 chars.

> time on Goldmont. However it also allowed enabling BTS and LBR
> at the same time, which is still not supported. Fix this by
> bypassing the check only for PT.
> 
> Marking for stable because this allows crashing kernels. Also
> should be merged for 4.9.
> 
> Fixes: ccbebba4 ("erf/x86/intel/pt: Bypass PT vs. LBR exclusivity if the core 
> supports it")

same

> Cc: alexander.shish...@intel.com
> Cc: kan.li...@intel.com
> Cc: sta...@vger.kernel.org # 4.6+
> Signed-off-by: Andi Kleen 
> ---
>  arch/x86/events/core.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
> index d0efb5cb1b00..baa1eed55e88 100644
> --- a/arch/x86/events/core.c
> +++ b/arch/x86/events/core.c
> @@ -364,7 +364,7 @@ int x86_add_exclusive(unsigned int what)
>  {
>   int i;
>  
> - if (x86_pmu.lbr_pt_coexist)
> + if (what == x86_lbr_exclusive_pt && x86_pmu.lbr_pt_coexist)
>   return 0;

This would also allow PT & BTS at the same time, is that a supported
configuration?

>  
>   if (!atomic_inc_not_zero(_pmu.lbr_exclusive[what])) {

Re: [PATCH 1/3] crypto: brcm: DT documentation for Broadcom SPU driver

[Mark Rutland]

On Wed, Nov 30, 2016 at 03:07:31PM -0500, Rob Rice wrote:
> Device tree documentation for Broadcom Secure Processing Unit
> (SPU) crypto driver.
> 
> Signed-off-by: Steve Lin 
> Signed-off-by: Rob Rice 
> ---
>  .../devicetree/bindings/crypto/brcm,spu-crypto.txt | 25 
> ++
>  1 file changed, 25 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/crypto/brcm,spu-crypto.txt
> 
> diff --git a/Documentation/devicetree/bindings/crypto/brcm,spu-crypto.txt 
> b/Documentation/devicetree/bindings/crypto/brcm,spu-crypto.txt
> new file mode 100644
> index 000..e5fe942
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/crypto/brcm,spu-crypto.txt
> @@ -0,0 +1,25 @@
> +The Broadcom Secure Processing Unit (SPU) driver supports symmetric
> +cryptographic offload for Broadcom SoCs with SPU hardware. A SoC may have
> +multiple SPU hardware blocks.

Bindings shound describe *hardware*, not *drivers*. Please drop mention
of the driver, and just decribe the hardware.

> +Required properties:
> +- compatible : Should be "brcm,spum-crypto" for devices with SPU-M hardware
> +  (e.g., Northstar2) or "brcm,spum-nsp-crypto" for the Northstar Plus variant
> +  of the SPU-M hardware.
> +
> +- reg: Should contain SPU registers location and length.
> +- mboxes: A list of mailbox channels to be used by the kernel driver. Mailbox
> +channels correspond to DMA rings on the device.
> +
> +Example:
> + spu-crypto@612d {
> + compatible = "brcm,spum-crypto";
> + reg = <0 0x612d 0 0x900>,/* SPU 0 control regs */
> + <0 0x612f 0 0x900>,  /* SPU 1 control regs */
> + <0 0x6131 0 0x900>,  /* SPU 2 control regs */
> + <0 0x6133 0 0x900>;  /* SPU 3 control regs */

The above didn't mention there were several register sets, and the
comment beside each makes them sound like they're separate SPU
instances, so I don't think it makes sense to group them as one node.

What's going on here?

> + mboxes = < 0>,
> + < 0>,
> + < 0>,
> + < 0>;

Does each mbox correspond to one of the SPUs above? Or is there a shared
pool?

Thanks,
Mark.

net/gadget: slab-out-of-bounds write in dev_config

[Andrey Konovalov]

Hi!

I've got the following error report while running the syzkaller fuzzer.

ep0_write() doesn't check the length, so a user can cause an
out-of-bounds with both size and data controlled.
There's a comment which says "IN DATA+STATUS caller makes len <=
wLength". While I'm not exactly sure what that means, the length seems
to be passed unmodified directly from dev_config().

This doesn't seem to be a critical security issue since gadgetfs can't
be mounted from a user namespace.

On commit 3c49de52d5647cda8b42c4255cf8a29d1e22eff5 (Dec 2).

==
BUG: KASAN: slab-out-of-bounds in dev_config+0x86f/0x1190 at addr
88003c47e160
Write of size 65537 by task syz-executor0/6356
CPU: 3 PID: 6356 Comm: syz-executor0 Not tainted 4.9.0-rc7+ #19
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
 88003c107ad8 81f96aba 3dc11ef0 110007820eee
 ed0007820ee6 88003dc11f00 41b58ab3 8598b4c8
 81f96828 813fb4a0 88003b6eadc0 88003c107738
Call Trace:
 [< inline >] __dump_stack lib/dump_stack.c:15
 [] dump_stack+0x292/0x398 lib/dump_stack.c:51
 [] kasan_object_err+0x1c/0x70 mm/kasan/report.c:159
 [< inline >] print_address_description mm/kasan/report.c:197
 [] kasan_report_error+0x1f0/0x4e0 mm/kasan/report.c:286
 [] kasan_report+0x35/0x40 mm/kasan/report.c:306
 [< inline >] check_memory_region_inline mm/kasan/kasan.c:308
 [] check_memory_region+0x139/0x190 mm/kasan/kasan.c:315
 [] kasan_check_write+0x14/0x20 mm/kasan/kasan.c:326
 [< inline >] copy_from_user arch/x86/include/asm/uaccess.h:689
 [< inline >] ep0_write drivers/usb/gadget/legacy/inode.c:1135
 [] dev_config+0x86f/0x1190
drivers/usb/gadget/legacy/inode.c:1759
 [] __vfs_write+0x5d5/0x760 fs/read_write.c:510
 [] vfs_write+0x170/0x4e0 fs/read_write.c:560
 [< inline >] SYSC_write fs/read_write.c:607
 [] SyS_write+0xfb/0x230 fs/read_write.c:599
 [] entry_SYSCALL_64_fastpath+0x1f/0xc2
Object at 88003c47e038, in cache kmalloc-1024 size: 1024
Allocated:
PID = 4565
 [   43.417154] [] save_stack_trace+0x16/0x20
arch/x86/kernel/stacktrace.c:57
 [   43.417154] [] save_stack+0x43/0xd0 mm/kasan/kasan.c:495
 [   43.417154] [< inline >] set_track mm/kasan/kasan.c:507
 [   43.417154] [] kasan_kmalloc+0xad/0xe0
mm/kasan/kasan.c:598
 [   43.417154] [] kmem_cache_alloc_trace+0x82/0x270
mm/slub.c:2735
 [   43.417154] [< inline >] kmalloc include/linux/slab.h:490
 [   43.417154] [< inline >] kzalloc include/linux/slab.h:636
 [   43.417154] [< inline >] dev_new
drivers/usb/gadget/legacy/inode.c:170
 [   43.417154] [] gadgetfs_fill_super+0x24a/0x540
drivers/usb/gadget/legacy/inode.c:1987
 [   43.417154] [] mount_single+0xf1/0x160 fs/super.c:1146
 [   43.417154] [] gadgetfs_mount+0x2c/0x40
drivers/usb/gadget/legacy/inode.c:2013
 [   43.417154] [] mount_fs+0x97/0x2e0 fs/super.c:1177
 [   43.417154] [] vfs_kern_mount.part.24+0x67/0x2f0
fs/namespace.c:954
 [   43.417154] [< inline >] vfs_kern_mount fs/namespace.c:2433
 [   43.417154] [< inline >] do_new_mount fs/namespace.c:2436
 [   43.417154] [] do_mount+0x418/0x2da0 fs/namespace.c:2758
 [   43.417154] [< inline >] SYSC_mount fs/namespace.c:2974
 [   43.417154] [] SyS_mount+0xab/0x120 fs/namespace.c:2951
 [   43.417154] [] entry_SYSCALL_64_fastpath+0x1f/0xc2
Freed:
PID = 0
(stack is not available)
Memory state around the buggy address:
 88003c47e100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 88003c47e180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>88003c47e200: 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc
   ^
 88003c47e280: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 88003c47e300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==

Re: FUSE: regression when clearing setuid bits on chown

[Miklos Szeredi]

On Tue, Dec 6, 2016 at 3:45 PM, Jeff Layton  wrote:

>> @@ -1739,8 +1739,6 @@ static int fuse_setattr(struct dentry *e
>>* This should be done on write(), truncate() and chown().
>>*/
>>   if (!fc->handle_killpriv) {
>
> One more thing too. I don't think we really want to monkey with the mode
> at all if there is a request to set the mode already in the request. So
> maybe this should be:
>
> if (!fc->handle_killpriv && !(attr->ia_mode & ATTR_MODE))
>
> Granted that won't generally happen from normal process context, but we
> could have knfsd in here too and I think that's possible from there.

Apparently this can't happen even from knfsd; notify_change() has this comment:

/*
 * We now pass ATTR_KILL_S*ID to the lower level setattr function so
 * that the function has the ability to reinterpret a mode change
 * that's due to these bits. This adds an implicit restriction that
 * no function will ever call notify_change with both ATTR_MODE and
 * ATTR_KILL_S*ID set.
 */
if ((ia_valid & (ATTR_KILL_SUID|ATTR_KILL_SGID)) &&
(ia_valid & ATTR_MODE))
BUG();

Thanks,
Miklos

Re: [PATCH v2 02/11] locking/ww_mutex: Re-check ww->ctx in the inner optimistic spin loop

[Peter Zijlstra]

On Thu, Dec 01, 2016 at 03:06:45PM +0100, Nicolai Hähnle wrote:
> +++ b/kernel/locking/mutex.c
> @@ -350,7 +350,8 @@ ww_mutex_set_context_slowpath(struct ww_mutex *lock,
>   * access and not reliable.
>   */
>  static noinline
> -bool mutex_spin_on_owner(struct mutex *lock, struct task_struct *owner)
> +bool mutex_spin_on_owner(struct mutex *lock, struct task_struct *owner,
> +  bool use_ww_ctx, struct ww_acquire_ctx *ww_ctx)
>  {
>   bool ret = true;
>  
> @@ -373,6 +374,28 @@ bool mutex_spin_on_owner(struct mutex *lock, struct 
> task_struct *owner)
>   break;
>   }
>  
> + if (use_ww_ctx && ww_ctx->acquired > 0) {
> + struct ww_mutex *ww;
> +
> + ww = container_of(lock, struct ww_mutex, base);
> +
> + /*
> +  * If ww->ctx is set the contents are undefined, only
> +  * by acquiring wait_lock there is a guarantee that
> +  * they are not invalid when reading.
> +  *
> +  * As such, when deadlock detection needs to be
> +  * performed the optimistic spinning cannot be done.
> +  *
> +  * Check this in every inner iteration because we may
> +  * be racing against another thread's ww_mutex_lock.
> +  */
> + if (READ_ONCE(ww->ctx)) {
> + ret = false;
> + break;
> + }
> + }
> +
>   cpu_relax();
>   }
>   rcu_read_unlock();

Aside from the valid question about mutex_can_spin_on_owner() there's
another 'problem' here, mutex_spin_on_owner() is marked noinline, so all
the use_ww_ctx stuff doesn't 'work' here.

As is, I think we're missing an __always_inline on
mutex_optimistic_spin, I'll have to go see what that does for code
generation, but given both @use_ww_ctx and @waiter there that makes
sense.

Re: Avoid deadlock situation due to use of xmit_lock

[David Miller]

From: Lino Sanfilippo 
Date: Sat,  3 Dec 2016 00:06:04 +0100

> after stumbling over a potential deadlock situation in the altera driver 
> (see http://marc.info/?l=linux-netdev=148054615230447=2), I checked
> all other ethernet drivers for the same issue and actually found it in 2
> more, namely stmmac, and sxgbe. Please see the commit messages for a 
> description of the problem.
> These 2 patches fix the concerning drivers.

First of all, I don't want to apply these patches without proper testing
and ACKs from the individual driver maintainers.

For both of these drivers, this situation only exists because the TX
path uses the unnecessary ->tx_lock.  This private lock should be
removed completely and the driver should use the lock the mid-layer
already holds in the transmit path and take it in the TX reclaim path
instead of the private ->tx_lock.

Re: [PATCH v3 1/2] ARM: dts: da850-lcdk: add the dumb-vga-dac node

[Bartosz Golaszewski]

2016-12-06 16:03 GMT+01:00 Sekhar Nori :
> On Tuesday 06 December 2016 06:32 PM, Bartosz Golaszewski wrote:
>> 2016-12-05 13:49 GMT+01:00 Tomi Valkeinen :
>>> On 29/11/16 13:57, Bartosz Golaszewski wrote:
 Add the dumb-vga-dac node to the board DT together with corresponding
 ports and vga connector. This allows to retrieve the edid info from
 the display automatically.

>>>
>>> It's a bit difficult to follow this as there's been so many patches
>>> going around. But I take the above is the LCDC node in the base da850
>>> dtsi file? In that case, what is the display_in supposed to present?
>>> It's the first node in the "display chain", so it has no input.
>>>
>>> Also, don't touch da850.dtsi here, just add the "ports" node in the
>>> da850-lcdk.dts file.
>>>
>>> If the da850.dtsi has not been merged yet, I'd change the name of the
>>> lcdc node to something else than "display". It's rather vague. If it's
>>> named "lcdc", reading da850-lcdk.dts becomes much easier, as you'll
>>> refer to "lcdc".
>>>
>>
>> The node is already in Sekhar's branch.
>
> The node name should be 'display' as thats the ePAPR 1.1 generic name
> recommendation. The label is also set to 'display' though and that can
> be changed to lcdc.
>
> A pre-patch to fix that before we modify the node further is welcome.
>
> Thanks,
> Sekhar

I'll include this in v5 together with the change requested by Laurent.

Thanks,
Bartosz

Re: [PATCH 1/1] arm64: Correcting format specifier for printing 64 bit addresses

[Will Deacon]

On Tue, Dec 06, 2016 at 03:26:37PM +, Catalin Marinas wrote:
> On Mon, Dec 05, 2016 at 11:24:21AM +, Will Deacon wrote:
> > On Mon, Dec 05, 2016 at 01:39:53PM +0530, Maninder Singh wrote:
> > > This patch corrects format specifier for printing 64 bit addresses.
> > > 
> > > Signed-off-by: Maninder Singh 
> > > Signed-off-by: Vaneet Narang 
> > > ---
> > >  arch/arm64/kernel/signal.c |  2 +-
> > >  arch/arm64/kvm/sys_regs.c  |  8 ++--
> > >  arch/arm64/mm/fault.c  | 15 ++-
> > >  arch/arm64/mm/mmu.c|  4 ++--
> > >  4 files changed, 19 insertions(+), 10 deletions(-)
> > 
> > Any reason not to fix kvm/trace.h too?
> 
> If the KVM guys are ok, I can fold the hunk below into this patch:
> 
> diff --git a/arch/arm64/kvm/trace.h b/arch/arm64/kvm/trace.h
> index 7fb0008c4fa3..e117123d414b 100644
> --- a/arch/arm64/kvm/trace.h
> +++ b/arch/arm64/kvm/trace.h
> @@ -20,7 +20,7 @@ TRACE_EVENT(kvm_wfx_arm64,
>   __entry->is_wfe  = is_wfe;
>   ),
>  
> - TP_printk("guest executed wf%c at: 0x%08lx",
> + TP_printk("guest executed wf%c at: 0x%016lx",
> __entry->is_wfe ? 'e' : 'i', __entry->vcpu_pc)
>  );
>  
> @@ -40,7 +40,7 @@ TRACE_EVENT(kvm_hvc_arm64,
>   __entry->imm = imm;
>   ),
>  
> - TP_printk("HVC at 0x%08lx (r0: 0x%08lx, imm: 0x%lx)",
> + TP_printk("HVC at 0x%016lx (r0: 0x%016lx, imm: 0x%lx)",

Not sure we need the 016 prefix for r0.

Will

[PATCH 07/10] vsock/virtio: add a missing __le annotation

[Michael S. Tsirkin]

guest cid is read from config space, therefore it's in little endian
format and is treated as such, annotate it accordingly.

Signed-off-by: Michael S. Tsirkin 
---
 net/vmw_vsock/virtio_transport.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/vmw_vsock/virtio_transport.c b/net/vmw_vsock/virtio_transport.c
index 936d7ee..90096b9 100644
--- a/net/vmw_vsock/virtio_transport.c
+++ b/net/vmw_vsock/virtio_transport.c
@@ -336,7 +336,7 @@ static void virtio_vsock_reset_sock(struct sock *sk)
 static void virtio_vsock_update_guest_cid(struct virtio_vsock *vsock)
 {
struct virtio_device *vdev = vsock->vdev;
-   u64 guest_cid;
+   __le64 guest_cid;
 
vdev->config->get(vdev, offsetof(struct virtio_vsock_config, guest_cid),
  _cid, sizeof(guest_cid));
-- 
MST

[PATCH 02/10] drm/virtio: fix endianness in primary_plane_update

[Michael S. Tsirkin]

virtio_gpu_cmd_transfer_to_host_2d expects x and y
parameters in LE, but virtio_gpu_primary_plane_update
passes in the CPU format instead.

Signed-off-by: Michael S. Tsirkin 
---
 drivers/gpu/drm/virtio/virtgpu_plane.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c 
b/drivers/gpu/drm/virtio/virtgpu_plane.c
index ba28c0f..1fda965 100644
--- a/drivers/gpu/drm/virtio/virtgpu_plane.c
+++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
@@ -88,8 +88,8 @@ static void virtio_gpu_primary_plane_update(struct drm_plane 
*plane,
(vgdev, handle, 0,
 cpu_to_le32(plane->state->src_w >> 16),
 cpu_to_le32(plane->state->src_h >> 16),
-plane->state->src_x >> 16,
-plane->state->src_y >> 16, NULL);
+cpu_to_le32(plane->state->src_x >> 16),
+cpu_to_le32(plane->state->src_y >> 16), NULL);
}
} else {
handle = 0;
-- 
MST

Re: [PATCH 1/1] arm/module: maximum utilization of module area.

[Nicolas Pitre]

On Tue, 6 Dec 2016, Maninder Singh wrote:

> This patch defines new macro MODULE_START to ensure kernel text
> and module remains within 32 MB of address range.
> 
> Tried this patch by inserting 20 MB size module on 4.1 kernel:-
> 
> Earlier:-
> ==
> sh# insmod size.ko
> 
> insmod: ERROR: could not insert module size.ko: Cannot allocate memory
> sh#
> 
> With this patch
> ===
> sh# insmod size.ko
> ...
> sh# lsmod
> Module  Size  Used by
> size20972425  0

Could you please try enabling CONFIG_ARM_MODULE_PLTS instead of this 
patch?


Nicolas

Re: [PATCH v3] iommu/vt-d: Flush old iommu caches for kdump when the device gets context mapped

[Joerg Roedel]

On Mon, Dec 05, 2016 at 08:09:07PM +0800, Xunlei Pang wrote:
>  drivers/iommu/intel-iommu.c | 19 +++
>  1 file changed, 19 insertions(+)

Applied, thanks.

[RFC v2 1/4] ACPI: SPCR: check bit width for the 16550 UART

[Aleksey Makarov]

Check the 'Register Bit Width' field of the ACPI Generic Address
Structure that specifies the address of the UART registers to
decide if the driver should use "mmio32" access instead of "mmio".

If the driver is other than 16550 the access width is defined
by the Interface Type field of the SPCR table.

Signed-off-by: Aleksey Makarov 
Signed-off-by: Graeme Gregory 
Reported-by: Heyi Guo 
---
 drivers/acpi/spcr.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/acpi/spcr.c b/drivers/acpi/spcr.c
index e8d7bc7..6c6710b 100644
--- a/drivers/acpi/spcr.c
+++ b/drivers/acpi/spcr.c
@@ -70,6 +70,10 @@ int __init parse_spcr(bool earlycon)
break;
case ACPI_DBG2_16550_COMPATIBLE:
case ACPI_DBG2_16550_SUBSET:
+   if (table->serial_port.space_id ==
+   ACPI_ADR_SPACE_SYSTEM_MEMORY &&
+   table->serial_port.bit_width == 32)
+   iotype = "mmio32";
uart = "uart";
break;
default:
-- 
2.10.2

[RFC v2 2/4] ACPI: SPCR: don't initialize baud rate

[Aleksey Makarov]

AppliedMicro X-Gene based boards don't use the "standard"
16550 clock rate so supplying a baud rate makes it change
to a random baud rate.

I suggest to introduce a new value '0' for the "Baud
Rate" field of SPCR (now this value is reserved).

This patch introduces a check for this value.  In this case
the code does not emit baud rate specification for initialization
of the console.

Signed-off-by: Aleksey Makarov 
---
 drivers/acpi/spcr.c | 22 +++---
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/drivers/acpi/spcr.c b/drivers/acpi/spcr.c
index 6c6710b..2bf338c 100644
--- a/drivers/acpi/spcr.c
+++ b/drivers/acpi/spcr.c
@@ -37,7 +37,7 @@ int __init parse_spcr(bool earlycon)
acpi_status status;
char *uart;
char *iotype;
-   int baud_rate;
+   char *baud_rate_string;
int err;
 
if (acpi_disabled)
@@ -82,25 +82,33 @@ int __init parse_spcr(bool earlycon)
}
 
switch (table->baud_rate) {
+   case 0:
+   /*
+* This value is not standaritzed by ACPI SPCR for now.
+* It means that hardware should not be re-initialized with
+* new speed.
+*/
+   baud_rate_string = "";
+   break;
case 3:
-   baud_rate = 9600;
+   baud_rate_string = ",9600";
break;
case 4:
-   baud_rate = 19200;
+   baud_rate_string = ",19200";
break;
case 6:
-   baud_rate = 57600;
+   baud_rate_string = ",57600";
break;
case 7:
-   baud_rate = 115200;
+   baud_rate_string = ",115200";
break;
default:
err = -ENOENT;
goto done;
}
 
-   snprintf(opts, sizeof(opts), "%s,%s,0x%llx,%d", uart, iotype,
-table->serial_port.address, baud_rate);
+   snprintf(opts, sizeof(opts), "%s,%s,0x%llx%s", uart, iotype,
+table->serial_port.address, baud_rate_string);
 
pr_info("console: %s\n", opts);
 
-- 
2.10.2

[RFC v2 3/4] ACPI: DBG2: add 16550 UART with 32-bit access

[Aleksey Makarov]

It was suggested to add a new Microsoft Debug Port Table 2
(DBG2) (the table used to enumerate the various subtypes of serial
port covered by the SPCR) 16550 UART subtype that may be needed for
some additional platforms, such as those based upon AppliedMicro
X-Gene ARMv8 SoCs.  This new subtype would be 16550-compatible
with 32-bit access.  There already exists 32-bit variant
ACPI_DBG2_ARM_SBSA_32BIT of SBSA console ACPI_DBG2_ARM_SBSA_GENERIC.

This patch introduces it to Linux kernel.

Signed-off-by: Aleksey Makarov 
---
 include/acpi/actbl2.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h
index c93dbad..f219b04 100644
--- a/include/acpi/actbl2.h
+++ b/include/acpi/actbl2.h
@@ -371,6 +371,7 @@ struct acpi_dbg2_device {
 
 #define ACPI_DBG2_16550_COMPATIBLE  0x
 #define ACPI_DBG2_16550_SUBSET  0x0001
+#define ACPI_DBG2_16550_32BIT   0x0002
 #define ACPI_DBG2_ARM_PL011 0x0003
 #define ACPI_DBG2_ARM_SBSA_32BIT0x000D
 #define ACPI_DBG2_ARM_SBSA_GENERIC  0x000E
-- 
2.10.2

Re: [RESEND][PATCH v4] cgroup: Use CAP_SYS_RESOURCE to allow a process to migrate other tasks between cgroups

[Tejun Heo]

Hello,

On Tue, Dec 06, 2016 at 09:01:17AM -0800, Andy Lutomirski wrote:
> How would one be granted the right to move processes around in one's
> own subtree?

Through expicit delegation - chowning of the directory and
cgroup.procs file.

> Are you imagining that, if you're in /a/b and you want to move a
> process that's currently in /a/b/c to /a/b/d then you're allowed to
> because the target process is in your tree?  If so, I doubt this has
> the security properties you want -- namely, if you can cooperate with
> anyone in /, even if they're unprivileged, you can break it.

Delegation is an explicit operation and reflected in the ownership of
the subdirectories and cgroup interface files in them.  The
subhierarchy containment is achieved by requiring the user who's
trying to migrate a process to have write perm on cgroup.procs on the
common ancestor of the source and target in addition to the target.
So, a user who has a subhierarchy delegated to it can move processes
around inside but not out of or into it.  Also, if there are multiple
delegated disjoint subhierarchies, processes can't be moved across
them by the delegatee either.

Thanks.

-- 
tejun

[PATCH v3 1/7] irda: w83977af_ir: Whitespace neatening

[Joe Perches]

Remove leading and trailing whitespace.
git diff -w shows no differences.

Signed-off-by: Joe Perches 
---
 drivers/net/irda/w83977af_ir.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/irda/w83977af_ir.c b/drivers/net/irda/w83977af_ir.c
index 96745888a4fc..d4b1d74d3081 100644
--- a/drivers/net/irda/w83977af_ir.c
+++ b/drivers/net/irda/w83977af_ir.c
@@ -263,7 +263,7 @@ static int w83977af_close(struct w83977af_ir *self)
 {
int iobase;
 
-iobase = self->io.fir_base;
+   iobase = self->io.fir_base;
 
 #ifdef CONFIG_USE_W977_PNP
/* enter PnP configuration mode */
-- 
2.10.0.rc2.1.g053435c

Re: [PATCH v2 1/2] vfio iommu type1: Fix size argument to vfio_find_dma() during DMA UNMAP.

[Kirti Wankhede]

On 12/6/2016 11:08 PM, Alex Williamson wrote:
> On Tue, 6 Dec 2016 22:43:30 +0530
> Kirti Wankhede  wrote:
> 
>> vfio_dma keeps track of address range from (dma->iova + 0) to
>> (dma->iova + dma->size - 1), while vfio_find_dma() search logic looks for
>> range from (dma->iova + 1) to (dma->iova + dma->size).
> 
> This is not true.  The issue is with the non-inclusive address at the
> end of a range being incompatible with passing zero for the range
> size.  Passing zero for the range size is a bit of a hack and doing
> such triggers a corner case in the end of range detection where we test
> (start + size <= dma->iova).  Using <= here covers the non-inclusive
> range end, ie. if the range was start=0x0, size=0x1000, the range is
> actually 0x0-0xfff.  Thus if start+size is 0x1000, it should not be
> considered part of a range beginning at 0x1000.  So there's no
> incompatibility as implied in the statement above, it's more that using
> zero for the size isn't compatible with matching the start address of
> an existing vfio_dma.  Thanks,
> 

Makes sense. Updating the description of both patch.

Thanks,
Kirti

> Alex
> 
>> In vfio_find_dma(), when the start address is equal to dma->iova and size
>> is 0, check for the end of search range makes it to take wrong side of
>> RB-tree. That fails the search even though the address is present in
>> mapped dma ranges. Due to this, in vfio_dma_do_unmap(), while checking
>> boundary conditions, size should be set to 1 for verifying start address
>> of unmap range.
>> vfio_find_dma() is also used to verify last address in unmap range with
>> size = 0, but in that case address to be searched is calculated with
>> size - 1 and so it works correctly.
>>
>> Signed-off-by: Kirti Wankhede 
>> Signed-off-by: Neo Jia 
>> ---
>>  drivers/vfio/vfio_iommu_type1.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/vfio/vfio_iommu_type1.c 
>> b/drivers/vfio/vfio_iommu_type1.c
>> index a28fbddb505c..8e9e94ccb2ff 100644
>> --- a/drivers/vfio/vfio_iommu_type1.c
>> +++ b/drivers/vfio/vfio_iommu_type1.c
>> @@ -826,7 +826,7 @@ again:
>>   * mappings within the range.
>>   */
>>  if (iommu->v2) {
>> -dma = vfio_find_dma(iommu, unmap->iova, 0);
>> +dma = vfio_find_dma(iommu, unmap->iova, 1);
>>  if (dma && dma->iova != unmap->iova) {
>>  ret = -EINVAL;
>>  goto unlock;
> 

Re: [tpmdd-devel] [PATCH v2 1/3] tpm_crb: map locality registers

[Jarkko Sakkinen]

On Mon, Dec 05, 2016 at 09:31:57PM +, Winkler, Tomas wrote:
> > 
> > On Mon, Dec 05, 2016 at 12:07:51PM +, Winkler, Tomas wrote:
> > > > > ---
> > > > >  drivers/char/tpm/tpm_crb.c | 96
> > > > > ++
> > > > >  1 file changed, 64 insertions(+), 32 deletions(-)
> > > > >
> > > > > diff --git a/drivers/char/tpm/tpm_crb.c
> > > > > b/drivers/char/tpm/tpm_crb.c index 717b6b4..8d81b66 100644
> > > > > --- a/drivers/char/tpm/tpm_crb.c
> > > > > +++ b/drivers/char/tpm/tpm_crb.c
> > > > > @@ -52,18 +52,28 @@ enum crb_cancel {
> > > > >   CRB_CANCEL_INVOKE   = BIT(0),
> > > > >  };
> > > > >
> > > > > -struct crb_control_area {
> > > > > - u32 req;
> > > > > - u32 sts;
> > > > > - u32 cancel;
> > > > > - u32 start;
> > > > > - u32 int_enable;
> > > > > - u32 int_sts;
> > > > > - u32 cmd_size;
> > > > > - u32 cmd_pa_low;
> > > > > - u32 cmd_pa_high;
> > > > > - u32 rsp_size;
> > > > > - u64 rsp_pa;
> > > > > +struct crb_regs_head {
> > > > > + u32 loc_state;
> > > > > + u32 reserved1;
> > > > > + u32 loc_ctrl;
> > > > > + u32 loc_sts;
> > > > > + u8 reserved2[32];
> > > > > + u64 intf_id;
> > > > > + u64 ctrl_ext;
> > > > > +} __packed;
> > > > > +
> > > > > +struct crb_regs_tail {
> > > > > + u32 ctrl_req;
> > > > > + u32 ctrl_sts;
> > > > > + u32 ctrl_cancel;
> > > > > + u32 ctrl_start;
> > > > > + u32 ctrl_int_enable;
> > > > > + u32 ctrl_int_sts;
> > > > > + u32 ctrl_cmd_size;
> > > > > + u32 ctrl_cmd_pa_low;
> > > > > + u32 ctrl_cmd_pa_high;
> > > > > + u32 ctrl_rsp_size;
> > > > > + u64 ctrl_rsp_pa;
> > > > >  } __packed;
> > >
> > >
> > > Now I wonder if using  traditional offsets wouldn't be cleaner solution.
> > 
> > I'm not sure what you are trying to say.
> 
> Such as iowrite32(val, base + offset)

I rather stick using structures. I do not see the point to turn things
around.

> 
> > 
> > > > >  enum crb_status {
> > > > > @@ -78,7 +88,8 @@ enum crb_flags {  struct crb_priv {
> > > > >   unsigned int flags;
> > > > >   void __iomem *iobase;
> > > > > - struct crb_control_area __iomem *cca;
> > > > > + struct crb_regs_head __iomem *regs_h;
> > > > > + struct crb_regs_tail __iomem *regs_t;
> > > Why just not leaving it cca, it's descriptive enough.
> > > > >   u8 __iomem *cmd;
> > > > >   u8 __iomem *rsp;
> > > > >   u32 cmd_size;
> > > > > @@ -104,7 +115,7 @@ static int __maybe_unused crb_go_idle(struct
> > > > > device
> > > > *dev, struct crb_priv *priv)
> > > > >   if (priv->flags & CRB_FL_ACPI_START)
> > > > >   return 0;
> > > > >
> > > > > - iowrite32(CRB_CTRL_REQ_GO_IDLE, >cca->req);
> > > > > + iowrite32(CRB_CTRL_REQ_GO_IDLE, >regs_t->ctrl_req);
> > > > >   /* we don't really care when this settles */
> > > > >
> > > > >   return 0;
> > > > > @@ -128,21 +139,23 @@ static int __maybe_unused
> > > > > crb_cmd_ready(struct
> > > > device *dev,
> > > > >   struct crb_priv *priv)
> > > > >  {
> > > > >   ktime_t stop, start;
> > > > > + u32 req;
> > > > >
> > > > >   if (priv->flags & CRB_FL_ACPI_START)
> > > > >   return 0;
> > > > >
> > > > > - iowrite32(CRB_CTRL_REQ_CMD_READY, >cca->req);
> > > > > + iowrite32(CRB_CTRL_REQ_CMD_READY, >regs_t->ctrl_req);
> > > > >
> > > > >   start = ktime_get();
> > > > >   stop = ktime_add(start, ms_to_ktime(TPM2_TIMEOUT_C));
> > > > >   do {
> > > > > - if (!(ioread32(>cca->req) &
> > > > CRB_CTRL_REQ_CMD_READY))
> > > > > + req = ioread32(>regs_t->ctrl_req);
> > > > > + if (!(req & CRB_CTRL_REQ_CMD_READY))
> > > > >   return 0;
> > > > >   usleep_range(50, 100);
> > > > >   } while (ktime_before(ktime_get(), stop));
> > > > >
> > > > > - if (ioread32(>cca->req) & CRB_CTRL_REQ_CMD_READY) {
> > > > > + if (ioread32(>regs_t->ctrl_req) & CRB_CTRL_REQ_CMD_READY)
> > > > {
> > > > >   dev_warn(dev, "cmdReady timed out\n");
> > > > >   return -ETIME;
> > > > >   }
> > > > > @@ -155,7 +168,7 @@ static u8 crb_status(struct tpm_chip *chip)
> > > > >   struct crb_priv *priv = dev_get_drvdata(>dev);
> > > > >   u8 sts = 0;
> > > > >
> > > > > - if ((ioread32(>cca->start) & CRB_START_INVOKE) !=
> > > > > + if ((ioread32(>regs_t->ctrl_start) & CRB_START_INVOKE) !=
> > > > >   CRB_START_INVOKE)
> > > > >   sts |= CRB_DRV_STS_COMPLETE;
> > > > >
> > > > > @@ -171,7 +184,7 @@ static int crb_recv(struct tpm_chip *chip, u8
> > > > > *buf,
> > > > size_t count)
> > > > >   if (count < 6)
> > > > >   return -EIO;
> > > > >
> > > > > - if (ioread32(>cca->sts) & CRB_CTRL_STS_ERROR)
> > > > > + if (ioread32(>regs_t->ctrl_sts) & CRB_CTRL_STS_ERROR)
> > > > >   return -EIO;
> > > > >
> > > > >   

Re: [PATCH v2 02/11] locking/ww_mutex: Re-check ww->ctx in the inner optimistic spin loop

[Waiman Long]

On 12/06/2016 01:29 PM, Peter Zijlstra wrote:
> On Tue, Dec 06, 2016 at 11:03:28AM -0500, Waiman Long wrote:
>> The mutex_spin_on_owner() function was originally marked noinline
>> because it could be a major consumer of CPU cycles in a contended lock.
>> Having it shown separately in the perf output will help the users have a
>> better understanding of what is consuming all the CPU cycles. So I would
>> still like to keep it this way.
> ah!, I tried to dig through history but couldn't find a reason for it.
>
>> If you have concern about additional latency for non-ww_mutex calls, one
>> alternative can be:
> That's pretty horrific :/

I am not totally against making mutex_spin_on_owner() an inline
function. If you think it is the right way to go, I am OK with that.

-Longman

Re: [PATCH v3] arm: dts: zynq: Add MicroZed board support

[Michal Simek]

On 5.12.2016 17:28, Jagan Teki wrote:
> On Mon, Sep 26, 2016 at 8:22 AM, Michal Simek  wrote:
>> On 23.9.2016 11:48, Jagan Teki wrote:
>>> From: Jagan Teki 
>>>
>>> Added basic dts support for MicroZed board.
>>>
>>> - UART
>>> - SDHCI
>>> - Ethernet
>>>
>>> Cc: Soren Brinkmann 
>>> Cc: Michal Simek 
>>> Signed-off-by: Jagan Teki 
>>> ---
>>> Changes for v3:
>>>   - Add Xilinx copyright
>>> Changes for v2:
>>>   - Add SDHCI
>>>   - Add Ethernet
>>>
>>>  arch/arm/boot/dts/Makefile  |  1 +
>>>  arch/arm/boot/dts/zynq-microzed.dts | 96 
>>> +
>>>  2 files changed, 97 insertions(+)
>>>  create mode 100644 arch/arm/boot/dts/zynq-microzed.dts
>>>
>>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>>> index faacd52..4d7b858 100644
>>> --- a/arch/arm/boot/dts/Makefile
>>> +++ b/arch/arm/boot/dts/Makefile
>>> @@ -862,6 +862,7 @@ dtb-$(CONFIG_ARCH_VT8500) += \
>>>   wm8750-apc8750.dtb \
>>>   wm8850-w70v2.dtb
>>>  dtb-$(CONFIG_ARCH_ZYNQ) += \
>>> + zynq-microzed.dtb \
>>>   zynq-parallella.dtb \
>>>   zynq-zc702.dtb \
>>>   zynq-zc706.dtb \
>>> diff --git a/arch/arm/boot/dts/zynq-microzed.dts 
>>> b/arch/arm/boot/dts/zynq-microzed.dts
>>> new file mode 100644
>>> index 000..b9376a4
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/zynq-microzed.dts
>>> @@ -0,0 +1,96 @@
>>> +/*
>>> + * Copyright (C) 2011 - 2014 Xilinx
>>> + * Copyright (C) 2016 Jagan Teki 
>>> + *
>>> + * This software is licensed under the terms of the GNU General Public
>>> + * License version 2, as published by the Free Software Foundation, and
>>> + * may be copied, distributed, and modified under those terms.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>> + * GNU General Public License for more details.
>>> + */
>>> +/dts-v1/;
>>> +/include/ "zynq-7000.dtsi"
>>> +
>>> +/ {
>>> + model = "Zynq MicroZED Development Board";
>>> + compatible = "xlnx,zynq-microzed", "xlnx,zynq-7000";
>>> +
>>> + aliases {
>>> + ethernet0 = 
>>> + serial0 = 
>>> + };
>>> +
>>> + memory {
>>> + device_type = "memory";
>>> + reg = <0x0 0x4000>;
>>> + };
>>> +
>>> + chosen {
>>> + bootargs = "earlycon";
>>> + stdout-path = "serial0:115200n8";
>>> + };
>>> +
>>> + usb_phy0: phy0 {
>>> + compatible = "usb-nop-xceiv";
>>> + #phy-cells = <0>;
>>> + };
>>> +};
>>> +
>>> + {
>>> + ps-clk-frequency = <>;
>>> +};
>>> +
>>> + {
>>> + status = "okay";
>>> + phy-mode = "rgmii-id";
>>> + phy-handle = <_phy>;
>>> +
>>> + ethernet_phy: ethernet-phy@0 {
>>> + reg = <0>;
>>> + };
>>> +};
>>> +
>>> + {
>>> + status = "okay";
>>> +};
>>> +
>>> + {
>>> + status = "okay";
>>> +};
>>> +
>>> + {
>>> + status = "okay";
>>> + dr_mode = "host";
>>> + usb-phy = <_phy0>;
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <_usb0_default>;
>>> +};
>>> +
>>> + {
>>> + pinctrl_usb0_default: usb0-default {
>>> + mux {
>>> + groups = "usb0_0_grp";
>>> + function = "usb0";
>>> + };
>>> +
>>> + conf {
>>> + groups = "usb0_0_grp";
>>> + slew-rate = <0>;
>>> + io-standard = <1>;
>>> + };
>>> +
>>> + conf-rx {
>>> + pins = "MIO29", "MIO31", "MIO36";
>>> + bias-high-impedance;
>>> + };
>>> +
>>> + conf-tx {
>>> + pins = "MIO28", "MIO30", "MIO32", "MIO33", "MIO34",
>>> +"MIO35", "MIO37", "MIO38", "MIO39";
>>> + bias-disable;
>>> + };
>>> + };
>>> +};
>>>
>>
>> Applied.
> 
> Was it missed? I couldn't see it on the source for a while. any help?

Thanks for reminder. I have that patch in one branch (was in different)

https://github.com/Xilinx/linux-xlnx/commits/zynq/dt

Thanks,
Michal

Re: FUSE: regression when clearing setuid bits on chown

[Jeff Layton]

On Tue, 2016-12-06 at 15:51 +0100, Miklos Szeredi wrote:
> On Tue, Dec 6, 2016 at 3:45 PM, Jeff Layton  wrote:
> 
> > 
> > > 
> > > @@ -1739,8 +1739,6 @@ static int fuse_setattr(struct dentry *e
> > >* This should be done on write(), truncate() and chown().
> > >*/
> > >   if (!fc->handle_killpriv) {
> > 
> > One more thing too. I don't think we really want to monkey with the mode
> > at all if there is a request to set the mode already in the request. So
> > maybe this should be:
> > 
> > if (!fc->handle_killpriv && !(attr->ia_mode & ATTR_MODE))
> > 
> > Granted that won't generally happen from normal process context, but we
> > could have knfsd in here too and I think that's possible from there.
> 
> Apparently this can't happen even from knfsd; notify_change() has this 
> comment:
> 
> /*
>  * We now pass ATTR_KILL_S*ID to the lower level setattr function so
>  * that the function has the ability to reinterpret a mode change
>  * that's due to these bits. This adds an implicit restriction that
>  * no function will ever call notify_change with both ATTR_MODE and
>  * ATTR_KILL_S*ID set.
>  */
> if ((ia_valid & (ATTR_KILL_SUID|ATTR_KILL_SGID)) &&
> (ia_valid & ATTR_MODE))
> BUG();
> 
> 

Ahh right, I had forgotten about that. Eventually we may want to lift
that restriction, but you can add this to the current patch:

Reviewed-by: Jeff Layton 

Thanks for fixing it quickly!

Re: [PATCH v2 1/2] devicetree: i2c-hid: Add Wacom digitizer + regulator support

[Rob Herring]

On Tue, Dec 6, 2016 at 2:48 AM, Benjamin Tissoires
 wrote:
> On Dec 05 2016 or thereabouts, Rob Herring wrote:
>> On Thu, Dec 01, 2016 at 09:24:50AM -0800, Brian Norris wrote:
>> > Hi Benjamin and Rob,
>> >
>> > On Thu, Dec 01, 2016 at 03:34:34PM +0100, Benjamin Tissoires wrote:
>> > > On Nov 30 2016 or thereabouts, Brian Norris wrote:
>> > > > From: Caesar Wang 
>> > > >
>> > > > Add a compatible string and regulator property for Wacom W9103
>> > > > digitizer. Its VDD supply may need to be enabled before using it.
>> > > >
>> > > > Signed-off-by: Caesar Wang 
>> > > > Cc: Rob Herring 
>> > > > Cc: Jiri Kosina 
>> > > > Cc: linux-in...@vger.kernel.org
>> > > > Signed-off-by: Brian Norris 
>> > > > ---
>> > > > v1 was a few months back. I finally got around to rewriting it based on
>> > > > DT binding feedback.
>> > > >
>> > > > v2:
>> > > >  * add compatible property for wacom
>> > > >  * name the regulator property specifically (VDD)
>> > > >
>> > > >  Documentation/devicetree/bindings/input/hid-over-i2c.txt | 6 +-
>> > > >  1 file changed, 5 insertions(+), 1 deletion(-)
>> > > >
>> > > > diff --git a/Documentation/devicetree/bindings/input/hid-over-i2c.txt 
>> > > > b/Documentation/devicetree/bindings/input/hid-over-i2c.txt
>> > > > index 488edcb264c4..eb98054e60c9 100644
>> > > > --- a/Documentation/devicetree/bindings/input/hid-over-i2c.txt
>> > > > +++ b/Documentation/devicetree/bindings/input/hid-over-i2c.txt
>> > > > @@ -11,12 +11,16 @@ If this binding is used, the kernel module i2c-hid 
>> > > > will handle the communication
>> > > >  with the device and the generic hid core layer will handle the 
>> > > > protocol.
>> > > >
>> > > >  Required properties:
>> > > > -- compatible: must be "hid-over-i2c"
>> > > > +- compatible: must be "hid-over-i2c", or a device-specific string 
>> > > > like:
>> > > > +* "wacom,w9013"
>> > >
>> > > NACK on this one.
>> > >
>> > > After re-reading the v1 submission I realized Rob asked for this change,
>> > > but I strongly disagree.
>> > >
>> > > HID over I2C is a generic protocol, in the same way HID over USB is. We
>> > > can not start adding device specifics here, this is opening the can of
>> > > worms. If the device is a HID one, nothing else should matter. The rest
>> > > (description of the device, name, etc...) is all provided by the
>> > > protocol.
>> >
>> > I should have spoken up when Rob made the suggestion, because I more or
>> > less agree with Benjamin here. I don't really see why this needs to have
>> > a specialized compatible string, as the property is still fairly
>> > generic, and the entire device handling is via a generic protocol. The
>> > fact that we manage its power via a regulator is not very
>> > device-specific.
>>
>> It doesn't matter that the protocol is generic. The device attached and
>> the implementation is not. Implementations have been known to have
>> bugs/quirks (generally speaking, not HID over I2C in particular). There
>> are also things outside the scope of what is 'hid-over-i2c' like what's
>> needed to power-on the device which this patch clearly show.
>
> Yes, there are bugs, quirks, even with HID. But the HID declares within
> the protocol the Vendor ID and the Product ID, which means once we pass
> the initial "device is ready" step and can do a single i2c write/read,
> we don't give a crap about device tree anymore.
>
> This is just about setting the device in shape so that it can answer a
> single write/read.
>
>>
>> This is no different than a panel attached via LVDS, eDP, etc., or
>> USB/PCIe device hard-wired on a board. They all use standard protocols
>> and all need additional data to describe them. Of course, adding a
>> single property for a delay would not be a big deal, but it's never
>> ending. Next you need multiple supplies, GPIO controls, mutiple
>> delays... This has been discussed to death already. As Thierry Reding
>> said, you're not special[1].
>
> I can somewhat understand what you mean. The official specification is
> for ACPI. And ACPI allows to calls various settings while querying the
> _STA method for instance. So in the ACPI world, we don't need to care
> about regulators or GPIOs because the OEM deals with this in its own
> blob.
>
> Now, coming back to our issue. We are not special, maybe, if he says so.
> But this really feels like a design choice between putting the burden on
> device tree and OEMs or in the module maintainers. And I'd rather have
> the OEM deal with their device than me having to update the module for
> each generations of hardware. Indeed, this looks like an "endless"
> amount of quirks, but I'd rather have this endless amount of quirks than
> having to maintain an endless amount of list of new devices that behaves
> the same way. We are talking here about "wacom,w9013", but then comes
> "wacom,w9014" and we need to upgrade 

Re: [PATCH] bitops: add equivalent of BIT(x) for bitfields

[Sebastian Frias]

Hi Geert,

On 06/12/16 12:12, Geert Uytterhoeven wrote:
>>> ... which means "generate a value"??
>>>
>>
>> Yes.
>> Although I'm not sure if I understood the essence of your point.
>> Are you suggesting that the name should be GENERATE_A_VALUE?
> 
> No. I mean that "value" is a way too generic name.
> Hence "GENVALUE" may be suitable for a macro local to a driver, but is way
> too generic and fuzzy for a global function.

IMHO GENMASK presents the same situation, but actually I don't really mind
about the name.

> 
>> There's already GENMASK, which "generates a mask".
> 
> Yes. And it generates a (bit)mask, which is clear from its name.
> But a "value" is just too generic for a global function, and make me think of
> a pseudo-random number generator ;-)

:-)

>>> "val |= 0x5a << 12;" looks much more readable to me...
>>>
>>
>> Well, the idea behind this is that one can use it like:
>>
>> (see https://marc.info/?l=linux-kernel=148095872915717=2)
>>
>> ...
>> #define TIMEOUT_CLK_UNIT_MHZ   BIT(6)
>> #define BUS_CLK_FREQ_FOR_SD_CLK(x) GENVALUE(14,7,x)
>> ...
>> val = 0;
>> val |= TIMEOUT_CLK_UNIT_MHZ; /* unit: MHz */
>> val |= BUS_CLK_FREQ_FOR_SD_CLK(200); /* SDIO clock: 200MHz */
>> ...
>>
>> which makes it very practical for writing macros for associated HW
>> documentation.
> 
> Actually I more like the SETBITFIELD name...
> 

Well, Linus did not like it for example.
Since the start I was open to suggestions because I felt the name
was not great either.

https://marc.info/?l=linux-kernel=148095805515487=2


>>> OK. So it inserts a value into a bitfield.
>>>
>>> Yes, that can be useful. Now let's find a sensible name for this.
>>> Perhaps inspired by a PowerPC mnemonic? At least that would be more
>>> obvious than "GENVALUE", IMHO...
>>
>> I'm open to suggestions.
> 
> BITFIELD_INSERT()?

The problem is that right now it does not inserts into anything,
it just generates a value. The user can then OR that with something else
essentially "inserting" the value.

(see my reply to Borislav here:
https://marc.info/?l=linux-kernel=148095872915717=2 )

This allows a use case where BIT() and GENVALUE() can be used in a
similar way:

#define TIMEOUT_CLK_UNIT_MHZ   BIT(6)
#define BUS_CLK_FREQ_FOR_SD_CLK(x) GENVALUE(14,7,x)
...
val = 0;
val |= TIMEOUT_CLK_UNIT_MHZ; /* unit: MHz */
val |= BUS_CLK_FREQ_FOR_SD_CLK(200); /* SDIO clock: 200MHz */
...

I can write BITFIELD_INSERT as well, but I would not want to have
to choose between BITFIELD_INSERT and GENVALUE, because that would
mean that the snippet above would become:

#define BITFIELD_INSERT(target, msb, lsb, val)  \
(target = ((target & ~GENMASK(msb, lsb)) | GENVALUE(msb, lsb, val)))
...
#define TIMEOUT_CLK_UNIT_MHZ  BIT(6)
#define BUS_CLK_FREQ_FOR_SD_CLK(y, x) BITFIELD_INSERT(y,14,7,x)
...
val = 0;
val |= TIMEOUT_CLK_UNIT_MHZ; /* unit: MHz */
BUS_CLK_FREQ_FOR_SD_CLK(val, 200);   /* SDIO clock: 200MHz */
...


NOTES:
- Going for BITFIELD_INSERT() means that we probably
need to decide its behaviour w.r.t existing bits, does it OR
(thus preserving bits set) or does it overwrite? (most likely
the later option)
- Going for BITFIELD_INSERT() calls for its counter-part
BITFIELD_EXTRACT(), so that we can do:

...
   val = 0x1115a000;
   if (BITFIELD_EXTRACT(val, 19, 12) == 0x5a)
...


Best regards,

Sebastian

[PATCH 00/16] FSI device driver introduction

[christopher . lee . bostic]

From: Chris Bostic 

Introduction of the IBM 'Flexible Support Interface' (FSI) bus device
driver. FSI is a high fan out serial bus consisting of a clock and a serial
data line capable of running at speeds up to 166 MHz.

This set provides the basic framework to add FSI extensions to the
Linux bus and device models. Master specific implementations are
defined to utilize the core FSI function.

In Linux, we have a core FSI "bus type", along with drivers for FSI
masters and engines.

The FSI master drivers expose a read/write interface to the bus address
space. The master drivers are under drivers/fsi/fsi-master-*.c.

The core handles probing and discovery of slaves and slave
engines, using those read/write interfaces. It is responsible for
creating the endpoint Linux devices corresponding to the discovered
engines on each slave.

Slave engines are identified by an 'engine' type, and an optional
version. Engine, a.k.a. client, drivers are matched and bound to these
engines during discovery.

This patch set does not include extended FSI function such as:
*  Hub master support
*  Cascaded master support
*  Application layer hot plug notification
*  Application layer FSI bus status interface

Common FSI terminology:

* Master
Controller of the FSI bus.  Only the master is allowed to control the
clock line and is the initiator of all transactions on a bus.

* Slave
The receiver or target of a master initiated transaction.  The slave
cannot initiate communications on a bus and must respond to any
master requests for data.

* CFAM
Stands for Common Field replaceable unit Access Macro.  A CFAM is an
ASIC residing in any device requiring FSI communications. CFAMs
consist of an array of hardware 'engines' used for various purposes.
I2C masters, UARTs, General Purpose IO hardware are common types of
these engines.

* Configuration Space / Table
A table contained at the beginning of each CFAM address space.
This table lists information such as the CFAM's ID, which engine types
and versions it has available, as well as its addressing range.

* FSI Engine driver
A device driver that registers with the FSI core so that it can access
devices it owns on an FSI bus.


Chris Bostic (5):
  drivers/fsi: Set up links for slave communication
  drivers/fsi: Set slave SMODE to init communication
  drivers/fsi: Add master unscan
  drivers/fsi: Add documentation for GPIO bindings
  drivers/fsi: Add GPIO based FSI master

Jeremy Kerr (11):
  drivers/fsi: Add empty fsi bus definitions
  drivers/fsi: Add device & driver definitions
  drivers/fsi: add driver to device matches
  drivers/fsi: Add fsi master definition
  drivers/fsi: Add fake master driver
  drivers/fsi: Add slave definition
  drivers/fsi: Add empty master scan
  drivers/fsi: Add crc4 helpers
  drivers/fsi: Implement slave initialisation
  drivers/fsi: scan slaves & register devices
  drivers/fsi: Add device read/write/peek functions

 .../devicetree/bindings/fsi/fsi-master-gpio.txt|  21 +
 drivers/Kconfig|   2 +
 drivers/Makefile   |   1 +
 drivers/fsi/Kconfig|  29 ++
 drivers/fsi/Makefile   |   4 +
 drivers/fsi/fsi-core.c | 514 +++
 drivers/fsi/fsi-master-fake.c  |  95 
 drivers/fsi/fsi-master-gpio.c  | 552 +
 drivers/fsi/fsi-master.h   |  62 +++
 include/linux/fsi.h|  60 +++
 10 files changed, 1340 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/fsi/fsi-master-gpio.txt
 create mode 100644 drivers/fsi/Kconfig
 create mode 100644 drivers/fsi/Makefile
 create mode 100644 drivers/fsi/fsi-core.c
 create mode 100644 drivers/fsi/fsi-master-fake.c
 create mode 100644 drivers/fsi/fsi-master-gpio.c
 create mode 100644 drivers/fsi/fsi-master.h
 create mode 100644 include/linux/fsi.h

-- 
1.8.2.2

RE: [LINUX RFC v4 3/4] mtd: spi-nor: add stripe support

[Naga Sureshkumar Relli]

Hi Mark and Cyrille,

> -Original Message-
> From: Cyrille Pitchen [mailto:cyrille.pitc...@atmel.com]
> Sent: Tuesday, December 06, 2016 4:30 PM
> To: Naga Sureshkumar Relli ; broo...@kernel.org;
> michal.si...@xilinx.com; Soren Brinkmann ; Harini
> Katakam ; Punnaiah Choudary Kalluri
> 
> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; linux-...@lists.infradead.org
> Subject: Re: [LINUX RFC v4 3/4] mtd: spi-nor: add stripe support
>
> Le 06/12/2016 à 07:54, Naga Sureshkumar Relli a écrit :
> > Hi Cyrille,
> >
> >> -Original Message-
> >> From: Cyrille Pitchen [mailto:cyrille.pitc...@atmel.com]
> >> Sent: Monday, December 05, 2016 6:34 PM
> >> To: Naga Sureshkumar Relli ; broo...@kernel.org;
> >> michal.si...@xilinx.com; Soren Brinkmann ; Harini
> >> Katakam ; Punnaiah Choudary Kalluri
> >> 
> >> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> >> linux- ker...@vger.kernel.org; linux-...@lists.infradead.org
> >> Subject: Re: [LINUX RFC v4 3/4] mtd: spi-nor: add stripe support
> >>
> >> Hi Naga,
> >>
> >> Le 05/12/2016 à 08:02, Naga Sureshkumar Relli a écrit :
> >>> Hi Cyrille,
> >>>
> > Hi Cyrille,
> >
> >> I have not finished to review the whole series yet but here some
> >> first
> >> comments:
> >
> > Thanks for reviewing these patch series.
> >
> >>
> >> Le 27/11/2016 à 09:33, Naga Sureshkumar Relli a écrit :
> >>> This patch adds stripe support and it is needed for GQSPI
> >>> parallel configuration mode by:
> >>>
> >>> - Adding required parameters like stripe and shift to spi_nor
> >>>   structure.
> >>> - Initializing all added parameters in spi_nor_scan()
> >>> - Updating read_sr() and read_fsr() for getting status from both
> >>>   flashes
> >>> - Increasing page_size, sector_size, erase_size and toatal flash
> >>>   size as and when required.
> >>> - Dividing address by 2
> >>> - Updating spi->master->flags for qspi driver to change CS
> >>>
> >>> Signed-off-by: Naga Sureshkumar Relli 
> >>> ---
> >>> Changes for v4:
> >>>  - rename isparallel to stripe
> >>> Changes for v3:
> >>>  - No change
> >>> Changes for v2:
> >>>  - Splitted to separate MTD layer changes from SPI core changes
> >>> ---
> >>>  drivers/mtd/spi-nor/spi-nor.c | 130
> >> --
> >>>  include/linux/mtd/spi-nor.h   |   2 +
> >>>  2 files changed, 103 insertions(+), 29 deletions(-)
> >>>
> >>> diff --git a/drivers/mtd/spi-nor/spi-nor.c
> >>> b/drivers/mtd/spi-nor/spi-nor.c index d0fc165..4252239 100644
> >>> --- a/drivers/mtd/spi-nor/spi-nor.c
> >>> +++ b/drivers/mtd/spi-nor/spi-nor.c
> >>> @@ -22,6 +22,7 @@
> >>>  #include 
> >>>  #include 
> >>>  #include 
> >>> +#include 
> >>>
> >>>  /* Define max times to check status register before we give up.
> >>> */
> >>>
> >>> @@ -89,15 +90,24 @@ static const struct flash_info
> >>> *spi_nor_match_id(const char *name);  static int read_sr(struct
> >>> spi_nor *nor)  {
> >>>   int ret;
> >>> - u8 val;
> >>> + u8 val[2];
> >>>
> >>> - ret = nor->read_reg(nor, SPINOR_OP_RDSR, , 1);
> >>> - if (ret < 0) {
> >>> - pr_err("error %d reading SR\n", (int) ret);
> >>> - return ret;
> >>> + if (nor->stripe) {
> >>> + ret = nor->read_reg(nor, SPINOR_OP_RDSR, [0], 2);
> >>> + if (ret < 0) {
> >>> + pr_err("error %d reading SR\n", (int) ret);
> >>> + return ret;
> >>> + }
> >>> + val[0] |= val[1];
> >> Why '|' rather than '&' ?
> >> I guess because of the 'Write In Progress/Busy' bit: when called
> >> by spi_nor_sr_ready(), you want to be sure that this 'BUSY' bit
> >> is cleared on both memories.
> >>
> >> But what about when the Status Register is read for purpose other
> >> than checking the state of the 'BUSY' bit?
> >>
> > Yes you are correct, I will change this.
> >
> >> What about SPI controllers supporting more than 2 memories in
> >> parallel?
> >>
> >> This solution might fit the ZynqMP controller but doesn't look so
> >> generic.
> >>
> >>> + } else {
> >>> + ret = nor->read_reg(nor, SPINOR_OP_RDSR, [0], 1);
> >>> + if (ret < 0) {
> >>> + pr_err("error %d reading SR\n", (int) ret);
> >>> + return ret;
> >>> + }
> >>>   }
> >>>
> >>> - return val;
> >>> + return val[0];
> >>>  }
> >>>
> >>>  /*
> >>> @@ -108,15 +118,24 @@ static int read_sr(struct spi_nor *nor)
> >>>