[PATCH] Document that IRQ_NONE should be returned when IRQ not actually *handled*

[David Woodhouse]

Our IRQ storm detection works when an interrupt handler returns
IRQ_NONE for thousands of consecutive interrupts in a second. It
doesn't hurt to occasionally return IRQ_NONE when the interrupt is
actually genuine.

Drivers should only be returning IRQ_HANDLED if they have actually
*done* something to stop an interrupt from happening — it doesn't just
mean "this really *was* my device".

Signed-off-by: David Woodhouse 
---
See recent discussion about the 8139cp Ethernet driver¹. It developed
(OK, I introduced) a bug where it would re-enable the RX IRQ when
handling a TX timeout and resetting the hardware.

This leads to an IRQ storm with cp_interrupt() *not* doing anything
about the RX IRQ, because NAPI was already scheduled. And then
returning IRQ_HANDLED anyway. And complete death of the machine.

Our IRQ storm detection should handle that kind of thing — it's
designed to catch both hardware *and* software screwups. But because of
the cp_interrupt() return value, it didn't.

I tried to fix cp_interrupt(), and submitted a patch which made the
failure mode much saner — the offending IRQ got disabled and the
machine continued happily, with the network even *working* in polling
mode. It met with resistance.

To overcome that resistance, we should clearly document the expectation
that device drivers should return IRQ_NONE in that kind of case. Let's
start by at least fixing the *wrong* text in irqreturn.h, which says
that IRQ_NONE means "not my device"...

¹ http://www.spinics.net/lists/netdev/msg343991.html
  http://www.spinics.net/lists/netdev/msg343995.html
  http://www.spinics.net/lists/netdev/msg344265.html


diff --git a/include/linux/irqreturn.h b/include/linux/irqreturn.h
index e374e36..eb1bdcf 100644
--- a/include/linux/irqreturn.h
+++ b/include/linux/irqreturn.h
@@ -3,7 +3,7 @@
 
 /**
  * enum irqreturn
- * @IRQ_NONE   interrupt was not from this device
+ * @IRQ_NONE   interrupt was not from this device or was not handled
  * @IRQ_HANDLEDinterrupt was handled by this device
  * @IRQ_WAKE_THREADhandler requests to wake the handler thread
  */

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation



smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH 08/10] merge_config.sh: use trap for cleanup

[Darren Hart]

On Wed, Oct 28, 2015 at 09:42:09AM +0900, Olof Johansson wrote:
> Use the trap to cleanup even on regular exit.
> 
> Signed-off-by: Olof Johansson 
> ---
>  scripts/kconfig/merge_config.sh | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/scripts/kconfig/merge_config.sh b/scripts/kconfig/merge_config.sh
> index 1945b2c..b26c0ef 100755
> --- a/scripts/kconfig/merge_config.sh
> +++ b/scripts/kconfig/merge_config.sh
> @@ -23,10 +23,12 @@
>  EXITVAL=0
>  
>  clean_up() {
> - rm -f $TMP_FILE
> + if [ -n "$CLEAN_FILES" ] ; then
> + rm -f $CLEAN_FILES

Hrm... where did CLEAN_FILES come from? I dodn't see it in master and I don't
see it in patches 1-7. Did I miss it?

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

Re: [PATCH v3 0/3] virtio DMA API core stuff

[Andy Lutomirski]

On Tue, Oct 27, 2015 at 11:53 PM, David Woodhouse  wrote:
> On Tue, 2015-10-27 at 23:38 -0700, Andy Lutomirski wrote:
>>
>> Changes from v2:
>>  - Fix really embarrassing bug.  This version actually works.
>
> So embarrassing you didn't want to tell us what it was? ...

Shhh, it's a secret!

I somehow managed to test-boot a different kernel than I thought I was booting.

>
> --- a/drivers/virtio/virtio_ring.c
> +++ b/drivers/virtio/virtio_ring.c
> @@ -292,7 +292,7 @@ static inline int virtqueue_add(struct virtqueue *_vq,
> vq, desc, total_sg * sizeof(struct vring_desc),
> DMA_TO_DEVICE);
>
> -   if (vring_mapping_error(vq, vq->vring.desc[head].addr))
> +   if (vring_mapping_error(vq, addr))
> goto unmap_release;
>
> vq->vring.desc[head].flags = cpu_to_virtio16(_vq->vdev, 
> VRING_DESC_F_INDIRECT);
>
> That wasn't going to be the reason for Christian's failure, was it?
>

Not obviously, but it's possible.  Now that I'm staring at it, I have
some more big-endian issues, so there'll be a v4.  I'll also play with
Michael's thing.  Expect a long delay, though -- my flight's about to
leave.

The readme notwithstanding, virtme (https://github.com/amluto/virtme)
actually has s390x support, so I can try to debug when I get home.
I'm not about to try doing this on a laptop :)

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

Re: [PATCH v3 1/3] virtio_net: Stop doing DMA from the stack

[Michael S. Tsirkin]

On Tue, Oct 27, 2015 at 11:38:58PM -0700, Andy Lutomirski wrote:
> From: Andy Lutomirski 
> 
> Once virtio starts using the DMA API, we won't be able to safely DMA
> from the stack.  virtio-net does a couple of config DMA requests
> from small stack buffers -- switch to using dynamically-allocated
> memory.
> 
> This should have no effect on any performance-critical code paths.
> 
> Cc: "Michael S. Tsirkin" 
> Cc: virtualizat...@lists.linux-foundation.org
> Reviewed-by: Joerg Roedel 
> Signed-off-by: Andy Lutomirski 

Same issues as v2 (I only saw v3 now).
I've proposed an alternative patch.

> ---
> 
> Hi Michael and DaveM-
> 
> This is a prerequisite for the virtio DMA fixing project.  It works
> as a standalone patch, though.  Would it make sense to apply it to
> an appropriate networking tree now?
> 
> (This is unchanged from v2.)
> 
> drivers/net/virtio_net.c | 53 
>  1 file changed, 36 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index d8838dedb7a4..4f10f8a58811 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -976,31 +976,43 @@ static bool virtnet_send_command(struct virtnet_info 
> *vi, u8 class, u8 cmd,
>struct scatterlist *out)
>  {
>   struct scatterlist *sgs[4], hdr, stat;
> - struct virtio_net_ctrl_hdr ctrl;
> - virtio_net_ctrl_ack status = ~0;
> +
> + struct {
> + struct virtio_net_ctrl_hdr ctrl;
> + virtio_net_ctrl_ack status;
> + } *buf;
> +
>   unsigned out_num = 0, tmp;
> + bool ret;
>  
>   /* Caller should know better */
>   BUG_ON(!virtio_has_feature(vi->vdev, VIRTIO_NET_F_CTRL_VQ));
>  
> - ctrl.class = class;
> - ctrl.cmd = cmd;
> + buf = kmalloc(sizeof(*buf), GFP_ATOMIC);
> + if (!buf)
> + return false;
> + buf->status = ~0;
> +
> + buf->ctrl.class = class;
> + buf->ctrl.cmd = cmd;
>   /* Add header */
> - sg_init_one(, , sizeof(ctrl));
> + sg_init_one(, >ctrl, sizeof(buf->ctrl));
>   sgs[out_num++] = 
>  
>   if (out)
>   sgs[out_num++] = out;
>  
>   /* Add return status. */
> - sg_init_one(, , sizeof(status));
> + sg_init_one(, >status, sizeof(buf->status));
>   sgs[out_num] = 
>  
>   BUG_ON(out_num + 1 > ARRAY_SIZE(sgs));
>   virtqueue_add_sgs(vi->cvq, sgs, out_num, 1, vi, GFP_ATOMIC);
>  
> - if (unlikely(!virtqueue_kick(vi->cvq)))
> - return status == VIRTIO_NET_OK;
> + if (unlikely(!virtqueue_kick(vi->cvq))) {
> + ret = (buf->status == VIRTIO_NET_OK);
> + goto out;
> + }
>  
>   /* Spin for a response, the kick causes an ioport write, trapping
>* into the hypervisor, so the request should be handled immediately.
> @@ -1009,7 +1021,11 @@ static bool virtnet_send_command(struct virtnet_info 
> *vi, u8 class, u8 cmd,
>  !virtqueue_is_broken(vi->cvq))
>   cpu_relax();
>  
> - return status == VIRTIO_NET_OK;
> + ret = (buf->status == VIRTIO_NET_OK);
> +
> +out:
> + kfree(buf);
> + return ret;
>  }
>  
>  static int virtnet_set_mac_address(struct net_device *dev, void *p)
> @@ -1151,7 +1167,7 @@ static void virtnet_set_rx_mode(struct net_device *dev)
>  {
>   struct virtnet_info *vi = netdev_priv(dev);
>   struct scatterlist sg[2];
> - u8 promisc, allmulti;
> + u8 *cmdbyte;
>   struct virtio_net_ctrl_mac *mac_data;
>   struct netdev_hw_addr *ha;
>   int uc_count;
> @@ -1163,22 +1179,25 @@ static void virtnet_set_rx_mode(struct net_device 
> *dev)
>   if (!virtio_has_feature(vi->vdev, VIRTIO_NET_F_CTRL_RX))
>   return;
>  
> - promisc = ((dev->flags & IFF_PROMISC) != 0);
> - allmulti = ((dev->flags & IFF_ALLMULTI) != 0);
> + cmdbyte = kmalloc(sizeof(*cmdbyte), GFP_ATOMIC);
> + if (!cmdbyte)
> + return;
>  
> - sg_init_one(sg, , sizeof(promisc));
> + sg_init_one(sg, cmdbyte, sizeof(*cmdbyte));
>  
> + *cmdbyte = ((dev->flags & IFF_PROMISC) != 0);
>   if (!virtnet_send_command(vi, VIRTIO_NET_CTRL_RX,
> VIRTIO_NET_CTRL_RX_PROMISC, sg))
>   dev_warn(>dev, "Failed to %sable promisc mode.\n",
> -  promisc ? "en" : "dis");
> -
> - sg_init_one(sg, , sizeof(allmulti));
> +  *cmdbyte ? "en" : "dis");
>  
> + *cmdbyte = ((dev->flags & IFF_ALLMULTI) != 0);
>   if (!virtnet_send_command(vi, VIRTIO_NET_CTRL_RX,
> VIRTIO_NET_CTRL_RX_ALLMULTI, sg))
>   dev_warn(>dev, "Failed to %sable allmulti mode.\n",
> -  allmulti ? "en" : "dis");
> +  *cmdbyte ? "en" : "dis");
> +
> + kfree(cmdbyte);
>  
>   uc_count = netdev_uc_count(dev);
>   mc_count = netdev_mc_count(dev);
> -- 
> 2.4.3
--
To unsubscribe from this 

Re: [PATCH v2 1/3] virtio_net: Stop doing DMA from the stack

[Michael S. Tsirkin]

On Tue, Oct 27, 2015 at 10:30:19PM -0700, Andy Lutomirski wrote:
> From: Andy Lutomirski 
> 
> Once virtio starts using the DMA API, we won't be able to safely DMA
> from the stack.  virtio-net does a couple of config DMA requests
> from small stack buffers -- switch to using dynamically-allocated
> memory.
> 
> This should have no effect on any performance-critical code paths.
> 
> Cc: net...@vger.kernel.org
> Cc: "Michael S. Tsirkin" 
> Cc: virtualizat...@lists.linux-foundation.org
> Reviewed-by: Joerg Roedel 
> Signed-off-by: Andy Lutomirski 
> ---
> 
> Hi Michael and DaveM-
> 
> This is a prerequisite for the virtio DMA fixing project.  It works
> as a standalone patch, though.  Would it make sense to apply it to
> an appropriate networking tree now?
> 
>  drivers/net/virtio_net.c | 53 
> 
>  1 file changed, 36 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index d8838dedb7a4..4f10f8a58811 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -976,31 +976,43 @@ static bool virtnet_send_command(struct virtnet_info 
> *vi, u8 class, u8 cmd,
>struct scatterlist *out)
>  {
>   struct scatterlist *sgs[4], hdr, stat;
> - struct virtio_net_ctrl_hdr ctrl;
> - virtio_net_ctrl_ack status = ~0;
> +
> + struct {
> + struct virtio_net_ctrl_hdr ctrl;
> + virtio_net_ctrl_ack status;
> + } *buf;
> +
>   unsigned out_num = 0, tmp;
> + bool ret;
>  
>   /* Caller should know better */
>   BUG_ON(!virtio_has_feature(vi->vdev, VIRTIO_NET_F_CTRL_VQ));
>  
> - ctrl.class = class;
> - ctrl.cmd = cmd;
> + buf = kmalloc(sizeof(*buf), GFP_ATOMIC);
> + if (!buf)
> + return false;

This is problematic. The command is never retried, the error
is propagated to userspace.

> + buf->status = ~0;
> +
> + buf->ctrl.class = class;
> + buf->ctrl.cmd = cmd;
>   /* Add header */
> - sg_init_one(, , sizeof(ctrl));
> + sg_init_one(, >ctrl, sizeof(buf->ctrl));
>   sgs[out_num++] = 
>  
>   if (out)
>   sgs[out_num++] = out;
>  
>   /* Add return status. */
> - sg_init_one(, , sizeof(status));
> + sg_init_one(, >status, sizeof(buf->status));
>   sgs[out_num] = 
>  
>   BUG_ON(out_num + 1 > ARRAY_SIZE(sgs));
>   virtqueue_add_sgs(vi->cvq, sgs, out_num, 1, vi, GFP_ATOMIC);
>  
> - if (unlikely(!virtqueue_kick(vi->cvq)))
> - return status == VIRTIO_NET_OK;
> + if (unlikely(!virtqueue_kick(vi->cvq))) {
> + ret = (buf->status == VIRTIO_NET_OK);
> + goto out;
> + }
>  
>   /* Spin for a response, the kick causes an ioport write, trapping
>* into the hypervisor, so the request should be handled immediately.
> @@ -1009,7 +1021,11 @@ static bool virtnet_send_command(struct virtnet_info 
> *vi, u8 class, u8 cmd,
>  !virtqueue_is_broken(vi->cvq))
>   cpu_relax();
>  
> - return status == VIRTIO_NET_OK;
> + ret = (buf->status == VIRTIO_NET_OK);
> +
> +out:
> + kfree(buf);
> + return ret;
>  }
>  
>  static int virtnet_set_mac_address(struct net_device *dev, void *p)
> @@ -1151,7 +1167,7 @@ static void virtnet_set_rx_mode(struct net_device *dev)
>  {
>   struct virtnet_info *vi = netdev_priv(dev);
>   struct scatterlist sg[2];
> - u8 promisc, allmulti;
> + u8 *cmdbyte;
>   struct virtio_net_ctrl_mac *mac_data;
>   struct netdev_hw_addr *ha;
>   int uc_count;
> @@ -1163,22 +1179,25 @@ static void virtnet_set_rx_mode(struct net_device 
> *dev)
>   if (!virtio_has_feature(vi->vdev, VIRTIO_NET_F_CTRL_RX))
>   return;
>  
> - promisc = ((dev->flags & IFF_PROMISC) != 0);
> - allmulti = ((dev->flags & IFF_ALLMULTI) != 0);
> + cmdbyte = kmalloc(sizeof(*cmdbyte), GFP_ATOMIC);
> + if (!cmdbyte)
> + return;

Here the error is ignored, rx mode will be incorrect.
OTOH it looks like that's already the case.

>  
> - sg_init_one(sg, , sizeof(promisc));
> + sg_init_one(sg, cmdbyte, sizeof(*cmdbyte));
>  
> + *cmdbyte = ((dev->flags & IFF_PROMISC) != 0);
>   if (!virtnet_send_command(vi, VIRTIO_NET_CTRL_RX,
> VIRTIO_NET_CTRL_RX_PROMISC, sg))
>   dev_warn(>dev, "Failed to %sable promisc mode.\n",
> -  promisc ? "en" : "dis");
> -
> - sg_init_one(sg, , sizeof(allmulti));
> +  *cmdbyte ? "en" : "dis");
>  
> + *cmdbyte = ((dev->flags & IFF_ALLMULTI) != 0);
>   if (!virtnet_send_command(vi, VIRTIO_NET_CTRL_RX,
> VIRTIO_NET_CTRL_RX_ALLMULTI, sg))
>   dev_warn(>dev, "Failed to %sable allmulti mode.\n",
> -  allmulti ? "en" : "dis");
> +  *cmdbyte ? "en" : "dis");
> +
> + kfree(cmdbyte);
>  
>   

Re: [PATCH 07/10] merge_config.sh: add tests

[Olof Johansson]

On Wed, Oct 28, 2015 at 4:00 PM, Darren Hart  wrote:
> On Wed, Oct 28, 2015 at 09:42:08AM +0900, Olof Johansson wrote:
>> For being a small script, merge_config.sh is fairly scary to change since 
>> there's no
>> real way to know if you did something wrong. So it seems appropriate to add 
>> a simple
>> test suite.
>>
>> I've started with testcases in the areas I care about, other should of 
>> course feel
>> free to expand on this.
>>
>> Use is simple, from the kernel tree, run 
>> ./scripts/kconfig/merge_config_test/runall.
>> It'll execute out of a tmpdir under /tmp.
>>
>> Signed-off-by: Olof Johansson 
>
> Thanks for writing the test cases. Shell scripting is so easy to bikeshed - so
> I'm going to skip that. I didn't catch any bashisms, and the test coverage is
> good.

Thanks!

Anyone who wishes to contribute style comments has to contribute at
least one additional testcase as well. Fair? :)


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

Re: [PATCH 00/10] merge_config misc reworks and testcases

[Darren Hart]

On Wed, Oct 28, 2015 at 01:30:59AM -0400, Bruce Ashfield wrote:
> On 10/28/2015 01:02 AM, Darren Hart wrote:
> >On Wed, Oct 28, 2015 at 09:42:01AM +0900, Olof Johansson wrote:
> >>- The script now prints the warnings on stderr, and returns non-0 when
> >>   something is encountered
> >
> >This one might impact linux-yocto usage, Bruce? That said, it seems like the
> >right thing to do. So I'd still like to see it go in, but we may need to 
> >plan to
> >update the dependent tooling to use it.
> 
> I don't directly let the merge_config output be visible, but capture it
> and then do more processing later. So while this may mean that I have
> to update some wrappers to capture stderr, it shouldn't be a big deal.
> 
> >
> >>
> >>- Optionally, it'll also return non-0 when a redundant entry is found. I
> >>   presumed people rely on -r not being a failure so I did this separately
> >>
> >>- CONFIG_FOO=n and "# CONFIG_FOO is not set" is now treated the same,
> >>   and using the former doesn't cause an invalid warning when the results
> >>   are checked at the end
> >>
> >>- Slightly odd things happened if a fragment contains the same option
> >>   twice: It'd produce a warning that was malformed. Now just ignore that
> >>   and use only the latest value of said option.
> >
> >This one will likely impact usage as well. linux-yocto does want to report 
> >when
> >there is an override, not as an error, but for informational purposes - 
> >"Where
> >does my option get clobbered?"
> 
> I haven't looked at the patches yet (and I will shortly), but if that
> is within a single fragment, I can live with it going away, since it is
> easy to check that outside of the merge script.
> 
> But if this is a redefinition between fragments, that's something different
> and something that I capture and report to users, and yes, I
> currently take it from the output of the merge_config run. If it goes
> away, I'd have to recreate it somehow.
> 
> So if this can at least be maintained as enabled via a parameter, that
> would be be ideal. Otherwise, I'll have to recreate the output some
> other way.

It still reports redundancies across different fragments. It just fixes the grep
so it doesn't display two options from the same file.

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

Re: [PATCH] drm/vmwgfx: switch from ioremap_cache to memremap

[Thomas Hellstrom]

Dan,

On 10/19/2015 11:34 PM, Williams, Dan J wrote:
> On Tue, 2015-10-13 at 20:52 +0200, Thomas Hellstrom wrote:
>>> Ok, I'll make local read_fifo() and write_fifo() macros to make this
>>> explicit.  Are these names ok with you?
>> Sure.
>>
> So I ended up just leaving the __iomem annotation on mmio_virt for now
> until the implementation can be converted to use explicit barriers where
> necessary.

Thanks, I'll queue this on vmwgfx-next for 4.4 and carry on from there.

Reviewed-by: Thomas Hellstrom 


>
> 8<-
> Subject: drm/vmwgfx: switch from ioremap_cache to memremap
>
> From: Dan Williams 
>
> Per commit 2e586a7e017a "drm/vmwgfx: Map the fifo as cached" the driver
> expects the fifo registers to be cacheable.  In preparation for
> deprecating ioremap_cache() convert its usage in vmwgfx to memremap().
>
> Cc: David Airlie 
> Cc: Thomas Hellstrom 
> Cc: Sinclair Yeh 
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Dan Williams 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |   14 ++
>  1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> index 2c7a25c71af2..33e9eda77bad 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> @@ -752,8 +752,14 @@ static int vmw_driver_load(struct drm_device *dev, 
> unsigned long chipset)
>   ttm_lock_set_kill(_priv->fbdev_master.lock, false, SIGTERM);
>   dev_priv->active_master = _priv->fbdev_master;
>  
> - dev_priv->mmio_virt = ioremap_cache(dev_priv->mmio_start,
> - dev_priv->mmio_size);
> + /*
> +  * Force __iomem for this mapping until the implied compiler
> +  * barriers and {READ|WRITE}_ONCE semantics from the
> +  * io{read|write}32() accessors can be replaced with explicit
> +  * barriers.
> +  */
> + dev_priv->mmio_virt = (void __iomem *) memremap(dev_priv->mmio_start,
> + dev_priv->mmio_size, MEMREMAP_WB);
>  
>   if (unlikely(dev_priv->mmio_virt == NULL)) {
>   ret = -ENOMEM;
> @@ -907,7 +913,7 @@ out_no_irq:
>  out_no_device:
>   ttm_object_device_release(_priv->tdev);
>  out_err4:
> - iounmap(dev_priv->mmio_virt);
> + memunmap((void __force *) dev_priv->mmio_virt);
>  out_err3:
>   vmw_ttm_global_release(dev_priv);
>  out_err0:
> @@ -958,7 +964,7 @@ static int vmw_driver_unload(struct drm_device *dev)
>   pci_release_regions(dev->pdev);
>  
>   ttm_object_device_release(_priv->tdev);
> - iounmap(dev_priv->mmio_virt);
> + memunmap((void __force *) dev_priv->mmio_virt);
>   if (dev_priv->ctx.staged_bindings)
>   vmw_binding_state_free(dev_priv->ctx.staged_bindings);
>   vmw_ttm_global_release(dev_priv);
>

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

Re: [PATCH V3 3/5] cpufreq: ondemand: queue work for policy->cpus together

[Rafael J. Wysocki]

On Wednesday, October 28, 2015 12:16:35 PM Viresh Kumar wrote:
> On 28-10-15, 07:38, Rafael J. Wysocki wrote:
> > On Tuesday, October 13, 2015 01:39:03 PM Viresh Kumar wrote:
> > > Currently update_sampling_rate() runs over each online CPU and
> > > cancels/queues work on it. Its very inefficient for the case where a
> > > single policy manages multiple CPUs, as they can be processed together.
> > 
> > In the case of one policy object shared between multiple CPUs, I'm
> > wondering why we don't use a single delayed work function for all of them
> > in the first place.  That would address the problem at the source instead
> > of dealing with the symptoms.
> 
> That's what we had long back. The problem is that the timers queued
> for cpufreq are deferrable and if the CPU, on which the timer is
> queued, goes idle, then the governor would halt. And there can be
> other CPUs in the policy->cpus group which are still running.

It looks like we shouldn't be using delayed works for this, really.

We should be using timer functions and normal work items.  Schedule the
timer function on all CPUs sharing the policy and then queue up the
work item from the first one that executes the timer.  Then make the
timer function bail out immediately until the work has completed and
re-schedule the timers from the work item.

Thanks,
Rafael

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

Re: perf: fuzzer triggered trouble on AMD, maybe ibs related

[Stephane Eranian]

On Thu, Oct 22, 2015 at 6:46 PM, Vince Weaver  wrote:
> Hello
>
> I've been busy but finally had a chance to run perf_fuzzer on current git.
> I am running on an AMD A10 system (my traditional Haswell system is
> otherwise occupied).
>
> I got the following WARNING which was followed by an NMI storm which
> eventually managed to confuse ext4 enough that my / partition was
> remounted read-only? Very alarming.
>
> This is in static void perf_ibs_start(struct perf_event *event, int flags)
>
> if (WARN_ON_ONCE(!(hwc->state & PERF_HES_STOPPED)))
> return;
>
Was able to reproduce a similar warning in generic x86 code:

[ 2357.625987] WARNING: CPU: 2 PID: 17152 at
arch/x86/kernel/cpu/perf_event.c:1209 x86_pmu_start+0xa2/0x100()
[ 2357.635775] Modules linked in: cfg80211 snd_hda_codec_realtek
snd_hda_codec_generic snd_hda_intel snd_hda_codec kvm_amd kvm
snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event
snd_rawmidi snd_seq crct10dif_pclmul crc32_pclmul snd_seq_device
snd_timer aesni_intel snd eeepc_wmi asus_wmi aes_x86_64 sparse_keymap
lrw video gf128mul glue_helper edac_mce_amd ablk_helper cryptd shpchp
edac_core wmi soundcore i2c_piix4 serio_raw 8250_fintek k10temp
fam15h_power mac_hid parport_pc ppdev lp parport autofs4 psmouse r8169
ahci libahci mii
[ 2357.687313] CPU: 2 PID: 17152 Comm: perf_fuzzer Not tainted 4.3.0-rc7+ #1
[ 2357.694212] Hardware name: To be filled by O.E.M. To be filled by
O.E.M./M5A97 PRO, BIOS 1604 10/16/2012
[ 2357.703829]  81a9f3e0 88021ec83d80 8139bed4

[ 2357.711636]  88021ec83db8 81078f26 88021ec8c040
8800c9f85000
[ 2357.719430]  0001 8802131d4868 8802131d4800
88021ec83dc8
[ 2357.727158] Call Trace:
[ 2357.729657][] dump_stack+0x44/0x60
[ 2357.735573]  [] warn_slowpath_common+0x86/0xc0
[ 2357.746342]  [] warn_slowpath_null+0x1a/0x20
[ 2357.756968]  [] x86_pmu_start+0xa2/0x100
[ 2357.767071]  [] perf_event_task_tick+0x239/0x270
[ 2357.777894]  [] scheduler_tick+0x7b/0xd0
[ 2357.788053]  [] ? tick_sched_do_timer+0x30/0x30
[ 2357.798693]  [] update_process_times+0x51/0x60
[ 2357.809102]  [] tick_sched_handle.isra.15+0x25/0x60
[ 2357.819956]  [] tick_sched_timer+0x40/0x70
[ 2357.829943]  [] __hrtimer_run_queues+0xe4/0x200
[ 2357.840398]  [] hrtimer_interrupt+0xa8/0x1a0
[ 2357.850522]  [] local_apic_timer_interrupt+0x38/0x60
[ 2357.861370]  [] smp_trace_apic_timer_interrupt+0x44/0xab
[ 2357.872524]  [] trace_apic_timer_interrupt+0x82/0x90
[ 2357.883314]  

This can be explained if the event is not in the cpuc->active_mask as
per code in
x86_pmu_stop() vs x86_pmu_start(). I am investigating some more


> [  359.629045] WARNING: CPU: 0 PID: 0 at 
> arch/x86/kernel/cpu/perf_event_amd_ibs.c:372 perf_ibs_start+0x43/0x131()
> [  359.639091] Modules linked in: nfsd auth_rpcgss oid_registry nfs_acl nfs 
> lockd grace fscache sunrpc nls_utf8 nls_cp437 vfat fat snd_hda_codec_realtek 
> snd_hda_codec_generic snd_hda_codec_hdmi kvm_amd kvm sha256_generic hmac drbg 
> ansi_cprng aesni_intel aes_x86_64 snd_hda_intel ablk_helper cryptd 
> snd_hda_codec lrw snd_hda_core gf128mul glue_helper ppdev snd_hwdep hp_wmi 
> snd_pcm evdev sparse_keymap snd_timer pl2303 radeon ttm drm_kms_helper 
> tpm_infineon pcspkr drm efivars psmouse serio_raw i2c_piix4 i2c_algo_bit 
> usbserial fb_sys_fops shpchp k10temp parport_pc snd syscopyarea i2c_core 
> parport soundcore tpm_tis wmi sysfillrect button tpm sysimgblt acpi_cpufreq 
> processor sg sr_mod cdrom sd_mod ohci_pci ahci libahci tg3 xhci_pci ptp 
> pps_core libata xhci_hcd ohci_hcd ehci_pci libphy ehci_hcd crc32c_intel
> [  359.711502]  scsi_mod usbcore usb_common
> [  359.714203] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GW   
> 4.3.0-rc6+ #12
> [  359.721804] Hardware name: Hewlett-Packard HP Compaq Pro 6305 SFF/1850, 
> BIOS K06 v02.57 08/16/2013
> [  359.730808]  0006 8123e6b7  
> 8104519a
> [  359.738322]  8102a003 880224098c00 e8c036d0 
> 81824ec0
> [  359.745832]  88022ec0f8e0 8102a003 880224098c00 
> e8c06a70
> [  359.753328] Call Trace:
> [  359.755793][] ? dump_stack+0x40/0x50
> [  359.761762]  [] ? warn_slowpath_common+0x94/0xa9
> [  359.767963]  [] ? perf_ibs_start+0x43/0x131
> [  359.773730]  [] ? perf_ibs_start+0x43/0x131
> [  359.779495]  [] ? perf_event_task_tick+0x101/0x1b5
> [  359.785874]  [] ? tick_sched_do_timer+0x24/0x24
> [  359.791990]  [] ? scheduler_tick+0x64/0x7d
> [  359.797673]  [] ? update_process_times+0x3b/0x45
> [  359.803876]  [] ? tick_sched_handle+0x3e/0x4a
> [  359.809820]  [] ? tick_sched_timer+0x2f/0x53
> [  359.815676]  [] ? __hrtimer_run_queues+0xb9/0x18b
> [  359.821967]  [] ? hrtimer_interrupt+0x61/0x101
> [  359.827995]  [] ? smp_apic_timer_interrupt+0x20/0x2f
> [  359.834549]  [] ? apic_timer_interrupt+0x7f/0x90
> [  359.840745][] ? cpuidle_enter_state+0xf3/0x145
> [  359.847579]  [] ? 

Re: [PATCH 1/6] dmaengine: tegra-apb: Correct runtime-pm usage

[Vinod Koul]

On Fri, Oct 16, 2015 at 09:25:52AM +0100, Jon Hunter wrote:
> @@ -1182,14 +1182,11 @@ static int tegra_dma_alloc_chan_resources(struct 
> dma_chan *dc)
>  {
>   struct tegra_dma_channel *tdc = to_tegra_dma_chan(dc);
>   struct tegra_dma *tdma = tdc->tdma;
> - int ret;
>  
>   dma_cookie_init(>dma_chan);
>   tdc->config_init = false;
> - ret = clk_prepare_enable(tdma->dma_clk);
> - if (ret < 0)
> - dev_err(tdc2dev(tdc), "clk_prepare_enable failed: %d\n", ret);
> - return ret;
> +
> + return pm_runtime_get_sync(tdma->dev);

Alloc channel is supposed to return number of descriptors allocated and if
pm_runtime_get_sync() returns postive values we get wrong return!

>   pm_runtime_enable(>dev);
> - if (!pm_runtime_enabled(>dev)) {
> + if (!pm_runtime_enabled(>dev))
>   ret = tegra_dma_runtime_resume(>dev);
> - if (ret) {
> - dev_err(>dev, "dma_runtime_resume failed %d\n",
> - ret);
> - goto err_pm_disable;
> - }
> - }
> + else
> + ret = pm_runtime_get_sync(>dev);

do we need pm_runtime_get() here, should we use pm_request_resume() ?

>  static int tegra_dma_pm_suspend(struct device *dev)
>  {
>   struct tegra_dma *tdma = dev_get_drvdata(dev);
> - int i;
> - int ret;
> + int i, ret;
>  
>   /* Enable clock before accessing register */
> - ret = tegra_dma_runtime_resume(dev);
> + ret = pm_runtime_get_sync(dev);

If you are runtime suspended then core will runtime resume you before
invoking suspend, so why do we need this

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

[PATCH v2] cputime: fix invalid gtime

[Hiroshi Shimamoto]

From: Hiroshi Shimamoto 

/proc/stats shows invalid gtime when the thread is running in guest.
When vtime accounting is not enabled, we cannot get a valid delta.
The delta is calculated now - tsk->vtime_snap, but tsk->vtime_snap
is only updated when vtime accounting is enabled.

This patch makes task_gtime() just return gtime when vtime accounting
is not enabled.

The kernel config contains CONFIG_VIRT_CPU_ACCOUNTING_GEN=y and
CONFIG_NO_HZ_FULL_ALL=n and boot without nohz_full.

I ran and stop a busy loop in VM and see the gtime in host.
Dump the 43rd field which shows the gtime in every second.
 # while :; do awk '{print $3" "$43}' /proc/3955/task/4014/stat; sleep 1; done
S 4348
R 7064566
R 7064766
R 7064967
R 7065168
S 4759
S 4759

During running busy loop, it returns large value.

After applying this patch, we can see right gtime.

 # while :; do awk '{print $3" "$43}' /proc/10913/task/10956/stat; sleep 1; done
S 5338
R 5365
R 5465
R 5566
R 5666
S 5726
S 5726

Signed-off-by: Hiroshi Shimamoto 
---
 kernel/sched/cputime.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
index 8cbc3db..f614ee9 100644
--- a/kernel/sched/cputime.c
+++ b/kernel/sched/cputime.c
@@ -786,6 +786,9 @@ cputime_t task_gtime(struct task_struct *t)
unsigned int seq;
cputime_t gtime;
 
+   if (!vtime_accounting_enabled())
+   return t->gtime;
+
do {
seq = read_seqbegin(>vtime_seqlock);
 
-- 
1.8.3.1

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

Re: [PATCH 07/10] merge_config.sh: add tests

[Darren Hart]

On Wed, Oct 28, 2015 at 09:42:08AM +0900, Olof Johansson wrote:
> For being a small script, merge_config.sh is fairly scary to change since 
> there's no
> real way to know if you did something wrong. So it seems appropriate to add a 
> simple
> test suite.
> 
> I've started with testcases in the areas I care about, other should of course 
> feel
> free to expand on this.
> 
> Use is simple, from the kernel tree, run 
> ./scripts/kconfig/merge_config_test/runall.
> It'll execute out of a tmpdir under /tmp.
> 
> Signed-off-by: Olof Johansson 

Thanks for writing the test cases. Shell scripting is so easy to bikeshed - so
I'm going to skip that. I didn't catch any bashisms, and the test coverage is
good.

Reviewed-by: Darren Hart 

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

[PATCH] lpfc: replaced kmalloc + memset with kzalloc

[Saurabh Sengar]

replacing kmalloc and memset by a single call of kzalloc

Signed-off-by: Saurabh Sengar 
---
 drivers/scsi/lpfc/lpfc_els.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc_els.c b/drivers/scsi/lpfc/lpfc_els.c
index 36bf58b..9729ab1 100644
--- a/drivers/scsi/lpfc/lpfc_els.c
+++ b/drivers/scsi/lpfc/lpfc_els.c
@@ -4990,13 +4990,12 @@ lpfc_els_rcv_rdp(struct lpfc_vport *vport, struct 
lpfc_iocbq *cmdiocb,
if (RDP_NPORT_ID_SIZE !=
be32_to_cpu(rdp_req->nport_id_desc.length))
goto rjt_logerr;
-   rdp_context = kmalloc(sizeof(struct lpfc_rdp_context), GFP_KERNEL);
+   rdp_context = kzalloc(sizeof(struct lpfc_rdp_context), GFP_KERNEL);
if (!rdp_context) {
rjt_err = LSRJT_UNABLE_TPC;
goto error;
}
 
-   memset(rdp_context, 0, sizeof(struct lpfc_rdp_context));
cmd = >iocb;
rdp_context->ndlp = lpfc_nlp_get(ndlp);
rdp_context->ox_id = cmd->unsli3.rcvsli3.ox_id;
-- 
1.9.1

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

Re: [PATCH 6/6] dmaengine: tegra-apb: Disable interrupts on removal

[Vinod Koul]

On Fri, Oct 16, 2015 at 11:57:02AM +0100, Jon Hunter wrote:
> >>> How about just calling free_irq()? That's how you'd typically handle this.
> >>
> >> Yes, however, the interrupt is requested by devm_request_irq(). I guess
> >> I could call devm_free_irq() here?
> > 
> > Just use request_irq() instead of devm_request_irq(). You have the same
> > issue on the error path in the probe function anyway and also need to add
> > the free_irq() before the tasklet_kill() there as well.
> 
> I was wondering about that but the tasklets should never be scheduled if
> the probe does not succeed, so I think it is ok.

This is actually very racy, if probe fails but due to devm_ calls your irq
is alive till it freed by core

And a faulty device triggering irq can complicate matters, so for irq IMHO
we don't get much benefit with devm_ variant

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

Re: [PATCH v3 0/3] virtio DMA API core stuff

[David Woodhouse]

On Tue, 2015-10-27 at 23:38 -0700, Andy Lutomirski wrote:
> 
> Changes from v2:
>  - Fix really embarrassing bug.  This version actually works.

So embarrassing you didn't want to tell us what it was? ...

--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -292,7 +292,7 @@ static inline int virtqueue_add(struct virtqueue *_vq,
vq, desc, total_sg * sizeof(struct vring_desc),
DMA_TO_DEVICE);
 
-   if (vring_mapping_error(vq, vq->vring.desc[head].addr))
+   if (vring_mapping_error(vq, addr))
goto unmap_release;
 
vq->vring.desc[head].flags = cpu_to_virtio16(_vq->vdev, 
VRING_DESC_F_INDIRECT);

That wasn't going to be the reason for Christian's failure, was it?


-- 
dwmw2




smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH v3] dmaengine: fsl-edma: add PM suspend/resume support

[Vinod Koul]

On Tue, Oct 27, 2015 at 03:58:31AM +, Yao Yuan wrote:
> Hi Vinod,
> 

Please do not top post

> Thanks for your review.
> I did the test and it seems that it should be ok when CONFIG_PM is not 
> defined.
> So I removed the protection code to make it more readable.
> Do you think is it ok?

Yes I did check, this seems okay, pls ignore this comment. You still need to
explain why you use late/early calls

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

Re: [PATCH V3 3/5] cpufreq: ondemand: queue work for policy->cpus together

[Viresh Kumar]

On 28-10-15, 07:38, Rafael J. Wysocki wrote:
> On Tuesday, October 13, 2015 01:39:03 PM Viresh Kumar wrote:
> > Currently update_sampling_rate() runs over each online CPU and
> > cancels/queues work on it. Its very inefficient for the case where a
> > single policy manages multiple CPUs, as they can be processed together.
> 
> In the case of one policy object shared between multiple CPUs, I'm
> wondering why we don't use a single delayed work function for all of them
> in the first place.  That would address the problem at the source instead
> of dealing with the symptoms.

That's what we had long back. The problem is that the timers queued
for cpufreq are deferrable and if the CPU, on which the timer is
queued, goes idle, then the governor would halt. And there can be
other CPUs in the policy->cpus group which are still running.

> > Also drop the unnecessary cancel_delayed_work_sync() as we are doing a
> > mod_delayed_work_on() in gov_queue_work(), which will take care of
> > pending works for us.
> 
> I'd prefer a separate patch for that if poss.

okay.

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

Re: [PATCH V3 1/5] cpufreq: ondemand: Drop unnecessary locks from update_sampling_rate()

[Viresh Kumar]

On 28-10-15, 06:54, Rafael J. Wysocki wrote:
> On Wednesday, October 28, 2015 10:14:51 AM Viresh Kumar wrote:
> > In cases where a single policy controls multiple CPUs, a timer is
> > queued for every cpu present in policy->cpus. When we reach the timer
> > handler (which can be on multiple CPUs together) on any CPU, we trace
> > CPU load for all policy->cpus and update the frequency accordingly.
> 
> That would be in dbs_timer(), right?

Yeah, and we already do stuff from within the mutex there.

> > The lock is for protecting multiple CPUs to do the same thing
> > together, as only its required to be done by a single CPU. Once any
> > CPUs handler has completed, it updates the last update time and drops
> > the mutex. At that point of time, other blocked handler (if any) check
> > the last update time and return early.
> 
> Well, that would mean we only needed to hold the lock around the
> need_load_eval() evaluation in dbs_timer() if I'm not mistaken.

Actually yeah, but then the fourth patch of this series uses the
timer_mutex to fix a long standing problem (which was fixed by hacking
the code earlier). And so we need to take the lock for the entire
dbs_timer() routine.

> We also should acquire it around updates of the sampling rate, which
> essentially is set_sampling_rate().

Why? In the worst case we may schedule the next timer for the earlier
sampling rate. But do we care that much for that race, that we want to
add locks here as well ?

> Is there any reason to acquire it in cpufreq_governor_limits(), then,
> for example?

Yeah, we are calling dbs_check_cpu(dbs_data, cpu) from that path,
which will reevaluate the load.

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

Re: [PATCH V3 4/5] cpufreq: governor: Quit work-handlers early if governor is stopped

[Rafael J. Wysocki]

On Tuesday, October 13, 2015 01:39:04 PM Viresh Kumar wrote:
> cpufreq_governor_lock is abused by using it outside of cpufreq core,
> i.e. in cpufreq-governors. But we didn't had a better solution to the
> problem (described later) at that point of time, and following was the
> only acceptable solution:
> 
> 6f1e4efd882e ("cpufreq: Fix timer/workqueue corruption by protecting
> reading governor_enabled")
> 
> The cpufreq governor core is fixed against possible races now and things
> are in much better shape.
> 
> The original problem:
> 
> When a CPU is hot unplugged, we cancel delayed works for all
> policy->cpus via gov_cancel_work(). If the work is already running on
> any CPU, the workqueue code will wait for the work to finish, to prevent
> the work items from re-queuing themselves.
> 
> This works most of the time, except for the case where the work handler
> determines that it should adjust the delay for all other CPUs, that the
> policy is managing. When this happens, the canceling CPU will cancel its
> own work but can queue up the works on other policy->cpus.
> 
> For example, consider CPU 0-4 in a policy and we called
> gov_cancel_work() for them. Workqueue core canceled the works for 0-3
> and is waiting for the handler to finish on CPU4. At that time, handler
> on CPU4 can restart works on CPU 0-3 again. Which makes 0-3 run works,
> which the governor core thinks are canceled.
> 
> To fix that in a different (non-hacky) way, set set shared->policy to
> false before trying to cancel the work. It should be updated within
> timer_mutex, which will prevent the work-handlers to start. Once the
> work-handlers finds that we are already trying to stop the governor, it
> will exit early. And that will prevent queuing of works again as well.
> 
> Signed-off-by: Viresh Kumar 

I have a hard time figuring out what the patch is supposed to achieve from
the above.

Do we eventually want to get rid of cpufreq_governor_lock and that's why we're
doing this?

> ---
>  drivers/cpufreq/cpufreq_governor.c | 33 +++--
>  1 file changed, 23 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/cpufreq/cpufreq_governor.c 
> b/drivers/cpufreq/cpufreq_governor.c
> index 750626d8fb03..931424ca96d9 100644
> --- a/drivers/cpufreq/cpufreq_governor.c
> +++ b/drivers/cpufreq/cpufreq_governor.c
> @@ -171,10 +171,6 @@ void gov_queue_work(struct dbs_data *dbs_data, struct 
> cpufreq_policy *policy,
>  {
>   int i;
>  
> - mutex_lock(_governor_lock);
> - if (!policy->governor_enabled)
> - goto out_unlock;
> -
>   if (!all_cpus) {
>   /*
>* Use raw_smp_processor_id() to avoid preemptible warnings.
> @@ -188,9 +184,6 @@ void gov_queue_work(struct dbs_data *dbs_data, struct 
> cpufreq_policy *policy,
>   for_each_cpu(i, policy->cpus)
>   __gov_queue_work(i, dbs_data, delay);
>   }
> -
> -out_unlock:
> - mutex_unlock(_governor_lock);
>  }
>  EXPORT_SYMBOL_GPL(gov_queue_work);
>  
> @@ -229,13 +222,24 @@ static void dbs_timer(struct work_struct *work)
>   struct cpu_dbs_info *cdbs = container_of(work, struct cpu_dbs_info,
>dwork.work);
>   struct cpu_common_dbs_info *shared = cdbs->shared;
> - struct cpufreq_policy *policy = shared->policy;
> - struct dbs_data *dbs_data = policy->governor_data;
> + struct cpufreq_policy *policy;
> + struct dbs_data *dbs_data;
>   unsigned int sampling_rate, delay;
>   bool modify_all = true;
>  
>   mutex_lock(>timer_mutex);
>  
> + policy = shared->policy;
> +
> + /*
> +  * Governor might already be disabled and there is no point continuing
> +  * with the work-handler.
> +  */
> + if (!policy)
> + goto unlock;
> +
> + dbs_data = policy->governor_data;
> +
>   if (dbs_data->cdata->governor == GOV_CONSERVATIVE) {
>   struct cs_dbs_tuners *cs_tuners = dbs_data->tuners;
>  
> @@ -252,6 +256,7 @@ static void dbs_timer(struct work_struct *work)
>   delay = dbs_data->cdata->gov_dbs_timer(cdbs, dbs_data, modify_all);
>   gov_queue_work(dbs_data, policy, delay, modify_all);
>  
> +unlock:
>   mutex_unlock(>timer_mutex);
>  }
>  
> @@ -488,9 +493,17 @@ static int cpufreq_governor_stop(struct cpufreq_policy 
> *policy,
>   if (!shared || !shared->policy)
>   return -EBUSY;
>  
> + /*
> +  * Work-handler must see this updated, as it should not proceed any
> +  * further after governor is disabled. And so timer_mutex is taken while
> +  * updating this value.
> +  */
> + mutex_lock(>timer_mutex);
> + shared->policy = NULL;
> + mutex_unlock(>timer_mutex);

So this assumes that dbs_timer() will acquire the mutex and see that
shared->policy is now NULL, so it will bail out immediately, but ->

> +
>   gov_cancel_work(dbs_data, policy);
>  
> - shared->policy = NULL;
>   

Re: character driver - poll() timeout

[Muni Sekhar]

On Tue, Oct 27, 2015 at 8:48 PM, Clemens Ladisch  wrote:
> Muni Sekhar wrote:
>> On Tue, Oct 27, 2015 at 1:41 PM, Clemens Ladisch  wrote:
>>> Muni Sekhar wrote:
 Is it possible to print the timeout value in character driver poll() API?
>>>
>>> No.  Your driver's poll callback never waits.
>>>
>>> Why do you think you need this value?
>>
>> I need to find out when exactly driver's poll callback returned timeout.
>
> Your poll callback _cannot_ return a timeout.
>
> Why do you think you need this information for?

During stress test, my test application fails and throws poll() timeout error.

I need to debug what is the state of my driver during that time. I
added prints in driver poll(), but I gets lots of debug prints if
poll() timeout is more.

So I am wonder if it is possible to get a single debug print for this scenario?


>
>
> Regards,
> Clemens



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

[PATCH v3 0/3] virtio DMA API core stuff

[Andy Lutomirski]

This switches virtio to use the DMA API unconditionally.  I'm sure
it breaks things, but it seems to work on x86 using virtio-pci, with
and without Xen, and using both the modern 1.0 variant and the
legacy variant.

Changes from v2:
 - Fix really embarrassing bug.  This version actually works.

Changes from v1:
 - Fix an endian conversion error causing a BUG to hit.
 - Fix a DMA ordering issue (swiotlb=force works now).
 - Minor cleanups.

Andy Lutomirski (3):
  virtio_net: Stop doing DMA from the stack
  virtio_ring: Support DMA APIs
  virtio_pci: Use the DMA API

 drivers/net/virtio_net.c   |  53 +++
 drivers/virtio/Kconfig |   2 +-
 drivers/virtio/virtio_pci_common.h |   3 +-
 drivers/virtio/virtio_pci_legacy.c |  19 +++-
 drivers/virtio/virtio_pci_modern.c |  34 +--
 drivers/virtio/virtio_ring.c   | 187 ++---
 tools/virtio/linux/dma-mapping.h   |  17 
 7 files changed, 246 insertions(+), 69 deletions(-)
 create mode 100644 tools/virtio/linux/dma-mapping.h

-- 
2.4.3

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

[PATCH v3 1/3] virtio_net: Stop doing DMA from the stack

[Andy Lutomirski]

From: Andy Lutomirski 

Once virtio starts using the DMA API, we won't be able to safely DMA
from the stack.  virtio-net does a couple of config DMA requests
from small stack buffers -- switch to using dynamically-allocated
memory.

This should have no effect on any performance-critical code paths.

Cc: "Michael S. Tsirkin" 
Cc: virtualizat...@lists.linux-foundation.org
Reviewed-by: Joerg Roedel 
Signed-off-by: Andy Lutomirski 
---

Hi Michael and DaveM-

This is a prerequisite for the virtio DMA fixing project.  It works
as a standalone patch, though.  Would it make sense to apply it to
an appropriate networking tree now?

(This is unchanged from v2.)

drivers/net/virtio_net.c | 53 
 1 file changed, 36 insertions(+), 17 deletions(-)

diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index d8838dedb7a4..4f10f8a58811 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -976,31 +976,43 @@ static bool virtnet_send_command(struct virtnet_info *vi, 
u8 class, u8 cmd,
 struct scatterlist *out)
 {
struct scatterlist *sgs[4], hdr, stat;
-   struct virtio_net_ctrl_hdr ctrl;
-   virtio_net_ctrl_ack status = ~0;
+
+   struct {
+   struct virtio_net_ctrl_hdr ctrl;
+   virtio_net_ctrl_ack status;
+   } *buf;
+
unsigned out_num = 0, tmp;
+   bool ret;
 
/* Caller should know better */
BUG_ON(!virtio_has_feature(vi->vdev, VIRTIO_NET_F_CTRL_VQ));
 
-   ctrl.class = class;
-   ctrl.cmd = cmd;
+   buf = kmalloc(sizeof(*buf), GFP_ATOMIC);
+   if (!buf)
+   return false;
+   buf->status = ~0;
+
+   buf->ctrl.class = class;
+   buf->ctrl.cmd = cmd;
/* Add header */
-   sg_init_one(, , sizeof(ctrl));
+   sg_init_one(, >ctrl, sizeof(buf->ctrl));
sgs[out_num++] = 
 
if (out)
sgs[out_num++] = out;
 
/* Add return status. */
-   sg_init_one(, , sizeof(status));
+   sg_init_one(, >status, sizeof(buf->status));
sgs[out_num] = 
 
BUG_ON(out_num + 1 > ARRAY_SIZE(sgs));
virtqueue_add_sgs(vi->cvq, sgs, out_num, 1, vi, GFP_ATOMIC);
 
-   if (unlikely(!virtqueue_kick(vi->cvq)))
-   return status == VIRTIO_NET_OK;
+   if (unlikely(!virtqueue_kick(vi->cvq))) {
+   ret = (buf->status == VIRTIO_NET_OK);
+   goto out;
+   }
 
/* Spin for a response, the kick causes an ioport write, trapping
 * into the hypervisor, so the request should be handled immediately.
@@ -1009,7 +1021,11 @@ static bool virtnet_send_command(struct virtnet_info 
*vi, u8 class, u8 cmd,
   !virtqueue_is_broken(vi->cvq))
cpu_relax();
 
-   return status == VIRTIO_NET_OK;
+   ret = (buf->status == VIRTIO_NET_OK);
+
+out:
+   kfree(buf);
+   return ret;
 }
 
 static int virtnet_set_mac_address(struct net_device *dev, void *p)
@@ -1151,7 +1167,7 @@ static void virtnet_set_rx_mode(struct net_device *dev)
 {
struct virtnet_info *vi = netdev_priv(dev);
struct scatterlist sg[2];
-   u8 promisc, allmulti;
+   u8 *cmdbyte;
struct virtio_net_ctrl_mac *mac_data;
struct netdev_hw_addr *ha;
int uc_count;
@@ -1163,22 +1179,25 @@ static void virtnet_set_rx_mode(struct net_device *dev)
if (!virtio_has_feature(vi->vdev, VIRTIO_NET_F_CTRL_RX))
return;
 
-   promisc = ((dev->flags & IFF_PROMISC) != 0);
-   allmulti = ((dev->flags & IFF_ALLMULTI) != 0);
+   cmdbyte = kmalloc(sizeof(*cmdbyte), GFP_ATOMIC);
+   if (!cmdbyte)
+   return;
 
-   sg_init_one(sg, , sizeof(promisc));
+   sg_init_one(sg, cmdbyte, sizeof(*cmdbyte));
 
+   *cmdbyte = ((dev->flags & IFF_PROMISC) != 0);
if (!virtnet_send_command(vi, VIRTIO_NET_CTRL_RX,
  VIRTIO_NET_CTRL_RX_PROMISC, sg))
dev_warn(>dev, "Failed to %sable promisc mode.\n",
-promisc ? "en" : "dis");
-
-   sg_init_one(sg, , sizeof(allmulti));
+*cmdbyte ? "en" : "dis");
 
+   *cmdbyte = ((dev->flags & IFF_ALLMULTI) != 0);
if (!virtnet_send_command(vi, VIRTIO_NET_CTRL_RX,
  VIRTIO_NET_CTRL_RX_ALLMULTI, sg))
dev_warn(>dev, "Failed to %sable allmulti mode.\n",
-allmulti ? "en" : "dis");
+*cmdbyte ? "en" : "dis");
+
+   kfree(cmdbyte);
 
uc_count = netdev_uc_count(dev);
mc_count = netdev_mc_count(dev);
-- 
2.4.3

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

[PATCH v3 2/3] virtio_ring: Support DMA APIs

[Andy Lutomirski]

virtio_ring currently sends the device (usually a hypervisor)
physical addresses of its I/O buffers.  This is okay when DMA
addresses and physical addresses are the same thing, but this isn't
always the case.  For example, this never works on Xen guests, and
it is likely to fail if a physical "virtio" device ever ends up
behind an IOMMU or swiotlb.

The immediate use case for me is to enable virtio on Xen guests.
For that to work, we need vring to support DMA address translation
as well as a corresponding change to virtio_pci or to another
driver.

With this patch, if enabled, virtfs survives kmemleak and
CONFIG_DMA_API_DEBUG.

Signed-off-by: Andy Lutomirski 
---
 drivers/virtio/Kconfig   |   2 +-
 drivers/virtio/virtio_ring.c | 187 +++
 tools/virtio/linux/dma-mapping.h |  17 
 3 files changed, 169 insertions(+), 37 deletions(-)
 create mode 100644 tools/virtio/linux/dma-mapping.h

diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index cab9f3f63a38..77590320d44c 100644
--- a/drivers/virtio/Kconfig
+++ b/drivers/virtio/Kconfig
@@ -60,7 +60,7 @@ config VIRTIO_INPUT
 
  config VIRTIO_MMIO
tristate "Platform bus driver for memory mapped virtio devices"
-   depends on HAS_IOMEM
+   depends on HAS_IOMEM && HAS_DMA
select VIRTIO
---help---
 This drivers provides support for memory mapped virtio
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index 096b857e7b75..6962ea37ade0 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef DEBUG
 /* For development, we want to crash whenever the ring is screwed. */
@@ -54,7 +55,14 @@
 #define END_USE(vq)
 #endif
 
-struct vring_virtqueue {
+struct vring_desc_state
+{
+   void *data; /* Data for callback. */
+   struct vring_desc *indir_desc;  /* Indirect descriptor, if any. */
+};
+
+struct vring_virtqueue
+{
struct virtqueue vq;
 
/* Actual memory layout for this queue */
@@ -92,12 +100,71 @@ struct vring_virtqueue {
ktime_t last_add_time;
 #endif
 
-   /* Tokens for callbacks. */
-   void *data[];
+   /* Per-descriptor state. */
+   struct vring_desc_state desc_state[];
 };
 
 #define to_vvq(_vq) container_of(_vq, struct vring_virtqueue, vq)
 
+/*
+ * The DMA ops on various arches are rather gnarly right now, and
+ * making all of the arch DMA ops work on the vring device itself
+ * is a mess.  For now, we use the parent device for DMA ops.
+ */
+struct device *vring_dma_dev(const struct vring_virtqueue *vq)
+{
+   return vq->vq.vdev->dev.parent;
+}
+
+/* Map one sg entry. */
+static dma_addr_t vring_map_one_sg(const struct vring_virtqueue *vq,
+  struct scatterlist *sg,
+  enum dma_data_direction direction)
+{
+   /*
+* We can't use dma_map_sg, because we don't use scatterlists in
+* the way it expects (we don't guarantee that the scatterlist
+* will exist for the lifetime of the mapping).
+*/
+   return dma_map_page(vring_dma_dev(vq),
+   sg_page(sg), sg->offset, sg->length,
+   direction);
+}
+
+static dma_addr_t vring_map_single(const struct vring_virtqueue *vq,
+  void *cpu_addr, size_t size,
+  enum dma_data_direction direction)
+{
+   return dma_map_single(vring_dma_dev(vq),
+ cpu_addr, size, direction);
+}
+
+static void vring_unmap_one(const struct vring_virtqueue *vq,
+   struct vring_desc *desc)
+{
+   u16 flags = virtio16_to_cpu(vq->vq.vdev, desc->flags);
+
+   if (flags & VRING_DESC_F_INDIRECT) {
+   dma_unmap_single(vring_dma_dev(vq),
+virtio64_to_cpu(vq->vq.vdev, desc->addr),
+virtio32_to_cpu(vq->vq.vdev, desc->len),
+(flags & VRING_DESC_F_WRITE) ?
+DMA_FROM_DEVICE : DMA_TO_DEVICE);
+   } else {
+   dma_unmap_page(vring_dma_dev(vq),
+  virtio64_to_cpu(vq->vq.vdev, desc->addr),
+  virtio32_to_cpu(vq->vq.vdev, desc->len),
+  (flags & VRING_DESC_F_WRITE) ?
+  DMA_FROM_DEVICE : DMA_TO_DEVICE);
+   }
+}
+
+static int vring_mapping_error(const struct vring_virtqueue *vq,
+  dma_addr_t addr)
+{
+   return dma_mapping_error(vring_dma_dev(vq), addr);
+}
+
 static struct vring_desc *alloc_indirect(struct virtqueue *_vq,
 unsigned int total_sg, gfp_t gfp)
 {
@@ -131,7 +198,7 @@ static inline int virtqueue_add(struct virtqueue *_vq,
struct vring_virtqueue *vq 

[PATCH v3 3/3] virtio_pci: Use the DMA API

[Andy Lutomirski]

This fixes virtio-pci on platforms and busses that have IOMMUs.  This
will break the experimental QEMU Q35 IOMMU support until QEMU is
fixed.  In exchange, it fixes physical virtio hardware as well as
virtio-pci running under Xen.

We should clean up the virtqueue API to do its own allocation and
teach virtqueue_get_avail and virtqueue_get_used to return DMA
addresses directly.

Signed-off-by: Andy Lutomirski 
---
 drivers/virtio/virtio_pci_common.h |  3 ++-
 drivers/virtio/virtio_pci_legacy.c | 19 +++
 drivers/virtio/virtio_pci_modern.c | 34 --
 3 files changed, 41 insertions(+), 15 deletions(-)

diff --git a/drivers/virtio/virtio_pci_common.h 
b/drivers/virtio/virtio_pci_common.h
index b976d968e793..cd6196b513ad 100644
--- a/drivers/virtio/virtio_pci_common.h
+++ b/drivers/virtio/virtio_pci_common.h
@@ -38,8 +38,9 @@ struct virtio_pci_vq_info {
/* the number of entries in the queue */
int num;
 
-   /* the virtual address of the ring queue */
+   /* the ring queue */
void *queue;
+   dma_addr_t queue_dma_addr;  /* bus address */
 
/* the list node for the virtqueues list */
struct list_head node;
diff --git a/drivers/virtio/virtio_pci_legacy.c 
b/drivers/virtio/virtio_pci_legacy.c
index 48bc9797e530..b5293e5f2af4 100644
--- a/drivers/virtio/virtio_pci_legacy.c
+++ b/drivers/virtio/virtio_pci_legacy.c
@@ -135,12 +135,14 @@ static struct virtqueue *setup_vq(struct 
virtio_pci_device *vp_dev,
info->msix_vector = msix_vec;
 
size = PAGE_ALIGN(vring_size(num, VIRTIO_PCI_VRING_ALIGN));
-   info->queue = alloc_pages_exact(size, GFP_KERNEL|__GFP_ZERO);
+   info->queue = dma_zalloc_coherent(_dev->pci_dev->dev, size,
+ >queue_dma_addr,
+ GFP_KERNEL);
if (info->queue == NULL)
return ERR_PTR(-ENOMEM);
 
/* activate the queue */
-   iowrite32(virt_to_phys(info->queue) >> VIRTIO_PCI_QUEUE_ADDR_SHIFT,
+   iowrite32(info->queue_dma_addr >> VIRTIO_PCI_QUEUE_ADDR_SHIFT,
  vp_dev->ioaddr + VIRTIO_PCI_QUEUE_PFN);
 
/* create the vring */
@@ -169,7 +171,8 @@ out_assign:
vring_del_virtqueue(vq);
 out_activate_queue:
iowrite32(0, vp_dev->ioaddr + VIRTIO_PCI_QUEUE_PFN);
-   free_pages_exact(info->queue, size);
+   dma_free_coherent(_dev->pci_dev->dev, size,
+ info->queue, info->queue_dma_addr);
return ERR_PTR(err);
 }
 
@@ -194,7 +197,8 @@ static void del_vq(struct virtio_pci_vq_info *info)
iowrite32(0, vp_dev->ioaddr + VIRTIO_PCI_QUEUE_PFN);
 
size = PAGE_ALIGN(vring_size(info->num, VIRTIO_PCI_VRING_ALIGN));
-   free_pages_exact(info->queue, size);
+   dma_free_coherent(_dev->pci_dev->dev, size,
+ info->queue, info->queue_dma_addr);
 }
 
 static const struct virtio_config_ops virtio_pci_config_ops = {
@@ -227,6 +231,13 @@ int virtio_pci_legacy_probe(struct virtio_pci_device 
*vp_dev)
return -ENODEV;
}
 
+   rc = dma_set_mask_and_coherent(_dev->dev, DMA_BIT_MASK(64));
+   if (rc)
+   rc = dma_set_mask_and_coherent(_dev->dev,
+   DMA_BIT_MASK(32));
+   if (rc)
+   dev_warn(_dev->dev, "Failed to enable 64-bit or 32-bit DMA. 
 Trying to continue, but this might not work.\n");
+
rc = pci_request_region(pci_dev, 0, "virtio-pci-legacy");
if (rc)
return rc;
diff --git a/drivers/virtio/virtio_pci_modern.c 
b/drivers/virtio/virtio_pci_modern.c
index 8e5cf194cc0b..fbe0bd1c4881 100644
--- a/drivers/virtio/virtio_pci_modern.c
+++ b/drivers/virtio/virtio_pci_modern.c
@@ -293,14 +293,16 @@ static size_t vring_pci_size(u16 num)
return PAGE_ALIGN(vring_size(num, SMP_CACHE_BYTES));
 }
 
-static void *alloc_virtqueue_pages(int *num)
+static void *alloc_virtqueue_pages(struct virtio_pci_device *vp_dev,
+  int *num, dma_addr_t *dma_addr)
 {
void *pages;
 
/* TODO: allocate each queue chunk individually */
for (; *num && vring_pci_size(*num) > PAGE_SIZE; *num /= 2) {
-   pages = alloc_pages_exact(vring_pci_size(*num),
- GFP_KERNEL|__GFP_ZERO|__GFP_NOWARN);
+   pages = dma_zalloc_coherent(
+   _dev->pci_dev->dev, vring_pci_size(*num),
+   dma_addr, GFP_KERNEL|__GFP_NOWARN);
if (pages)
return pages;
}
@@ -309,7 +311,9 @@ static void *alloc_virtqueue_pages(int *num)
return NULL;
 
/* Try to get a single page. You are my only hope! */
-   return alloc_pages_exact(vring_pci_size(*num), GFP_KERNEL|__GFP_ZERO);
+   return dma_zalloc_coherent(
+   _dev->pci_dev->dev, vring_pci_size(*num),
+ 

Re: [PATCH 06/10] merge_config.sh: only consider last value of symbols

[Darren Hart]

On Wed, Oct 28, 2015 at 09:42:07AM +0900, Olof Johansson wrote:

Needs a commit message here that says (I think): Avoid mangled error output by
collecting only the last value. Warnings are still issued when overrides occur.

Agreed on the change though.

Reviewed-by: Darren Hart 

> Signed-off-by: Olof Johansson 
> ---
>  scripts/kconfig/merge_config.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/scripts/kconfig/merge_config.sh b/scripts/kconfig/merge_config.sh
> index 933f2d6..1945b2c 100755
> --- a/scripts/kconfig/merge_config.sh
> +++ b/scripts/kconfig/merge_config.sh
> @@ -39,7 +39,7 @@ usage() {
>  }
>  
>  getval() {
> - grep -w -e "$1" "$2" | sed 's/^CONFIG_\(.*\)=n$/# CONFIG_\1 is not 
> set/g'
> + grep -w -e "$1" "$2" | tail -1 | sed 's/^CONFIG_\(.*\)=n/# CONFIG_\1 is 
> not set/g'
>  }
>  
>  CONF_IS_ERR=false
> -- 
> 2.1.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

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

Re: [PATCH 05/10] merge_config.sh: Better handling of CONFIG_FOO=n

[Bruce Ashfield]

On 10/28/2015 02:26 AM, Darren Hart wrote:

On Wed, Oct 28, 2015 at 09:42:06AM +0900, Olof Johansson wrote:

Kconfig knows how to handle CONFIG_FOO=n just fine, but it'll always
use "# CONFIG FOO is not set" in the resulting config. Mangle the input
accordingly so we don't report this as a failure when it isn't.

Signed-off-by: Olof Johansson 


Matching Kconfig behavior is the logical approach, no point in complaining if
Kconfig will accpet the result.

Bruce, I think we'll just need to update the linux-yocto tool documentation not
to mark =n as wrong.


purists still think it is wrong :) The tools don't report this as
an error anymore, so there's no change here.

Bruce



Reviewed-by: Darren Hart 



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

[PATCH v2 2/4] ocfs2: sysfile interfaces for online file check

[Gang He]

Implement online file check sysfile interfaces, e.g.
how to create the related sysfile according to device name,
how to display/handle file check request from the sysfile.

Signed-off-by: Gang He 
---
 fs/ocfs2/Makefile|   3 +-
 fs/ocfs2/filecheck.c | 566 +++
 fs/ocfs2/filecheck.h |  48 +
 fs/ocfs2/inode.h |   3 +
 4 files changed, 619 insertions(+), 1 deletion(-)
 create mode 100644 fs/ocfs2/filecheck.c
 create mode 100644 fs/ocfs2/filecheck.h

diff --git a/fs/ocfs2/Makefile b/fs/ocfs2/Makefile
index ce210d4..e27e652 100644
--- a/fs/ocfs2/Makefile
+++ b/fs/ocfs2/Makefile
@@ -41,7 +41,8 @@ ocfs2-objs := \
quota_local.o   \
quota_global.o  \
xattr.o \
-   acl.o
+   acl.o   \
+   filecheck.o
 
 ocfs2_stackglue-objs := stackglue.o
 ocfs2_stack_o2cb-objs := stack_o2cb.o
diff --git a/fs/ocfs2/filecheck.c b/fs/ocfs2/filecheck.c
new file mode 100644
index 000..f12ed1f
--- /dev/null
+++ b/fs/ocfs2/filecheck.c
@@ -0,0 +1,566 @@
+/* -*- mode: c; c-basic-offset: 8; -*-
+ * vim: noexpandtab sw=8 ts=8 sts=0:
+ *
+ * filecheck.c
+ *
+ * Code which implements online file check.
+ *
+ * Copyright (C) 2015 Novell.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License as published by the Free Software Foundation, version 2.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "ocfs2.h"
+#include "ocfs2_fs.h"
+#include "stackglue.h"
+#include "inode.h"
+
+#include "filecheck.h"
+
+
+/* File check error strings,
+ * must correspond with error number in header file.
+ */
+static const char * const ocfs2_filecheck_errs[] = {
+   "SUCCESS",
+   "FAILED",
+   "INPROGRESS",
+   "READONLY",
+   "INVALIDINO",
+   "BLOCKECC",
+   "BLOCKNO",
+   "VALIDFLAG",
+   "GENERATION",
+   "UNSUPPORTED"
+};
+
+static DEFINE_SPINLOCK(ocfs2_filecheck_sysfs_lock);
+static LIST_HEAD(ocfs2_filecheck_sysfs_list);
+
+struct ocfs2_filecheck {
+   struct list_head fc_head;   /* File check entry list head */
+   spinlock_t fc_lock;
+   unsigned int fc_max;/* Maximum number of entry in list */
+   unsigned int fc_size;   /* Current entry count in list */
+   unsigned int fc_done;   /* File check entries are done in list */
+};
+
+struct ocfs2_filecheck_sysfs_entry {
+   struct list_head fs_list;
+   atomic_t fs_count;
+   struct super_block *fs_sb;
+   struct kset *fs_kset;
+   struct ocfs2_filecheck *fs_fcheck;
+};
+
+#define OCFS2_FILECHECK_MAXSIZE100
+#define OCFS2_FILECHECK_MINSIZE10
+
+/* File check operation type */
+enum {
+   OCFS2_FILECHECK_TYPE_CHK = 0,   /* Check a file */
+   OCFS2_FILECHECK_TYPE_FIX,   /* Fix a file */
+   OCFS2_FILECHECK_TYPE_SET = 100  /* Set file check options */
+};
+
+struct ocfs2_filecheck_entry {
+   struct list_head fe_list;
+   unsigned long fe_ino;
+   unsigned int fe_type;
+   unsigned short fe_done:1;
+   unsigned short fe_status:15;
+};
+
+struct ocfs2_filecheck_args {
+   unsigned int fa_type;
+   union {
+   unsigned long fa_ino;
+   unsigned int fa_len;
+   };
+};
+
+static const char *
+ocfs2_filecheck_error(int errno)
+{
+   if (!errno)
+   return ocfs2_filecheck_errs[errno];
+
+   BUG_ON(errno < OCFS2_FILECHECK_ERR_START ||
+   errno > OCFS2_FILECHECK_ERR_END);
+   return ocfs2_filecheck_errs[errno - OCFS2_FILECHECK_ERR_START + 1];
+}
+
+static ssize_t ocfs2_filecheck_show(struct kobject *kobj,
+   struct kobj_attribute *attr,
+   char *buf);
+static ssize_t ocfs2_filecheck_store(struct kobject *kobj,
+   struct kobj_attribute *attr,
+   const char *buf, size_t count);
+static struct kobj_attribute ocfs2_attr_filecheck =
+   __ATTR(filecheck, S_IRUSR | S_IWUSR,
+   ocfs2_filecheck_show,
+   ocfs2_filecheck_store);
+
+static int ocfs2_filecheck_sysfs_wait(atomic_t *p)
+{
+   schedule();
+   return 0;
+}
+
+static void
+ocfs2_filecheck_sysfs_free(struct ocfs2_filecheck_sysfs_entry *entry)
+{
+   struct ocfs2_filecheck_entry *p;
+
+   if (!atomic_dec_and_test(>fs_count))
+   wait_on_atomic_t(>fs_count, ocfs2_filecheck_sysfs_wait,
+

[PATCH v2 1/4] ocfs2: export ocfs2_kset for online file check

[Gang He]

Export ocfs2_kset object from ocfs2_stackglue kernel module,
then online file check code will create the related sysfiles
under ocfs2_kset object.

Signed-off-by: Gang He 
---
 fs/ocfs2/stackglue.c | 3 ++-
 fs/ocfs2/stackglue.h | 2 ++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/fs/ocfs2/stackglue.c b/fs/ocfs2/stackglue.c
index 5d965e8..13219ed 100644
--- a/fs/ocfs2/stackglue.c
+++ b/fs/ocfs2/stackglue.c
@@ -629,7 +629,8 @@ static struct attribute_group ocfs2_attr_group = {
.attrs = ocfs2_attrs,
 };
 
-static struct kset *ocfs2_kset;
+struct kset *ocfs2_kset;
+EXPORT_SYMBOL_GPL(ocfs2_kset);
 
 static void ocfs2_sysfs_exit(void)
 {
diff --git a/fs/ocfs2/stackglue.h b/fs/ocfs2/stackglue.h
index 66334a3..f2dce10 100644
--- a/fs/ocfs2/stackglue.h
+++ b/fs/ocfs2/stackglue.h
@@ -298,4 +298,6 @@ void ocfs2_stack_glue_set_max_proto_version(struct 
ocfs2_protocol_version *max_p
 int ocfs2_stack_glue_register(struct ocfs2_stack_plugin *plugin);
 void ocfs2_stack_glue_unregister(struct ocfs2_stack_plugin *plugin);
 
+extern struct kset *ocfs2_kset;
+
 #endif  /* STACKGLUE_H */
-- 
2.1.2

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

[PATCH v2 3/4] ocfs2: create/remove sysfile for online file check

[Gang He]

Create online file check sysfile when ocfs2 mount,
remove the related sysfile when ocfs2 umount.

Signed-off-by: Gang He 
---
 fs/ocfs2/super.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/fs/ocfs2/super.c b/fs/ocfs2/super.c
index 403c566..7213a94 100644
--- a/fs/ocfs2/super.c
+++ b/fs/ocfs2/super.c
@@ -74,6 +74,7 @@
 #include "suballoc.h"
 
 #include "buffer_head_io.h"
+#include "filecheck.h"
 
 static struct kmem_cache *ocfs2_inode_cachep;
 struct kmem_cache *ocfs2_dquot_cachep;
@@ -1202,6 +1203,9 @@ static int ocfs2_fill_super(struct super_block *sb, void 
*data, int silent)
/* Start this when the mount is almost sure of being successful */
ocfs2_orphan_scan_start(osb);
 
+   /* Create filecheck sysfile /sys/fs/ocfs2//filecheck */
+   ocfs2_filecheck_create_sysfs(sb);
+
return status;
 
 read_super_error:
@@ -1658,6 +1662,7 @@ static void ocfs2_put_super(struct super_block *sb)
 
ocfs2_sync_blockdev(sb);
ocfs2_dismount_volume(sb, 0);
+   ocfs2_filecheck_remove_sysfs(sb);
 }
 
 static int ocfs2_statfs(struct dentry *dentry, struct kstatfs *buf)
-- 
2.1.2

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

Re: [PATCH 05/10] merge_config.sh: Better handling of CONFIG_FOO=n

[Darren Hart]

On Wed, Oct 28, 2015 at 09:42:06AM +0900, Olof Johansson wrote:
> Kconfig knows how to handle CONFIG_FOO=n just fine, but it'll always
> use "# CONFIG FOO is not set" in the resulting config. Mangle the input
> accordingly so we don't report this as a failure when it isn't.
> 
> Signed-off-by: Olof Johansson 

Matching Kconfig behavior is the logical approach, no point in complaining if
Kconfig will accpet the result.

Bruce, I think we'll just need to update the linux-yocto tool documentation not
to mark =n as wrong.

Reviewed-by: Darren Hart 

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

[PATCH v2 4/4] ocfs2: check/fix inode block for online file check

[Gang He]

Implement online check or fix inode block during
reading a inode block to memory.

Signed-off-by: Gang He 
---
 fs/ocfs2/inode.c   | 196 +++--
 fs/ocfs2/ocfs2_trace.h |   2 +
 2 files changed, 192 insertions(+), 6 deletions(-)

diff --git a/fs/ocfs2/inode.c b/fs/ocfs2/inode.c
index b254416..d811698 100644
--- a/fs/ocfs2/inode.c
+++ b/fs/ocfs2/inode.c
@@ -53,6 +53,7 @@
 #include "xattr.h"
 #include "refcounttree.h"
 #include "ocfs2_trace.h"
+#include "filecheck.h"
 
 #include "buffer_head_io.h"
 
@@ -74,6 +75,13 @@ static int ocfs2_truncate_for_delete(struct ocfs2_super *osb,
struct inode *inode,
struct buffer_head *fe_bh);
 
+static int ocfs2_filecheck_read_inode_block_full(struct inode *inode,
+   struct buffer_head **bh, int flags, int type);
+static int ocfs2_filecheck_validate_inode_block(struct super_block *sb,
+   struct buffer_head *bh);
+static int ocfs2_filecheck_repair_inode_block(struct super_block *sb,
+   struct buffer_head *bh);
+
 void ocfs2_set_inode_flags(struct inode *inode)
 {
unsigned int flags = OCFS2_I(inode)->ip_attr;
@@ -127,6 +135,7 @@ struct inode *ocfs2_ilookup(struct super_block *sb, u64 
blkno)
 struct inode *ocfs2_iget(struct ocfs2_super *osb, u64 blkno, unsigned flags,
 int sysfile_type)
 {
+   int rc = 0;
struct inode *inode = NULL;
struct super_block *sb = osb->sb;
struct ocfs2_find_inode_args args;
@@ -161,12 +170,17 @@ struct inode *ocfs2_iget(struct ocfs2_super *osb, u64 
blkno, unsigned flags,
}
trace_ocfs2_iget5_locked(inode->i_state);
if (inode->i_state & I_NEW) {
-   ocfs2_read_locked_inode(inode, );
+   rc = ocfs2_read_locked_inode(inode, );
unlock_new_inode(inode);
}
if (is_bad_inode(inode)) {
iput(inode);
-   inode = ERR_PTR(-ESTALE);
+   if ((flags & OCFS2_FI_FLAG_FILECHECK_CHK) ||
+   (flags & OCFS2_FI_FLAG_FILECHECK_FIX))
+   /* Return OCFS2_FILECHECK_ERR_XXX related errno */
+   inode = ERR_PTR(rc);
+   else
+   inode = ERR_PTR(-ESTALE);
goto bail;
}
 
@@ -494,16 +508,32 @@ static int ocfs2_read_locked_inode(struct inode *inode,
}
 
if (can_lock) {
-   status = ocfs2_read_inode_block_full(inode, ,
-OCFS2_BH_IGNORE_CACHE);
+   if (args->fi_flags & OCFS2_FI_FLAG_FILECHECK_CHK)
+   status = ocfs2_filecheck_read_inode_block_full(inode,
+   , OCFS2_BH_IGNORE_CACHE, 0);
+   else if (args->fi_flags & OCFS2_FI_FLAG_FILECHECK_FIX)
+   status = ocfs2_filecheck_read_inode_block_full(inode,
+   , OCFS2_BH_IGNORE_CACHE, 1);
+   else
+   status = ocfs2_read_inode_block_full(inode,
+   , OCFS2_BH_IGNORE_CACHE);
} else {
status = ocfs2_read_blocks_sync(osb, args->fi_blkno, 1, );
/*
 * If buffer is in jbd, then its checksum may not have been
 * computed as yet.
 */
-   if (!status && !buffer_jbd(bh))
-   status = ocfs2_validate_inode_block(osb->sb, bh);
+   if (!status && !buffer_jbd(bh)) {
+   if (args->fi_flags & OCFS2_FI_FLAG_FILECHECK_CHK)
+   status = ocfs2_filecheck_validate_inode_block(
+   osb->sb, bh);
+   else if (args->fi_flags & OCFS2_FI_FLAG_FILECHECK_FIX)
+   status = ocfs2_filecheck_repair_inode_block(
+   osb->sb, bh);
+   else
+   status = ocfs2_validate_inode_block(
+   osb->sb, bh);
+   }
}
if (status < 0) {
mlog_errno(status);
@@ -531,6 +561,14 @@ static int ocfs2_read_locked_inode(struct inode *inode,
 
BUG_ON(args->fi_blkno != le64_to_cpu(fe->i_blkno));
 
+   if (buffer_dirty(bh)) {
+   status = ocfs2_write_block(osb, bh, INODE_CACHE(inode));
+   if (status < 0) {
+   mlog_errno(status);
+   goto bail;
+   }
+   }
+
status = 0;
 
 bail:
@@ -1385,6 +1423,152 @@ bail:
return rc;
 }
 
+static int ocfs2_filecheck_validate_inode_block(struct super_block *sb,
+  

[PATCH v2 0/4] Add online file check feature

[Gang He]

When there are errors in the ocfs2 filesystem,
they are usually accompanied by the inode number which caused the error.
This inode number would be the input to fixing the file.
One of these options could be considered:
A file in the sys filesytem which would accept inode numbers.
This could be used to communication back what has to be fixed or is fixed.
You could write:
$# echo "CHECK " > /sys/fs/ocfs2/devname/filecheck
or
$# echo "FIX " > /sys/fs/ocfs2/devname/filecheck

Compare with first version, I use strncasecmp instead of double strncmp
functions. Second, update the source file contribution vendor.

Gang He (4):
  ocfs2: export ocfs2_kset for online file check
  ocfs2: sysfile interfaces for online file check
  ocfs2: create/remove sysfile for online file check
  ocfs2: check/fix inode block for online file check

 fs/ocfs2/Makefile  |   3 +-
 fs/ocfs2/filecheck.c   | 566 +
 fs/ocfs2/filecheck.h   |  48 +
 fs/ocfs2/inode.c   | 196 -
 fs/ocfs2/inode.h   |   3 +
 fs/ocfs2/ocfs2_trace.h |   2 +
 fs/ocfs2/stackglue.c   |   3 +-
 fs/ocfs2/stackglue.h   |   2 +
 fs/ocfs2/super.c   |   5 +
 9 files changed, 820 insertions(+), 8 deletions(-)
 create mode 100644 fs/ocfs2/filecheck.c
 create mode 100644 fs/ocfs2/filecheck.h

-- 
2.1.2

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

[PATCH] tty/vt/keyboard: use memdup_user to simplify code

[Saurabh Sengar]

use memdup_user rather than duplicating implementation.
found by coccinelle

Signed-off-by: Saurabh Sengar 
---
 drivers/tty/vt/keyboard.c | 14 +-
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
index 6f0336f..f973bfc 100644
--- a/drivers/tty/vt/keyboard.c
+++ b/drivers/tty/vt/keyboard.c
@@ -1706,16 +1706,12 @@ int vt_do_diacrit(unsigned int cmd, void __user *udp, 
int perm)
return -EINVAL;
 
if (ct) {
-   dia = kmalloc(sizeof(struct kbdiacr) * ct,
-   GFP_KERNEL);
-   if (!dia)
-   return -ENOMEM;
 
-   if (copy_from_user(dia, a->kbdiacr,
-   sizeof(struct kbdiacr) * ct)) {
-   kfree(dia);
-   return -EFAULT;
-   }
+   dia = memdup_user(a->kbdiacr,
+   sizeof(struct kbdiacr) * ct);
+   if (IS_ERR(dia))
+   return PTR_ERR(dia);
+
}
 
spin_lock_irqsave(_event_lock, flags);
-- 
1.9.1

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

Re: [PATCH v12 0/6] Altera PCIe host controller driver with MSI support

[Ley Foon Tan]

On Wed, Oct 28, 2015 at 9:02 AM, Bjorn Helgaas  wrote:
> On Tue, Oct 27, 2015 at 7:56 PM, Ley Foon Tan  wrote:
>> On Tue, Oct 27, 2015 at 10:26 PM, Bjorn Helgaas  wrote:
>>> Hi Ley,
>>>
>>> On Fri, Oct 23, 2015 at 06:27:09PM +0800, Ley Foon Tan wrote:
 This is the 12th version of patch set to add support for Altera PCIe host
 controller with MSI feature on Altera FPGA device families. This patchset
 mainly resovle the comments from Bjorn.


 This patchset is based on v4.3-rc6.

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

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


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

  .../devicetree/bindings/pci/altera-pcie-msi.txt|  28 +
  .../devicetree/bindings/pci/altera-pcie.txt|  49 ++
  MAINTAINERS|  16 +
  arch/arm/include/asm/Kbuild|   1 +
  drivers/pci/host/Kconfig   |  16 +
  drivers/pci/host/Makefile  |   2 +
  drivers/pci/host/pcie-altera-msi.c | 314 +++
  drivers/pci/host/pcie-altera.c | 580 
 +
  include/linux/pci_ids.h|   2 +
  9 files changed, 1008 insertions(+)
  create mode 100644 
 Documentation/devicetree/bindings/pci/altera-pcie-msi.txt
  create mode 100644 Documentation/devicetree/bindings/pci/altera-pcie.txt
  create mode 100644 drivers/pci/host/pcie-altera-msi.c
  create mode 100644 drivers/pci/host/pcie-altera.c
>>>
>>> I applied these to pci/host-altera for v4.4, thanks!
>>>
>>> I squashed these into three patches:
>>>
>>>   - add msi.h to Kbuild
>>>   - add Altera host driver (including DT binding and MAINTAINERS update)
>>>   - add Altera MSI driver (including DT binding and MAINTAINERS update)
>>>
>>> Since the convention is to add PCI ID #defines only when they are used in
>>> multiple places, I replaced PCI_VENDOR_ID_ALTERA with 0x1172 in the single
>>> place it is used.
>> Hi Bjorn
>>
>> Thanks for applied these.
>>
>> By the way, I can't see pci/host-altera branch in your pci.git tree
>> yet. It takes some time to appear there?
>
> Sorry, I forgot to push it.  It should be there now!
>
Yes, saw it now. It will merge to 'next' branch eventually?

Thanks!

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

Re: [PATCH] ARM: dts: sunxi: sun6i-a31s-primo81.dts: add touchscreen axis swapping property

[Maxime Ripard]

Hi,

On Sat, Oct 24, 2015 at 11:07:31PM +0200, Karsten Merker wrote:
> The MSI Primo81 has a display in portrait mode but a touchscreen
> in landscape mode.  To have both of them use the same coordinate
> system, the touchscreen-swapped-x-y property has to be set
> for the touchscreen.
> 
> Signed-off-by: Karsten Merker 

Queued as a fix for 4.4.

Thanks!
Maxime

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


signature.asc
Description: Digital signature

Re: [PATCH v4 0/2] powerpc/512x: add LocalPlus Bus FIFO device driver

[Vinod Koul]

On Tue, Oct 27, 2015 at 11:42:57PM +0300, Alexander Popov wrote:
> >> Hello,
> >>
> >> I've done my best to fix the issues pointed by Timur Tabi and Vinod Koul.
> >> Could I have a feedback please?
> > 
> > I dont see to have v4 in my list :( Can you please repost
> 
> Hello, Vinod
> 
> I'm sure I haven't miss your address in the list of the recipients.
> Anyway I can repost.
> 
> Anatolij Gustschin wrote that he applied v4 with some fix to mpc5xxx/next
> some time ago.

Okay, I though these were dmaengine patches but looking back they seemed to
be for arch code, so nothing to do here for me and then you :)

> So should I repost v4 for everybody? How should I mark the reposted patches?

Its merged so fine with me

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

Re: [PATCH 04/10] merge_config.sh: exit non-0 in case of failures

[Darren Hart]

On Wed, Oct 28, 2015 at 09:42:05AM +0900, Olof Johansson wrote:
> Exit with non-0 value in cases where there was a failure to set an option.
> Also, add a '-e' during which the conflict warnings are considered failures
> (-e -r will result in these being failures, -r will result in them just being
> reported).
> 
> Signed-off-by: Olof Johansson 

It's useful to be able to check the return code for errors. Since override is
often expected, making tat configurable makes sense.

Reviewed-by: Darren Hart 

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

Re: [PATCH 00/10] merge_config misc reworks and testcases

[Bruce Ashfield]

On 10/28/2015 01:02 AM, Darren Hart wrote:

On Wed, Oct 28, 2015 at 09:42:01AM +0900, Olof Johansson wrote:

Hi,

Somewhat wide distribution list here, since I've added everyone who's
touched the script, with the presumption that those have been the major
users of it. Please make sure none of these changes break your use cases.


+Bruce. I think you were going to test these with the linux-yocto tooling. Did
you get a chance to run that test? I'd like your thoughts on the two comments
below:


I ran some initial tests, but I didn't end up doing a full
update due to other constraints.

But in the next few weeks, I can do that update and full run.





I've done some reworks of merge_config.sh. I was quite hesitant to start
this since there are no good ways to see if your changes break others
or not, so the first thing I did was to add some tests. I know this is
highly unorthodox so try not to panic. :-)

As far as what this series does is:

- Adds a way to pass in CONFIG_FOO= on the command line, it gets
   treated as a single-entry fragment file

- The script now prints the warnings on stderr, and returns non-0 when
   something is encountered


This one might impact linux-yocto usage, Bruce? That said, it seems like the
right thing to do. So I'd still like to see it go in, but we may need to plan to
update the dependent tooling to use it.


I don't directly let the merge_config output be visible, but capture it
and then do more processing later. So while this may mean that I have
to update some wrappers to capture stderr, it shouldn't be a big deal.





- Optionally, it'll also return non-0 when a redundant entry is found. I
   presumed people rely on -r not being a failure so I did this separately

- CONFIG_FOO=n and "# CONFIG_FOO is not set" is now treated the same,
   and using the former doesn't cause an invalid warning when the results
   are checked at the end

- Slightly odd things happened if a fragment contains the same option
   twice: It'd produce a warning that was malformed. Now just ignore that
   and use only the latest value of said option.


This one will likely impact usage as well. linux-yocto does want to report when
there is an override, not as an error, but for informational purposes - "Where
does my option get clobbered?"


I haven't looked at the patches yet (and I will shortly), but if that
is within a single fragment, I can live with it going away, since it is
easy to check that outside of the merge script.

But if this is a redefinition between fragments, that's something different
and something that I capture and report to users, and yes, I
currently take it from the output of the merge_config run. If it goes
away, I'd have to recreate it somehow.

So if this can at least be maintained as enabled via a parameter, that
would be be ideal. Otherwise, I'll have to recreate the output some
other way.

Bruce







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

[GIT] Networking

[David Miller]

This may look a bit scary this late in the release cycle, but as is typically
the case it's predominantly small driver fixes all over the place.

1) Fix two regressions in ipv6 route lookups, particularly wrt. output
   interface specifications in the lookup key.  From David Ahern.

2) Fix checks in ipv6 IPSEC tunnel pre-encap fragmentation, from
   Herbert Xu.

3) Fix mis-advertisement of 1000BASE-T on bcm63xx_enet, from Simon
   Arlott.

4) Some smsc phys misbehave with energy detect mode enabled, so add a
   DT property and disable it on such switches.  From Heiko Schocher.

5) Fix TSO corruption on TX in mv643xx_eth, from Philipp Kirchhofer.

6) Fix regression added by removal of openvswitch vport stats, from
   James Morse.

7) Vendor Kconfig options should be bool, not tristate, from Andreas
   Schwab.

8) Use non-_BH() net stats bump in tcp_xmit_probe_skb(), otherwise
   we barf during TCP REPAIR operations.

9) Fix various bugs in openvswitch conntrack support, from Joe
   Stringer.

10) Fix NETLINK_LIST_MEMBERSHIPS locking, from David Herrmann.

11) Don't have VSOCK do sock_put() in interrupt context, from Jorgen
Hansen.

12) Fix skb_realloc_headroom() failures properly in ISDN, from Karsten
Keil.

13) Add some device IDs to qmi_wwan, from Bjorn Mork.

14) Fix ovs egress tunnel information when using lwtunnel devices,
from Pravin B Shelar.

15) Add missing NETIF_F_FRAGLIST to macvtab feature list, from Jason
Wang.

16) Fix incorrect handling of throw routes when the result of the
throw cannot find a match, from Xin Long.

17) Protect ipv6 MTU calculations from wrap-around, from Hannes
Frederic Sowa.

18) Fix failed autonegotiation on KSZ9031 micrel PHYs, from Nathan
Sullivan.

19) Add missing memory barries in descriptor accesses or xgbe driver,
from Thomas Lendacky.

20) Fix release conditon test in pppoe_release(), from Guillaume Nault.

21) Fix gianfar bugs wrt. filter configuration, from Claudiu Manoil.

22) Fix violations of RX buffer alignment in sh_eth driver, from Sergei
Shtylyov.

23) Fixing missing of_node_put() calls in various places around the
networking, from Julia Lawall.

24) Fix incorrect leaf now walking in ipv4 routing tree, from Alexander
Duyck.

25) RDS doesn't check pskb_pull()/pskb_trim() return values, from
Sowmini Varadhan.

26) Fix VLAN configuration in mlx4 driver, from Jack Morgenstein.

Please pull, thanks a lot.

The following changes since commit 1099f86044111e9a7807f09523e42d4c9d0fb781:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2015-10-19 
09:55:40 -0700)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master

for you to fetch changes up to e18f6ac30d31433d8cd9ccf693d3cdd5d2e66ef9:

  Merge branch 'mlx4-fixes' (2015-10-27 20:27:45 -0700)



Alexander Duyck (1):
  fib_trie: leaf_walk_rcu should not compute key if key is less than pn->key

Andreas Schwab (1):
  net: cavium: change NET_VENDOR_CAVIUM to bool

Andrew F. Davis (1):
  net: phy: dp83848: Add TI DP83848 Ethernet PHY

Andrew Shewmaker (1):
  tcp: allow dctcp alpha to drop to zero

Bjørn Mork (1):
  qmi_wwan: add Sierra Wireless MC74xx/EM74xx

Carol L Soto (1):
  net/mlx4: Copy/set only sizeof struct mlx4_eqe bytes

Claudiu Manoil (4):
  gianfar: Remove duplicated argument to bitwise OR
  gianfar: Don't enable the Filer w/o the Parser
  gianfar: Fix Rx BSY error handling
  MAINTAINERS: Add entry for gianfar ethernet driver

Dan Carpenter (1):
  irda: precedence bug in irlmp_seq_hb_idx()

David Ahern (2):
  net: Really fix vti6 with oif in dst lookups
  net: ipv6: Dont add RT6_LOOKUP_F_IFACE flag if saddr set

David Daney (1):
  net: thunderx: Rewrite silicon revision tests.

David Herrmann (1):
  netlink: fix locking around NETLINK_LIST_MEMBERSHIPS

David S. Miller (12):
  Merge branch 'smsc-energy-detect'
  Merge branch 'mv643xx-fixes'
  Merge git://git.kernel.org/.../pablo/nf
  Merge branch 'isdn-null-deref'
  Merge branch 'master' of git://git.kernel.org/.../klassert/ipsec
  Merge branch 'master' of git://git.kernel.org/.../jkirsher/net-queue
  Merge branch 'ipv6-overflow-arith'
  Merge branch 'thunderx-fixes'
  Merge branch 'gianfar-fixes'
  Merge branch 'sh_eth-fixes'
  Merge branch 'net_of_node_put'
  Merge branch 'mlx4-fixes'

Eric Dumazet (1):
  ipv6: gre: support SIT encapsulation

Florian Westphal (1):
  netfilter: sync with packet rx also after removing queue entries

Gao feng (1):
  vsock: fix missing cleanup when misc_register failed

Guillaume Nault (1):
  ppp: fix pppoe_dev deletion condition in pppoe_release()

Hannes Frederic Sowa (2):
  overflow-arith: begin to add support for overflow builtin functions
  ipv6: protect mtu calculation of wrap-around and infinite loop by 

Re: [PATCH v2] Input: tsc2005 - Add support for tsc2004

[Dmitry Torokhov]

On Wed, Oct 28, 2015 at 12:48:29AM -0500, Michael Welling wrote:
> On Tue, Oct 27, 2015 at 10:41:52PM -0700, Dmitry Torokhov wrote:
> > On Wed, Oct 28, 2015 at 12:23:34AM -0500, Michael Welling wrote:
> > > On Tue, Oct 27, 2015 at 06:51:41PM -0700, Dmitry Torokhov wrote:
> > > > Hi Michael,
> > > > On Tue, Oct 27, 2015 at 07:17:01PM -0500, Michael Welling wrote:
> > > > > Adds support for the i2c based tsc2004. Support was added to the 
> > > > > tsc2005 driver
> > > > > due to the similarity of the devices.
> > > > > 
> > > > > Signed-off-by: Michael Welling 
> > > > > ---
> > > > > v2: Fixes Kconfig based on report for 0-day build bot.
> > > > > 
> > > > >  .../bindings/input/touchscreen/tsc2004.txt |  38 
> > > > >  drivers/input/touchscreen/Kconfig  |   7 +-
> > > > >  drivers/input/touchscreen/tsc2005.c| 206 
> > > > > -
> > > > 
> > > > Could we maybe split the code into core, spi and i2c drivers instead of
> > > > keeping everything together and rely on #ifdefs?
> > > >
> > > Dmitry,
> > > 
> > > So then we have three files?
> > > Perhaps:
> > > drivers/input/touchscreen/tsc2004.c
> > > drivers/input/touchscreen/tsc2005.c
> > > drivers/input/touchscreen/tsc200x-core.c
> > > 
> > > Please ellaborate exactly how you want things to be structured and named 
> > > so
> > > that I don't waste time in revision.
> > 
> > Sure, the naming above is fine. You'd have to export the
> > tsc_common_probe() and put I2C and SPI bits into tsc2005.c/tsc2004.c
> > 
> > I'd probably have separate Kconfig entries for TSC2004 and TSC2005 and
> > have the core be invisible module that the former 2 explicitly "select".
> > 
> > Does this make sense?
> 
> Yes it does.
> 
> I have been told that using wildcard names is bad in other subsystems.
> Perhaps tsc200x-core.c should be called something else because it has
> nothing to do with the tsc2007 but it is covered by the wildcard.
> 
> You you think this is a big deal?

No I do not.

Thanks.

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

Re: [PATCH V3 3/5] cpufreq: ondemand: queue work for policy->cpus together

[Rafael J. Wysocki]

On Tuesday, October 13, 2015 01:39:03 PM Viresh Kumar wrote:
> Currently update_sampling_rate() runs over each online CPU and
> cancels/queues work on it. Its very inefficient for the case where a
> single policy manages multiple CPUs, as they can be processed together.

In the case of one policy object shared between multiple CPUs, I'm
wondering why we don't use a single delayed work function for all of them
in the first place.  That would address the problem at the source instead
of dealing with the symptoms.

> Also drop the unnecessary cancel_delayed_work_sync() as we are doing a
> mod_delayed_work_on() in gov_queue_work(), which will take care of
> pending works for us.

I'd prefer a separate patch for that if poss.

Thanks,
Rafael

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

Re: [PATCH v2 2/3] virtio_ring: Support DMA APIs

[David Woodhouse]

On Wed, 2015-10-28 at 14:52 +0900, Christian Borntraeger wrote:
>0059b25a: e3201024   lg  %r2,32(%r1)
>   #0059b260: e310b0a4   lg  %r1,160(%r11)
>   >0059b266: 4810100c   lh  %r1,12(%r1)

Precisely what is that? Is that loading ->archdata.dev_ops (offset 160)
from a device and then trying to find the ->unmap_page method therein?

-- 
dwmw2




smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH 03/10] merge_config.sh: minor argument parsing refactoring

[Darren Hart]

On Wed, Oct 28, 2015 at 09:42:04AM +0900, Olof Johansson wrote:
> Every case that continues iterating needs a shift, so move it to common 
> location.
> Also, the continues are redundant.
> 
> Signed-off-by: Olof Johansson 

Nice cleanup, thanks Olof.

Reviewed-by: Darren Hart 

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

Re: [PATCH V3 2/5] cpufreq: ondemand: update sampling rate immediately

[Rafael J. Wysocki]

On Tuesday, October 13, 2015 01:39:02 PM Viresh Kumar wrote:
> We are immediately updating sampling rate for already queued-works, only
> if the new expiry is lesser than the old one.
> 
> But what about the case, where the user doesn't want frequent events and
> want to increase sampling time immediately? Shouldn't we cancel the
> works (and so their interrupts) on all policy->cpus (which might occur
> very shortly).
> 
> This patch removes this special case and simplifies code by immediately
> updating the expiry.

The changelog is a complete disaster. :-/

Your argument seems to be that it should be OK to do the
cancel_delayed_work_sync()/gov_queue_work() combo in all cases, because
even if the new rate is greater than the old one, the user may actually
want it to take effect immediately and it shouldn't hurt to skip the next
sample anyway in that case.

Is this really the case, though?  What about the old rate is 1s, the new one
is 2s and the timer is just about to expire?  Won't the canceling effectively
move the next sample 3s away from the previous one which may not be desirable?

The current code just allows the timer to expire, unless that would prevent
the new rate from taking effect for too long, which seems perfectly reasonable
to me.

All that seems to be racy with respect to the delayed work execution, but that's
a different problem.

> Signed-off-by: Viresh Kumar 
> ---
>  drivers/cpufreq/cpufreq_ondemand.c | 25 -
>  1 file changed, 4 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/cpufreq/cpufreq_ondemand.c 
> b/drivers/cpufreq/cpufreq_ondemand.c
> index 03ac6ce54042..bf0511a9735c 100644
> --- a/drivers/cpufreq/cpufreq_ondemand.c
> +++ b/drivers/cpufreq/cpufreq_ondemand.c
> @@ -231,17 +231,8 @@ static unsigned int od_dbs_timer(struct cpu_dbs_info 
> *cdbs,
>  static struct common_dbs_data od_dbs_cdata;
>  
>  /**
> - * update_sampling_rate - update sampling rate effective immediately if 
> needed.
> + * update_sampling_rate - update sampling rate immediately.
>   * @new_rate: new sampling rate
> - *
> - * If new rate is smaller than the old, simply updating
> - * dbs_tuners_int.sampling_rate might not be appropriate. For example, if the
> - * original sampling_rate was 1 second and the requested new sampling rate 
> is 10
> - * ms because the user needs immediate reaction from ondemand governor, but 
> not
> - * sure if higher frequency will be required or not, then, the governor may
> - * change the sampling rate too late; up to 1 second later. Thus, if we are
> - * reducing the sampling rate, we need to make the new value effective
> - * immediately.
>   */
>  static void update_sampling_rate(struct dbs_data *dbs_data,
>   unsigned int new_rate)
> @@ -255,7 +246,6 @@ static void update_sampling_rate(struct dbs_data 
> *dbs_data,
>   for_each_online_cpu(cpu) {
>   struct cpufreq_policy *policy;
>   struct od_cpu_dbs_info_s *dbs_info;
> - unsigned long next_sampling, appointed_at;
>  
>   policy = cpufreq_cpu_get(cpu);
>   if (!policy)
> @@ -270,16 +260,9 @@ static void update_sampling_rate(struct dbs_data 
> *dbs_data,
>   if (!delayed_work_pending(_info->cdbs.dwork))
>   continue;
>  
> - next_sampling = jiffies + usecs_to_jiffies(new_rate);
> - appointed_at = dbs_info->cdbs.dwork.timer.expires;
> -
> - if (time_before(next_sampling, appointed_at)) {
> - cancel_delayed_work_sync(_info->cdbs.dwork);
> -
> - gov_queue_work(dbs_data, policy,
> -usecs_to_jiffies(new_rate), true);
> -
> - }
> + cancel_delayed_work_sync(_info->cdbs.dwork);
> + gov_queue_work(dbs_data, policy, usecs_to_jiffies(new_rate),
> +true);
>   }
>  }

Thanks,
Rafael

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

Re: [PATCH 3/9] powerpc32: checksum_wrappers_64 becomes checksum_wrappers

[Anton Blanchard]

Hi Scott,

> I wonder why it was 64-bit specific in the first place.

I think it was part of a series where I added my 64bit assembly checksum
routines, and I didn't step back and think that the wrapper code would
be useful on 32 bit.

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

[PATCH 3/3] ARC: mm: HIGHMEM: switch to using phys_addr_t for physical addresses

[Vineet Gupta]

This allows PAE40 support in next patch when we switch to > 32-bits of
physical addresses

Signed-off-by: Vineet Gupta 
---
 arch/arc/include/asm/cacheflush.h |  8 
 arch/arc/mm/cache.c   | 26 +-
 arch/arc/mm/tlb.c | 10 +-
 3 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/arch/arc/include/asm/cacheflush.h 
b/arch/arc/include/asm/cacheflush.h
index 0992d3dbcc65..fbe3587c4f36 100644
--- a/arch/arc/include/asm/cacheflush.h
+++ b/arch/arc/include/asm/cacheflush.h
@@ -31,10 +31,10 @@
 
 void flush_cache_all(void);
 
-void flush_icache_range(unsigned long start, unsigned long end);
-void __sync_icache_dcache(unsigned long paddr, unsigned long vaddr, int len);
-void __inv_icache_page(unsigned long paddr, unsigned long vaddr);
-void __flush_dcache_page(unsigned long paddr, unsigned long vaddr);
+void flush_icache_range(unsigned long kstart, unsigned long kend);
+void __sync_icache_dcache(phys_addr_t paddr, unsigned long vaddr, int len);
+void __inv_icache_page(phys_addr_t paddr, unsigned long vaddr);
+void __flush_dcache_page(phys_addr_t paddr, unsigned long vaddr);
 
 #define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 1
 
diff --git a/arch/arc/mm/cache.c b/arch/arc/mm/cache.c
index 08a7cc0ac100..6941db059ad8 100644
--- a/arch/arc/mm/cache.c
+++ b/arch/arc/mm/cache.c
@@ -26,7 +26,7 @@ int ioc_exists;
 volatile int slc_enable = 1, ioc_enable = 1;
 unsigned long perip_space = ARC_UNCACHED_ADDR_SPACE;
 
-void (*_cache_line_loop_ic_fn)(unsigned long paddr, unsigned long vaddr,
+void (*_cache_line_loop_ic_fn)(phys_addr_t paddr, unsigned long vaddr,
   unsigned long sz, const int cacheop);
 
 void (*__dma_cache_wback_inv)(unsigned long start, unsigned long sz);
@@ -223,7 +223,7 @@ slc_chk:
  */
 
 static inline
-void __cache_line_loop_v2(unsigned long paddr, unsigned long vaddr,
+void __cache_line_loop_v2(phys_addr_t paddr, unsigned long vaddr,
  unsigned long sz, const int op)
 {
unsigned int aux_cmd;
@@ -261,7 +261,7 @@ void __cache_line_loop_v2(unsigned long paddr, unsigned 
long vaddr,
 }
 
 static inline
-void __cache_line_loop_v3(unsigned long paddr, unsigned long vaddr,
+void __cache_line_loop_v3(phys_addr_t paddr, unsigned long vaddr,
  unsigned long sz, const int op)
 {
unsigned int aux_cmd, aux_tag;
@@ -315,7 +315,7 @@ void __cache_line_loop_v3(unsigned long paddr, unsigned 
long vaddr,
  * specified in PTAG (similar to MMU v3)
  */
 static inline
-void __cache_line_loop_v4(unsigned long paddr, unsigned long vaddr,
+void __cache_line_loop_v4(phys_addr_t paddr, unsigned long vaddr,
  unsigned long sz, const int cacheop)
 {
unsigned int aux_cmd;
@@ -419,7 +419,7 @@ static inline void __dc_entire_op(const int op)
 /*
  * D-Cache Line ops: Per Line INV (discard or wback+discard) or FLUSH (wback)
  */
-static inline void __dc_line_op(unsigned long paddr, unsigned long vaddr,
+static inline void __dc_line_op(phys_addr_t paddr, unsigned long vaddr,
unsigned long sz, const int op)
 {
unsigned long flags;
@@ -452,7 +452,7 @@ static inline void __ic_entire_inv(void)
 }
 
 static inline void
-__ic_line_inv_vaddr_local(unsigned long paddr, unsigned long vaddr,
+__ic_line_inv_vaddr_local(phys_addr_t paddr, unsigned long vaddr,
  unsigned long sz)
 {
unsigned long flags;
@@ -469,7 +469,7 @@ __ic_line_inv_vaddr_local(unsigned long paddr, unsigned 
long vaddr,
 #else
 
 struct ic_inv_args {
-   unsigned long paddr, vaddr;
+   phys_addr_t paddr, vaddr;
int sz;
 };
 
@@ -480,7 +480,7 @@ static void __ic_line_inv_vaddr_helper(void *info)
 __ic_line_inv_vaddr_local(ic_inv->paddr, ic_inv->vaddr, ic_inv->sz);
 }
 
-static void __ic_line_inv_vaddr(unsigned long paddr, unsigned long vaddr,
+static void __ic_line_inv_vaddr(phys_addr_t paddr, unsigned long vaddr,
unsigned long sz)
 {
struct ic_inv_args ic_inv = {
@@ -501,7 +501,7 @@ static void __ic_line_inv_vaddr(unsigned long paddr, 
unsigned long vaddr,
 
 #endif /* CONFIG_ARC_HAS_ICACHE */
 
-noinline void slc_op(unsigned long paddr, unsigned long sz, const int op)
+noinline void slc_op(phys_addr_t paddr, unsigned long sz, const int op)
 {
 #ifdef CONFIG_ISA_ARCV2
/*
@@ -591,7 +591,7 @@ void flush_dcache_page(struct page *page)
} else if (page_mapped(page)) {
 
/* kernel reading from page with U-mapping */
-   unsigned long paddr = (unsigned long)page_address(page);
+   phys_addr_t paddr = (unsigned long)page_address(page);
unsigned long vaddr = page->index << PAGE_CACHE_SHIFT;
 
if (addr_not_cache_congruent(paddr, vaddr))
@@ -739,14 +739,14 @@ EXPORT_SYMBOL(flush_icache_range);
  *builtin kernel page will not have any virtual mappings.
  *  

Re: [PATCH] MAINTAINERS: Start using the 'reviewer' (R) tag

[Lee Jones]

On Wed, 28 Oct 2015, Javier Martinez Canillas wrote:

> Hello Joe,
> 
> On Wed, Oct 28, 2015 at 12:06 PM, Joe Perches  wrote:
> > On Wed, 2015-10-28 at 11:53 +0100, Javier Martinez Canillas wrote:
> >> (Lee) think(s) that the difference between a maintainer and
> >> a reviewer is if a branch with fixes / new features are kept and pull
> >> requests sent while I think that the difference is the level of
> >> involvement someone has with a driver regardless of how patches ends
> >> in the subsystem tree (picked directly by subsystem maintainers or
> >> sent through pull requests).
> >>
> >> Is the first time I heard your definition but maybe I'm the one that
> >> is wrong so it would be great to get a consensus on that and get it
> >> documented somewhere.
> >
> > I think Lee is over-analyzing.
> >
> > From MAINTAINERS:
> > M: Mail patches to: FullName 
> > R: Designated reviewer: FullName 
> >These reviewers should be CCed on patches.
> > S: Status, one of the following:
> >Supported:   Someone is actually paid to look after this.
> >Maintained:  Someone actually looks after it.
> >
> > "looking after" doesn't mean upstreaming.
> >
> 
> Agreed and upstreaming doesn't mean sending pull request, you can for
> example upstream the downstream changes for a driver you maintain by
> posting patches or ack patches others post and let the subsystem
> maintainer to pick those (even if you are listed as the driver
> maintainer in MAINTAINERS).
> 
> So by following Lee's definition, then most drivers' maintainers
> should not be called maintainers since keeping a tree with patches for
> both fixes and new features, sending pull requests, etc is only
> justified for drivers that have a lot of changes per release. Is not
> worth it for drivers that are in "maintenance mode" where only bugs
> are fixed every once in a while or features are seldom added.

Exactly right.

Although, it looks like M: doesn't even mean Maintainer.  If it did, I
would have made these points over and over until death (or until I got
bored).  However, as M: actually means "Mail patches to", there seems
to be very little difference between that and "Designated reviewer"
and makes me wonder why the R: tag was ever even introduced.  I guess
all of the other guys in the threads below also thought M: meant
Maintainer, or else they would have just added poor old Josh as a
"Mail patches to" recipient and been done with it.

> > The original threads for this were:
> >
> > http://lists.linuxfoundation.org/pipermail/ksummit-discuss/2014-May/000830.html
> > https://lkml.org/lkml/2014/6/2/446

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] MAINTAINERS: Start using the 'reviewer' (R) tag

[Joe Perches]

On Wed, 2015-10-28 at 12:14 +, Lee Jones wrote:
> Ah, but wait.  get_maintainer.pl *does* assume M means Maintainer
> doesn't it?

No, it looks at the "S:" line.


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

Re: [PATCH -rt] Revert "net: use synchronize_rcu_expedited()"

[Paul E. McKenney]

On Wed, Oct 28, 2015 at 03:34:00AM -0500, Josh Cartwright wrote:
> On Tue, Oct 27, 2015 at 04:15:59PM -0700, Paul E. McKenney wrote:
> > On Tue, Oct 27, 2015 at 08:27:53AM -0700, Eric Dumazet wrote:
> > > On Tue, 2015-10-27 at 12:02 -0300, Arnaldo Carvalho de Melo wrote:
> [..]
> > > > The first suggestion, with it disabled by default seems to be the most
> > > > flexible tho, i.e, Paul's original message plus the boot parameter line:
> > > > 
> > > > Alternatively, a boot-time option could be used:
> > > > 
> > > > int some_rt_boot_parameter = CONFIG_SYNC_NET_DEFAULT;
> > > > 
> > > > if (rtnl_is_locked() && !some_rt_boot_parameter)
> > > > synchronize_rcu_expedited();
> > > > else
> > > > synchronize_rcu();
> > 
> > This could be OK, but why not start with something very simple and 
> > automatic?
> > We can always add more knobs when and if they actually prove necessary.
> 
> I suppose the question is if, for acme's usecases the answer to "when
> it's proven necessary" is "now".
> 
> > In contrast, unnecessary knobs can cause confusion and might at the same 
> > time
> > get locked into some misbegotten userspace application, which would make the
> > unnecessary knob really hard to get rid of.
> 
> I think I would make a stronger statement; the CONFIG_SYNC_NET_DEFAULT
> proposed option would be a boot/compile time parameter which says "I
> require networking (and network configuration) in my critical path", why
> don't we have these flags for other I/O subsystems?  What's special
> about networking?
> 
> We don't because applications can make use of thread priorities to
> express exactly which tasks should be more important than others.  So
> perhaps the failure here is that RCU (and networking, by implication)
> doesn't (can't?) take into consideration the calling thread's priority?
> (And, there may be a cascade of other problems as well, like deferred
> work pushed to a waitqueue, and thus losing the callers priority, etc)
> 
> (I will admit that RCU is a black box to me, so it is entirely possible
> it's already capable of this, or it's fundamentally impossible, or
> somewhere in between :)

CONFIG_RCU_KTHREAD_PRIO=nn, where 0 says SCHED_OTHER and 0 < nn <= 99
says SCHED_FIFO with RT priority nn.

> > > > Then RT oriented kernel .config files would have CONFIG_SYNC_NET_DEFAULT
> > > > set to 1, while upstream would have this default to 0.
> > > > 
> > > > RT oriented kernel users could try using this in some scenarios where
> > > > networking is not the critical path.
> > > 
> > > Well, if synchronize_rcu_expedited() is such a problem on RT, then maybe
> > > a generic solution would make synchronize_rcu_expedited() to fallback
> > > synchronize_rcu() after boot time on RT.
> > > 
> > > Not sure why networking use of synchronize_rcu_expedited() would be
> > > problematic, and not the others.
> > 
> > From what I can see, their testing just happened to run into this one.
> > Perhaps further testing will run into others, or perhaps the others are
> > off in code paths that should not be exercised while running RT apps.
> 
> I accidentally ran into this issue when I was doing testing with an
> ethernet cable w/ a broken RJ-45 connector (without the tab, that I was
> just too lazy to replace), and I kept accidentally knocking it out.  :)
> 
> Regardless, industrial automation environments aren't known for having
> the most stable network environments; there may be deployed systems
> doing high priority motion control tasks, we'd want to ensure that the
> poor network technician sent in to repair a defective network switch
> wouldn't end up being mangled.
> 
> > > scripts/checkpatch.pl has this comment about this :
> 
> Also, Documentation/RCU/checklist.txt mentions:
> 
>   Use of the expedited primitives should be restricted to rare
>   configuration-change operations that would not normally be
>   undertaken while a real-time..
> 
> I think it could have been argued at the time, that operations under
> rtnl_lock() were "configuration-change" operations.  However, for our
> use cases, it's not, as link changes are external events beyond control.

Certainly the variety of operations that people are willing to run
concurrently with real-time applications seems to be steadily growing
over time...  But much depends on the RT deadlines.

Thanx, Paul

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

[PATCH] ntp:Fix second_overflow's input parameter type

[DengChao]

The function "second_overflow" uses "unsigned long"
as its input parameter type which will overflow after
year 2106 on 32bit systems.
This patch replaces it with a time64_t type.
Since "next_ntp_leap_sec" is already calculated, we can reuse it
and avoid re-doing the division (which is now moreexpensive
with 64bit types) in the one-per-second TIME_INS/DEL checks.

Signed-off-by: DengChao 
---
 kernel/time/ntp.c  | 16 +---
 kernel/time/ntp_internal.h |  2 +-
 2 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
index df68cb8..f4a9e18 100644
--- a/kernel/time/ntp.c
+++ b/kernel/time/ntp.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "ntp_internal.h"
 
@@ -390,10 +391,11 @@ ktime_t ntp_get_next_leap(void)
  *
  * Also handles leap second processing, and returns leap offset
  */
-int second_overflow(unsigned long secs)
+int second_overflow(time64_t secs)
 {
s64 delta;
int leap = 0;
+   s32 rem;
 
/*
 * Leap second processing. If in leap-insert state at the end of the
@@ -404,19 +406,19 @@ int second_overflow(unsigned long secs)
case TIME_OK:
if (time_status & STA_INS) {
time_state = TIME_INS;
-   ntp_next_leap_sec = secs + SECS_PER_DAY -
-   (secs % SECS_PER_DAY);
+   div_s64_rem(secs, SECS_PER_DAY, );
+   ntp_next_leap_sec = secs + SECS_PER_DAY - rem;
} else if (time_status & STA_DEL) {
time_state = TIME_DEL;
-   ntp_next_leap_sec = secs + SECS_PER_DAY -
-((secs+1) % SECS_PER_DAY);
+   div_s64_rem(secs + 1, SECS_PER_DAY, );
+   ntp_next_leap_sec = secs + SECS_PER_DAY - rem;
}
break;
case TIME_INS:
if (!(time_status & STA_INS)) {
ntp_next_leap_sec = TIME64_MAX;
time_state = TIME_OK;
-   } else if (secs % SECS_PER_DAY == 0) {
+   } else if (secs == ntp_next_leap_sec) {
leap = -1;
time_state = TIME_OOP;
printk(KERN_NOTICE
@@ -427,7 +429,7 @@ int second_overflow(unsigned long secs)
if (!(time_status & STA_DEL)) {
ntp_next_leap_sec = TIME64_MAX;
time_state = TIME_OK;
-   } else if ((secs + 1) % SECS_PER_DAY == 0) {
+   } else if (secs == ntp_next_leap_sec) {
leap = 1;
ntp_next_leap_sec = TIME64_MAX;
time_state = TIME_WAIT;
diff --git a/kernel/time/ntp_internal.h b/kernel/time/ntp_internal.h
index 6543050..446846b 100644
--- a/kernel/time/ntp_internal.h
+++ b/kernel/time/ntp_internal.h
@@ -6,7 +6,7 @@ extern void ntp_clear(void);
 /* Returns how long ticks are at present, in ns / 2^NTP_SCALE_SHIFT. */
 extern u64 ntp_tick_length(void);
 extern ktime_t ntp_get_next_leap(void);
-extern int second_overflow(unsigned long secs);
+extern int second_overflow(time64_t secs);
 extern int ntp_validate_timex(struct timex *);
 extern int __do_adjtimex(struct timex *, struct timespec64 *, s32 *);
 extern void __hardpps(const struct timespec *, const struct timespec *);
-- 
1.9.1

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

[v6, 2/6] fsl/fman: Add FMan support

[igal.liberman]

From: Igal Liberman 

Add the Data Path Acceleration Architecture Frame Manger Driver.
The FMan embeds a series of hardware blocks that implement a group
of Ethernet interfaces. This patch adds The FMan configuration,
initialization and runtime control routines.

The FMan driver supports several hardware versions
differentiated by things like:
- Different type of MACs
- Number of MAC and ports
- Available resources
- Different hardware errata

Signed-off-by: Igal Liberman 
---
 drivers/net/ethernet/freescale/fman/Makefile |2 +-
 drivers/net/ethernet/freescale/fman/fman.c   | 2896 ++
 drivers/net/ethernet/freescale/fman/fman.h   |  329 +++
 3 files changed, 3226 insertions(+), 1 deletion(-)
 create mode 100644 drivers/net/ethernet/freescale/fman/fman.c
 create mode 100644 drivers/net/ethernet/freescale/fman/fman.h

diff --git a/drivers/net/ethernet/freescale/fman/Makefile 
b/drivers/net/ethernet/freescale/fman/Makefile
index fc2e194..fb5a7f0 100644
--- a/drivers/net/ethernet/freescale/fman/Makefile
+++ b/drivers/net/ethernet/freescale/fman/Makefile
@@ -2,4 +2,4 @@ subdir-ccflags-y +=  
-I$(srctree)/drivers/net/ethernet/freescale/fman
 
 obj-y  += fsl_fman.o
 
-fsl_fman-objs  := fman_muram.o
+fsl_fman-objs  := fman_muram.o fman.o
diff --git a/drivers/net/ethernet/freescale/fman/fman.c 
b/drivers/net/ethernet/freescale/fman/fman.c
new file mode 100644
index 000..c8923c68
--- /dev/null
+++ b/drivers/net/ethernet/freescale/fman/fman.c
@@ -0,0 +1,2896 @@
+/*
+ * Copyright 2008-2015 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in the
+ *   documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ *   names of its contributors may be used to endorse or promote products
+ *   derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include "fman.h"
+#include "fman_muram.h"
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* General defines */
+#define FMAN_LIODN_TBL 64  /* size of LIODN table */
+#define MAX_NUM_OF_MACS10
+#define FM_NUM_OF_FMAN_CTRL_EVENT_REGS 4
+#define BASE_RX_PORTID 0x08
+#define BASE_TX_PORTID 0x28
+
+/* Modules registers offsets */
+#define BMI_OFFSET 0x0008
+#define QMI_OFFSET 0x00080400
+#define DMA_OFFSET 0x000C2000
+#define FPM_OFFSET 0x000C3000
+#define IMEM_OFFSET0x000C4000
+#define CGP_OFFSET 0x000DB000
+
+/* Exceptions bit map */
+#define EX_DMA_BUS_ERROR   0x8000
+#define EX_DMA_READ_ECC0x4000
+#define EX_DMA_SYSTEM_WRITE_ECC0x2000
+#define EX_DMA_FM_WRITE_ECC0x1000
+#define EX_FPM_STALL_ON_TASKS  0x0800
+#define EX_FPM_SINGLE_ECC  0x0400
+#define EX_FPM_DOUBLE_ECC  0x0200
+#define EX_QMI_SINGLE_ECC  0x0100
+#define EX_QMI_DEQ_FROM_UNKNOWN_PORTID 0x0080
+#define EX_QMI_DOUBLE_ECC  0x0040
+#define EX_BMI_LIST_RAM_ECC0x0020
+#define EX_BMI_STORAGE_PROFILE_ECC 0x0010
+#define EX_BMI_STATISTICS_RAM_ECC  0x0008
+#define EX_IRAM_ECC0x0004
+#define EX_MURAM_ECC  

[v6, 3/6] fsl/fman: Add FMan MAC support

[igal.liberman]

From: Igal Liberman 

Add the Data Path Acceleration Architecture Frame Manger MAC support.
This patch adds The FMan MAC configuration, initialization and
runtime control routines.
This patch contains support for these types of MACs:
- dTSEC: Three speed Ethernet controller (10/100/1000 Mbps)
- tGEC: 10G Ethernet controller (10 Gbps)
- mEMAC: Multi-rate Ethernet MAC (10/100/1000/1 Mbps)
Different FMan revisions have different type and number of MACs.

Signed-off-by: Igal Liberman 
---
 drivers/net/ethernet/freescale/fman/Makefile   |3 +-
 .../net/ethernet/freescale/fman/crc_mac_addr_ext.h |  314 
 drivers/net/ethernet/freescale/fman/fman_dtsec.c   | 1608 
 drivers/net/ethernet/freescale/fman/fman_dtsec.h   |   59 +
 drivers/net/ethernet/freescale/fman/fman_mac.h |  276 
 drivers/net/ethernet/freescale/fman/fman_memac.c   | 1307 
 drivers/net/ethernet/freescale/fman/fman_memac.h   |   60 +
 drivers/net/ethernet/freescale/fman/fman_tgec.c|  798 ++
 drivers/net/ethernet/freescale/fman/fman_tgec.h|   55 +
 9 files changed, 4479 insertions(+), 1 deletion(-)
 create mode 100644 drivers/net/ethernet/freescale/fman/crc_mac_addr_ext.h
 create mode 100644 drivers/net/ethernet/freescale/fman/fman_dtsec.c
 create mode 100644 drivers/net/ethernet/freescale/fman/fman_dtsec.h
 create mode 100644 drivers/net/ethernet/freescale/fman/fman_mac.h
 create mode 100644 drivers/net/ethernet/freescale/fman/fman_memac.c
 create mode 100644 drivers/net/ethernet/freescale/fman/fman_memac.h
 create mode 100644 drivers/net/ethernet/freescale/fman/fman_tgec.c
 create mode 100644 drivers/net/ethernet/freescale/fman/fman_tgec.h

diff --git a/drivers/net/ethernet/freescale/fman/Makefile 
b/drivers/net/ethernet/freescale/fman/Makefile
index fb5a7f0..43360d70 100644
--- a/drivers/net/ethernet/freescale/fman/Makefile
+++ b/drivers/net/ethernet/freescale/fman/Makefile
@@ -1,5 +1,6 @@
 subdir-ccflags-y +=  -I$(srctree)/drivers/net/ethernet/freescale/fman
 
-obj-y  += fsl_fman.o
+obj-y  += fsl_fman.o fsl_fman_mac.o
 
 fsl_fman-objs  := fman_muram.o fman.o
+fsl_fman_mac-objs := fman_dtsec.o fman_memac.o fman_tgec.o
diff --git a/drivers/net/ethernet/freescale/fman/crc_mac_addr_ext.h 
b/drivers/net/ethernet/freescale/fman/crc_mac_addr_ext.h
new file mode 100644
index 000..92f2e87
--- /dev/null
+++ b/drivers/net/ethernet/freescale/fman/crc_mac_addr_ext.h
@@ -0,0 +1,314 @@
+/*
+ * Copyright 2008-2015 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in the
+ *   documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ *   names of its contributors may be used to endorse or promote products
+ *   derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/* Define a macro that calculate the crc value of an Ethernet MAC address
+ * (48 bitd address)
+ */
+
+#ifndef __crc_mac_addr_ext_h
+#define __crc_mac_addr_ext_h
+
+#include 
+
+static u32 crc_table[256] = {
+   0x,
+   0x77073096,
+   0xee0e612c,
+   0x990951ba,
+   0x076dc419,
+   0x706af48f,
+   0xe963a535,
+   0x9e6495a3,
+   0x0edb8832,
+   0x79dcb8a4,
+   0xe0d5e91e,
+   0x97d2d988,
+   0x09b64c2b,
+   0x7eb17cbd,
+   0xe7b82d07,
+   0x90bf1d91,
+   0x1db71064,
+   0x6ab020f2,
+   0xf3b97148,
+   

[v6, 1/6] fsl/fman: Add FMan MURAM support

[igal.liberman]

From: Igal Liberman 

Add Frame Manager Multi-User RAM support.
This internal FMan memory block is used by the
FMan hardware modules, the management being made
through the generic allocator.

The FMan Internal memory, for example, is used for
allocating transmit and receive FIFOs.

Signed-off-by: Igal Liberman 
---
 drivers/net/ethernet/freescale/Kconfig   |1 +
 drivers/net/ethernet/freescale/Makefile  |2 +
 drivers/net/ethernet/freescale/fman/Kconfig  |8 ++
 drivers/net/ethernet/freescale/fman/Makefile |5 +
 drivers/net/ethernet/freescale/fman/fman_muram.c |  159 ++
 drivers/net/ethernet/freescale/fman/fman_muram.h |   51 +++
 6 files changed, 226 insertions(+)
 create mode 100644 drivers/net/ethernet/freescale/fman/Kconfig
 create mode 100644 drivers/net/ethernet/freescale/fman/Makefile
 create mode 100644 drivers/net/ethernet/freescale/fman/fman_muram.c
 create mode 100644 drivers/net/ethernet/freescale/fman/fman_muram.h

diff --git a/drivers/net/ethernet/freescale/Kconfig 
b/drivers/net/ethernet/freescale/Kconfig
index ff76d4e..f3f89cc 100644
--- a/drivers/net/ethernet/freescale/Kconfig
+++ b/drivers/net/ethernet/freescale/Kconfig
@@ -53,6 +53,7 @@ config FEC_MPC52xx_MDIO
  If compiled as module, it will be called fec_mpc52xx_phy.
 
 source "drivers/net/ethernet/freescale/fs_enet/Kconfig"
+source "drivers/net/ethernet/freescale/fman/Kconfig"
 
 config FSL_PQ_MDIO
tristate "Freescale PQ MDIO"
diff --git a/drivers/net/ethernet/freescale/Makefile 
b/drivers/net/ethernet/freescale/Makefile
index 71debd1..4097c58 100644
--- a/drivers/net/ethernet/freescale/Makefile
+++ b/drivers/net/ethernet/freescale/Makefile
@@ -17,3 +17,5 @@ gianfar_driver-objs := gianfar.o \
gianfar_ethtool.o
 obj-$(CONFIG_UCC_GETH) += ucc_geth_driver.o
 ucc_geth_driver-objs := ucc_geth.o ucc_geth_ethtool.o
+
+obj-$(CONFIG_FSL_FMAN) += fman/
diff --git a/drivers/net/ethernet/freescale/fman/Kconfig 
b/drivers/net/ethernet/freescale/fman/Kconfig
new file mode 100644
index 000..66b7296
--- /dev/null
+++ b/drivers/net/ethernet/freescale/fman/Kconfig
@@ -0,0 +1,8 @@
+config FSL_FMAN
+   bool "FMan support"
+   depends on FSL_SOC || COMPILE_TEST
+   select GENERIC_ALLOCATOR
+   default n
+   help
+   Freescale Data-Path Acceleration Architecture Frame Manager
+   (FMan) support
diff --git a/drivers/net/ethernet/freescale/fman/Makefile 
b/drivers/net/ethernet/freescale/fman/Makefile
new file mode 100644
index 000..fc2e194
--- /dev/null
+++ b/drivers/net/ethernet/freescale/fman/Makefile
@@ -0,0 +1,5 @@
+subdir-ccflags-y +=  -I$(srctree)/drivers/net/ethernet/freescale/fman
+
+obj-y  += fsl_fman.o
+
+fsl_fman-objs  := fman_muram.o
diff --git a/drivers/net/ethernet/freescale/fman/fman_muram.c 
b/drivers/net/ethernet/freescale/fman/fman_muram.c
new file mode 100644
index 000..35d4a50
--- /dev/null
+++ b/drivers/net/ethernet/freescale/fman/fman_muram.c
@@ -0,0 +1,159 @@
+/*
+ * Copyright 2008-2015 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in the
+ *   documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ *   names of its contributors may be used to endorse or promote products
+ *   derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include "fman_muram.h"
+
+#include 
+#include 
+#include 

[PATCH v5 5/7] vfio: platform: add compat in vfio_platform_device

[Eric Auger]

Let's retrieve the compatibility string on probe and store it
in the vfio_platform_device struct

Signed-off-by: Eric Auger 

---

v2 -> v3:
- populate compat after vdev check
---
 drivers/vfio/platform/vfio_platform_common.c  | 15 ---
 drivers/vfio/platform/vfio_platform_private.h |  1 +
 2 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/vfio/platform/vfio_platform_common.c 
b/drivers/vfio/platform/vfio_platform_common.c
index 3b7e52c..f2d41a0 100644
--- a/drivers/vfio/platform/vfio_platform_common.c
+++ b/drivers/vfio/platform/vfio_platform_common.c
@@ -41,16 +41,11 @@ static const struct vfio_platform_reset_combo 
reset_lookup_table[] = {
 static void vfio_platform_get_reset(struct vfio_platform_device *vdev,
struct device *dev)
 {
-   const char *compat;
int (*reset)(struct vfio_platform_device *);
-   int ret, i;
-
-   ret = device_property_read_string(dev, "compatible", );
-   if (ret)
-   return;
+   int i;
 
for (i = 0 ; i < ARRAY_SIZE(reset_lookup_table); i++) {
-   if (!strcmp(reset_lookup_table[i].compat, compat)) {
+   if (!strcmp(reset_lookup_table[i].compat, vdev->compat)) {
request_module(reset_lookup_table[i].module_name);
reset = __symbol_get(
reset_lookup_table[i].reset_function_name);
@@ -544,6 +539,12 @@ int vfio_platform_probe_common(struct vfio_platform_device 
*vdev,
if (!vdev)
return -EINVAL;
 
+   ret = device_property_read_string(dev, "compatible", >compat);
+   if (ret) {
+   pr_err("VFIO: cannot retrieve compat for %s\n", vdev->name);
+   return -EINVAL;
+   }
+
group = iommu_group_get(dev);
if (!group) {
pr_err("VFIO: No IOMMU group for device %s\n", vdev->name);
diff --git a/drivers/vfio/platform/vfio_platform_private.h 
b/drivers/vfio/platform/vfio_platform_private.h
index fd262be..415310f 100644
--- a/drivers/vfio/platform/vfio_platform_private.h
+++ b/drivers/vfio/platform/vfio_platform_private.h
@@ -57,6 +57,7 @@ struct vfio_platform_device {
int refcnt;
struct mutexigate;
struct module   *parent_module;
+   const char  *compat;
 
/*
 * These fields should be filled by the bus specific binder
-- 
1.9.1

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

[v6, 0/6] Freescale DPAA FMan

[igal.liberman]

From: Igal Liberman 

The Freescale Data Path Acceleration Architecture (DPAA) is a set
of hardware components on specific QorIQ multicore processors.
This architecture provides the infrastructure to support
simplified sharing of networking interfaces and accelerators
by multiple CPU cores and the accelerators.

One of the DPAA accelerators is the Frame Manager (FMan)
which contains a series of hardware blocks: ports, Ethernet MACs,
a multi user RAM (MURAM) and Storage Profile (SP).

This patch set introduce the FMan drivers.
Each driver configures and initializes the corresponding
FMan hardware module (described above).
The MAC driver offers support for three different
types of MACs (eTSEC, TGEC, MEMAC).

v5 --> v6:
- Addressed feedback from Scott:
- Moved kernel doc to source files
- Removed a series of configurable settings
- Miscellaneous code updates

v4 --> v5:
- Addressed feedback from David Miller:
- Removed driver layering
- Reduce namespace pollution
- Reduce code complexity and size

v3 --> v4:
- Remove device_initcall call in driver registration (redundant)
- Remove hot/cold labels
- Minor update in FMan Clock read from device-tree
- Update fixed-link support
- Addressed feedback from Stephen Hemminger
- Remove bogus blank line

v2 --> v3:
- Addressed feedback from Scott:
- Remove typedefs
- Remove unnecessary memory barriers
- Remove unnecessary casting
- Remove KConfig options
- Remove early_params
- Remove Hungarian notation
- Remove __packed__  attribute and padding from structures
- Remove unlikely attribute (where it's not needed)
- Use proper error codes and remove unnecessary prints
- Use proper values for sleep routines
- Replace complex Macros with functions
- Improve device tree processing code
- Use symbolic defines
- Add time-out in busy-wait loops
- Removed exit code (loadable module support will be added 
later)
- Fixed "fixed-link" issue raised by Joakim Tjernlund

v1 --> v2:
- Addressed feedback from Paul Bolle:
- General feedback of FMan Driver layer
- Remove Errata defines
- Aligned comments to Kernel Doc
- Remove Loadable Module support (not yet supported)
- Removed not needed KConfig dependencies
- Addressed feedback from Scott Wood
- Use Kernel ioread/iowrite services
- Squash FLIB source and header patches together

This submission is based on the prior Freescale DPAA FMan V3,RFC submission.
Several issues addresses in this submission:
- Reduced MAC layering and complexity
- Reduced code base
- T1024/T2080 10G best effort support

Igal Liberman (6):
  fsl/fman: Add FMan MURAM support
  fsl/fman: Add FMan support
  fsl/fman: Add FMan MAC support
  fsl/fman: Add FMan SP support
  fsl/fman: Add FMan Port Support
  fsl/fman: Add FMan MAC driver

 drivers/net/ethernet/freescale/Kconfig |1 +
 drivers/net/ethernet/freescale/Makefile|2 +
 drivers/net/ethernet/freescale/fman/Kconfig|8 +
 drivers/net/ethernet/freescale/fman/Makefile   |7 +
 .../net/ethernet/freescale/fman/crc_mac_addr_ext.h |  314 +++
 drivers/net/ethernet/freescale/fman/fman.c | 2896 
 drivers/net/ethernet/freescale/fman/fman.h |  329 +++
 drivers/net/ethernet/freescale/fman/fman_dtsec.c   | 1608 +++
 drivers/net/ethernet/freescale/fman/fman_dtsec.h   |   59 +
 drivers/net/ethernet/freescale/fman/fman_mac.h |  276 ++
 drivers/net/ethernet/freescale/fman/fman_memac.c   | 1307 +
 drivers/net/ethernet/freescale/fman/fman_memac.h   |   60 +
 drivers/net/ethernet/freescale/fman/fman_muram.c   |  159 ++
 drivers/net/ethernet/freescale/fman/fman_muram.h   |   51 +
 drivers/net/ethernet/freescale/fman/fman_port.c| 1800 
 drivers/net/ethernet/freescale/fman/fman_port.h|  151 +
 drivers/net/ethernet/freescale/fman/fman_sp.c  |  167 ++
 drivers/net/ethernet/freescale/fman/fman_sp.h  |  103 +
 drivers/net/ethernet/freescale/fman/fman_tgec.c|  798 ++
 drivers/net/ethernet/freescale/fman/fman_tgec.h|   55 +
 drivers/net/ethernet/freescale/fman/mac.c  |  980 +++
 drivers/net/ethernet/freescale/fman/mac.h  |   97 +
 22 files changed, 11228 insertions(+)
 create mode 100644 drivers/net/ethernet/freescale/fman/Kconfig
 create mode 100644 drivers/net/ethernet/freescale/fman/Makefile
 create mode 100644 drivers/net/ethernet/freescale/fman/crc_mac_addr_ext.h
 create mode 

[PATCH v5 4/7] vfio: platform: reset: calxedaxgmac: add reset function registration

[Eric Auger]

This patch adds the reset function registration/unregistration.
This is handled through the module_vfio_reset_handler macro. This
latter also defines a MODULE_ALIAS which simplifies the load from
vfio-platform.

Signed-off-by: Eric Auger 
Reviewed-by: Arnd Bergmann 

---

v3 -> v4:
- I restored the EXPORT_SYMBOL which will be removed when switching the
  lookup method
- Add Arnd R-b.

v2 -> v3:
- do not include vfio_platform_reset_private.h anymore (removed)
- remove pr_info
- rework commit message

v1 -> v2:
- uses the module_vfio_reset_handler macro
- add pr_info on vfio reset
- do not export vfio_platform_calxedaxgmac_reset symbol anymore
---
 drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c 
b/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c
index 619dc7d..80718f2 100644
--- a/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c
+++ b/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c
@@ -30,8 +30,6 @@
 #define DRIVER_AUTHOR   "Eric Auger "
 #define DRIVER_DESC "Reset support for Calxeda xgmac vfio platform device"
 
-#define CALXEDAXGMAC_COMPAT "calxeda,hb-xgmac"
-
 /* XGMAC Register definitions */
 #define XGMAC_CONTROL   0x  /* MAC Configuration */
 
@@ -80,6 +78,8 @@ int vfio_platform_calxedaxgmac_reset(struct 
vfio_platform_device *vdev)
 }
 EXPORT_SYMBOL_GPL(vfio_platform_calxedaxgmac_reset);
 
+module_vfio_reset_handler("calxeda,hb-xgmac", 
vfio_platform_calxedaxgmac_reset);
+
 MODULE_VERSION(DRIVER_VERSION);
 MODULE_LICENSE("GPL v2");
 MODULE_AUTHOR(DRIVER_AUTHOR);
-- 
1.9.1

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

[PATCH 7/8] Staging: rtl8192u: ieee80211: removed unnecessary braces

[Kurt Kanzenbach]

This patch fixes the following checkpatch warning:
  - WARNING: braces {} are not necessary for single statement blocks

Signed-off-by: Kurt Kanzenbach 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
index 7c166cf..157af31 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
@@ -572,9 +572,8 @@ static int ieee80211_michael_mic_add(struct sk_buff *skb, 
int hdr_len, void *pri
 
// { david, 2006.9.1
// fix the wpa process with wmm enabled.
-   if (IEEE80211_QOS_HAS_SEQ(le16_to_cpu(hdr->frame_ctl))) {
+   if (IEEE80211_QOS_HAS_SEQ(le16_to_cpu(hdr->frame_ctl)))
tkey->tx_hdr[12] = *(skb->data + hdr_len - 2) & 0x07;
-   }
// }
pos = skb_put(skb, 8);
 
@@ -621,9 +620,8 @@ static int ieee80211_michael_mic_verify(struct sk_buff 
*skb, int keyidx,
michael_mic_hdr(skb, tkey->rx_hdr);
// { david, 2006.9.1
// fix the wpa process with wmm enabled.
-   if (IEEE80211_QOS_HAS_SEQ(le16_to_cpu(hdr->frame_ctl))) {
+   if (IEEE80211_QOS_HAS_SEQ(le16_to_cpu(hdr->frame_ctl)))
tkey->rx_hdr[12] = *(skb->data + hdr_len - 2) & 0x07;
-   }
// }
 
if (michael_mic(tkey->rx_tfm_michael, >key[24], tkey->rx_hdr,
-- 
2.4.10

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

[PATCH v5 0/7] VFIO platform reset module rework

[Eric Auger]

This series fixes the current implementation by getting rid of the
usage of __symbol_get which caused a compilation issue with
CONFIG_MODULES disabled. On top of this, the usage of MODULE_ALIAS makes
possible to add a new reset module without being obliged to update the
framework. The new implementation relies on the reset module registering
its reset function to the vfio-platform driver.

The series is available at

https://git.linaro.org/people/eric.auger/linux.git/shortlog/refs/heads/v4.3-rc7-rework-v5

Best Regards

Eric

v4 -> v5:
- no code change
- only added Arnd's new R-b

v3 -> v4:
- Remove the EXPORT_SYMBOL_GPL(vfio_platform_calxedaxgmac_reset) later
  in [6/7], to keep the functionality working all along the series
- Add Arnd R-b (I dared to keep them despite the above change)
- vfio_platform_unregister_reset gets the reset function to do a double
  check on the compat and the function pointer too
- __vfio_platform_register_reset turned to 'void'

v2 -> v3:
- use driver_mutex instead of reset_mutex
- style fixes: single mutex_unlock
- use static nodes; vfio_platform_register_reset now is a macro
- vfio_platform_reset_private.h removed since reset_module_(un)register
  disappear. No use of symbol_get anymore.
- new patch introducing vfio-platform-base
- reset look-up moved back at vfio-platform probe time
- new patch featuring dev_info/dev_warn

v1 -> v2:
* in vfio_platform_common.c:
  - move reset lookup at load time and put reset at release: this is to
prevent a race between the 2 load module loads
  - reset_list becomes static
  - vfio_platform_register/unregister_reset take a const char * as compat
  - fix node link
  - remove old combo struct and cleanup proto of vfio_platform_get_reset
  - add mutex to protect the reset list
* in calxeda xgmac reset module
  - introduce vfio_platform_reset_private.h
  - use module_vfio_reset_handler macro
  - do not export vfio_platform_calxedaxgmac_reset symbol anymore
  - add a pr_info to show the device is reset by vfio reset module


Eric Auger (7):
  vfio: platform: introduce vfio-platform-base module
  vfio: platform: add capability to register a reset function
  vfio: platform: introduce module_vfio_reset_handler macro
  vfio: platform: reset: calxedaxgmac: add reset function registration
  vfio: platform: add compat in vfio_platform_device
  vfio: platform: use list of registered reset function
  vfio: platform: add dev_info on device reset

 drivers/vfio/platform/Makefile |   6 +-
 .../platform/reset/vfio_platform_calxedaxgmac.c|   5 +-
 drivers/vfio/platform/vfio_amba.c  |   1 +
 drivers/vfio/platform/vfio_platform.c  |   1 +
 drivers/vfio/platform/vfio_platform_common.c   | 119 +++--
 drivers/vfio/platform/vfio_platform_private.h  |  40 ++-
 6 files changed, 130 insertions(+), 42 deletions(-)

-- 
1.9.1

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

Re: [PATCH 31/52] perf stat record: Synthesize stat record data

[Jiri Olsa]

On Tue, Oct 27, 2015 at 11:42:44AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Sun, Oct 25, 2015 at 03:51:47PM +0100, Jiri Olsa escreveu:
> > Synthesizing needed stat record data for report/script:
> >   - cpu/thread maps
> >   - stat config
> 
> After this it gets a bit better, but then I expected that to specify an
> event I would be able to use:
> 
> [root@zoo linux]# perf stat record -e cycles usleep 1
>   Error: unknown switch `e'
> 
>  Usage: perf record [] []
> or: perf record [] --  []
> 
> -o, --outputoutput file name
> 
> 
> But I need to do it as:
> 
> [root@zoo linux]# perf stat -e cycles record usleep 1
> 
>  Performance counter stats for 'usleep 1':
> 
> 948417  cycles
>   
> 
>0.000749965 seconds time elapsed
> 
> [root@zoo linux]# 
> 
> --
> 
> This is confusing...

yep, the thing is that we need to have all the options supported
by perf stat to work under perf stat record.

you basically let user use perf stat with 'record' that just says
'store the data I'm monitoring'

I'll try to find some way to move the options under perf stat record
without too many changes.. but not sure

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

[PATCH 1/8] Staging: rtl8192u: ieee80211: fixed open brace positions

[Kurt Kanzenbach]

This patch fixes the following checkpatch error:
  - ERROR: that open brace { should be on the previous line

Signed-off-by: Kurt Kanzenbach 
---
 .../staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c  | 18 ++
 1 file changed, 6 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
index 1f80c52..dd058b6 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
@@ -185,8 +185,7 @@ static inline u16 Mk16_le(u16 *v)
 }
 
 
-static const u16 Sbox[256] =
-{
+static const u16 Sbox[256] = {
0xC6A5, 0xF884, 0xEE99, 0xF68D, 0xFF0D, 0xD6BD, 0xDEB1, 0x9154,
0x6050, 0x0203, 0xCEA9, 0x567D, 0xE719, 0xB562, 0x4DE6, 0xEC9A,
0x8F45, 0x1F9D, 0x8940, 0xFA87, 0xEF15, 0xB2EB, 0x8EC9, 0xFB0B,
@@ -320,8 +319,7 @@ static int ieee80211_tkip_encrypt(struct sk_buff *skb, int 
hdr_len, void *priv)
 
hdr = (struct rtl_80211_hdr_4addr *) skb->data;
 
-   if (!tcb_desc->bHwSec)
-   {
+   if (!tcb_desc->bHwSec) {
if (!tkey->tx_phase1_done) {
tkip_mixing_phase1(tkey->tx_ttak, tkey->key, hdr->addr2,
tkey->tx_iv32);
@@ -338,14 +336,12 @@ static int ieee80211_tkip_encrypt(struct sk_buff *skb, 
int hdr_len, void *priv)
memmove(pos, pos + 8, hdr_len);
pos += hdr_len;
 
-   if (tcb_desc->bHwSec)
-   {
+   if (tcb_desc->bHwSec) {
*pos++ = Hi8(tkey->tx_iv16);
*pos++ = (Hi8(tkey->tx_iv16) | 0x20) & 0x7F;
*pos++ = Lo8(tkey->tx_iv16);
}
-   else
-   {
+   else {
*pos++ = rc4key[0];
*pos++ = rc4key[1];
*pos++ = rc4key[2];
@@ -357,8 +353,7 @@ static int ieee80211_tkip_encrypt(struct sk_buff *skb, int 
hdr_len, void *priv)
*pos++ = (tkey->tx_iv32 >> 16) & 0xff;
*pos++ = (tkey->tx_iv32 >> 24) & 0xff;
 
-   if (!tcb_desc->bHwSec)
-   {
+   if (!tcb_desc->bHwSec) {
icv = skb_put(skb, 4);
crc = ~crc32_le(~0, pos, len);
icv[0] = crc;
@@ -429,8 +424,7 @@ static int ieee80211_tkip_decrypt(struct sk_buff *skb, int 
hdr_len, void *priv)
iv32 = pos[4] | (pos[5] << 8) | (pos[6] << 16) | (pos[7] << 24);
pos += 8;
 
-   if (!tcb_desc->bHwSec)
-   {
+   if (!tcb_desc->bHwSec) {
if (iv32 < tkey->rx_iv32 ||
(iv32 == tkey->rx_iv32 && iv16 <= tkey->rx_iv16)) {
if (net_ratelimit()) {
-- 
2.4.10

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

[PULL] clockevents: fixes for 4.3-rc7

[Daniel Lezcano]

Hi Thomas,

this pull request contains a set of fixes for tip/timers/urgent:

 - Prevent ftrace recursion by adding the 'notrace' attribute to the 
sched_clock read callback (Jisheng Zhang).


 - Fix multiple shutdown call issue (Magnus Damm).

Beside that, the commit fc686d0037d782c994e338ecb01bfef8bbafff9f:

"clockevents/drivers/mtk: Fix spurious interrupt leading to crash"

is merged in tip/timers/core but it is needed also as a fix for 4.3. 
This pull request does not contain this fix in order to prevent a 
conflict when merging tip/timers/urgent into tip/timers/core.


How shall I backport this fix from 'core' to 'urgent' without bringing a 
conflict when you will merge both branches ?


Thanks !

  -- Daniel

The following changes since commit 56fd16cabac9cd8f15e2902898a9d0cc96e2fa70:

  timekeeping: Increment clock_was_set_seq in timekeeping_init() 
(2015-10-16 15:50:22 +0200)


are available in the git repository at:

  http://git.linaro.org/people/daniel.lezcano/linux.git 
clockevents/4.3-fixes


for you to fetch changes up to b52e0b08c33a1c58830e3a2350b632dbf8fc1688:

  clocksource/drivers/sh_mtu2: Fix multiple shutdown call issue 
(2015-10-28 10:19:32 +0100)



Jisheng Zhang (7):
  clocksource/drivers/arm_global_timer: Prevent ftrace recursion
  clocksource/drivers/pistachio: Prevent ftrace recursion
  clocksource/drivers/samsung_pwm_timer: Prevent ftrace recursion
  clocksource/drivers/prima2: Prevent ftrace recursion
  clocksource/drivers/vf_pit_timer: Prevent ftrace recursion
  clocksource/drivers/fsl_ftm_timer: Prevent ftrace recursion
  clocksource/drivers/digicolor: Prevent ftrace recursion

Magnus Damm (1):
  clocksource/drivers/sh_mtu2: Fix multiple shutdown call issue

 drivers/clocksource/arm_global_timer.c  | 9 +++--
 drivers/clocksource/fsl_ftm_timer.c | 2 +-
 drivers/clocksource/samsung_pwm_timer.c | 2 +-
 drivers/clocksource/sh_mtu2.c   | 4 +++-
 drivers/clocksource/time-pistachio.c| 3 ++-
 drivers/clocksource/timer-digicolor.c   | 2 +-
 drivers/clocksource/timer-prima2.c  | 2 +-
 drivers/clocksource/vf_pit_timer.c  | 2 +-
 8 files changed, 17 insertions(+), 9 deletions(-)

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

Follow Linaro:   Facebook |
 Twitter |
 Blog

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

Re: [PATCH v3 1/2] ASoC: wm9713: convert to regmap

[Charles Keepax]

On Tue, Oct 27, 2015 at 10:58:21PM +0100, Robert Jarzmik wrote:
> Convert the Wolfson WM9713 to regmap API. This will leverage all the
> regmap functions (debug, registers update, etc ...).
> 
> As a bonus, this will pave the path to gpio chip introduction, and
> devicetree support.
> 
> Signed-off-by: Robert Jarzmik 
> ---
> Since v1: fix suspend/resume (that specific part is not tested yet)
> Since v2: split out the snd_soc_*() from regmap support
> ---
>  sound/soc/codecs/Kconfig  |   1 +
>  sound/soc/codecs/wm9713.c | 182 
> --
>  2 files changed, 114 insertions(+), 69 deletions(-)
> 
> diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
> index 0c9733ecd17f..ba306f8f3717 100644
> --- a/sound/soc/codecs/Kconfig
> +++ b/sound/soc/codecs/Kconfig
> @@ -879,6 +879,7 @@ config SND_SOC_WM9712
>  
>  config SND_SOC_WM9713
>   tristate
> + select REGMAP_AC97
>  
>  # Amp
>  config SND_SOC_LM4857
> diff --git a/sound/soc/codecs/wm9713.c b/sound/soc/codecs/wm9713.c
> index 4083a5130cbd..8e2cc1112e40 100644
> --- a/sound/soc/codecs/wm9713.c
> +++ b/sound/soc/codecs/wm9713.c
> @@ -19,6 +19,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -39,33 +40,15 @@ struct wm9713_priv {
>   struct mutex lock;
>  };
>  
> -static unsigned int ac97_read(struct snd_soc_codec *codec,
> - unsigned int reg);
> -static int ac97_write(struct snd_soc_codec *codec,
> - unsigned int reg, unsigned int val);
> -
> -/*
> - * WM9713 register cache
> - * Reg 0x3c bit 15 is used by touch driver.
> - */
> -static const u16 wm9713_reg[] = {
> - 0x6174, 0x8080, 0x8080, 0x8080,
> - 0xc880, 0xe808, 0xe808, 0x0808,
> - 0x00da, 0x8000, 0xd600, 0xaaa0,
> - 0xaaa0, 0xaaa0, 0x, 0x,
> - 0x0f0f, 0x0040, 0x, 0x7f00,
> - 0x0405, 0x0410, 0xbb80, 0xbb80,
> - 0x, 0xbb80, 0x, 0x4523,
> - 0x, 0x2000, 0x7eff, 0x,
> - 0x, 0x, 0x0080, 0x,
> - 0x, 0x, 0xfffe, 0x,
> - 0x, 0x, 0x, 0xfffe,
> - 0x4000, 0x, 0x, 0x,
> - 0xb032, 0x3e00, 0x, 0x,
> - 0x, 0x, 0x, 0x,
> - 0x, 0x, 0x, 0x0006,
> - 0x0001, 0x, 0x574d, 0x4c13,
> -};
> +static unsigned int ac97_read(struct snd_soc_codec *codec, unsigned int reg)
> +{
> + return snd_soc_read(codec, reg);
> +}
> +static int ac97_write(struct snd_soc_codec *codec, unsigned int reg,
> +   unsigned int val)
> +{
> + return snd_soc_write(codec, reg, val);
> +}
>  
>  #define HPL_MIXER 0
>  #define HPR_MIXER 1
> @@ -674,39 +657,97 @@ static const struct snd_soc_dapm_route 
> wm9713_audio_map[] = {
>   {"Capture Mono Mux", "Right", "Right Capture Source"},
>  };
>  
> -static unsigned int ac97_read(struct snd_soc_codec *codec,
> - unsigned int reg)
> +static bool wm9713_readable_reg(struct device *dev, unsigned int reg)
>  {
> - struct wm9713_priv *wm9713 = snd_soc_codec_get_drvdata(codec);
> - u16 *cache = codec->reg_cache;
> -
> - if (reg == AC97_RESET || reg == AC97_GPIO_STATUS ||
> - reg == AC97_VENDOR_ID1 || reg == AC97_VENDOR_ID2 ||
> - reg == AC97_CD)
> - return soc_ac97_ops->read(wm9713->ac97, reg);
> - else {
> - reg = reg >> 1;
> -
> - if (reg >= (ARRAY_SIZE(wm9713_reg)))
> - return -EIO;
> -
> - return cache[reg];
> + switch (reg) {
> + case AC97_RESET ... AC97_PCM_SURR_DAC_RATE:
> + case AC97_PCM_LR_ADC_RATE:
> + case AC97_CENTER_LFE_MASTER:
> + case AC97_SPDIF ... AC97_LINE1_LEVEL:
> + case AC97_GPIO_CFG ... 0x5c:
> + case AC97_CODEC_CLASS_REV ... AC97_PCI_SID:
> + case 0x74 ... AC97_VENDOR_ID2:
> + return true;
> + default:
> + return false;
>   }
>  }
>  
> -static int ac97_write(struct snd_soc_codec *codec, unsigned int reg,
> - unsigned int val)
> +static bool wm9713_writeable_reg(struct device *dev, unsigned int reg)
>  {
> - struct wm9713_priv *wm9713 = snd_soc_codec_get_drvdata(codec);
> + switch (reg) {
> + case AC97_VENDOR_ID1:
> + case AC97_VENDOR_ID2:
> + return false;
> + default:
> + return wm9713_readable_reg(dev, reg);
> + }
> +}
>  
> - u16 *cache = codec->reg_cache;
> - soc_ac97_ops->write(wm9713->ac97, reg, val);
> - reg = reg >> 1;
> - if (reg < (ARRAY_SIZE(wm9713_reg)))
> - cache[reg] = val;
> +static const struct reg_default wm9713_reg_defaults[] = {
> + { 0x02, 0x8080 },   /* Speaker Output Volume */
> + { 0x04, 0x8080 },   /* Headphone Output Volume */
> + { 0x06, 0x8080 },   /* Out3/OUT4 Volume */
> + { 0x08, 0xc880 },   /* Mono Volume */
> + { 0x0a, 0xe808 },   /* LINEIN Volume */
> + { 0x0c, 0xe808 },   /* DAC PGA Volume */
> + { 0x0e, 0x0808 

[PATCH 2/8] clocksource/drivers/pistachio: Prevent ftrace recursion

[Daniel Lezcano]

From: Jisheng Zhang 

Currently pistachio can be used as a scheduler clock. We properly marked
pistachio_read_sched_clock() as notrace but we then call another function
pistachio_clocksource_read_cycles() that _wasn't_ notrace.

Having a traceable function in the sched_clock() path leads to a recursion
within ftrace and a kernel crash.

Fix this by adding notrace attribute to the pistachio_clocksource_read_cycles()
function.

Signed-off-by: Jisheng Zhang 
Signed-off-by: Daniel Lezcano 
---
 drivers/clocksource/time-pistachio.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/clocksource/time-pistachio.c 
b/drivers/clocksource/time-pistachio.c
index 18d4266..bba6799 100644
--- a/drivers/clocksource/time-pistachio.c
+++ b/drivers/clocksource/time-pistachio.c
@@ -67,7 +67,8 @@ static inline void gpt_writel(void __iomem *base, u32 value, 
u32 offset,
writel(value, base + 0x20 * gpt_id + offset);
 }
 
-static cycle_t pistachio_clocksource_read_cycles(struct clocksource *cs)
+static cycle_t notrace
+pistachio_clocksource_read_cycles(struct clocksource *cs)
 {
struct pistachio_clocksource *pcs = to_pistachio_clocksource(cs);
u32 counter, overflw;
-- 
1.9.1

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

[PATCH v6 08/15] scsi: ufs: add retries to dme_peer get and set attribute

[Yaniv Gardi]

The dme_peer get/set attribute commands are prone to errors, therefore
we add three retries for the UIC command sending.
Error code returned from ufshcd_send_uic_cmd() is checked, and unless
it was successful or the retries have finished, another command will be
sent.

Reviewed-by: Gilad Broner 
Reviewed-by: Dolev Raviv 
Signed-off-by: Lee Susman 
Signed-off-by: Yaniv Gardi 

---
 drivers/scsi/ufs/ufshcd.c | 40 +---
 1 file changed, 29 insertions(+), 11 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 8a04691..5005d12 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -70,6 +70,9 @@
 /* Task management command timeout */
 #define TM_CMD_TIMEOUT 100 /* msecs */
 
+/* maximum number of retries for a general UIC command  */
+#define UFS_UIC_COMMAND_RETRIES 3
+
 /* maximum number of link-startup retries */
 #define DME_LINKSTARTUP_RETRIES 3
 
@@ -2185,6 +2188,7 @@ int ufshcd_dme_set_attr(struct ufs_hba *hba, u32 attr_sel,
};
const char *set = action[!!peer];
int ret;
+   int retries = UFS_UIC_COMMAND_RETRIES;
 
uic_cmd.command = peer ?
UIC_CMD_DME_PEER_SET : UIC_CMD_DME_SET;
@@ -2192,10 +2196,18 @@ int ufshcd_dme_set_attr(struct ufs_hba *hba, u32 
attr_sel,
uic_cmd.argument2 = UIC_ARG_ATTR_TYPE(attr_set);
uic_cmd.argument3 = mib_val;
 
-   ret = ufshcd_send_uic_cmd(hba, _cmd);
-   if (ret)
-   dev_err(hba->dev, "%s: attr-id 0x%x val 0x%x error code %d\n",
-   set, UIC_GET_ATTR_ID(attr_sel), mib_val, ret);
+   do {
+   /* for peer attributes we retry upon failure */
+   ret = ufshcd_send_uic_cmd(hba, _cmd);
+   if (ret)
+   dev_dbg(hba->dev, "%s: attr-id 0x%x val 0x%x error code 
%d\n",
+   set, UIC_GET_ATTR_ID(attr_sel), mib_val, ret);
+   } while (ret && peer && --retries);
+
+   if (!retries)
+   dev_err(hba->dev, "%s: attr-id 0x%x val 0x%x failed %d 
retries\n",
+   set, UIC_GET_ATTR_ID(attr_sel), mib_val,
+   retries);
 
return ret;
 }
@@ -2220,6 +2232,7 @@ int ufshcd_dme_get_attr(struct ufs_hba *hba, u32 attr_sel,
};
const char *get = action[!!peer];
int ret;
+   int retries = UFS_UIC_COMMAND_RETRIES;
struct ufs_pa_layer_attr orig_pwr_info;
struct ufs_pa_layer_attr temp_pwr_info;
bool pwr_mode_change = false;
@@ -2250,14 +2263,19 @@ int ufshcd_dme_get_attr(struct ufs_hba *hba, u32 
attr_sel,
UIC_CMD_DME_PEER_GET : UIC_CMD_DME_GET;
uic_cmd.argument1 = attr_sel;
 
-   ret = ufshcd_send_uic_cmd(hba, _cmd);
-   if (ret) {
-   dev_err(hba->dev, "%s: attr-id 0x%x error code %d\n",
-   get, UIC_GET_ATTR_ID(attr_sel), ret);
-   goto out;
-   }
+   do {
+   /* for peer attributes we retry upon failure */
+   ret = ufshcd_send_uic_cmd(hba, _cmd);
+   if (ret)
+   dev_dbg(hba->dev, "%s: attr-id 0x%x error code %d\n",
+   get, UIC_GET_ATTR_ID(attr_sel), ret);
+   } while (ret && peer && --retries);
+
+   if (!retries)
+   dev_err(hba->dev, "%s: attr-id 0x%x failed %d retries\n",
+   get, UIC_GET_ATTR_ID(attr_sel), retries);
 
-   if (mib_val)
+   if (mib_val && !ret)
*mib_val = uic_cmd.argument3;
 
if (peer && (hba->quirks & UFSHCD_QUIRK_DME_PEER_ACCESS_AUTO_MODE)
-- 
1.8.5.2

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

[PATCH v6 14/15] scsi: ufs: commit descriptors before setting the doorbell

[Yaniv Gardi]

Add a write memory barrier to make sure descriptors prepared are actually
written to memory before ringing the doorbell. We have also added the
write memory barrier after ringing the doorbell register so that
controller sees the new request immediately.

Reviewed-by: Dolev Raviv 
Signed-off-by: Gilad Broner 
Signed-off-by: Subhash Jadavani 
Signed-off-by: Yaniv Gardi 

---
 drivers/scsi/ufs/ufshcd.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index dfc4ac1..ec90504 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -1628,6 +1628,8 @@ static int ufshcd_exec_dev_cmd(struct ufs_hba *hba,
 
hba->dev_cmd.complete = 
 
+   /* Make sure descriptors are ready before ringing the doorbell */
+   wmb();
spin_lock_irqsave(hba->host->host_lock, flags);
ufshcd_send_command(hba, tag);
spin_unlock_irqrestore(hba->host->host_lock, flags);
-- 
1.8.5.2

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

Re: [RFT, PATCH v1 1/1] hexdump: truncate output in case of overflow

[Aaro Koskinen]

Hi,

On Wed, Oct 28, 2015 at 12:48:19PM +0200, Andy Shevchenko wrote:
> There is a classical off-by-one error in case when we try to place, for
> example, 1+1 bytes as hex in the buffer of size 6. The expected result is to
> get an output truncated, but in the reality we get 6 bytes filed followed by
> terminating NUL.
> 
> Change the logic how we fill the output in case of byte dumping into limited
> space. This will follow the snprintf() behaviour by truncating output even on
> half bytes.
> 
> Fixes: 114fc1afb2de (hexdump: make it return number of bytes placed in buffer)
> Reported-by: Aaro Koskinen 
> Signed-off-by: Andy Shevchenko 

Thanks, this fixes the crash with kmemleak for me:

Tested-by: Aaro Koskinen 

A.

> ---
> Waiting for Aaro's Tested-by: tag, that's why RFT. Meanwhile I will update
> test-hexdump to cover all corner case in overflow.
> 
> Linus, it would be nice to promote the fix when we get Aaro's confirmation.
> 
>  lib/hexdump.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/hexdump.c b/lib/hexdump.c
> index 8d74c20..992457b 100644
> --- a/lib/hexdump.c
> +++ b/lib/hexdump.c
> @@ -169,11 +169,15 @@ int hex_dump_to_buffer(const void *buf, size_t len, int 
> rowsize, int groupsize,
>   }
>   } else {
>   for (j = 0; j < len; j++) {
> - if (linebuflen < lx + 3)
> + if (linebuflen < lx + 2)
>   goto overflow2;
>   ch = ptr[j];
>   linebuf[lx++] = hex_asc_hi(ch);
> + if (linebuflen < lx + 2)
> + goto overflow2;
>   linebuf[lx++] = hex_asc_lo(ch);
> + if (linebuflen < lx + 2)
> + goto overflow2;
>   linebuf[lx++] = ' ';
>   }
>   if (j)
> -- 
> 2.6.1
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] xfrm: dst_entries_init() per-net dst_ops

[Dan Streetman]

On Tue, Oct 27, 2015 at 12:15 PM,   wrote:
> From: Dan Streetman 
>
> The ipv4 and ipv6 xfrms each create a template dst_ops object, and
> perform dst_entries_init() on the template objects.  Then each net
> namespace has its net.xfrm.xfrm[46]_dst_ops field set to the template
> values.  The problem with that is the dst_ops.pcpuc_entries field is
> a percpu counter and cannot be used correctly by simply copying it to
> another object.
>
> The result of this is a very subtle bug; changes to the dst entries
> counter from one net namespace may sometimes get applied to a different
> net namespace dst entries counter.  This is because of how the percpu
> counter works; it has a main count field as well as a pointer to the
> percpu variables.  Each net namespace maintains its own main count
> variable, but all point to one set of percpu variables.  When any net
> namespace happens to change one of the percpu variables to outside its
> small batch range, its count is moved to the net namespace's main count
> variable.  So with multiple net namespaces operating concurrently, the
> dst_ops entries counter can stray from the actual value that it should
> be; if counts are consistently moved from one net namespace to another
> (which my testing showed is likely), then one net namespace winds up
> with a negative dst_ops count (which is reported as 0) while another
> winds up with a continually increasing count, eventually reaching its
> gc_thresh limit, which causes all new traffic on the net namespace to
> fail with -ENOBUFS.
>
> This removes the dst_entries_init (and dst_entries_destroy) call for
> the template dst_ops objects; their counters will never be used.
> Instead dst_entries_init is called for each net namespace's dst_ops
> object, right after copying its values from the template, and

Well I'm not sure why my test kernel booted, while the test robot
found the bug of GFP_KERNEL percpu counter alloc during atomic
context.  Thanks test robot!

I'll update the patch and resend.


> dst_entries_destroy is called when the net namespace is removed.
>
> Signed-off-by: Dan Streetman 
> Signed-off-by: Dan Streetman 
> ---
>  net/ipv4/xfrm4_policy.c |  5 +++--
>  net/ipv6/xfrm6_policy.c | 10 --
>  net/xfrm/xfrm_policy.c  | 25 +++--
>  3 files changed, 30 insertions(+), 10 deletions(-)
>
> diff --git a/net/ipv4/xfrm4_policy.c b/net/ipv4/xfrm4_policy.c
> index f2606b9..5f747ee 100644
> --- a/net/ipv4/xfrm4_policy.c
> +++ b/net/ipv4/xfrm4_policy.c
> @@ -235,6 +235,9 @@ static void xfrm4_dst_ifdown(struct dst_entry *dst, 
> struct net_device *dev,
> xfrm_dst_ifdown(dst, dev);
>  }
>
> +/* This is used as a template only; the dst_entries counter is not
> + * initialized for this, but must be on per-net copies of this
> + */
>  static struct dst_ops xfrm4_dst_ops = {
> .family =   AF_INET,
> .gc =   xfrm4_garbage_collect,
> @@ -325,8 +328,6 @@ static void __init xfrm4_policy_init(void)
>
>  void __init xfrm4_init(void)
>  {
> -   dst_entries_init(_dst_ops);
> -
> xfrm4_state_init();
> xfrm4_policy_init();
> xfrm4_protocol_init();
> diff --git a/net/ipv6/xfrm6_policy.c b/net/ipv6/xfrm6_policy.c
> index 2cc5840..b895ec1 100644
> --- a/net/ipv6/xfrm6_policy.c
> +++ b/net/ipv6/xfrm6_policy.c
> @@ -279,6 +279,9 @@ static void xfrm6_dst_ifdown(struct dst_entry *dst, 
> struct net_device *dev,
> xfrm_dst_ifdown(dst, dev);
>  }
>
> +/* This is used as a template only; the dst_entries counter is not
> + * initialized for this, but must be on per-net copies of this
> + */
>  static struct dst_ops xfrm6_dst_ops = {
> .family =   AF_INET6,
> .gc =   xfrm6_garbage_collect,
> @@ -376,13 +379,9 @@ int __init xfrm6_init(void)
>  {
> int ret;
>
> -   dst_entries_init(_dst_ops);
> -
> ret = xfrm6_policy_init();
> -   if (ret) {
> -   dst_entries_destroy(_dst_ops);
> +   if (ret)
> goto out;
> -   }
> ret = xfrm6_state_init();
> if (ret)
> goto out_policy;
> @@ -411,5 +410,4 @@ void xfrm6_fini(void)
> xfrm6_protocol_fini();
> xfrm6_policy_fini();
> xfrm6_state_fini();
> -   dst_entries_destroy(_dst_ops);
>  }
> diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
> index 09bfcba..5381719 100644
> --- a/net/xfrm/xfrm_policy.c
> +++ b/net/xfrm/xfrm_policy.c
> @@ -2896,12 +2896,32 @@ static void __net_init xfrm_dst_ops_init(struct net 
> *net)
>
> rcu_read_lock();
> afinfo = rcu_dereference(xfrm_policy_afinfo[AF_INET]);
> -   if (afinfo)
> +   if (afinfo) {
> net->xfrm.xfrm4_dst_ops = *afinfo->dst_ops;
> +   dst_entries_init(>xfrm.xfrm4_dst_ops);
> +   }
>  #if IS_ENABLED(CONFIG_IPV6)
> 

Re: [PATCH V1 11/11] arm64, pci, acpi: Support for ACPI based PCI hostbridge init

[Liviu . Dudau]

On Wed, Oct 28, 2015 at 02:42:30PM +0100, Tomasz Nowicki wrote:
> On 28.10.2015 12:49, liviu.du...@arm.com wrote:
> >On Tue, Oct 27, 2015 at 05:38:42PM +0100, Tomasz Nowicki wrote:
> >>Because of two patch series:
> >>1. Jiang Liu's common interface to support PCI host bridge init
> >>2. Refactoring of MMCONFIG, part of this patch set
> >>now we can think about PCI buses enumeration for ARM64 and ACPI tables.
> >>
> >>This patch introduce ACPI based PCI hostbridge init calls which
> >>use information from MCFG table (PCI config space regions) and
> >>_CRS (IO/irq resources) to initialize PCI hostbridge.
> >>
> >>Signed-off-by: Tomasz Nowicki 
> >>Signed-off-by: Hanjun Guo 
> >>Signed-off-by: Suravee Suthikulpanit 
> >>CC: Arnd Bergmann 
> >>CC: Catalin Marinas 
> >>CC: Liviu Dudau 
> >>CC: Lorenzo Pieralisi 
> >>CC: Will Deacon 
> >>---
> >>  arch/arm64/Kconfig  |   6 ++
> >>  arch/arm64/kernel/pci.c | 208 
> >> +---
> >>  2 files changed, 202 insertions(+), 12 deletions(-)
> >>
> >>diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> >>index 07d1811..bbcc6b1 100644
> >>--- a/arch/arm64/Kconfig
> >>+++ b/arch/arm64/Kconfig
> >>@@ -89,6 +89,7 @@ config ARM64
> >>select SPARSE_IRQ
> >>select SYSCTL_EXCEPTION_TRACE
> >>select HAVE_CONTEXT_TRACKING
> >>+   select HAVE_PCI_ECAM
> >>help
> >>  ARM 64-bit (AArch64) Linux support.
> >>
> >>@@ -202,6 +203,11 @@ source "drivers/pci/Kconfig"
> >>  source "drivers/pci/pcie/Kconfig"
> >>  source "drivers/pci/hotplug/Kconfig"
> >>
> >>+config PCI_MMCONFIG
> >>+   def_bool y
> >>+   select PCI_ECAM
> >>+   depends on ACPI
> >>+
> >>  endmenu
> >>
> >>  menu "Kernel Features"
> >>diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> >>index b3d098b..66cc1ae 100644
> >>--- a/arch/arm64/kernel/pci.c
> >>+++ b/arch/arm64/kernel/pci.c
> >>@@ -11,12 +11,15 @@
> >>   */
> >>
> >>  #include 
> >>+#include 
> >>  #include 
> >>  #include 
> >>  #include 
> >>  #include 
> >>+#include 
> >>  #include 
> >>  #include 
> >>+#include 
> >>  #include 
> >>
> >>  #include 
> >>@@ -52,35 +55,216 @@ int pcibios_enable_device(struct pci_dev *dev, int 
> >>mask)
> >>  }
> >>
> >>  /*
> >>- * Try to assign the IRQ number from DT when adding a new device
> >>+ * Try to assign the IRQ number from DT/ACPI when adding a new device
> >>   */
> >>  int pcibios_add_device(struct pci_dev *dev)
> >>  {
> >>-   dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
> >>+   if (acpi_disabled)
> >>+   dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
> >>+#ifdef CONFIG_ACPI
> >>+   else
> >>+   acpi_pci_irq_enable(dev);
> >>+#endif
> >>
> >>return 0;
> >>  }
> >>
> >>+#ifdef CONFIG_ACPI
> >>+int pcibios_root_bridge_prepare(struct pci_host_bridge *bridge)
> >>+{
> >>+   struct acpi_pci_root *root = bridge->bus->sysdata;
> >>+
> >>+   ACPI_COMPANION_SET(>dev, root->device);
> >>+   return 0;
> >>+}
> >>+
> >>+void pcibios_add_bus(struct pci_bus *bus)
> >>+{
> >>+   acpi_pci_add_bus(bus);
> >>+}
> >>+
> >>+void pcibios_remove_bus(struct pci_bus *bus)
> >>+{
> >>+   acpi_pci_remove_bus(bus);
> >>+}
> >>+
> >>+static int __init pcibios_assign_resources(void)
> >>+{
> >>+   if (acpi_disabled)
> >>+   return 0;
> >>+
> >>+   pci_assign_unassigned_resources();
> >>+   return 0;
> >
> >You can change this function into:
> >{
> > if (!acpi_disabled)
> > pci_assign_unassigned_resources();
> >
> > return 0;
> >}
> >
> >as the equivalent but shorter form.
> 
> Sure, will do.
> 
> >
> >>+}
> >>  /*
> >>- * raw_pci_read/write - Platform-specific PCI config space access.
> >>+ * rootfs_initcall comes after subsys_initcall and fs_initcall_sync,
> >>+ * so we know acpi scan and PCI_FIXUP_FINAL quirks have both run.
> >>   */
> >>-int raw_pci_read(unsigned int domain, unsigned int bus,
> >>- unsigned int devfn, int reg, int len, u32 *val)
> >
> >What happened with raw_pci_{read,write} ? Why do you remove them?
> 
> We do not need raw_pci_{read,write} any more, we will use empty
> raw_pci_{read,write} from mcfg.c introduced in patch 6/11.
> 
> I think this is another candidate to split up, first I will remove these
> raw_pci_{read,write} accessors and then introduce ACPI PCI hostbridge init,
> it will be easier to review, what do you think?

Yes, I like that. If the calls were redundant after 6/11 then they should
not have been kept until this patch to be removed.

> 
> >
> >
> >>+rootfs_initcall(pcibios_assign_resources);
> >
> >Would you be so kind and explain to me why you need this initcall?
> >Can you not set the PCI_REASSIGN_ALL_RSRC flag before calling
> >pci_scan_root_bus() ?
> >
> >I haven't focused on ACPI before so I'm a bit hazy on the init order when
> >that is enabled. That being said, I don't like 

[PATCH 3.12 026/123] windfarm: decrement client count when unregistering

[Jiri Slaby]

From: Paul Bolle 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit fe2b592173ff0274e70dc44d1d28c19bb995aa7c upstream.

wf_unregister_client() increments the client count when a client
unregisters. That is obviously incorrect. Decrement that client count
instead.

Fixes: 75722d3992f5 ("[PATCH] ppc64: Thermal control for SMU based machines")

Signed-off-by: Paul Bolle 
Signed-off-by: Michael Ellerman 
Signed-off-by: Jiri Slaby 
---
 drivers/macintosh/windfarm_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/macintosh/windfarm_core.c 
b/drivers/macintosh/windfarm_core.c
index 3ee198b65843..cc7ece1712b5 100644
--- a/drivers/macintosh/windfarm_core.c
+++ b/drivers/macintosh/windfarm_core.c
@@ -435,7 +435,7 @@ int wf_unregister_client(struct notifier_block *nb)
 {
mutex_lock(_lock);
blocking_notifier_chain_unregister(_client_list, nb);
-   wf_client_count++;
+   wf_client_count--;
if (wf_client_count == 0)
wf_stop_thread();
mutex_unlock(_lock);
-- 
2.6.2

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

Re: [PATCH v3 2/5] mfd: sec: Add support for S2MPS15 PMIC

[Alim Akhtar]

Hello,

On 10/28/2015 02:16 PM, Lee Jones wrote:

On Wed, 28 Oct 2015, Krzysztof Kozlowski wrote:


On 26.10.2015 23:34, Lee Jones wrote:

On Mon, 26 Oct 2015, Alim Akhtar wrote:


From: Thomas Abraham 

Add support for S2MPS15 PMIC which is similar to S2MPS11 PMIC. The S2MPS15
PMIC supports 27 LDO regulators, 10 buck regulators, RTC, three 32.768KHz
clock outputs and battery charger. This patch adds initial support for
LDO and buck regulators of S2MPS15 device.

Signed-off-by: Thomas Abraham 
Signed-off-by: Alim Akhtar 
[Alim: Added s2mps15_devs like rtc and clk and related changes]
Reviewed-by: Krzysztof Kozlowski 
---
  drivers/mfd/sec-core.c  |   31 +++
  drivers/mfd/sec-irq.c   |8 ++
  include/linux/mfd/samsung/core.h|1 +
  include/linux/mfd/samsung/s2mps15.h |  158 +++
  4 files changed, 198 insertions(+)
  create mode 100644 include/linux/mfd/samsung/s2mps15.h


I replied to the previous set and won't be reviewing this one until
all of the open points are solved.


The naming and compatibles used by the driver are confusing but how it
was at beginning. Beside the confusion, the names are correct:

1. Main mfd driver:
  - compatible: samsung,s2mps1*-pmic
  - driver name: sec_pmic

2. Regulator driver:
  - no compatible (because it always searches for "regulators" subnode of
its parent... that is the convention/legacy behaviour)
  - driver name: s2mps1*-pmic

I hope that explains your concerns.


It explains *why*, but doesn't ease my concerns in any way.

Unfortunately I've only just realised the disparity we have between
MFD and the Regulator subsystem, which is annoying because it's now
almost impossible to rectify.

We should have taken one of two views.  Either a) The MFD is the PMIC
device which encompasses regulator control.  In which case the MFD
and it's corresponding compatible string would be named *-pmic and the
regulator driver would be called *-regulator. Or b) The MFD could be
considered a normal MFD and be named after the model number, then the
regulator 'could' be named *-pmic.

However, with reference to b), how much other Power Management does
the regulator driver do besides control regulators?  I suspect not
much.  Therefore my preference would be for a).  My second choice
would be a mixuture of the two where nothing gets named *-pmic.  The
last option on my list would be the current situation where we seem to
be calling both the MFD (PMIC) itself and the Regulator driver
*-pmic, which is not good.

Well, I would have also preferred option a), but keeping existing DT 
bindings, looks like we need to go with the current situation.

Krzysztof any thought on this?


diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
index 2626fc0b5b8c..db3d4d4ff805 100644
--- a/drivers/mfd/sec-core.c
+++ b/drivers/mfd/sec-core.c
@@ -29,6 +29,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -96,6 +97,17 @@ static const struct mfd_cell s2mps14_devs[] = {
}
  };

+static const struct mfd_cell s2mps15_devs[] = {
+   {
+   .name = "s2mps15-pmic",
+   }, {
+   .name = "s2mps15-rtc",
+   }, {
+   .name = "s2mps15-clk",
+   .of_compatible = "samsung,s2mps15-clk",
+   },
+};
+
  static const struct mfd_cell s2mpa01_devs[] = {
{
.name = "s2mpa01-pmic",
@@ -125,6 +137,9 @@ static const struct of_device_id sec_dt_match[] = {
.compatible = "samsung,s2mps14-pmic",
.data = (void *)S2MPS14X,
}, {
+   .compatible = "samsung,s2mps15-pmic",
+   .data = (void *)S2MPS15X,
+   }, {
.compatible = "samsung,s2mpa01-pmic",
.data = (void *)S2MPA01,
}, {
@@ -226,6 +241,15 @@ static const struct regmap_config s2mps14_regmap_config = {
.cache_type = REGCACHE_FLAT,
  };

+static const struct regmap_config s2mps15_regmap_config = {
+   .reg_bits = 8,
+   .val_bits = 8,
+
+   .max_register = S2MPS15_REG_LDODSCH4,
+   .volatile_reg = s2mps11_volatile,
+   .cache_type = REGCACHE_FLAT,
+};
+
  static const struct regmap_config s2mpu02_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
@@ -387,6 +411,9 @@ static int sec_pmic_probe(struct i2c_client *i2c,
case S2MPS14X:
regmap = _regmap_config;
break;
+   case S2MPS15X:
+   regmap = _regmap_config;
+   break;
case S5M8763X:
regmap = _regmap_config;
break;
@@ -445,6 +472,10 @@ static int sec_pmic_probe(struct i2c_client *i2c,
sec_devs = s2mps14_devs;
num_sec_devs = ARRAY_SIZE(s2mps14_devs);
break;
+   case S2MPS15X:
+   sec_devs = s2mps15_devs;
+   

RE: [RFC PATCH 1/2] usb: doc: Add bindings for ULPI platform driver

[Subbaraya Sundeep Bhatta]

Hi Kishon,

> -Original Message-
> From: Kishon Vijay Abraham I [mailto:kis...@ti.com]
> Sent: Sunday, October 11, 2015 8:11 PM
> To: Punnaiah Choudary Kalluri; ba...@ti.com
> Cc: Rob Herring; Subbaraya Sundeep Bhatta; Peter Chen;
> devicet...@vger.kernel.org; gre...@linuxfoundation.org; linux-
> u...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org
> Subject: Re: [RFC PATCH 1/2] usb: doc: Add bindings for ULPI platform driver
> 
> Hi,
> 
> On Sunday 11 October 2015 04:45 PM, punnaiah choudary kalluri wrote:
> > On Wed, Sep 30, 2015 at 9:48 PM, Felipe Balbi  wrote:
> >> On Thu, Sep 24, 2015 at 11:18:01AM -0500, Rob Herring wrote:
> >>> On Thu, Sep 24, 2015 at 4:26 AM, Subbaraya Sundeep Bhatta
> >>>  wrote:
>  Hi Peter,
> 
> > -Original Message-
> > From: Peter Chen [mailto:peter.c...@freescale.com]
> > Sent: Thursday, September 24, 2015 2:41 PM
> > To: Subbaraya Sundeep Bhatta
> > Cc: ba...@ti.com; devicet...@vger.kernel.org; kis...@ti.com;
> > gre...@linuxfoundation.org; linux-...@vger.kernel.org; linux-
> > ker...@vger.kernel.org; Punnaiah Choudary Kalluri; Subbaraya
> > Sundeep Bhatta; linux-arm-ker...@lists.infradead.org
> > Subject: Re: [RFC PATCH 1/2] usb: doc: Add bindings for ULPI
> > platform driver
> >
> > On Wed, Sep 23, 2015 at 06:24:01PM +0530, Subbaraya Sundeep
> Bhatta
> > wrote:
> >> This patch adds binding doc info for generic ULPI PHYs platform
> >> driver.
> >>
> >> Signed-off-by: Subbaraya Sundeep Bhatta 
> >> ---
> >>  .../devicetree/bindings/usb/ulpi-platform-phy.txt  |   34
> > 
> >>  1 files changed, 34 insertions(+), 0 deletions(-)  create mode
> >> 100644
> >> Documentation/devicetree/bindings/usb/ulpi-platform-phy.txt
> >>
> >> diff --git
> >> a/Documentation/devicetree/bindings/usb/ulpi-platform-phy.txt
> >> b/Documentation/devicetree/bindings/usb/ulpi-platform-phy.txt
> >> new file mode 100644
> >> index 000..7b8cbb4
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/usb/ulpi-platform-phy.txt
> >> @@ -0,0 +1,34 @@
> >> +Platform driver for generic ULPI PHYs
> >> +
> >> +Required properties:
> >> +- compatible   : Should be "ulpi-phy"
> >> +- reg  : Physical base address and size of the USB
> >> + controller registers map to which this PHY
> >> + is connected.
> >> +- view-port: Should contain viewport register offset 
> >> of the
> >> + USB controller to which this PHY is
> >> +connected Optional
> >> +properties:
> >> +- drv-vbus : required if turning VBUS on/off has to be driven
> >> + by writing to PHY. This feature depends on board
> >> + design.
> >> +
> >> +Example:
> >> +Below example shows the PHY binding for Chipidea USB controller
> >> +which has ulpi viewport register at 0x0170
> >> +
> >> +   usb_phy0: phy0 {
> >> +   compatible = "ulpi-phy";
> >> +   reg = <0xe0002000 0x1000>;
> >> +   view-port = <0x0170>;
> >> +   drv-vbus;
> >> +   };
> >> +
> >> +   usb0: usb@e0002000 {
> >> +compatible = "chipidea,usb2";
> >> +interrupt-parent = <>;
> >> +interrupts = <0 21 4>;
> >> +reg = <0xe0002000 0x1000>;
> >
> > Although just call devm_ioremap twice for the same register region
> > does not cause any errors, I am not sure if it will has other
> > potential problems. Cc: arm list.
> 
>  Yes Peter I was also in doubt to call devm_ioremap twice for same 
>  register
> region.
>  devm_ioremap_resource complained hence modified to devm_ioremap.
>  Thanks for adding arm-list.
> >>>
> >>> Don't put overlapping resources in the DT. Having 2 drivers
> >>> accessing the same registers is not a clean or safe design.
> >>
> >> thanks, saves me the trouble of saying the same thing.
> >>
> >> Bottom line, if devm_ioremap_resource() fails, you're wrong. Just fix
> >> your driver and move on.
> >
> > Any suggestions on how to move further?
> > Chipidea controller provides ulpi view port register for accessing the
> > usb phy registers. Now we want to add new driver for ulpi phy
> > configuration and that obviously it need of ulpi view port register
> > access. So, sharing the register space between these two drivers is 
> > necessary
> here.
> 
> Why not program ULPI the same way as DWC3 does?

Sorry for delay in response, back from long vacation.
Can we call generic PHY phy->power_on and power_off 

Re: [PATCH v5] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

[Bjorn Helgaas]

On Wed, Oct 28, 2015 at 10:17:22AM +, Bharat Kumar Gogada wrote:
> > On Mon, Oct 26, 2015 at 08:26:26PM +0530, Bharat Kumar Gogada wrote:
> > > Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP.
> 
> > > +
> > > + while ((status = nwl_bridge_readl(pcie, MSGF_MSI_STATUS_LO)) !=
> > 0) {
> > > + for_each_set_bit(bit, , 32) {
> > > + nwl_bridge_writel(pcie, 1 << bit,
> > MSGF_MSI_STATUS_LO);
> > > + virq = irq_find_mapping(msi->dev_domain, bit);
> > > + if (virq)
> > > + generic_handle_irq(virq);
> > > + }
> > > + }
> > > +
> > > + chained_irq_exit(chip, desc);
> > > +}
> > 
> > These are basically identical.  Can you factor them out somehow to avoid
> > repeating the code?
> 
> Is it okay if irq_set_chained_handler_and_data being invoked with two 
> different interrupt numbers, but pointing to 
> same interrupt handler?

Yes, that should be fine.

> > > +
> > > + pcie->legacy_irq_domain =
> > irq_domain_add_linear(legacy_intc_node, 4,
> > > +
> > _domain_ops,
> > > + pcie);
> > > +
> > > + if (!pcie->legacy_irq_domain) {
> > > + dev_err(pcie->dev, "failed to create IRQ domain\n");
> > > + return -ENOMEM;
> > > + }
> > > +
> > > +#ifdef CONFIG_PCI_MSI
> > > + msi->dev_domain = irq_domain_add_linear(NULL,
> > INT_PCI_MSI_NR,
> > > + _msi_domain_ops, pcie);
> > > + if (!msi->dev_domain) {
> > > + dev_err(pcie->dev, "failed to create dev IRQ domain\n");
> > > + return -ENOMEM;
> > > + }
> > > + msi->msi_chip.domain = pci_msi_create_irq_domain(node,
> > > +
> > _msi_domain_info,
> > > + msi->dev_domain);
> > > + if (!msi->msi_chip.domain) {
> > > + dev_err(pcie->dev, "failed to create msi IRQ domain\n");
> > > + irq_domain_remove(msi->dev_domain);
> > > + return -ENOMEM;
> > > + }
> > > +#endif
> > > + return 0;
> > > +}
> > > +
> > > +static int nwl_pcie_enable_msi(struct nwl_pcie *pcie, struct pci_bus
> > > +*bus) {
> > 
> > It looks strange to have all the "#ifdef CONFIG_PCI_MSI" above, and here
> > we have this long MSI-related function without any ifdefs around it.  Seems
> > like this should be ifdef'ed also?  What about nwl_pcie_msi_handler_high(),
> > nwl_pcie_msi_handler_low(), nwl_compose_msi_msg(),
> > nwl_msi_set_affinity(), etc.?
> > 
> In probe I'm invoking "nwl_pcie_enable_msi" using "if 
> (IS_ENABLED(CONFIG_PCI_MSI)) " check, since this is at run time 
> I haven't kept above mentioned functions under #ifdef CONFIG_PCI_MSI.
> The above MSI domain allocation was under ifdef, since if driver was compiled 
> for legacy some of the MSI hierarchy API's and structures aren't available.

OK.  It *looks* strange, but maybe it's the best we can do.  I'm not
enamored of IS_ENABLED() thing yet; I guess I just haven't
internalized the combination compile-time and run-time behavior.

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

Re: [PATCH v4 11/11] scsi: ufs-exynos: add UFS host support for Exynos SoCs

[Kishon Vijay Abraham I]

Hi,

On Sunday 25 October 2015 05:34 PM, Alim Akhtar wrote:
> Hi Kishon
> Thanks again for you review.
> 
> On Fri, Oct 23, 2015 at 8:48 PM, Kishon Vijay Abraham I  wrote:
>> Hi,
>>
>> On Thursday 15 October 2015 08:38 AM, Alim Akhtar wrote:
>>> +CCing kishon Vijay,
>>>
>>> On 10/14/2015 06:25 PM, Alim Akhtar wrote:
 From: Seungwon Jeon 

 This patch introduces Exynos UFS host controller driver,
 which mainly handles vendor-specific operations including
 link startup, power mode change and hibernation/unhibernation.

 Signed-off-by: Seungwon Jeon 
 Signed-off-by: Alim Akhtar 
 ---
   drivers/scsi/ufs/Kconfig |   12 +
   drivers/scsi/ufs/Makefile|1 +
   drivers/scsi/ufs/ufs-exynos-hw.c |  131 
   drivers/scsi/ufs/ufs-exynos-hw.h |   43 ++
   drivers/scsi/ufs/ufs-exynos.c| 1317
 ++
   drivers/scsi/ufs/ufs-exynos.h|  247 +++
   drivers/scsi/ufs/ufshci.h|   26 +-
   drivers/scsi/ufs/unipro.h|   47 ++
   8 files changed, 1823 insertions(+), 1 deletion(-)
   create mode 100644 drivers/scsi/ufs/ufs-exynos-hw.c
   create mode 100644 drivers/scsi/ufs/ufs-exynos-hw.h
   create mode 100644 drivers/scsi/ufs/ufs-exynos.c
   create mode 100644 drivers/scsi/ufs/ufs-exynos.h

>> .
>> .
>> 
>> .
>> .
 diff --git a/drivers/scsi/ufs/ufs-exynos-hw.c
 b/drivers/scsi/ufs/ufs-exynos-hw.c
 new file mode 100644
 index ..be6c61541a8f
 --- /dev/null
 +++ b/drivers/scsi/ufs/ufs-exynos-hw.c
 @@ -0,0 +1,131 @@
>> .
>> .
>> 
>> .
>> .
 +
 +#define PWR_MODE_STR_LEN64
 +static int exynos_ufs_post_pwr_mode(struct ufs_hba *hba,
 +struct ufs_pa_layer_attr *pwr_max,
 +struct ufs_pa_layer_attr *pwr_req)
 +{
 +struct exynos_ufs *ufs = to_exynos_ufs(hba);
 +struct exynos_ufs_phy_info *phy_info = phy_get_drvdata(ufs->phy);
>>
>> This is abusing the interface. phy_get_drvdata is meant to be used only
>> by the PHY driver.
 +struct exynos_ufs_phy_specific_ops *phy_ops =
 +phy_info->phy_specific_ops;
>>
>> I'm really not happy about having platform specific ops for PHY. We have
>> to see if existing PHY ops can be used for this or in worst case add new
>> PHY ops.
> Well you said you like the controller driver to use only PHY ops[1], I
> am sorry If I misunderstood that point, can you please help me to
> understand that?

I meant PHY generic ops and not PHY ops.
> [1]-> https://lkml.org/lkml/2015/9/18/29
> 
 +struct uic_pwr_mode *pwr = >pwr_act;
 +char pwr_str[PWR_MODE_STR_LEN] = "";
 +int ret = 0;
 +
 +if (ufs->drv_data->post_pwr_change)
 +ufs->drv_data->post_pwr_change(ufs, pwr);
 +
 +if (IS_UFS_PWR_MODE_HS(pwr->mode)) {
 +switch (pwr->hs_series) {
 +case PA_HS_MODE_A:
 +case PA_HS_MODE_B:
 +phy_ops->calibrate_phy(ufs->phy, CFG_POST_PWR_HS,
 +PWR_MODE_HS(pwr->gear, pwr->hs_series));
 +break;
 +}
 +
 +ret = phy_ops->wait_for_lock_acq(ufs->phy);
 +snprintf(pwr_str, sizeof(pwr_str), "Fast%s series_%s G_%d L_%d",
 +pwr->mode == FASTAUTO_MODE ? "_Auto" : "",
 +pwr->hs_series == PA_HS_MODE_A ? "A" : "B",
 +pwr->gear, pwr->lane);
 +} else if (IS_UFS_PWR_MODE_PWM(pwr->mode)) {
 +snprintf(pwr_str, sizeof(pwr_str), "Slow%s G_%d L_%d",
 +pwr->mode == SLOWAUTO_MODE ? "_Auto" : "",
 +pwr->gear, pwr->lane);
 +}
 +
 +dev_info(hba->dev, "Power mode change %d : %s\n", ret, pwr_str);
 +return ret;
 +}
 +
 +static void exynos_ufs_specify_nexus_t_xfer_req(struct ufs_hba *hba,
 +int tag, struct scsi_cmnd *cmd)
 +{
 +struct exynos_ufs *ufs = to_exynos_ufs(hba);
 +u32 type;
 +
 +type =  hci_readl(ufs, HCI_UTRL_NEXUS_TYPE);
 +
 +if (cmd)
 +hci_writel(ufs, type | (1 << tag), HCI_UTRL_NEXUS_TYPE);
 +else
 +hci_writel(ufs, type & ~(1 << tag), HCI_UTRL_NEXUS_TYPE);
 +}
 +
 +static void exynos_ufs_specify_nexus_t_tm_req(struct ufs_hba *hba,
 +int tag, u8 func)
 +{
 +struct exynos_ufs *ufs = to_exynos_ufs(hba);
 +u32 type;
 +
 +type =  hci_readl(ufs, HCI_UTMRL_NEXUS_TYPE);
 +
 +switch (func) {
 +case UFS_ABORT_TASK:
 +case UFS_QUERY_TASK:
 +hci_writel(ufs, type | (1 << tag), HCI_UTMRL_NEXUS_TYPE);
 +break;
 +case UFS_ABORT_TASK_SET:
 +case UFS_CLEAR_TASK_SET:
 +case UFS_LOGICAL_RESET:
 +case 

Re: [PATCH 0/2] perf: we can now read separate debug-info files based on a build ID

[Arnaldo Carvalho de Melo]

Em Tue, Oct 27, 2015 at 07:50:41PM -0700, Dima Kogan escreveu:
> Hi. I'd like to get this merged before I forget about it and then I hit


Hey, me too! But you forgot to ask me to :-) I.e. please CC whoever is
listed in the MAINTAINERS file, also please next time use 'git
format-patch' when sending patches, and don't attach the patches, so
that I can use 'git am' on them.

Anyway, thanks for the patches, I am going thru them now.

- Arnaldo


> this bug again at some point in the future. Any comment would be great.
> 
> Thanks!
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/8] Staging: rtl8192u: ieee80211: added missing space around '='

[Kurt Kanzenbach]

This patch fixes the following checkpatch error:
  - ERROR: spaces required around that '='

Signed-off-by: Kurt Kanzenbach 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
index 8091f49..6c48df1 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
@@ -360,7 +360,7 @@ static int ieee80211_tkip_encrypt(struct sk_buff *skb, int 
hdr_len, void *priv)
icv[3] = crc >> 24;
crypto_blkcipher_setkey(tkey->tx_tfm_arc4, rc4key, 16);
sg_init_one(, pos, len+4);
-   ret= crypto_blkcipher_encrypt(, , , len + 4);
+   ret = crypto_blkcipher_encrypt(, , , len + 4);
}
 
tkey->tx_iv16++;
-- 
2.4.10

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

[PATCH 5/8] Staging: rtl8192u: ieee80211: corrected indent

[Kurt Kanzenbach]

This patch corrects the indentation in five instances in the
ieee80211_crypt_tkip.c file.

Signed-off-by: Kurt Kanzenbach 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
index 06def48..bf71501 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
@@ -303,7 +303,7 @@ static void tkip_mixing_phase2(u8 *WEPSeed, const u8 *TK, 
const u16 *TTAK,
 static int ieee80211_tkip_encrypt(struct sk_buff *skb, int hdr_len, void *priv)
 {
struct ieee80211_tkip_data *tkey = priv;
-   int len;
+   int len;
u8 *pos;
struct rtl_80211_hdr_4addr *hdr;
cb_desc *tcb_desc = (cb_desc *)(skb->cb + MAX_DEV_ADDR_SIZE);
@@ -322,12 +322,12 @@ static int ieee80211_tkip_encrypt(struct sk_buff *skb, 
int hdr_len, void *priv)
if (!tcb_desc->bHwSec) {
if (!tkey->tx_phase1_done) {
tkip_mixing_phase1(tkey->tx_ttak, tkey->key, hdr->addr2,
-   tkey->tx_iv32);
+  tkey->tx_iv32);
tkey->tx_phase1_done = 1;
}
tkip_mixing_phase2(rc4key, tkey->key, tkey->tx_ttak, 
tkey->tx_iv16);
} else
-   tkey->tx_phase1_done = 1;
+   tkey->tx_phase1_done = 1;
 
 
len = skb->len - hdr_len;
@@ -598,7 +598,7 @@ static void ieee80211_michael_mic_failure(struct net_device 
*dev,
 }
 
 static int ieee80211_michael_mic_verify(struct sk_buff *skb, int keyidx,
-int hdr_len, void *priv)
+   int hdr_len, void *priv)
 {
struct ieee80211_tkip_data *tkey = priv;
u8 mic[8];
@@ -618,7 +618,7 @@ static int ieee80211_michael_mic_verify(struct sk_buff 
*skb, int keyidx,
// }
 
if (michael_mic(tkey->rx_tfm_michael, >key[24], tkey->rx_hdr,
-   skb->data + hdr_len, skb->len - 8 - hdr_len, 
mic))
+   skb->data + hdr_len, skb->len - 8 - hdr_len, mic))
return -1;
if (memcmp(mic, skb->data + skb->len - 8, 8) != 0) {
struct rtl_80211_hdr_4addr *hdr;
-- 
2.4.10

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

[PATCH 2/8] Staging: rtl8192u: ieee80211: fixed position of else statements

[Kurt Kanzenbach]

This patch fixes the following checkpatch error:
  - ERROR: else should follow close brace '}'

Signed-off-by: Kurt Kanzenbach 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
index dd058b6..8091f49 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
@@ -326,8 +326,7 @@ static int ieee80211_tkip_encrypt(struct sk_buff *skb, int 
hdr_len, void *priv)
tkey->tx_phase1_done = 1;
}
tkip_mixing_phase2(rc4key, tkey->key, tkey->tx_ttak, 
tkey->tx_iv16);
-   }
-   else
+   } else
tkey->tx_phase1_done = 1;
 
 
@@ -340,8 +339,7 @@ static int ieee80211_tkip_encrypt(struct sk_buff *skb, int 
hdr_len, void *priv)
*pos++ = Hi8(tkey->tx_iv16);
*pos++ = (Hi8(tkey->tx_iv16) | 0x20) & 0x7F;
*pos++ = Lo8(tkey->tx_iv16);
-   }
-   else {
+   } else {
*pos++ = rc4key[0];
*pos++ = rc4key[1];
*pos++ = rc4key[2];
-- 
2.4.10

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

[PATCH 0/8] Staging: rtl8192u: ieee80211: checkpatch cleanups

[Kurt Kanzenbach]

This patch series corrects most checkpatch.pl errors and some warnings in
the ieee80211_crypt_tkip.c file.

Kurt Kanzenbach (8):
  Staging: rtl8192u: ieee80211: fixed open brace positions
  Staging: rtl8192u: ieee80211: fixed position of else statements
  Staging: rtl8192u: ieee80211: added missing space around '='
  Staging: rtl8192u: ieee80211: added missing spaces after if
  Staging: rtl8192u: ieee80211: corrected indent
  Staging: rtl8192u: ieee80211: corrected block comments
  Staging: rtl8192u: ieee80211: removed unnecessary braces
  Staging: rtl8192u: ieee80211: added missing blank lines

 .../rtl8192u/ieee80211/ieee80211_crypt_tkip.c  | 76 --
 1 file changed, 41 insertions(+), 35 deletions(-)

-- 
2.4.10

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

[PATCH v5 2/7] vfio: platform: add capability to register a reset function

[Eric Auger]

In preparation for subsequent changes in reset function lookup,
lets introduce a dynamic list of reset combos (compat string,
reset module, reset function). The list can be populated/voided with
vfio_platform_register/unregister_reset. Those are not yet used in
this patch.

Signed-off-by: Eric Auger 
Reviewed-by: Arnd Bergmann 

---

v4 -> v5:
- add Arnd's R-b

v3 -> v4:
- __vfio_platform_register_reset does not return any value anymore
- vfio_platform_unregister_reset also takes the reset function pointer
  as parameter

v2 -> v3:
- use goto out to have a single mutex_unlock
- implement vfio_platform_register_reset as a macro (suggested by Arnd)
- move reset_node struct declaration back to vfio_platform_private.h
- vfio_platform_unregister_reset does not return any value anymore

v1 -> v2:
- reset_list becomes static
- vfio_platform_register/unregister_reset take a const char * as compat
- fix node leak
- add reset_lock to protect the reset list manipulation
- move vfio_platform_reset_node declaration in vfio_platform_common.c
---
 drivers/vfio/platform/vfio_platform_common.c  | 27 +++
 drivers/vfio/platform/vfio_platform_private.h | 20 
 2 files changed, 47 insertions(+)

diff --git a/drivers/vfio/platform/vfio_platform_common.c 
b/drivers/vfio/platform/vfio_platform_common.c
index 184e9d2..3b7e52c 100644
--- a/drivers/vfio/platform/vfio_platform_common.c
+++ b/drivers/vfio/platform/vfio_platform_common.c
@@ -27,6 +27,7 @@
 #define DRIVER_AUTHOR   "Antonios Motakis "
 #define DRIVER_DESC "VFIO platform base module"
 
+static LIST_HEAD(reset_list);
 static DEFINE_MUTEX(driver_lock);
 
 static const struct vfio_platform_reset_combo reset_lookup_table[] = {
@@ -578,6 +579,32 @@ struct vfio_platform_device 
*vfio_platform_remove_common(struct device *dev)
 }
 EXPORT_SYMBOL_GPL(vfio_platform_remove_common);
 
+void __vfio_platform_register_reset(struct vfio_platform_reset_node *node)
+{
+   mutex_lock(_lock);
+   list_add(>link, _list);
+   mutex_unlock(_lock);
+}
+EXPORT_SYMBOL_GPL(__vfio_platform_register_reset);
+
+void vfio_platform_unregister_reset(const char *compat,
+   vfio_platform_reset_fn_t fn)
+{
+   struct vfio_platform_reset_node *iter, *temp;
+
+   mutex_lock(_lock);
+   list_for_each_entry_safe(iter, temp, _list, link) {
+   if (!strcmp(iter->compat, compat) && (iter->reset == fn)) {
+   list_del(>link);
+   break;
+   }
+   }
+
+   mutex_unlock(_lock);
+
+}
+EXPORT_SYMBOL_GPL(vfio_platform_unregister_reset);
+
 MODULE_VERSION(DRIVER_VERSION);
 MODULE_LICENSE("GPL v2");
 MODULE_AUTHOR(DRIVER_AUTHOR);
diff --git a/drivers/vfio/platform/vfio_platform_private.h 
b/drivers/vfio/platform/vfio_platform_private.h
index 7128690..c563940 100644
--- a/drivers/vfio/platform/vfio_platform_private.h
+++ b/drivers/vfio/platform/vfio_platform_private.h
@@ -71,6 +71,15 @@ struct vfio_platform_device {
int (*reset)(struct vfio_platform_device *vdev);
 };
 
+typedef int (*vfio_platform_reset_fn_t)(struct vfio_platform_device *vdev);
+
+struct vfio_platform_reset_node {
+   struct list_head link;
+   char *compat;
+   struct module *owner;
+   vfio_platform_reset_fn_t reset;
+};
+
 struct vfio_platform_reset_combo {
const char *compat;
const char *reset_function_name;
@@ -90,4 +99,15 @@ extern int vfio_platform_set_irqs_ioctl(struct 
vfio_platform_device *vdev,
unsigned start, unsigned count,
void *data);
 
+extern void __vfio_platform_register_reset(struct vfio_platform_reset_node *n);
+extern void vfio_platform_unregister_reset(const char *compat,
+  vfio_platform_reset_fn_t fn);
+#define vfio_platform_register_reset(__compat, __reset)\
+static struct vfio_platform_reset_node __reset ## _node = {\
+   .owner = THIS_MODULE,   \
+   .compat = __compat, \
+   .reset = __reset,   \
+}; \
+__vfio_platform_register_reset(&__reset ## _node)
+
 #endif /* VFIO_PLATFORM_PRIVATE_H */
-- 
1.9.1

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

Re: [PATCH] MAINTAINERS: Start using the 'reviewer' (R) tag

[Javier Martinez Canillas]

Hello Lee,

On Wed, Oct 28, 2015 at 1:14 PM, Lee Jones  wrote:
> On Wed, 28 Oct 2015, Lee Jones wrote:
>
>> On Wed, 28 Oct 2015, Javier Martinez Canillas wrote:
>>
>> > Hello Joe,
>> >
>> > On Wed, Oct 28, 2015 at 12:06 PM, Joe Perches  wrote:
>> > > On Wed, 2015-10-28 at 11:53 +0100, Javier Martinez Canillas wrote:
>> > >> (Lee) think(s) that the difference between a maintainer and
>> > >> a reviewer is if a branch with fixes / new features are kept and pull
>> > >> requests sent while I think that the difference is the level of
>> > >> involvement someone has with a driver regardless of how patches ends
>> > >> in the subsystem tree (picked directly by subsystem maintainers or
>> > >> sent through pull requests).
>> > >>
>> > >> Is the first time I heard your definition but maybe I'm the one that
>> > >> is wrong so it would be great to get a consensus on that and get it
>> > >> documented somewhere.
>> > >
>> > > I think Lee is over-analyzing.
>> > >
>> > > From MAINTAINERS:
>> > > M: Mail patches to: FullName 
>> > > R: Designated reviewer: FullName 
>> > >These reviewers should be CCed on patches.
>> > > S: Status, one of the following:
>> > >Supported:   Someone is actually paid to look after this.
>> > >Maintained:  Someone actually looks after it.
>> > >
>> > > "looking after" doesn't mean upstreaming.
>> > >
>> >
>> > Agreed and upstreaming doesn't mean sending pull request, you can for
>> > example upstream the downstream changes for a driver you maintain by
>> > posting patches or ack patches others post and let the subsystem
>> > maintainer to pick those (even if you are listed as the driver
>> > maintainer in MAINTAINERS).
>> >
>> > So by following Lee's definition, then most drivers' maintainers
>> > should not be called maintainers since keeping a tree with patches for
>> > both fixes and new features, sending pull requests, etc is only
>> > justified for drivers that have a lot of changes per release. Is not
>> > worth it for drivers that are in "maintenance mode" where only bugs
>> > are fixed every once in a while or features are seldom added.
>>
>> Exactly right.
>>
>> Although, it looks like M: doesn't even mean Maintainer.  If it did, I
>> would have made these points over and over until death (or until I got
>> bored).  However, as M: actually means "Mail patches to", there seems
>> to be very little difference between that and "Designated reviewer"
>> and makes me wonder why the R: tag was ever even introduced.  I guess
>> all of the other guys in the threads below also thought M: meant
>> Maintainer, or else they would have just added poor old Josh as a
>> "Mail patches to" recipient and been done with it.
>
> Ah, but wait.  get_maintainer.pl *does* assume M means Maintainer
> doesn't it?  Which is why this came about.  So if we have a "Mail
> patches to" entry, get_maintainer.pl tells the user that this is a

Joe already answered but I'll elaborate a little bit:

"M:" means "Mail patches to" and "S:" means "Status" so what
get_maintainers.pl is reports the person in "M:" printing the status
of the file(s).

So for example if the file has "S: Supported" then the person listed
in "M:" is shown as "supporter" while if the status is "S:
Maintained", the person is listed as "maintainer".

There isn't a "Reviewed" status to specify files that are looked by
"Designated reviewers", it can be added but I don't see the reason of
it.

> Maintainer, which (given that there are over 1000 unique M: entries
> and I know that there are no where near that many actual Maintainers)
> means that it's printing out incorrect information most of the time.
>

Well, that's correct according to your definition of maintainer
(people with a tree that sends pull requests) but I can believe that
there are 1K unique maintainers for different small components
(without taking into account what components may be obsolete / not
used anymore) even if these maintainers don't send pull request
because the patch load is low and rely on subsystem maintainers to
pick directly from the list with their Acks.

For me the maintainer is that a) cares about the file and makes sure
that things remain working, fix issues, reviews patches from others,
etc b) is someone that actually understand the code in the files. A
subsystem maintainer has the last word of what gets merged into the
subsystem but may not be familiar with code under the subsystem and
relies on the file / driver maintainer to Ack the patch as correct
since that person is the one that knows the code.

> So back to my original thought then, what can we do to rectify this
> situation and make the information printed more meaningful.  Again,
> I'm back to using the R: tag appropriately.
>
> Any (technical, which aren't based on "but I really want to be listed
> as a Maintainer") thoughts?
>

I haven't read a "but I really want to be 

[PATCH v4] VFIO: platform: reset: AMD xgbe reset module

[Eric Auger]

This patch introduces a module that registers and implements a low-level
reset function for the AMD XGBE device.

it performs the following actions:
- reset the PHY
- disable auto-negotiation
- disable & clear auto-negotiation IRQ
- soft-reset the MAC

Those tiny pieces of code are inherited from the native xgbe driver.

Signed-off-by: Eric Auger 
Reviewed-by: Arnd Bergmann 

---

Applies on top of [PATCH v5 0/7] VFIO platform reset module rework

v3 -> v4:
- add Arnd's R-b

v2 -> v3:
- in Kconfig, add empty line between the 2 options
- remove DRIVER_VERSION, DRIVER_AUTHOR and DRIVER_DESC and put
  strings directly in MODULE macros

v1 -> v2:
- uses module_vfio_reset_handler macro
---
 drivers/vfio/platform/reset/Kconfig|   8 ++
 drivers/vfio/platform/reset/Makefile   |   2 +
 .../vfio/platform/reset/vfio_platform_amdxgbe.c| 127 +
 3 files changed, 137 insertions(+)
 create mode 100644 drivers/vfio/platform/reset/vfio_platform_amdxgbe.c

diff --git a/drivers/vfio/platform/reset/Kconfig 
b/drivers/vfio/platform/reset/Kconfig
index 746b96b..705 100644
--- a/drivers/vfio/platform/reset/Kconfig
+++ b/drivers/vfio/platform/reset/Kconfig
@@ -5,3 +5,11 @@ config VFIO_PLATFORM_CALXEDAXGMAC_RESET
  Enables the VFIO platform driver to handle reset for Calxeda xgmac
 
  If you don't know what to do here, say N.
+
+config VFIO_PLATFORM_AMDXGBE_RESET
+   tristate "VFIO support for AMD XGBE reset"
+   depends on VFIO_PLATFORM
+   help
+ Enables the VFIO platform driver to handle reset for AMD XGBE
+
+ If you don't know what to do here, say N.
diff --git a/drivers/vfio/platform/reset/Makefile 
b/drivers/vfio/platform/reset/Makefile
index 2a486af..93f4e23 100644
--- a/drivers/vfio/platform/reset/Makefile
+++ b/drivers/vfio/platform/reset/Makefile
@@ -1,5 +1,7 @@
 vfio-platform-calxedaxgmac-y := vfio_platform_calxedaxgmac.o
+vfio-platform-amdxgbe-y := vfio_platform_amdxgbe.o
 
 ccflags-y += -Idrivers/vfio/platform
 
 obj-$(CONFIG_VFIO_PLATFORM_CALXEDAXGMAC_RESET) += vfio-platform-calxedaxgmac.o
+obj-$(CONFIG_VFIO_PLATFORM_AMDXGBE_RESET) += vfio-platform-amdxgbe.o
diff --git a/drivers/vfio/platform/reset/vfio_platform_amdxgbe.c 
b/drivers/vfio/platform/reset/vfio_platform_amdxgbe.c
new file mode 100644
index 000..1636e22
--- /dev/null
+++ b/drivers/vfio/platform/reset/vfio_platform_amdxgbe.c
@@ -0,0 +1,127 @@
+/*
+ * VFIO platform driver specialized for AMD xgbe reset
+ * reset code is inherited from AMD xgbe native driver
+ *
+ * Copyright (c) 2015 Linaro Ltd.
+ *  www.linaro.org
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "vfio_platform_private.h"
+
+#define DMA_MR 0x3000
+#define MAC_VR 0x0110
+#define DMA_ISR0x3008
+#define MAC_ISR0x00b0
+#define PCS_MMD_SELECT 0xff
+#define MDIO_AN_INT0x8002
+#define MDIO_AN_INTMASK0x8001
+
+static unsigned int xmdio_read(void *ioaddr, unsigned int mmd,
+  unsigned int reg)
+{
+   unsigned int mmd_address, value;
+
+   mmd_address = (mmd << 16) | ((reg) & 0x);
+   iowrite32(mmd_address >> 8, ioaddr + (PCS_MMD_SELECT << 2));
+   value = ioread32(ioaddr + ((mmd_address & 0xff) << 2));
+   return value;
+}
+
+static void xmdio_write(void *ioaddr, unsigned int mmd,
+   unsigned int reg, unsigned int value)
+{
+   unsigned int mmd_address;
+
+   mmd_address = (mmd << 16) | ((reg) & 0x);
+   iowrite32(mmd_address >> 8, ioaddr + (PCS_MMD_SELECT << 2));
+   iowrite32(value, ioaddr + ((mmd_address & 0xff) << 2));
+}
+
+int vfio_platform_amdxgbe_reset(struct vfio_platform_device *vdev)
+{
+   struct vfio_platform_region xgmac_regs = vdev->regions[0];
+   struct vfio_platform_region xpcs_regs = vdev->regions[1];
+   u32 dma_mr_value, pcs_value, value;
+   unsigned int count;
+
+   if (!xgmac_regs.ioaddr) {
+   xgmac_regs.ioaddr =
+   ioremap_nocache(xgmac_regs.addr, xgmac_regs.size);
+   if (!xgmac_regs.ioaddr)
+   return -ENOMEM;
+   }
+   if (!xpcs_regs.ioaddr) {
+   xpcs_regs.ioaddr =
+  

[PATCH v5 3/7] vfio: platform: introduce module_vfio_reset_handler macro

[Eric Auger]

The module_vfio_reset_handler macro
- define a module alias
- implement module init/exit function which respectively registers
  and unregisters the reset function.

Signed-off-by: Eric Auger 
Reviewed-by: Arnd Bergmann 

---
v4 -> v5:
- add Arnd's R-b

v3 -> v4:
- pass reset to vfio_platform_unregister_reset

v2 -> v3:
- use vfio_platform_register_reset macro

v1 -> v2:
- remove vfio_platform_reset_private.h and move back the macro to
  vfio_platform_private.h header: removed reset_module_register &
  unregister (symbol_get)
- defines the module_vfio_reset_handler macro as suggested by Arnd
  (formerly in vfio_platform_reset_private.h)
---
 drivers/vfio/platform/vfio_platform_private.h | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/vfio/platform/vfio_platform_private.h 
b/drivers/vfio/platform/vfio_platform_private.h
index c563940..fd262be 100644
--- a/drivers/vfio/platform/vfio_platform_private.h
+++ b/drivers/vfio/platform/vfio_platform_private.h
@@ -110,4 +110,18 @@ static struct vfio_platform_reset_node __reset ## _node = 
{\
 }; \
 __vfio_platform_register_reset(&__reset ## _node)
 
+#define module_vfio_reset_handler(compat, reset)   \
+MODULE_ALIAS("vfio-reset:" compat);\
+static int __init reset ## _module_init(void)  \
+{  \
+   vfio_platform_register_reset(compat, reset);\
+   return 0;   \
+}; \
+static void __exit reset ## _module_exit(void) \
+{  \
+   vfio_platform_unregister_reset(compat, reset);  \
+}; \
+module_init(reset ## _module_init);\
+module_exit(reset ## _module_exit)
+
 #endif /* VFIO_PLATFORM_PRIVATE_H */
-- 
1.9.1

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

[PATCH v6 02/15] scsi: ufs: clear fields UTRD, UPIU req and rsp before new transfers

[Yaniv Gardi]

Some of the data structures (like response UPIU) and/or its elements
(unused fields) should be cleared before sending out the respective
command to UFS device.

This change clears the UPIU response data structure for query commands
and NOP command before sending out the command. We also initialize the
PRDT table length to zero which should take care of commands which doesn't
have any data associated with it. We are also clearing the unused fields in
request UPIU for NOP command.

Reviewed-by: Gilad Broner 
Reviewed-by: Dolev Raviv 
Signed-off-by: Subhash Jadavani 
Signed-off-by: Yaniv Gardi 

---
 drivers/scsi/ufs/ufshcd.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 3428f72..2d3ebca 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -1129,6 +1129,8 @@ static void ufshcd_prepare_req_desc_hdr(struct ufshcd_lrb 
*lrbp,
cpu_to_le32(OCS_INVALID_COMMAND_STATUS);
/* dword_3 is reserved, hence it is set to 0 */
req_desc->header.dword_3 = 0;
+
+   req_desc->prd_table_length = 0;
 }
 
 /**
@@ -1198,6 +1200,7 @@ static void ufshcd_prepare_utp_query_req_upiu(struct 
ufs_hba *hba,
if (query->request.upiu_req.opcode == UPIU_QUERY_OPCODE_WRITE_DESC)
memcpy(descp, query->descriptor, len);
 
+   memset(lrbp->ucd_rsp_ptr, 0, sizeof(struct utp_upiu_rsp));
 }
 
 static inline void ufshcd_prepare_utp_nop_upiu(struct ufshcd_lrb *lrbp)
@@ -1210,6 +1213,11 @@ static inline void ufshcd_prepare_utp_nop_upiu(struct 
ufshcd_lrb *lrbp)
ucd_req_ptr->header.dword_0 =
UPIU_HEADER_DWORD(
UPIU_TRANSACTION_NOP_OUT, 0, 0, lrbp->task_tag);
+   /* clear rest of the fields of basic header */
+   ucd_req_ptr->header.dword_1 = 0;
+   ucd_req_ptr->header.dword_2 = 0;
+
+   memset(lrbp->ucd_rsp_ptr, 0, sizeof(struct utp_upiu_rsp));
 }
 
 /**
-- 
1.8.5.2

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

[PATCH v6 11/15] scsi: ufs: retry failed query flag requests

[Yaniv Gardi]

UFS flag query requests may fail sometimes due to timeouts etc.
Add a wrapper function to retry up to 10 times in case of such
failure, similar to retries being made for attribute queries.

Reviewed-by: Dolev Raviv 
Signed-off-by: Gilad Broner 
Signed-off-by: Yaniv Gardi 

---
 drivers/scsi/ufs/ufshcd.c | 63 ---
 drivers/scsi/ufs/ufshcd.h |  4 +++
 2 files changed, 41 insertions(+), 26 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 60ba729..889a7be 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -1663,6 +1663,29 @@ static inline void ufshcd_init_query(struct ufs_hba *hba,
(*request)->upiu_req.selector = selector;
 }
 
+static int ufshcd_query_flag_retry(struct ufs_hba *hba,
+   enum query_opcode opcode, enum flag_idn idn, bool *flag_res)
+{
+   int ret;
+   int retries;
+
+   for (retries = 0; retries < QUERY_REQ_RETRIES; retries++) {
+   ret = ufshcd_query_flag(hba, opcode, idn, flag_res);
+   if (ret)
+   dev_dbg(hba->dev,
+   "%s: failed with error %d, retries %d\n",
+   __func__, ret, retries);
+   else
+   break;
+   }
+
+   if (ret)
+   dev_err(hba->dev,
+   "%s: query attribute, opcode %d, idn %d, failed with 
error %d after %d retires\n",
+   __func__, opcode, idn, ret, retries);
+   return ret;
+}
+
 /**
  * ufshcd_query_flag() - API function for sending flag query requests
  * hba: per-adapter instance
@@ -1672,7 +1695,7 @@ static inline void ufshcd_init_query(struct ufs_hba *hba,
  *
  * Returns 0 for success, non-zero in case of failure
  */
-static int ufshcd_query_flag(struct ufs_hba *hba, enum query_opcode opcode,
+int ufshcd_query_flag(struct ufs_hba *hba, enum query_opcode opcode,
enum flag_idn idn, bool *flag_res)
 {
struct ufs_query_req *request = NULL;
@@ -2657,17 +2680,12 @@ static int ufshcd_config_pwr_mode(struct ufs_hba *hba,
  */
 static int ufshcd_complete_dev_init(struct ufs_hba *hba)
 {
-   int i, retries, err = 0;
+   int i;
+   int err;
bool flag_res = 1;
 
-   for (retries = QUERY_REQ_RETRIES; retries > 0; retries--) {
-   /* Set the fDeviceInit flag */
-   err = ufshcd_query_flag(hba, UPIU_QUERY_OPCODE_SET_FLAG,
-   QUERY_FLAG_IDN_FDEVICEINIT, NULL);
-   if (!err || err == -ETIMEDOUT)
-   break;
-   dev_dbg(hba->dev, "%s: error %d retrying\n", __func__, err);
-   }
+   err = ufshcd_query_flag_retry(hba, UPIU_QUERY_OPCODE_SET_FLAG,
+   QUERY_FLAG_IDN_FDEVICEINIT, NULL);
if (err) {
dev_err(hba->dev,
"%s setting fDeviceInit flag failed with error %d\n",
@@ -2675,18 +2693,11 @@ static int ufshcd_complete_dev_init(struct ufs_hba *hba)
goto out;
}
 
-   /* poll for max. 100 iterations for fDeviceInit flag to clear */
-   for (i = 0; i < 100 && !err && flag_res; i++) {
-   for (retries = QUERY_REQ_RETRIES; retries > 0; retries--) {
-   err = ufshcd_query_flag(hba,
-   UPIU_QUERY_OPCODE_READ_FLAG,
-   QUERY_FLAG_IDN_FDEVICEINIT, _res);
-   if (!err || err == -ETIMEDOUT)
-   break;
-   dev_dbg(hba->dev, "%s: error %d retrying\n", __func__,
-   err);
-   }
-   }
+   /* poll for max. 1000 iterations for fDeviceInit flag to clear */
+   for (i = 0; i < 1000 && !err && flag_res; i++)
+   err = ufshcd_query_flag_retry(hba, UPIU_QUERY_OPCODE_READ_FLAG,
+   QUERY_FLAG_IDN_FDEVICEINIT, _res);
+
if (err)
dev_err(hba->dev,
"%s reading fDeviceInit flag failed with error %d\n",
@@ -3433,7 +3444,7 @@ static int ufshcd_enable_auto_bkops(struct ufs_hba *hba)
if (hba->auto_bkops_enabled)
goto out;
 
-   err = ufshcd_query_flag(hba, UPIU_QUERY_OPCODE_SET_FLAG,
+   err = ufshcd_query_flag_retry(hba, UPIU_QUERY_OPCODE_SET_FLAG,
QUERY_FLAG_IDN_BKOPS_EN, NULL);
if (err) {
dev_err(hba->dev, "%s: failed to enable bkops %d\n",
@@ -3482,7 +3493,7 @@ static int ufshcd_disable_auto_bkops(struct ufs_hba *hba)
goto out;
}
 
-   err = ufshcd_query_flag(hba, UPIU_QUERY_OPCODE_CLEAR_FLAG,
+   err = ufshcd_query_flag_retry(hba, UPIU_QUERY_OPCODE_CLEAR_FLAG,
QUERY_FLAG_IDN_BKOPS_EN, NULL);
if (err) {

[PATCH v6 05/15] scsi: ufs: increase fDeviceInit query response timeout

[Yaniv Gardi]

fDeviceInit query response time for some devices is too long that default
query request timeout of 100ms may not be enough. Experiments show that
fDeviceInit response sometimes takes 500ms so to be on safer side this
change sets the timeout to 600ms. Without this change, we might
unnecessarily have to retry fDeviceInit query requests multiple times and
each query request timeout prints one error message.

Reviewed-by: Gilad Broner 
Reviewed-by: Dolev Raviv 
Signed-off-by: Subhash Jadavani 
Signed-off-by: Yaniv Gardi 

---
 drivers/scsi/ufs/ufshcd.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index e0b8755..573a8cb 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -58,6 +58,12 @@
 #define QUERY_REQ_RETRIES 10
 /* Query request timeout */
 #define QUERY_REQ_TIMEOUT 30 /* msec */
+/*
+ * Query request timeout for fDeviceInit flag
+ * fDeviceInit query response time for some devices is too large that default
+ * QUERY_REQ_TIMEOUT may not be enough for such devices.
+ */
+#define QUERY_FDEVICEINIT_REQ_TIMEOUT 600 /* msec */
 
 /* Task management command timeout */
 #define TM_CMD_TIMEOUT 100 /* msecs */
@@ -1651,6 +1657,7 @@ static int ufshcd_query_flag(struct ufs_hba *hba, enum 
query_opcode opcode,
struct ufs_query_req *request = NULL;
struct ufs_query_res *response = NULL;
int err, index = 0, selector = 0;
+   int timeout = QUERY_REQ_TIMEOUT;
 
BUG_ON(!hba);
 
@@ -1683,7 +1690,10 @@ static int ufshcd_query_flag(struct ufs_hba *hba, enum 
query_opcode opcode,
goto out_unlock;
}
 
-   err = ufshcd_exec_dev_cmd(hba, DEV_CMD_TYPE_QUERY, QUERY_REQ_TIMEOUT);
+   if (idn == QUERY_FLAG_IDN_FDEVICEINIT)
+   timeout = QUERY_FDEVICEINIT_REQ_TIMEOUT;
+
+   err = ufshcd_exec_dev_cmd(hba, DEV_CMD_TYPE_QUERY, timeout);
 
if (err) {
dev_err(hba->dev,
-- 
1.8.5.2

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

Re: [PATCH v3 0/3] virtio DMA API core stuff

[Michael S. Tsirkin]

On Wed, Oct 28, 2015 at 05:09:47PM +0900, David Woodhouse wrote:
> On Wed, 2015-10-28 at 16:40 +0900, Christian Borntraeger wrote:
> > Am 28.10.2015 um 16:17 schrieb Michael S. Tsirkin:
> > > On Tue, Oct 27, 2015 at 11:38:57PM -0700, Andy Lutomirski wrote:
> > > > This switches virtio to use the DMA API unconditionally.  I'm sure
> > > > it breaks things, but it seems to work on x86 using virtio-pci, with
> > > > and without Xen, and using both the modern 1.0 variant and the
> > > > legacy variant.
> > > 
> > > I'm very glad to see work on this making progress.
> > > 
> > > I suspect we'll have to find a way to make this optional though, and
> > > keep doing the non-DMA API thing with old devices.  And I've been
> > > debating with myself whether a pci specific thing or a feature bit is
> > > preferable.
> > > 
> > 
> > We have discussed that at kernel summit. I will try to implement a dummy 
> > dma_ops for
> > s390 that does 1:1 mapping and Ben will look into doing some quirk to 
> > handle "old"
> > code in addition to also make it possible to mark devices as iommu bypass 
> > (IIRC,
> > via device tree, Ben?)
> 
> Right. You never eschew the DMA API in the *driver* — you just expect
> the DMA API to do the right thing for devices which don't need
> translation (with platforms using per-device dma_ops and generally
> getting their act together).
> We're pushing that on the platforms where it's currently an issue,
> including Power, SPARC and S390.
> 
> -- 
> dwmw2
> 
> 

Well APIs are just that - internal kernel APIs.
If the only user of an API is virtio, we can strick the
code in virtio.h just as well.
I think controlling this dynamically and not statically
in e.g. devicetree is important though.

E.g. on intel x86, there's an option iommu=pt which does the 1:1
thing for devices when used by kernel, but enables
the iommu if used by userspace/VMs.

Something like this would be needed for other platforms IMHO.

And given that
1. virtio seems the only user so far
2. supporting this per device seems like something that
   might become useful in the future
maybe we'd better make this part of virtio transports.

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

Re: [PATCH v2 00/17] add fixes, device quirks, error recovery,

[Gilad Broner]

Looks good to me.
Reviewed-by: Gilad Broner 

> V2:
> This series should be pushed on top of 15 patches series:
> "Big fixes, retries, handle a race condition"
> fixed and few comments.
>
> V1:
> This series should be pushed on top of 15 patches series:
> "Big fixes, retries, handle a race condition"
>
> Yaniv Gardi (17):
>   scsi: ufs-qcom: add number of lanes per direction
>   scsi: ufs: add option to change default UFS power management level
>   scsi: ufs: optimize system suspend handling
>   scsi: ufs: avoid spurious UFS host controller interrupts
>   scsi: ufs: implement scsi host timeout handler
>   scsi :ufs: verify hba controller hce reg value
>   scsi: ufs: separate device and host quirks
>   scsi: ufs: disable vccq if it's not needed by UFS device
>   scsi: ufs: make error handling bit faster
>   scsi: ufs: add error recovery after DL NAC error
>   scsi: ufs: add retry for query descriptors
>   scsi: ufs: handle non spec compliant bkops behaviour by device
>   scsi: ufs: tune UniPro parameters to optimize hibern8 exit time
>   scsi: ufs: fix leakage during link off state
>   scsi: ufs: add device quirk delay before putting UFS rails in LPM
>   scsi: ufs-qcom: set PA_Local_TX_LCC_Enable before link startup
>   scsi: ufs-qcom: fix compilation warnings
>
>  .../devicetree/bindings/ufs/ufshcd-pltfrm.txt  |  11 +
>  drivers/scsi/ufs/Makefile  |   2 +-
>  drivers/scsi/ufs/ufs-qcom.c| 163 -
>  drivers/scsi/ufs/ufs-qcom.h|   9 +
>  drivers/scsi/ufs/ufs.h |  32 +
>  drivers/scsi/ufs/ufs_quirks.c  | 104 +++
>  drivers/scsi/ufs/ufs_quirks.h  | 131 
>  drivers/scsi/ufs/ufshcd-pltfrm.c   |  36 +-
>  drivers/scsi/ufs/ufshcd.c  | 803
> ++---
>  drivers/scsi/ufs/ufshcd.h  |  44 +-
>  drivers/scsi/ufs/ufshci.h  |   4 +
>  drivers/scsi/ufs/unipro.h  |  22 +
>  12 files changed, 1217 insertions(+), 144 deletions(-)
>  create mode 100644 drivers/scsi/ufs/ufs_quirks.c
>  create mode 100644 drivers/scsi/ufs/ufs_quirks.h
>
> --
> 1.8.5.2
>
> --
> QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation
>


-- 
Qualcomm Israel, on behalf of Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

Re: [patch 3/3] vmstat: Create our own workqueue

[Tetsuo Handa]

Christoph Lameter wrote:
> On Wed, 28 Oct 2015, Tejun Heo wrote:
> 
> > The only thing necessary here is WQ_MEM_RECLAIM.  I don't see how
> > WQ_SYSFS and WQ_FREEZABLE make sense here.
> 
I can still trigger silent livelock with this patchset applied.

--
[  272.283217] MemAlloc-Info: 9 stalling task, 0 dying task, 0 victim task.
[  272.285089] MemAlloc: a.out(11325) gfp=0x24280ca order=0 delay=19164
[  272.286817] MemAlloc: a.out(11326) gfp=0x242014a order=0 delay=19104
[  272.288512] MemAlloc: vmtoolsd(1897) gfp=0x242014a order=0 delay=19072
[  272.290280] MemAlloc: kworker/1:3(11286) gfp=0x240 order=0 delay=19056
[  272.292114] MemAlloc: sshd(11202) gfp=0x242014a order=0 delay=18927
[  272.293908] MemAlloc: tuned(2073) gfp=0x242014a order=0 delay=18799
[  272.297360] MemAlloc: nmbd(4752) gfp=0x242014a order=0 delay=16532
[  272.299115] MemAlloc: auditd(529) gfp=0x242014a order=0 delay=13073
[  272.302248] MemAlloc: irqbalance(1696) gfp=0x242014a order=0 delay=10529
(...snipped...)
[  272.851035] Showing busy workqueues and worker pools:
[  272.852583] workqueue events: flags=0x0
[  272.853942]   pwq 6: cpus=3 node=0 flags=0x0 nice=0 active=1/256
[  272.855781] pending: vmw_fb_dirty_flush [vmwgfx]
[  272.857500]   pwq 2: cpus=1 node=0 flags=0x0 nice=0 active=1/256
[  272.859359] pending: vmpressure_work_fn
[  272.860840] workqueue events_freezable_power_: flags=0x84
[  272.862461]   pwq 2: cpus=1 node=0 flags=0x0 nice=0 active=2/256
[  272.864479] in-flight: 11286:disk_events_workfn
[  272.866065] pending: disk_events_workfn
[  272.867587] workqueue vmstat: flags=0x8
[  272.868942]   pwq 2: cpus=1 node=0 flags=0x0 nice=0 active=1/256
[  272.870785] pending: vmstat_update
[  272.872248] pool 2: cpus=1 node=0 flags=0x0 nice=0 workers=4 idle: 14 218 43
--

> 2. Create a separate workqueue so that the vmstat updater
>is not blocked by other work requeusts. This creates a
>new kernel thread  and avoids the issue of
>differentials not folded in a timely fashion.

Did you really mean "the vmstat updater is not blocked by other
work requeusts"?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[char-misc-next 1/2] mei: bus: use correct lock ordering

[Tomas Winkler]

The correct lock order is
  cl_bus_lock
device_lock
  me_clients_rwsem

This order was violated in bus rescan and remove routines
when me_client_rwsem was locked before cl_bus_lock.

Chain exists of:
[4.321653]   >device_lock --> >me_clients_rwsem -->
>cl_bus_lock
[4.321653]
[4.321679]  Possible unsafe locking scenario:
[4.321679]
[4.321693]CPU0CPU1
[4.321701]
[4.321709]   lock(>cl_bus_lock);
[4.321720]
lock(>me_clients_rwsem);
[4.321733]lock(>cl_bus_lock);
[4.321745]   lock(>device_lock);
[4.321755]
[4.321755]  *** DEADLOCK ***
[4.321755]

Signed-off-by: Tomas Winkler 
---
 drivers/misc/mei/bus.c | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
index 160e084ae800..46403e48be4f 100644
--- a/drivers/misc/mei/bus.c
+++ b/drivers/misc/mei/bus.c
@@ -830,17 +830,20 @@ static void mei_cl_bus_dev_stop(struct mei_cl_device 
*cldev)
  * mei_cl_bus_dev_destroy - destroy me client devices object
  *
  * @cldev: me client device
+ *
+ * Locking: called under "dev->cl_bus_lock" lock
  */
 static void mei_cl_bus_dev_destroy(struct mei_cl_device *cldev)
 {
+
+   WARN_ON(!mutex_is_locked(>bus->cl_bus_lock));
+
if (!cldev->is_added)
return;
 
device_del(>dev);
 
-   mutex_lock(>bus->cl_bus_lock);
list_del_init(>bus_list);
-   mutex_unlock(>bus->cl_bus_lock);
 
cldev->is_added = 0;
put_device(>dev);
@@ -866,8 +869,10 @@ void mei_cl_bus_remove_devices(struct mei_device *bus)
 {
struct mei_cl_device *cldev, *next;
 
+   mutex_lock(>cl_bus_lock);
list_for_each_entry_safe(cldev, next, >device_list, bus_list)
mei_cl_bus_remove_device(cldev);
+   mutex_unlock(>cl_bus_lock);
 }
 
 
@@ -877,12 +882,16 @@ void mei_cl_bus_remove_devices(struct mei_device *bus)
  *
  * @bus: mei device
  * @me_cl: me client
+ *
+ * Locking: called under "dev->cl_bus_lock" lock
  */
 static void mei_cl_bus_dev_init(struct mei_device *bus,
struct mei_me_client *me_cl)
 {
struct mei_cl_device *cldev;
 
+   WARN_ON(!mutex_is_locked(>cl_bus_lock));
+
dev_dbg(bus->dev, "initializing %pUl", mei_me_cl_uuid(me_cl));
 
if (me_cl->bus_added)
@@ -892,10 +901,8 @@ static void mei_cl_bus_dev_init(struct mei_device *bus,
if (!cldev)
return;
 
-   mutex_lock(>bus->cl_bus_lock);
me_cl->bus_added = true;
list_add_tail(>bus_list, >device_list);
-   mutex_unlock(>bus->cl_bus_lock);
 
 }
 
@@ -910,12 +917,13 @@ void mei_cl_bus_rescan(struct mei_device *bus)
struct mei_cl_device *cldev, *n;
struct mei_me_client *me_cl;
 
+   mutex_lock(>cl_bus_lock);
+
down_read(>me_clients_rwsem);
list_for_each_entry(me_cl, >me_clients, list)
mei_cl_bus_dev_init(bus, me_cl);
up_read(>me_clients_rwsem);
 
-   mutex_lock(>cl_bus_lock);
list_for_each_entry_safe(cldev, n, >device_list, bus_list) {
 
if (!mei_me_cl_is_active(cldev->me_cl)) {
-- 
2.4.3

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

Re: [RFC PATCH net-next 1/4] perf tools: Enable pre-event inherit setting by config terms

[Jiri Olsa]

On Wed, Oct 28, 2015 at 10:55:02AM +, Wang Nan wrote:

SNIP

> diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
> index f820906..397fb4e 100644
> --- a/tools/perf/util/evsel.c
> +++ b/tools/perf/util/evsel.c
> @@ -653,6 +653,15 @@ static void apply_config_terms(struct perf_evsel *evsel,
>   case PERF_EVSEL__CONFIG_TERM_STACK_USER:
>   dump_size = term->val.stack_user;
>   break;
> + case PERF_EVSEL__CONFIG_TERM_INHERIT:
> + /*
> +  * attr->inherit should has already been set by
> +  * perf_evsel__config. If user explicitly set
> +  * inherit using config terms, override global
> +  * opt->no_inherit setting.
> +  */
> + attr->inherit = term->val.inherit ? 1 : 0;
> + break;
>   default:
>   break;
>   }
> diff --git a/tools/perf/util/evsel.h b/tools/perf/util/evsel.h
> index 9a95e73..e402f83 100644
> --- a/tools/perf/util/evsel.h
> +++ b/tools/perf/util/evsel.h
> @@ -43,6 +43,7 @@ enum {
>   PERF_EVSEL__CONFIG_TERM_TIME,
>   PERF_EVSEL__CONFIG_TERM_CALLGRAPH,
>   PERF_EVSEL__CONFIG_TERM_STACK_USER,
> + PERF_EVSEL__CONFIG_TERM_INHERIT,
>   PERF_EVSEL__CONFIG_TERM_MAX,
>  };
>  
> @@ -55,6 +56,7 @@ struct perf_evsel_config_term {
>   booltime;
>   char*callgraph;
>   u64 stack_user;
> + u64 inherit;

seems like bool would be enough

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

Re: [PATCH] MAINTAINERS: Start using the 'reviewer' (R) tag

[Krzysztof Kozlowski]

W dniu 28.10.2015 o 19:14, Lee Jones pisze:
> On Wed, 28 Oct 2015, Krzysztof Kozlowski wrote:
>> On 28.10.2015 17:24, Lee Jones wrote:
>>> On Wed, 28 Oct 2015, Krzysztof Kozlowski wrote:
 2015-10-28 3:44 GMT+09:00 Joe Perches :
> On Tue, 2015-10-27 at 18:15 +, Lee Jones wrote:
>> On Tue, 27 Oct 2015, Sebastian Reichel wrote:> >
>>> I think you should CC the people, which are changed from "M:"
>>> to "R:", though.
>>
>> Yes, makes sense.
>>
>> I'd like to collect some Maintainer Acks first though.
>
> I think people from organizations like Samsung are actual 
> maintainers not reviewers.
>>>
>>> So this all hinges on how we are describing Maintainers and
>>> Reviewers.
>>>
>>> My personal definition (until convinced otherwise) is that Reviewers 
>>> care about their particular subsystem and/or files.  They conduct
>>> code reviews to ensure nothing gets broken and the code base stays in
>>> best possible state of worthiness.  On the other hand Maintainers
>>> usually conduct themselves as Reviewers but also have
>>> 'maintainership' duties as well; such as applying patches,
>>> *maintaining*, testing, rebasing, etc, an upstream branch and
>>> ultimately sending pull-requests to higher level Maintainers i.e.
>>> Linus.  Maintainers also have the ultimate say (unless over-ruled by
>>> Linus etc) over what gets applied.
>>
>> Okay, sounds reasonable... so if a person performs reviews plus he does
>> some of the other activities (not all) then who is he?
> 
> LT;DR: If someone doesn't *maintain* an upstream branch, they are not
> an upstream Maintainer.

If I understand your point correctly: The maintainer and supporter
should be mentioned if and only if he maintains an upstream branch?

> 
>> For example reviewing
> 
> Depends on the type of engagement.  Anyone can review any patch
> submitted to anywhere on the code-base.  This does not make them an
> accepted Reviewer.  Here I'm saying that a Reviewer is a competent
> engineer who has made a promise to dedicate time to review incoming
> patches in order to ensure quality.
> 
> To emphasise a tagged Reviewer isn't just someone who reviews code
> every now and again.  It's someone who cares and has a vested interest
> in either a subsystem as a whole, or perhaps individual or a group of
> drivers.  However, this person does not conduct upstream branch
> *maintenance*.
> 
>> testing + fixing bugs + cleaning up (sending
>> patches from time to time)?
> 
> This is a Submitter/Contributor.
> 
> When I said testing before, I meant the branch being maintained, not
> the driver on it's own.  That should be tested by Submitters/
> Contributors or Testers (who get to provide their Tested-by).
> 
>> Would that be sufficient requirement to call him maintainer of a driver?
>> Or maybe all of these requirements must be met (including handling of
>> patches and sending pull reqs)?
> 
> It's only really the handing of patches and the maintenance of an
> upstream branch which differentiates a Reviewer from a Maintainer. 
> 
> Their drivers are not thrown over a wall and forgotten.

 At least for Samsung Multifunction PMIC drivers (and some of Maxim 
 MUICs and PMICs) these are actively used by us in existing and new 
 products. They are also continuously extended and actually
 maintained. This means that it is not only about review of new
 patches but also about caring that nothing will become broken.
>>>
>>> Exactly.  This what I expect of any good code Reviewer.
>>>
 I would prefer to leave the "SAMSUNG MULTIFUNCTION PMIC DEVICE 
 DRIVERS" entry as is - maintainers.
>>>
>>> But you aren't maintaining the driver i.e. you don't collect patches 
>>> and *maintain* them on an upstream branch.
>>
>> Indeed, we don't. However are other non-reviewing activities sufficient?
> 
> The other non-reviewing activities you mentioned are that of the
> Submitter/Contributor/Tester.  They still don't make someone a
> Maintainer.

I think I got your point of view. I don't see it that way, especially
that I pointed the fact of combining these activities.
Submitter/Reviewer/Tester in one person.

> 
>>> Granted some of you guys 
>>> are doing a great job of maintaining branches on your downstream or 
>>> BSP kernels, but conduct a Reviewer type role for upstream.
>>
>> You mentioned also the "ultimate say over what gets applied" - which in
>> this particular case is interesting to us because we have direct
>> interest in these drivers being in a good shape and doing things we
>> expect them to do. Like representing the interest of users.
> 
> Any Reviewers opinion will matter to someone who ultimately applies
> the patches.  For instance, if you were to say to me "this change to
> our MFD doesn't suit us because of X", I almost certainly won't apply
> the patch.
> 
>> Of course one could say that every upstreaming person has such
>> expectations... but some of the upstreamers just send a 

Re: [PATCH 1/6] dmaengine: tegra-apb: Correct runtime-pm usage

[Jon Hunter]

On 28/10/15 07:03, Vinod Koul wrote:
> On Fri, Oct 16, 2015 at 09:25:52AM +0100, Jon Hunter wrote:
>> @@ -1182,14 +1182,11 @@ static int tegra_dma_alloc_chan_resources(struct 
>> dma_chan *dc)
>>  {
>>  struct tegra_dma_channel *tdc = to_tegra_dma_chan(dc);
>>  struct tegra_dma *tdma = tdc->tdma;
>> -int ret;
>>  
>>  dma_cookie_init(>dma_chan);
>>  tdc->config_init = false;
>> -ret = clk_prepare_enable(tdma->dma_clk);
>> -if (ret < 0)
>> -dev_err(tdc2dev(tdc), "clk_prepare_enable failed: %d\n", ret);
>> -return ret;
>> +
>> +return pm_runtime_get_sync(tdma->dev);
> 
> Alloc channel is supposed to return number of descriptors allocated and if
> pm_runtime_get_sync() returns postive values we get wrong return!

Yes I will fix. I assume that returning 0 is allowed if no descriptors
are allocated here. So much for correcting rpm usage ;-)

>>  pm_runtime_enable(>dev);
>> -if (!pm_runtime_enabled(>dev)) {
>> +if (!pm_runtime_enabled(>dev))
>>  ret = tegra_dma_runtime_resume(>dev);
>> -if (ret) {
>> -dev_err(>dev, "dma_runtime_resume failed %d\n",
>> -ret);
>> -goto err_pm_disable;
>> -}
>> -}
>> +else
>> +ret = pm_runtime_get_sync(>dev);
> 
> do we need pm_runtime_get() here, should we use pm_request_resume() ?

We definitely want pm_runtime_get_sync() because pm_request_resume() is
an ASYNC resume and so does not guarantee the device is accessible after
the call returns. The pm_runtime_get variant is nice too because it
keeps track of the number of gets and puts that have occurred.

>>  static int tegra_dma_pm_suspend(struct device *dev)
>>  {
>>  struct tegra_dma *tdma = dev_get_drvdata(dev);
>> -int i;
>> -int ret;
>> +int i, ret;
>>  
>>  /* Enable clock before accessing register */
>> -ret = tegra_dma_runtime_resume(dev);
>> +ret = pm_runtime_get_sync(dev);
> 
> If you are runtime suspended then core will runtime resume you before
> invoking suspend, so why do we need this

Is this change now in the mainline? Do you have commit ID for that?

I recall the last time we discussed this that Rafael said that they were
going to do that, but he said as a rule of thumb if you need to resume
it, resume it [0].

Cheers
Jon

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

Re: [PATCH 6/6] dmaengine: tegra-apb: Disable interrupts on removal

[Jon Hunter]

On 28/10/15 06:53, Vinod Koul wrote:
> On Fri, Oct 16, 2015 at 11:57:02AM +0100, Jon Hunter wrote:
> How about just calling free_irq()? That's how you'd typically handle this.

 Yes, however, the interrupt is requested by devm_request_irq(). I guess
 I could call devm_free_irq() here?
>>>
>>> Just use request_irq() instead of devm_request_irq(). You have the same
>>> issue on the error path in the probe function anyway and also need to add
>>> the free_irq() before the tasklet_kill() there as well.
>>
>> I was wondering about that but the tasklets should never be scheduled if
>> the probe does not succeed, so I think it is ok.
> 
> This is actually very racy, if probe fails but due to devm_ calls your irq
> is alive till it freed by core
> 
> And a faulty device triggering irq can complicate matters, so for irq IMHO
> we don't get much benefit with devm_ variant

That's fine, I will drop the devm_ usage here then.

Jon

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

Re: [PATCH] MAINTAINERS: Start using the 'reviewer' (R) tag

[Lee Jones]

On Wed, 28 Oct 2015, Krzysztof Kozlowski wrote:
> W dniu 28.10.2015 o 19:14, Lee Jones pisze:
> > On Wed, 28 Oct 2015, Krzysztof Kozlowski wrote:
> >> On 28.10.2015 17:24, Lee Jones wrote:
> >>> On Wed, 28 Oct 2015, Krzysztof Kozlowski wrote:
>  2015-10-28 3:44 GMT+09:00 Joe Perches :
> > On Tue, 2015-10-27 at 18:15 +, Lee Jones wrote:
> >> On Tue, 27 Oct 2015, Sebastian Reichel wrote:> >
> >>> I think you should CC the people, which are changed from "M:"
> >>> to "R:", though.
> >>
> >> Yes, makes sense.
> >>
> >> I'd like to collect some Maintainer Acks first though.
> >
> > I think people from organizations like Samsung are actual 
> > maintainers not reviewers.
> >>>
> >>> So this all hinges on how we are describing Maintainers and
> >>> Reviewers.
> >>>
> >>> My personal definition (until convinced otherwise) is that Reviewers 
> >>> care about their particular subsystem and/or files.  They conduct
> >>> code reviews to ensure nothing gets broken and the code base stays in
> >>> best possible state of worthiness.  On the other hand Maintainers
> >>> usually conduct themselves as Reviewers but also have
> >>> 'maintainership' duties as well; such as applying patches,
> >>> *maintaining*, testing, rebasing, etc, an upstream branch and
> >>> ultimately sending pull-requests to higher level Maintainers i.e.
> >>> Linus.  Maintainers also have the ultimate say (unless over-ruled by
> >>> Linus etc) over what gets applied.
> >>
> >> Okay, sounds reasonable... so if a person performs reviews plus he does
> >> some of the other activities (not all) then who is he?
> > 
> > LT;DR: If someone doesn't *maintain* an upstream branch, they are not
> > an upstream Maintainer.
> 
> If I understand your point correctly: The maintainer and supporter
> should be mentioned if and only if he maintains an upstream branch?

Now we have the dedicated Reviewer tag, yes.  That's pretty much how I
see it.  Granted, before we had it Maintainer was the best term as
encompassed both the reviewing and actual maintaining roles, however
now there is a more informative tag which accurately describes the
reviewing role better.

I think Stephen said it best [0]:

"I don't care much whether it's "M:" or "R:", although "R:" carries
more meaning and hence is probably better."

> >> For example reviewing
> > 
> > Depends on the type of engagement.  Anyone can review any patch
> > submitted to anywhere on the code-base.  This does not make them an
> > accepted Reviewer.  Here I'm saying that a Reviewer is a competent
> > engineer who has made a promise to dedicate time to review incoming
> > patches in order to ensure quality.
> > 
> > To emphasise a tagged Reviewer isn't just someone who reviews code
> > every now and again.  It's someone who cares and has a vested interest
> > in either a subsystem as a whole, or perhaps individual or a group of
> > drivers.  However, this person does not conduct upstream branch
> > *maintenance*.
> > 
> >> testing + fixing bugs + cleaning up (sending
> >> patches from time to time)?
> > 
> > This is a Submitter/Contributor.
> > 
> > When I said testing before, I meant the branch being maintained, not
> > the driver on it's own.  That should be tested by Submitters/
> > Contributors or Testers (who get to provide their Tested-by).
> > 
> >> Would that be sufficient requirement to call him maintainer of a driver?
> >> Or maybe all of these requirements must be met (including handling of
> >> patches and sending pull reqs)?
> > 
> > It's only really the handing of patches and the maintenance of an
> > upstream branch which differentiates a Reviewer from a Maintainer. 
> > 
> > Their drivers are not thrown over a wall and forgotten.
> 
>  At least for Samsung Multifunction PMIC drivers (and some of Maxim 
>  MUICs and PMICs) these are actively used by us in existing and new 
>  products. They are also continuously extended and actually
>  maintained. This means that it is not only about review of new
>  patches but also about caring that nothing will become broken.
> >>>
> >>> Exactly.  This what I expect of any good code Reviewer.
> >>>
>  I would prefer to leave the "SAMSUNG MULTIFUNCTION PMIC DEVICE 
>  DRIVERS" entry as is - maintainers.
> >>>
> >>> But you aren't maintaining the driver i.e. you don't collect patches 
> >>> and *maintain* them on an upstream branch.
> >>
> >> Indeed, we don't. However are other non-reviewing activities sufficient?
> > 
> > The other non-reviewing activities you mentioned are that of the
> > Submitter/Contributor/Tester.  They still don't make someone a
> > Maintainer.
> 
> I think I got your point of view. I don't see it that way, especially
> that I pointed the fact of combining these activities.
> Submitter/Reviewer/Tester in one person.

Each of these are perfectly valid and extremely worthy roles.  They
all have their own way of being identified using 

[PATCH v9 6/8] scsi: ufs: make the UFS variant a platform device

[Yaniv Gardi]

This change turns the UFS variant (SCSI_UFS_QCOM) into a UFS
a platform device.
In order to do so a few additional changes are required:
1. The ufshcd-pltfrm is no longer serves as a platform device.
   Now it only serves as a group of platform APIs such as PM APIs
   (runtime suspend/resume, system suspend/resume etc), parsers of
   clocks, regulators and pm_levels from DT.
2. What used to be the old platform "probe" is now "only"
   a pltfrm_init() routine, that does exactly the same, but only
   being called by the new probe function of the UFS variant.

Reviewed-by: Rob Herring 
Reviewed-by: Gilad Broner 
Signed-off-by: Yaniv Gardi 

---
 Documentation/devicetree/bindings/ufs/ufs-qcom.txt | 58 +
 .../devicetree/bindings/ufs/ufshcd-pltfrm.txt  | 11 ++-
 drivers/scsi/ufs/ufs-qcom.c| 62 +-
 drivers/scsi/ufs/ufshcd-pltfrm.c   | 98 ++
 drivers/scsi/ufs/ufshcd-pltfrm.h   | 41 +
 drivers/scsi/ufs/ufshcd.c  | 10 +++
 drivers/scsi/ufs/ufshcd.h  |  1 +
 7 files changed, 207 insertions(+), 74 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/ufs/ufs-qcom.txt
 create mode 100644 drivers/scsi/ufs/ufshcd-pltfrm.h

diff --git a/Documentation/devicetree/bindings/ufs/ufs-qcom.txt 
b/Documentation/devicetree/bindings/ufs/ufs-qcom.txt
new file mode 100644
index 000..070baf4
--- /dev/null
+++ b/Documentation/devicetree/bindings/ufs/ufs-qcom.txt
@@ -0,0 +1,58 @@
+* Qualcomm Technologies Inc Universal Flash Storage (UFS) PHY
+
+UFSPHY nodes are defined to describe on-chip UFS PHY hardware macro.
+Each UFS PHY node should have its own node.
+
+To bind UFS PHY with UFS host controller, the controller node should
+contain a phandle reference to UFS PHY node.
+
+Required properties:
+- compatible: compatible list, contains "qcom,ufs-phy-qmp-20nm"
+ or "qcom,ufs-phy-qmp-14nm" according to the relevant phy 
in use.
+- reg   : should contain PHY register address space (mandatory),
+- reg-names : indicates various resources passed to driver (via reg 
proptery) by name.
+  Required "reg-names" is "phy_mem".
+- #phy-cells: This property shall be set to 0
+- vdda-phy-supply   : phandle to main PHY supply for analog domain
+- vdda-pll-supply   : phandle to PHY PLL and Power-Gen block power supply
+- clocks   : List of phandle and clock specifier pairs
+- clock-names   : List of clock input name strings sorted in the same
+ order as the clocks property. "ref_clk_src", "ref_clk",
+ "tx_iface_clk" & "rx_iface_clk" are mandatory but
+ "ref_clk_parent" is optional
+
+Optional properties:
+- vdda-phy-max-microamp : specifies max. load that can be drawn from phy supply
+- vdda-pll-max-microamp : specifies max. load that can be drawn from pll supply
+- vddp-ref-clk-supply   : phandle to UFS device ref_clk pad power supply
+- vddp-ref-clk-max-microamp : specifies max. load that can be drawn from this 
supply
+- vddp-ref-clk-always-on : specifies if this supply needs to be kept always on
+
+Example:
+
+   ufsphy1: ufsphy@0xfc597000 {
+   compatible = "qcom,ufs-phy-qmp-20nm";
+   reg = <0xfc597000 0x800>;
+   reg-names = "phy_mem";
+   #phy-cells = <0>;
+   vdda-phy-supply = <_l4>;
+   vdda-pll-supply = <_l12>;
+   vdda-phy-max-microamp = <5>;
+   vdda-pll-max-microamp = <1000>;
+   clock-names = "ref_clk_src",
+   "ref_clk_parent",
+   "ref_clk",
+   "tx_iface_clk",
+   "rx_iface_clk";
+   clocks = <_rpm clk_ln_bb_clk>,
+   <_gcc clk_pcie_1_phy_ldo >,
+   <_gcc clk_ufs_phy_ldo>,
+   <_gcc clk_gcc_ufs_tx_cfg_clk>,
+   <_gcc clk_gcc_ufs_rx_cfg_clk>;
+   };
+
+   ufshc@0xfc598000 {
+   ...
+   phys = <>;
+   phy-names = "ufsphy";
+   };
diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt 
b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
index 5357919..03c0e98 100644
--- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
+++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
@@ -4,11 +4,18 @@ UFSHC nodes are defined to describe on-chip UFS host 
controllers.
 Each UFS controller instance should have its own node.
 
 Required properties:
-- compatible: compatible list, contains "jedec,ufs-1.1"
+- compatible   : must contain "jedec,ufs-1.1", may also list one or 
more
+ of the following:
+ 

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

[Ingo Molnar]

* Matt Fleming  wrote:

> On Fri, 23 Oct, at 12:33:29PM, Ingo Molnar wrote:
> > 
> > Matt, do you want to take these fixes, or should I apply them directly?
> 
> Could you please apply them directly with my Reviewed-by tag?

Sure, done!

Thanks,

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

Re: [PATCH V1 11/11] arm64, pci, acpi: Support for ACPI based PCI hostbridge init

[Liviu . Dudau]

On Tue, Oct 27, 2015 at 05:38:42PM +0100, Tomasz Nowicki wrote:
> Because of two patch series:
> 1. Jiang Liu's common interface to support PCI host bridge init
> 2. Refactoring of MMCONFIG, part of this patch set
> now we can think about PCI buses enumeration for ARM64 and ACPI tables.
> 
> This patch introduce ACPI based PCI hostbridge init calls which
> use information from MCFG table (PCI config space regions) and
> _CRS (IO/irq resources) to initialize PCI hostbridge.
> 
> Signed-off-by: Tomasz Nowicki 
> Signed-off-by: Hanjun Guo 
> Signed-off-by: Suravee Suthikulpanit 
> CC: Arnd Bergmann 
> CC: Catalin Marinas 
> CC: Liviu Dudau 
> CC: Lorenzo Pieralisi 
> CC: Will Deacon 
> ---
>  arch/arm64/Kconfig  |   6 ++
>  arch/arm64/kernel/pci.c | 208 
> +---
>  2 files changed, 202 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 07d1811..bbcc6b1 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -89,6 +89,7 @@ config ARM64
>   select SPARSE_IRQ
>   select SYSCTL_EXCEPTION_TRACE
>   select HAVE_CONTEXT_TRACKING
> + select HAVE_PCI_ECAM
>   help
> ARM 64-bit (AArch64) Linux support.
>  
> @@ -202,6 +203,11 @@ source "drivers/pci/Kconfig"
>  source "drivers/pci/pcie/Kconfig"
>  source "drivers/pci/hotplug/Kconfig"
>  
> +config PCI_MMCONFIG
> + def_bool y
> + select PCI_ECAM
> + depends on ACPI
> +
>  endmenu
>  
>  menu "Kernel Features"
> diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> index b3d098b..66cc1ae 100644
> --- a/arch/arm64/kernel/pci.c
> +++ b/arch/arm64/kernel/pci.c
> @@ -11,12 +11,15 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include 
> @@ -52,35 +55,216 @@ int pcibios_enable_device(struct pci_dev *dev, int mask)
>  }
>  
>  /*
> - * Try to assign the IRQ number from DT when adding a new device
> + * Try to assign the IRQ number from DT/ACPI when adding a new device
>   */
>  int pcibios_add_device(struct pci_dev *dev)
>  {
> - dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
> + if (acpi_disabled)
> + dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
> +#ifdef CONFIG_ACPI
> + else
> + acpi_pci_irq_enable(dev);
> +#endif
>  
>   return 0;
>  }
>  
> +#ifdef CONFIG_ACPI
> +int pcibios_root_bridge_prepare(struct pci_host_bridge *bridge)
> +{
> + struct acpi_pci_root *root = bridge->bus->sysdata;
> +
> + ACPI_COMPANION_SET(>dev, root->device);
> + return 0;
> +}
> +
> +void pcibios_add_bus(struct pci_bus *bus)
> +{
> + acpi_pci_add_bus(bus);
> +}
> +
> +void pcibios_remove_bus(struct pci_bus *bus)
> +{
> + acpi_pci_remove_bus(bus);
> +}
> +
> +static int __init pcibios_assign_resources(void)
> +{
> + if (acpi_disabled)
> + return 0;
> +
> + pci_assign_unassigned_resources();
> + return 0;

You can change this function into:
{
if (!acpi_disabled)
pci_assign_unassigned_resources();

return 0;
}

as the equivalent but shorter form.

> +}
>  /*
> - * raw_pci_read/write - Platform-specific PCI config space access.
> + * rootfs_initcall comes after subsys_initcall and fs_initcall_sync,
> + * so we know acpi scan and PCI_FIXUP_FINAL quirks have both run.
>   */
> -int raw_pci_read(unsigned int domain, unsigned int bus,
> -   unsigned int devfn, int reg, int len, u32 *val)

What happened with raw_pci_{read,write} ? Why do you remove them?


> +rootfs_initcall(pcibios_assign_resources);

Would you be so kind and explain to me why you need this initcall?
Can you not set the PCI_REASSIGN_ALL_RSRC flag before calling
pci_scan_root_bus() ?

I haven't focused on ACPI before so I'm a bit hazy on the init order when
that is enabled. That being said, I don't like adding in the architecture
code initcall hooks just to fix up some dependency orders that could / should
be fixed some other way.

> +
> +static void __iomem *
> +pci_mcfg_dev_base(struct pci_bus *bus, unsigned int devfn, int offset)
>  {
> - return -ENXIO;
> + struct pci_mmcfg_region *cfg;
> +
> + cfg = pci_mmconfig_lookup(pci_domain_nr(bus), bus->number);
> + if (cfg && cfg->virt)
> + return cfg->virt +
> + (PCI_MMCFG_BUS_OFFSET(bus->number) | (devfn << 12)) +
> + offset;
> + return NULL;
>  }
>  
> -int raw_pci_write(unsigned int domain, unsigned int bus,
> - unsigned int devfn, int reg, int len, u32 val)
> +struct pci_ops pci_root_ops = {
> + .map_bus = pci_mcfg_dev_base,
> + .read = pci_generic_config_read,
> + .write = pci_generic_config_write,
> +};
> +
> +#ifdef 

Re: [PATCH 31/52] perf stat record: Synthesize stat record data

[Jiri Olsa]

On Tue, Oct 27, 2015 at 11:42:44AM -0300, Arnaldo Carvalho de Melo wrote:

SNIP

> 
> So, I'm creating a perf/stat branch and putting what I processed so far, with
> the changelog edits and changes in some function/struct names I
> partially mentioned, please try to continue from there, ok?

ok, I'll rebase the rest on yours perf/stat

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

Re: [PATCH] MAINTAINERS: Start using the 'reviewer' (R) tag

[Lee Jones]

On Wed, 28 Oct 2015, Lee Jones wrote:

> On Wed, 28 Oct 2015, Javier Martinez Canillas wrote:
> 
> > Hello Joe,
> > 
> > On Wed, Oct 28, 2015 at 12:06 PM, Joe Perches  wrote:
> > > On Wed, 2015-10-28 at 11:53 +0100, Javier Martinez Canillas wrote:
> > >> (Lee) think(s) that the difference between a maintainer and
> > >> a reviewer is if a branch with fixes / new features are kept and pull
> > >> requests sent while I think that the difference is the level of
> > >> involvement someone has with a driver regardless of how patches ends
> > >> in the subsystem tree (picked directly by subsystem maintainers or
> > >> sent through pull requests).
> > >>
> > >> Is the first time I heard your definition but maybe I'm the one that
> > >> is wrong so it would be great to get a consensus on that and get it
> > >> documented somewhere.
> > >
> > > I think Lee is over-analyzing.
> > >
> > > From MAINTAINERS:
> > > M: Mail patches to: FullName 
> > > R: Designated reviewer: FullName 
> > >These reviewers should be CCed on patches.
> > > S: Status, one of the following:
> > >Supported:   Someone is actually paid to look after this.
> > >Maintained:  Someone actually looks after it.
> > >
> > > "looking after" doesn't mean upstreaming.
> > >
> > 
> > Agreed and upstreaming doesn't mean sending pull request, you can for
> > example upstream the downstream changes for a driver you maintain by
> > posting patches or ack patches others post and let the subsystem
> > maintainer to pick those (even if you are listed as the driver
> > maintainer in MAINTAINERS).
> > 
> > So by following Lee's definition, then most drivers' maintainers
> > should not be called maintainers since keeping a tree with patches for
> > both fixes and new features, sending pull requests, etc is only
> > justified for drivers that have a lot of changes per release. Is not
> > worth it for drivers that are in "maintenance mode" where only bugs
> > are fixed every once in a while or features are seldom added.
> 
> Exactly right.
> 
> Although, it looks like M: doesn't even mean Maintainer.  If it did, I
> would have made these points over and over until death (or until I got
> bored).  However, as M: actually means "Mail patches to", there seems
> to be very little difference between that and "Designated reviewer"
> and makes me wonder why the R: tag was ever even introduced.  I guess
> all of the other guys in the threads below also thought M: meant
> Maintainer, or else they would have just added poor old Josh as a
> "Mail patches to" recipient and been done with it.

Ah, but wait.  get_maintainer.pl *does* assume M means Maintainer
doesn't it?  Which is why this came about.  So if we have a "Mail
patches to" entry, get_maintainer.pl tells the user that this is a
Maintainer, which (given that there are over 1000 unique M: entries
and I know that there are no where near that many actual Maintainers)
means that it's printing out incorrect information most of the time.

So back to my original thought then, what can we do to rectify this
situation and make the information printed more meaningful.  Again,
I'm back to using the R: tag appropriately.

Any (technical, which aren't based on "but I really want to be listed
as a Maintainer") thoughts?

> > > The original threads for this were:
> > >
> > > http://lists.linuxfoundation.org/pipermail/ksummit-discuss/2014-May/000830.html
> > > https://lkml.org/lkml/2014/6/2/446

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/