Re: [PATCH v2 07/11] omap: remove old hsmmc.[ch] and in Makefile

[Ulf Hansson]

- Trimmed cc-list (could be a good idea for next submission as well)

On Mon, 21 Oct 2019 at 19:11, Tony Lindgren  wrote:
>
> * H. Nikolaus Schaller  [191021 17:08]:
> >
> > > Am 21.10.2019 um 16:30 schrieb Tony Lindgren :
> > >
> > > * H. Nikolaus Schaller  [191019 18:43]:
> > >> --- a/arch/arm/mach-omap2/Makefile
> > >> +++ b/arch/arm/mach-omap2/Makefile
> > >> @@ -216,7 +216,6 @@ obj-$(CONFIG_MACH_NOKIA_N8X0)  += 
> > >> board-n8x0.o
> > >>
> > >> # Platform specific device init code
> > >>
> > >> -omap-hsmmc-$(CONFIG_MMC_OMAP_HS)  := hsmmc.o
> > >> obj-y  += $(omap-hsmmc-m) 
> > >> $(omap-hsmmc-y)
> > >
> > > The related obj-y line can go now too, right?
> >
> > Yes, I think so. It is a construction that I have never seen before :)
> > Therefore I did not recognize that it is related.
> >
> > > And looks like common.h also has struct omap2_hsmmc_info
> > > so maybe check by grepping for hsmmc_info to see it's gone.
> >
> > Yes, it is just a forward-declaration of the struct name with
> > no user anywhere.
> >
> > Scheduled for v3.
> >
> > BTW: should this series go through your tree since it is an
> > omap machine?
>
> Or MMC tree as that's where the code change really are.

I am okay with that. I will have a look at the series and provide some comments.

Kind regards
Uffe

Re: [PATCH] drm/amdgpu: Fix memory leak in amdgpu_fence_emit

[Koenig, Christian]

Am 21.10.19 um 20:09 schrieb Navid Emamdoost:
> In the impelementation of amdgpu_fence_emit() if dma_fence_wait() fails
> and returns an errno, before returning the allocated memory for fence
> should be released.
>
> Fixes: 3d2aca8c8620 ("drm/amdgpu: fix old fence check in amdgpu_fence_emit")
> Signed-off-by: Navid Emamdoost 

Reviewed-by: Christian König 

> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
> index 23085b352cf2..2f59c9270a7e 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
> @@ -166,8 +166,10 @@ int amdgpu_fence_emit(struct amdgpu_ring *ring, struct 
> dma_fence **f,
>   if (old) {
>   r = dma_fence_wait(old, false);
>   dma_fence_put(old);
> - if (r)
> + if (r) {
> + dma_fence_put(fence);
>   return r;
> + }
>   }
>   }
>   

Re: [RFC 2/2] vhost: IFC VF vdpa layer

[Zhu Lingshan]

On 10/21/2019 6:19 PM, Jason Wang wrote:


On 2019/10/21 下午5:53, Zhu, Lingshan wrote:


On 10/16/2019 6:19 PM, Jason Wang wrote:


On 2019/10/16 上午9:30, Zhu Lingshan wrote:

This commit introduced IFC VF operations for vdpa, which complys to
vhost_mdev interfaces, handles IFC VF initialization,
configuration and removal.

Signed-off-by: Zhu Lingshan 
---
  drivers/vhost/ifcvf/ifcvf_main.c | 541 
+++

  1 file changed, 541 insertions(+)
  create mode 100644 drivers/vhost/ifcvf/ifcvf_main.c

diff --git a/drivers/vhost/ifcvf/ifcvf_main.c 
b/drivers/vhost/ifcvf/ifcvf_main.c

new file mode 100644
index ..c48a29969a85
--- /dev/null
+++ b/drivers/vhost/ifcvf/ifcvf_main.c
@@ -0,0 +1,541 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2019 Intel Corporation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "ifcvf_base.h"
+
+#define VERSION_STRING    "0.1"
+#define DRIVER_AUTHOR    "Intel Corporation"
+#define IFCVF_DRIVER_NAME    "ifcvf"
+
+static irqreturn_t ifcvf_intr_handler(int irq, void *arg)
+{
+    struct vring_info *vring = arg;
+
+    if (vring->cb.callback)
+    return vring->cb.callback(vring->cb.private);
+
+    return IRQ_HANDLED;
+}
+
+static u64 ifcvf_mdev_get_features(struct mdev_device *mdev)
+{
+    return IFC_SUPPORTED_FEATURES;



I would expect this should be done by querying the hw. Or IFC VF 
can't get any update through its firmware?


Hi Jason,

Thanks for your comments, for now driver just support these features.



Ok, it should work but less flexible, we can change it in the future.

sure!









+}
+
+static int ifcvf_mdev_set_features(struct mdev_device *mdev, u64 
features)

+{
+    struct ifcvf_adapter *adapter = mdev_get_drvdata(mdev);
+    struct ifcvf_hw *vf = IFC_PRIVATE_TO_VF(adapter);
+
+    vf->req_features = features;
+
+    return 0;
+}
+
+static u64 ifcvf_mdev_get_vq_state(struct mdev_device *mdev, u16 qid)
+{
+    struct ifcvf_adapter *adapter = mdev_get_drvdata(mdev);
+    struct ifcvf_hw *vf = IFC_PRIVATE_TO_VF(adapter);
+
+    return vf->vring[qid].last_avail_idx;



Does this really work? I'd expect it should be fetched from hw since 
it's an internal state.

for now, it's working, we intend to support LM in next version drivers.



I'm not sure I understand here, I don't see any synchronization 
between the hardware and last_avail_idx, so last_avail_idx should not 
change.


Btw, what did "LM" mean :) ?


I can add bar IO operations here, LM = live migration, sorry for the 
abbreviation.









+}
+
+static int ifcvf_mdev_set_vq_state(struct mdev_device *mdev, u16 
qid, u64 num)

+{
+    struct ifcvf_adapter *adapter = mdev_get_drvdata(mdev);
+    struct ifcvf_hw *vf = IFC_PRIVATE_TO_VF(adapter);
+
+    vf->vring[qid].last_used_idx = num;



I fail to understand why last_used_idx is needed. It looks to me the 
used idx in the used ring is sufficient.

I will remove it.




+ vf->vring[qid].last_avail_idx = num;



Do we need a synchronization with hw immediately here?



+
+    return 0;
+}
+
+static int ifcvf_mdev_set_vq_address(struct mdev_device *mdev, u16 
idx,

+ u64 desc_area, u64 driver_area,
+ u64 device_area)
+{
+    struct ifcvf_adapter *adapter = mdev_get_drvdata(mdev);
+    struct ifcvf_hw *vf = IFC_PRIVATE_TO_VF(adapter);
+
+    vf->vring[idx].desc = desc_area;
+    vf->vring[idx].avail = driver_area;
+    vf->vring[idx].used = device_area;
+
+    return 0;
+}
+
+static void ifcvf_mdev_set_vq_num(struct mdev_device *mdev, u16 
qid, u32 num)

+{
+    struct ifcvf_adapter *adapter = mdev_get_drvdata(mdev);
+    struct ifcvf_hw *vf = IFC_PRIVATE_TO_VF(adapter);
+
+    vf->vring[qid].size = num;
+}
+
+static void ifcvf_mdev_set_vq_ready(struct mdev_device *mdev,
+    u16 qid, bool ready)
+{
+
+    struct ifcvf_adapter *adapter = mdev_get_drvdata(mdev);
+    struct ifcvf_hw *vf = IFC_PRIVATE_TO_VF(adapter);
+
+    vf->vring[qid].ready = ready;
+}
+
+static bool ifcvf_mdev_get_vq_ready(struct mdev_device *mdev, u16 
qid)

+{
+
+    struct ifcvf_adapter *adapter = mdev_get_drvdata(mdev);
+    struct ifcvf_hw *vf = IFC_PRIVATE_TO_VF(adapter);
+
+    return vf->vring[qid].ready;
+}
+
+static void ifcvf_mdev_set_vq_cb(struct mdev_device *mdev, u16 idx,
+ struct virtio_mdev_callback *cb)
+{
+    struct ifcvf_adapter *adapter = mdev_get_drvdata(mdev);
+    struct ifcvf_hw *vf = IFC_PRIVATE_TO_VF(adapter);
+
+    vf->vring[idx].cb = *cb;
+}
+
+static void ifcvf_mdev_kick_vq(struct mdev_device *mdev, u16 idx)
+{
+    struct ifcvf_adapter *adapter = mdev_get_drvdata(mdev);
+    struct ifcvf_hw *vf = IFC_PRIVATE_TO_VF(adapter);
+
+    ifcvf_notify_queue(vf, idx);
+}
+
+static u8 ifcvf_mdev_get_status(struct mdev_device *mdev)
+{
+    struct ifcvf_adapter *adapter = mdev_get_drvdata(mdev);
+    struct ifcvf_hw *vf = IFC_PRIVATE_TO_VF(adapter);
+
+    return vf->status;
+}
+
+static u32 ifcvf_mdev_get_gen

Re: [PATCH v2 0/2] mm: Memory offlining + page isolation cleanups

[David Hildenbrand]

On 21.10.19 19:23, David Hildenbrand wrote:

Two cleanups that popped up while working on (and discussing) virtio-mem:
  https://lkml.org/lkml/2019/9/19/463

Tested with DIMMs on x86.

As discussed with michal in v1, I'll soon look into removing the use
of PG_reserved during memory onlining completely - most probably
disallowing to offline memory blocks with holes, cleaning up the
onlining+offlining code.


BTW, I remember that ZONE_DEVICE pages are still required to be set 
PG_reserved. That has to be sorted out first. I remember that somebody 
was working on it a while ago but didn't hear about that again. Will 
look into that as well - should be as easy as adding a zone check (if 
there isn't a pfn_to_online_page() check already). But of course, there 
might be special cases 



--

Thanks,

David / dhildenb

Re: [RFC 1/2] vhost: IFC VF hardware operation layer

[Zhu Lingshan]

On 10/22/2019 9:32 AM, Jason Wang wrote:


On 2019/10/22 上午12:31, Simon Horman wrote:

On Mon, Oct 21, 2019 at 05:55:33PM +0800, Zhu, Lingshan wrote:

On 10/16/2019 5:53 PM, Simon Horman wrote:

Hi Zhu,

thanks for your patch.

On Wed, Oct 16, 2019 at 09:10:40AM +0800, Zhu Lingshan wrote:

...


+static void ifcvf_read_dev_config(struct ifcvf_hw *hw, u64 offset,
+   void *dst, int length)
+{
+    int i;
+    u8 *p;
+    u8 old_gen, new_gen;
+
+    do {
+    old_gen = ioread8(&hw->common_cfg->config_generation);
+
+    p = dst;
+    for (i = 0; i < length; i++)
+    *p++ = ioread8((u8 *)hw->dev_cfg + offset + i);
+
+    new_gen = ioread8(&hw->common_cfg->config_generation);
+    } while (old_gen != new_gen);

Would it be wise to limit the number of iterations of the loop above?

Thanks but I don't quite get it. This is used to make sure the function
would get the latest config.

I am worried about the possibility that it will loop forever.
Could that happen?

...



My understanding is that the function here is similar to virtio config 
generation [1]. So this can only happen for a buggy hardware.


Thanks

[1] 
https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.html 
Section 2.4.1

Yes!






+static void io_write64_twopart(u64 val, u32 *lo, u32 *hi)
+{
+    iowrite32(val & ((1ULL << 32) - 1), lo);
+    iowrite32(val >> 32, hi);
+}

I see this macro is also in virtio_pci_modern.c

Assuming lo and hi aren't guaranteed to be sequential
and thus iowrite64_hi_lo() cannot be used perhaps
it would be good to add a common helper somewhere.

Thanks, I will try after this IFC patchwork, I will cc you.

Thanks.

...

[PATCH v2 2/2] habanalabs: handle large memory on MMU

[Omer Shpigelman]

This patch changes the allocation of the host memory pages array to use
vmalloc if needed. This in order to support mapping of large memory
chunks.

Signed-off-by: Omer Shpigelman 
---
 drivers/misc/habanalabs/memory.c | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/misc/habanalabs/memory.c b/drivers/misc/habanalabs/memory.c
index 552a47126567..ed3976f2198d 100644
--- a/drivers/misc/habanalabs/memory.c
+++ b/drivers/misc/habanalabs/memory.c
@@ -1228,7 +1228,7 @@ static int init_sg_list_for_vmalloc_memory(struct 
hl_device *hdev, u64 addr,
u64 tmp_addr;
int i, rc;
 
-   pages = kmalloc_array(npages, sizeof(struct page *), GFP_KERNEL);
+   pages = kvmalloc_array(npages, sizeof(struct page *), GFP_KERNEL);
if (!pages)
return -ENOMEM;
 
@@ -1249,17 +1249,11 @@ static int init_sg_list_for_vmalloc_memory(struct 
hl_device *hdev, u64 addr,
 
rc = sg_alloc_table_from_pages(sgt, pages, npages, offset, size,
GFP_KERNEL);
-   if (rc < 0) {
+   if (rc < 0)
dev_err(hdev->dev, "failed to create SG table from pages\n");
-   goto free_pages;
-   }
-
-   kfree(pages);
-
-   return 0;
 
 free_pages:
-   kfree(pages);
+   kvfree(pages);
return rc;
 }
 
-- 
2.17.1

[PATCH v2 1/2] habanalabs: support kernel memory mapping

[Omer Shpigelman]

In contrary to user memory, kernel memory is already pinned and has no
vm_area structure. Therefore we need a new code path to map this memory.
This is a pre-requisite patch for upstreaming future ASIC support

Signed-off-by: Omer Shpigelman 
---
Changes in v2:
 - use a boolean parameter to indicate for kernel address rather than
   calling is_vmalloc_addr, as kernel and user addresses can overlap on
   some architectures.
 
 drivers/misc/habanalabs/goya/goya.c  |   2 +-
 drivers/misc/habanalabs/habanalabs.h |  18 +-
 drivers/misc/habanalabs/memory.c | 409 +--
 3 files changed, 269 insertions(+), 160 deletions(-)

diff --git a/drivers/misc/habanalabs/goya/goya.c 
b/drivers/misc/habanalabs/goya/goya.c
index e8812154343f..4acc6aeb5b3f 100644
--- a/drivers/misc/habanalabs/goya/goya.c
+++ b/drivers/misc/habanalabs/goya/goya.c
@@ -3932,7 +3932,7 @@ static int goya_parse_cb_no_ext_queue(struct hl_device 
*hdev,
return 0;
 
dev_err(hdev->dev,
-   "Internal CB address %px + 0x%x is not in SRAM nor in DRAM\n",
+   "Internal CB address 0x%px + 0x%x is not in SRAM nor in DRAM\n",
parser->user_cb, parser->user_cb_size);
 
return -EFAULT;
diff --git a/drivers/misc/habanalabs/habanalabs.h 
b/drivers/misc/habanalabs/habanalabs.h
index 4ff2da859653..7eb1cfa49c5d 100644
--- a/drivers/misc/habanalabs/habanalabs.h
+++ b/drivers/misc/habanalabs/habanalabs.h
@@ -696,9 +696,11 @@ struct hl_ctx_mgr {
  * @sgt: pointer to the scatter-gather table that holds the pages.
  * @dir: for DMA unmapping, the direction must be supplied, so save it.
  * @debugfs_list: node in debugfs list of command submissions.
- * @addr: user-space virtual pointer to the start of the memory area.
+ * @addr: virtual address of the start of the memory area.
  * @size: size of the memory area to pin & map.
  * @dma_mapped: true if the SG was mapped to DMA addresses, false otherwise.
+ * @kernel_address: true if the host address is in the kernel address-space.
+ *  i.e. allocated by the kernel driver. false otherwise.
  */
 struct hl_userptr {
enum vm_type_t  vm_type; /* must be first */
@@ -710,6 +712,7 @@ struct hl_userptr {
u64 addr;
u32 size;
u8  dma_mapped;
+   u8  kernel_address;
 };
 
 /**
@@ -1529,9 +1532,20 @@ void hl_vm_ctx_fini(struct hl_ctx *ctx);
 int hl_vm_init(struct hl_device *hdev);
 void hl_vm_fini(struct hl_device *hdev);
 
+int hl_dma_map_host_va(struct hl_device *hdev, u64 addr, u64 size,
+   bool is_kernel_addr, struct hl_userptr **p_userptr);
+void hl_dma_unmap_host_va(struct hl_device *hdev, struct hl_userptr *userptr);
+int hl_init_phys_pg_pack_from_userptr(u32 asid, struct hl_userptr *userptr,
+   struct hl_vm_phys_pg_pack **pphys_pg_pack);
+void hl_free_phys_pg_pack(struct hl_device *hdev,
+   struct hl_vm_phys_pg_pack *phys_pg_pack);
+int hl_map_phys_pg_pack(struct hl_ctx *ctx, u64 vaddr,
+   struct hl_vm_phys_pg_pack *phys_pg_pack);
+void hl_unmap_phys_pg_pack(struct hl_ctx *ctx, u64 vaddr,
+   struct hl_vm_phys_pg_pack *phys_pg_pack);
 int hl_pin_host_memory(struct hl_device *hdev, u64 addr, u64 size,
struct hl_userptr *userptr);
-int hl_unpin_host_memory(struct hl_device *hdev, struct hl_userptr *userptr);
+void hl_unpin_host_memory(struct hl_device *hdev, struct hl_userptr *userptr);
 void hl_userptr_delete_list(struct hl_device *hdev,
struct list_head *userptr_list);
 bool hl_userptr_is_pinned(struct hl_device *hdev, u64 addr, u32 size,
diff --git a/drivers/misc/habanalabs/memory.c b/drivers/misc/habanalabs/memory.c
index 365fb0cb8dff..552a47126567 100644
--- a/drivers/misc/habanalabs/memory.c
+++ b/drivers/misc/habanalabs/memory.c
@@ -159,20 +159,22 @@ static int alloc_device_memory(struct hl_ctx *ctx, struct 
hl_mem_in *args,
 }
 
 /*
- * get_userptr_from_host_va - initialize userptr structure from given host
- *virtual address
- *
- * @hdev: habanalabs device structure
- * @args: parameters containing the virtual address and size
- * @p_userptr   : pointer to result userptr structure
+ * hl_dma_map_host_va() - DMA mapping of the given host virtual address.
+ * @hdev: habanalabs device structure.
+ * @addr: the host virtual address of the memory area.
+ * @size: the size of the memory area.
+ * @is_kernel_addr: true if the host address is in the kernel address-space.
+ *  i.e. allocated by the kernel driver. false otherwise.
+ * @p_userptr: pointer to result userptr structure.
  *
  * This function does the following:
- * - Allocate userptr structure
- * - Pin the given host memory using the userptr structure
- * - Perfor

Re: [PATCH v2] ACPI / processor_idle: use ndelay instead of io port access for wait

[Yin Fengwei]

On 2019/10/18 下午6:12, Rafael J. Wysocki wrote:

On Wednesday, October 16, 2019 7:56:17 AM CEST Yin, Fengwei wrote:

Hi David,

On 10/15/2019 7:48 PM, David Laight wrote:

From: Yin Fengwei

Sent: 15 October 2019 09:04
In function acpi_idle_do_entry(), an ioport access is used for dummy
wait to guarantee hardware behavior. But it could trigger unnecessary
vmexit in virtualization environment.

If we run linux as guest and export all available native C state to
guest, we did see many PM timer access triggered VMexit when guest
enter deeper C state in our environment (We used ACRN hypervisor
instead of kvm or xen which has PM timer emulated and exports all
native C state to guest).

According to the original comments of this part of code, io port
access is only for dummy wait. We could use busy wait instead of io
port access to guarantee hardware behavior and avoid unnecessary
VMexit.


You need some hard synchronisation instruction(s) after the inb()
and before any kind of delay to ensure your delay code is executed
after the inb() completes.

I'm pretty sure that inb() is only synchronised with memory reads.

Thanks a lot for the comments.

I didn't find the common serializing instructions API in kernel (only
memory  barrier which is used to make sure of memory access). For Intel
x86, cpuid could be used as serializing instruction. But it's not
suitable for common code here. Do you have any suggestion?


In the virt guest case you don't need to worry at all AFAICS, because the inb()
itself will trap to the HV.



...

+   /* profiling the time used for dummy wait op */
+   ktime_get_real_ts64(&ts0);
+   inl(acpi_gbl_FADT.xpm_timer_block.address);
+   ktime_get_real_ts64(&ts1);


You may as well use ktime_get() for this, as it's almost the same code as
ktime_get_real_ts64() AFAICS, only simpler.

Plus, static vars need not be initialized to 0.



That could be dominated by the cost of ktime_get_real_ts64().
It also need synchronising instructions.

I did some testing. ktime_get_real_ts64() takes much less time than io
port access.

The test code is like:
1.
local_irq_save(flag);
ktime_get_real_ts64(&ts0);
inl(acpi_gbl_FADT.xpm_timer_block.address);
ktime_get_real_ts64(&ts1);
local_irq_restore(flag);

2.
local_irq_save(flag);
ktime_get_real_ts64(&ts0);
ktime_get_real_ts64(&ts1);
local_irq_restore(flag);

The delta in 1 is about 50ns. And delta in 2 is about
2000ns. The date is gotten on Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz.
So I suppose the impact of ktime_get_real_ts64 is small.


You may not be hitting the worst case for ktime_get_real_ts64(), though.

I wonder if special casing the virt guest would be a better approach.

Then, you could leave the code as is for non-virt and I'm not sure if the
delay is needed in the virt guest case at all.

So maybe do something like "if not in a virt guest, do the dummy inl()"
and that would be it?

After re-think the scenario again, I'd like to change the patch to
something like following as Rafael suggested:

If it's not in virt guest, we still use inl for dummy wait.
If it's in virt guest, we could assume inb will be trapped to HV and
remove the dummy wait.

I will generate v3 soon.

Regards
Yin, Fengwei

Re: [PATCH 1/6] arm64: dts: rockchip: Fix rk3399-roc-pc pwm2 pin

[djw]

Sorry for the late reply, been stung by the mismatch use of ATF and U-Boot. If
you're using U-Boot version before v2019.10, make sure to use the ATF version
before this commit:

commit 0aad563c74807195cc7fe2208d17e2d889157f1e (HEAD, tag: blacksheep, 
refs/bisect/bad)
Author: Kever Yang 
Date:   Thu Sep 19 10:37:36 2019 +0800

rockchip: Update BL31_BASE to 0x4

or use the master branch in git://git.denx.de/u-boot-rockchip.git .

This is very important, or you'll be stuck at:

U-Boot TPL 2019.10-djw (Oct 22 2019 - 03:08:48)
Trying to boot from BOOTROM
Returning to boot ROM...

U-Boot SPL 2019.10-djw (Oct 22 2019 - 03:08:48 +)
Trying to boot from MMC1

I have tried the following combination:

 - U-Boot: v2019.10
 - ATF: 382ddb3dd46a rockchip: Fix typo for TF content text
 - Kernel: 5.4.0-rc3-next-20191017

*Without* the pwm patch, all boot fine. Here's the full log:

#+begin_src text
U-Boot TPL 2019.10-djw (Oct 22 2019 - 03:51:17)
Trying to boot from BOOTROM
Returning to boot ROM...

U-Boot SPL 2019.10-djw (Oct 22 2019 - 03:51:17 +)
Trying to boot from MMC1


U-Boot 2019.10-djw (Oct 22 2019 - 03:51:20 +)

Model: Firefly ROC-RK3399-PC Board
DRAM:  3.9 GiB
MMC:   dwmmc@fe32: 1, sdhci@fe33: 0
Loading Environment from EXT4... Card did not respond to voltage select!
In:serial@ff1a
Out:   serial@ff1a
Err:   serial@ff1a
Model: Firefly ROC-RK3399-PC Board
rockchip_dnl_key_pressed: adc_channel_single_shot fail!
Net:
Error: ethernet@fe30 address not set.
eth-1: ethernet@fe30
Hit any key to stop autoboot:  0
Card did not respond to voltage select!
switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:1...
Found U-Boot script /boot/boot.scr
2995 bytes read in 5 ms (585 KiB/s)
## Executing script at 0050
Boot script loaded from mmc 1
186 bytes read in 4 ms (44.9 KiB/s)
6748991 bytes read in 290 ms (22.2 MiB/s)
26163712 bytes read in 1110 ms (22.5 MiB/s)
53831 bytes read in 10 ms (5.1 MiB/s)
2698 bytes read in 8 ms (329.1 KiB/s)
Applying kernel provided DT fixup script (rockchip-fixup.scr)
## Executing script at 3900
## Loading init Ramdisk from Legacy Image at 0400 ...
   Image Name:   uInitrd
   Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
   Data Size:6748927 Bytes = 6.4 MiB
   Load Address: 
   Entry Point:  
   Verifying Checksum ... OK
## Flattened Device Tree blob at 01f0
   Booting using the fdt blob at 0x1f0
   Loading Ramdisk to f58b, end f5f1faff ... OK
   Loading Device Tree to f583a000, end f58a ... OK

Starting kernel ...

[0.00] Booting Linux on physical CPU 0x00 [0x410fd034]
[0.00] Linux version 5.4.0-rc3-next-20191017-05460-g3ef845da3c3b-dirty 
(dujw@tchip14) (gcc version 5.4.0 20160609 (Ubuntu/Linaro 
5.4.0-6ubuntu1~16.04.9)) #8 SMP PREEMPT Tue Oct 22 12:08:35 CST 2019
[0.00] Machine model: Firefly ROC-RK3399-PC Board
[0.00] earlycon: uart8250 at MMIO32 0xff1a (options '')
[0.00] printk: bootconsole [uart8250] enabled
[0.00] efi: Getting EFI parameters from FDT:
[0.00] efi: UEFI not found.
[0.00] cma: Reserved 32 MiB at 0x3e00
[0.00] NUMA: No NUMA configuration found
[0.00] NUMA: Faking a node at [mem 
0x0020-0xf7ff]
[0.00] NUMA: NODE_DATA [mem 0xf77ef100-0xf77f0fff]
[0.00] Zone ranges:
[0.00]   DMA  [mem 0x0020-0x3fff]
[0.00]   DMA32[mem 0x4000-0xf7ff]
[0.00]   Normal   empty
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x0020-0xf7ff]
[0.00] Initmem setup node 0 [mem 0x0020-0xf7ff]
[0.00] psci: probing for conduit method from DT.
[0.00] psci: PSCIv1.1 detected in firmware.
[0.00] psci: Using standard PSCI v0.2 function IDs
[0.00] psci: MIGRATE_INFO_TYPE not supported.
[0.00] psci: SMC Calling Convention v1.1
[0.00] percpu: Embedded 22 pages/cpu s52952 r8192 d28968 u90112
[0.00] Detected VIPT I-cache on CPU0
[0.00] CPU features: detected: ARM erratum 845719
[0.00] CPU features: detected: GIC system register CPU interface
[0.00] Speculative Store Bypass Disable mitigation not required
[0.00] Built 1 zonelists, mobility grouping on.  Total pages: 999432
[0.00] Policy zone: DMA32
[0.00] Kernel command line: 
root=UUID=78f156fe-c41f-4fdc-93f1-5d30f67659c8 rootwait rootfstype=ext4 
console=ttyS2,150 earlycon=uart8250,mmio32,0xff1a swiotlb=1 
console=tty1 panic=10 consoleblank=0 loglevel=7 ubootpart=e636e926-01 
usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u   cgroup_enable=cpuset 
cgroup_memory=1 cgroup_enable=memory swapaccount=1
[0.00] Dentry cache hash t

Re: [PATCH v5 0/9] Enable Sub-page Write Protection Support

[Yang Weijiang]

On Fri, Oct 11, 2019 at 09:11:54AM -0700, Jim Mattson wrote:
> On Fri, Oct 11, 2019 at 12:48 AM Yang Weijiang  
> wrote:
> >
> > On Thu, Oct 10, 2019 at 02:42:51PM -0700, Jim Mattson wrote:
> > > On Tue, Sep 17, 2019 at 1:52 AM Yang Weijiang  
> > > wrote:
> > > >
> > > > EPT-Based Sub-Page write Protection(SPP)is a HW capability which allows
> > > > Virtual Machine Monitor(VMM) to specify write-permission for guest
> > > > physical memory at a sub-page(128 byte) granularity. When this
> > > > capability is enabled, the CPU enforces write-access check for sub-pages
> > > > within a 4KB page.
> > > >
> > > > The feature is targeted to provide fine-grained memory protection for
> > > > usages such as device virtualization, memory check-point and VM
> > > > introspection etc.
> > > >
> > > > SPP is active when the "sub-page write protection" (bit 23) is 1 in
> > > > Secondary VM-Execution Controls. The feature is backed with a Sub-Page
> > > > Permission Table(SPPT), SPPT is referenced via a 64-bit control field
> > > > called Sub-Page Permission Table Pointer (SPPTP) which contains a
> > > > 4K-aligned physical address.
> > > >
> > > > To enable SPP for certain physical page, the gfn should be first mapped
> > > > to a 4KB entry, then set bit 61 of the corresponding EPT leaf entry.
> > > > While HW walks EPT, if bit 61 is set, it traverses SPPT with the guset
> > > > physical address to find out the sub-page permissions at the leaf entry.
> > > > If the corresponding bit is set, write to sub-page is permitted,
> > > > otherwise, SPP induced EPT violation is generated.
> > >
> > > How do you handle sub-page permissions for instructions emulated by kvm?
> > How about checking if the gpa is SPP protected, if it is, inject some
> > exception to guest?
> The SPP semantics are well-defined. If a kvm-emulated instruction
> tries to write to a sub-page that is write-protected, then an
> SPP-induced EPT violation should be synthesized.
Hi, Jim,

Regarding the emulated instructions in KVM, there're quite a few
instructions can write guest memory, such as MOVS, XCHG, INS etc.,
check each destination against SPP protected area would be trivial if
deals with them individually, and PIO/MMIO induced vmexit/page_fault also
can link to a SPP protected page, e.g., a string instruction's the destination
is SPP protected memory. Is there a good way to intercept these writes?
emulate_ops.write_emulated() is called in most of the emulation cases to
check and write guest memory, but not sure it's suitable.
Do you have any suggestion?

Thanks!

Re: [PATCH v2 02/13] arm64: dts: sc7180: Add minimal dts/dtsi files for SC7180 soc

[Rajendra Nayak]

Hi Matthias, thanks for the review

On 10/22/2019 5:38 AM, Matthias Kaehlcke wrote:

Hi Rajendra,

I don't have all the hardware documentation for a full review, but
find a few comments inline.


[]..


+#include "sc7180.dtsi"
+
+/ {
+   model = "Qualcomm Technologies, Inc. SC7180 IDP";
+   compatible = "qcom,sc7180-idp";
+
+   aliases {
+   serial0 = &uart2;
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+};
+
+&qupv3_id_0 {
+   status = "okay";
+};
+
+&uart2 {
+   status = "okay";
+};
+
+/* PINCTRL - additions to nodes defined in sc7180.dtsi */
+
+&qup_uart2_default {
+   pinconf-tx {
+   pins = "gpio44";
+   drive-strength = <2>;
+   bias-disable;
+   };
+
+   pinconf-rx {
+   pins = "gpio45";
+   drive-strength = <2>;
+   bias-pull-up;
+   };
+};


This config seems reasonable as default for a UART in general.
Would it make sense to configure these in the SoC .dtsi?


I think the general rule of thumb that was followed was to have
all pinmux configurations in soc file and all pinconf setting in
the board, even though it meant a bit of duplication in some cases.
See [1] for some discussions around it that happened in the past.

[1] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1603693.html




diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi 
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
new file mode 100644
index ..82bf7cdce6b8
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -0,0 +1,300 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * SC7180 SoC device tree source
+ *
+ * Copyright (c) 2019, The Linux Foundation. All rights reserved.
+ */
+
+#include 


Note: depends on "Add Global Clock controller (GCC) driver for SC7180"
(https://patchwork.kernel.org/project/linux-arm-msm/list/?submitter=179717)
which isn't merged yet.


Right, I did mention it in the cover letter, perhaps I should have mentioned it
as part of this patch as well.

[]..

+
+   soc: soc {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges = <0 0 0 0 0x10 0>;
+   dma-ranges = <0 0 0 0  0x10 0>;
+   compatible = "simple-bus";
+
+   gcc: clock-controller@10 {
+   compatible = "qcom,gcc-sc7180";





+   reg = <0 0x0010 0 0x1f>;
+   #clock-cells = <1>;
+   #reset-cells = <1>;
+   #power-domain-cells = <1>;
+   };
+
+   qupv3_id_0: geniqup@ac {


The QUP enumeration is a bit confusing. The Hardware Register
Description has QUPV3_0_QUPV3_ID_0 at 0x0080 and
QUPV3_1_QUPV3_ID_0 at 0x00a0. This QUP apparently is
the latter. In the SDM845 DT the QUP @ac has the label
'qupv3_id_1', I guess this should be the same here.


I had a re-look at the documentation again and yes, you are
right, this seems exactly same as on sdm845 except that on
sdm845 the 2 blocks were named QUPV3_0_QUPV3_ID_1 at 0x0080
and QUPV3_1_QUPV3_ID_1 at 0x00a0.
I will match this up with the labeling approach we followed on
sdm845. Thanks.




+   compatible = "qcom,geni-se-qup";
+   reg = <0 0x00ac 0 0x6000>;
+   clock-names = "m-ahb", "s-ahb";
+   clocks = <&gcc GCC_QUPV3_WRAP_1_M_AHB_CLK>,
+<&gcc GCC_QUPV3_WRAP_1_S_AHB_CLK>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+   status = "disabled";
+
+   uart2: serial@a88000 {
+   compatible = "qcom,geni-debug-uart";
+   reg = <0 0x00a88000 0 0x4000>;


Related to the comment above: on SDM845 this UART has the label
'uart10'. I understand these are different SoCs, but could you
please clarify the enumeration of the SC7180 QUPs and their ports?


I will move this to uart10 once I have the qup instance marked with id_1.
On sdm845 the qup_id_0 had SE instances from 0 to 7 and qup_id_1 had it
from 8 to 15. I will follow the same here so this uart instance would
remain the same as on sdm845, which is uart10.

thanks,
Rajendra




+   clock-names = "se";
+   clocks = <&gcc GCC_QUPV3_WRAP1_S2_CLK>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&qup_uart2_default>;
+   interrupts = ;
+   status = "disabled";
+   };
+   };
+




--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH] xfrm : lock input tasklet skb queue

[Herbert Xu]

On Mon, Oct 21, 2019 at 09:31:13AM -0700, Tom Rix wrote:
> When preempt rt is full, softirq and interrupts run in kthreads. So it
> is possible for the tasklet to sleep and for its queue to get modified
> while it sleeps.

This is ridiculous.  The network stack is full of assumptions
like this.  So I think we need to fix preempt rt instead because
you can't make a major change like this without auditing the entire
kernel first rather than relying on a whack-a-mole approach.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] usb: gadget: udc: Fix assignment of 0/1 to bool variables

[Felipe Balbi]

Hi,

Michal Simek  writes:
>> @@ -1952,9 +1952,9 @@ static void xudc_nonctrl_ep_handler(struct xusb_udc 
>> *udc, u8 epnum,
>>  ep = &udc->ep[epnum];
>>  /* Process the End point interrupts.*/
>>  if (intrstatus & (XUSB_STATUS_EP0_BUFF1_COMP_MASK << epnum))
>> -ep->buffer0ready = 0;
>> +ep->buffer0ready = false;
>>  if (intrstatus & (XUSB_STATUS_EP0_BUFF2_COMP_MASK << epnum))
>> -ep->buffer1ready = 0;
>> +ep->buffer1ready = false;
>>  
>>  if (list_empty(&ep->queue))
>>  return;
>> 
>
> Acked-by: Michal Simek 

I don't have the original patch, sorry. Care to resend with Acks?

-- 
balbi

Re: [PATCH v4 5/5] net: dsa: add support for Atheros AR9331 build-in switch

[Randy Dunlap]

On 10/21/19 10:57 PM, Oleksij Rempel wrote:
> Provide basic support for Atheros AR9331 build-in switch. So far it

   built-in

> works as port multiplexer without any hardware offloading support.
> 
> Signed-off-by: Oleksij Rempel 
> ---

> diff --git a/drivers/net/dsa/qca/Kconfig b/drivers/net/dsa/qca/Kconfig
> new file mode 100644
> index ..7e4978f46642
> --- /dev/null
> +++ b/drivers/net/dsa/qca/Kconfig
> @@ -0,0 +1,11 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +config NET_DSA_AR9331
> + tristate "Atheros AR9331 Ethernet switch support"
> + depends on NET_DSA
> + select NET_DSA_TAG_AR9331
> + select REGMAP
> + ---help---
> +   This enables support for the Atheros AR9331 build-in Ethernet

  built-in

> +   switch.
> +
> +

Thanks.
-- 
~Randy

Re: [PATCH v4 4/5] net: dsa: add support for Atheros AR9331 TAG format

[Randy Dunlap]

On 10/21/19 10:57 PM, Oleksij Rempel wrote:
> Add support for tag format used in Atheros AR9331 build-in switch.

built-in

> 
> Signed-off-by: Oleksij Rempel 
> ---
>  include/net/dsa.h|  2 +
>  net/dsa/Kconfig  |  6 +++
>  net/dsa/Makefile |  1 +
>  net/dsa/tag_ar9331.c | 96 
>  4 files changed, 105 insertions(+)
>  create mode 100644 net/dsa/tag_ar9331.c
> 

> diff --git a/net/dsa/Kconfig b/net/dsa/Kconfig
> index 29e2bd5cc5af..617c9607df5f 100644
> --- a/net/dsa/Kconfig
> +++ b/net/dsa/Kconfig
> @@ -29,6 +29,12 @@ config NET_DSA_TAG_8021Q
>  
> Drivers which use these helpers should select this as dependency.
>  
> +config NET_DSA_TAG_AR9331
> + tristate "Tag driver for Atheros AR9331 SoC with build-in switch"

 built-in

> + help
> +   Say Y or M if you want to enable support for tagging frames for
> +   the Atheros AR9331 SoC with build-in switch.

  built-in

> +
>  config NET_DSA_TAG_BRCM_COMMON
>   tristate
>   default n


thanks.
-- 
~Randy

Re: [PATCH 2/4] Bluetooth: hci_qca: Don't vote for specific voltage

[Balakrishna Godavarthi]

Hi Matthias, Bjorn andresson,

On 2019-10-21 12:07, Harish Bandi wrote:

+ Bala

On 2019-10-18 23:52, Matthias Kaehlcke wrote:

On Thu, Oct 17, 2019 at 10:24:02PM -0700, Bjorn Andersson wrote:

Devices with specific voltage requirements should not request voltage
from the driver, but instead rely on the system configuration to 
define

appropriate voltages for each rail.

This ensures that PMIC and board variations are accounted for, 
something

that the 0.1V range in the hci_qca driver currently tries to address.
But on the Lenovo Yoga C630 (with wcn3990) vddch0 is 3.1V, which 
means

the driver will fail to set the voltage.

Signed-off-by: Bjorn Andersson 
---
 drivers/bluetooth/hci_qca.c | 26 --
 1 file changed, 8 insertions(+), 18 deletions(-)

diff --git a/drivers/bluetooth/hci_qca.c 
b/drivers/bluetooth/hci_qca.c

index c07c529b0d81..54aafcc69d06 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -130,8 +130,6 @@ enum qca_speed_type {
  */
 struct qca_vreg {
const char *name;
-   unsigned int min_uV;
-   unsigned int max_uV;
unsigned int load_uA;
 };

@@ -1332,10 +1330,10 @@ static const struct hci_uart_proto qca_proto 
= {

 static const struct qca_vreg_data qca_soc_data_wcn3990 = {
.soc_type = QCA_WCN3990,
.vregs = (struct qca_vreg []) {
-   { "vddio",   180, 190,  15000  },
-   { "vddxo",   180, 190,  8  },
-   { "vddrf",   130, 135,  30 },
-   { "vddch0",  330, 340,  45 },
+   { "vddio", 15000  },
+   { "vddxo", 8  },
+   { "vddrf", 30 },
+   { "vddch0", 45 },
},
.num_vregs = 4,
 };
@@ -1343,10 +1341,10 @@ static const struct qca_vreg_data 
qca_soc_data_wcn3990 = {

 static const struct qca_vreg_data qca_soc_data_wcn3998 = {
.soc_type = QCA_WCN3998,
.vregs = (struct qca_vreg []) {
-   { "vddio",   180, 190,  1  },
-   { "vddxo",   180, 190,  8  },
-   { "vddrf",   130, 1352000,  30 },
-   { "vddch0",  330, 330,  45 },
+   { "vddio", 1  },
+   { "vddxo", 8  },
+   { "vddrf", 30 },
+   { "vddch0", 45 },
},
.num_vregs = 4,
 };
@@ -1386,13 +1384,6 @@ static int qca_power_off(struct hci_dev *hdev)
 static int qca_enable_regulator(struct qca_vreg vregs,
struct regulator *regulator)
 {
-   int ret;
-
-   ret = regulator_set_voltage(regulator, vregs.min_uV,
-   vregs.max_uV);
-   if (ret)
-   return ret;
-
return regulator_enable(regulator);

 }
@@ -1401,7 +1392,6 @@ static void qca_disable_regulator(struct 
qca_vreg vregs,

  struct regulator *regulator)
 {
regulator_disable(regulator);
-   regulator_set_voltage(regulator, 0, vregs.max_uV);

 }


This was brought up multiple times during the initial review, but
wasn't addressed.

Reviewed-by: Matthias Kaehlcke 



yes true PMIC dts regulator should do this.
But we have some real time issues observed.

Issue 1:

In PMIC dts node, ASAIK we have three levels of voltages.

1. Default voltage.
2. Minimum voltage. (mandatory entry)
3. Maximum voltage. (mandatory entry)

Let us assume that the if PMIC regulator dts node supports  defaults 
voltage to 3.2 Volts and Min  as 3.1 V and max as 3.3V
So default operating voltage is 3.1V  when we turn on BT (but according 
to spec SoC requires min of 3.3V to operate,

Might have some functionality failures on end to end testing

Issue 2:

WCN3990 RF is shared with WiFi, so it also try to turn on the 
regulators. Wifi driver uses the same approach of restricting to min and 
max voltages in driver.
Let us assume we turned ON BT and CH0 is set to 3.1v (as in your case), 
Wifi is tuned on now, as its request the CH0 to operate at 3.3 Volts, 
regulator will fail to set this voltage as BT is operating

at CH0 3.1v (assuming max voltage is 3.2v)
https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/tree/drivers/net/wireless/ath/ath10k/snoc.c#n39

Issue 3:

By mistake PMIC has low min or default voltage and high max voltages, 
that is harm for WNC3990.


I would suggest to restrict the min and max voltages in driver, instead 
of relaying on PMIC to do this.

BTW pmic will do this and doing it in our driver is safer.

Let me know your views on this.
--
Regards
Balakrishna.

[PATCH v4 4/4] perf/core,x86: synchronize PMU task contexts on optimized context switches

[Alexey Budankov]

Install Intel specific PMU task context synchronization adapter and
extend optimized context switch path with PMU specific task context
synchronization to fix LBR callstack virtualization on context switches.

Signed-off-by: Alexey Budankov 
---
 arch/x86/events/intel/core.c |  7 +++
 kernel/events/core.c | 13 +
 2 files changed, 20 insertions(+)

diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index bbf6588d47ee..b9f518aa478e 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -3820,6 +3820,12 @@ static void intel_pmu_sched_task(struct 
perf_event_context *ctx,
intel_pmu_lbr_sched_task(ctx, sched_in);
 }
 
+static void intel_pmu_sync_task_ctx(struct x86_perf_task_context *one,
+   struct x86_perf_task_context *another)
+{
+   intel_pmu_lbr_sync_task_ctx(one, another);
+}
+
 static int intel_pmu_check_period(struct perf_event *event, u64 value)
 {
return intel_pmu_has_bts_period(event, value) ? -EINVAL : 0;
@@ -3955,6 +3961,7 @@ static __initconst const struct x86_pmu intel_pmu = {
 
.guest_get_msrs = intel_guest_get_msrs,
.sched_task = intel_pmu_sched_task,
+   .sync_task_ctx  = intel_pmu_sync_task_ctx,
 
.check_period   = intel_pmu_check_period,
 
diff --git a/kernel/events/core.c b/kernel/events/core.c
index f9a5d4356562..51d4138b06f7 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -3204,11 +3204,24 @@ static void perf_event_context_sched_out(struct 
task_struct *task, int ctxn,
raw_spin_lock(&ctx->lock);
raw_spin_lock_nested(&next_ctx->lock, SINGLE_DEPTH_NESTING);
if (context_equiv(ctx, next_ctx)) {
+   struct pmu *pmu = ctx->pmu;
+
WRITE_ONCE(ctx->task, next);
WRITE_ONCE(next_ctx->task, task);
 
swap(ctx->task_ctx_data, next_ctx->task_ctx_data);
 
+   /*
+* PMU specific parts of task perf context can require
+* additional synchronization which makes sense only if
+* both next_ctx->task_ctx_data and ctx->task_ctx_data
+* pointers are allocated. As an example of such
+* synchronization see implementation details of Intel
+* LBR call stack data profiling;
+*/
+   if (ctx->task_ctx_data && next_ctx->task_ctx_data)
+   pmu->sync_task_ctx(next_ctx->task_ctx_data,
+  ctx->task_ctx_data);
/*
 * RCU_INIT_POINTER here is safe because we've not
 * modified the ctx and the above modification of
-- 
2.20.1

[PATCH v4 3/4] perf/x86/intel: implement LBR callstacks context synchronization

[Alexey Budankov]

Implement intel_pmu_lbr_sync_task_ctx() method updating counters
of the events that requested LBR callstack data on a sample.

The counter can be zero for the case when task context belongs to
a thread that has just come from a block on a futex and the context
contains saved (lbr_stack_state == LBR_VALID) LBR register values.

For the values to be restored at LBR registers on the next thread's
switch-in event it swaps the counter value with the one that is
expected to be non zero at the previous equivalent task perf event
context.

Swap operation type ensures the previous task perf event context
stays consistent with the amount of events that requested LBR
callstack data on a sample.

Signed-off-by: Alexey Budankov 
---
 arch/x86/events/intel/lbr.c  | 6 ++
 arch/x86/events/perf_event.h | 3 +++
 2 files changed, 9 insertions(+)

diff --git a/arch/x86/events/intel/lbr.c b/arch/x86/events/intel/lbr.c
index ea54634eabf3..3cf58bcb88af 100644
--- a/arch/x86/events/intel/lbr.c
+++ b/arch/x86/events/intel/lbr.c
@@ -417,6 +417,12 @@ static void __intel_pmu_lbr_save(struct 
x86_perf_task_context *task_ctx)
cpuc->last_log_id = ++task_ctx->log_id;
 }
 
+void intel_pmu_lbr_sync_task_ctx(struct x86_perf_task_context *prev,
+struct x86_perf_task_context *next)
+{
+   swap(prev->lbr_callstack_users, next->lbr_callstack_users);
+}
+
 void intel_pmu_lbr_sched_task(struct perf_event_context *ctx, bool sched_in)
 {
struct cpu_hw_events *cpuc = this_cpu_ptr(&cpu_hw_events);
diff --git a/arch/x86/events/perf_event.h b/arch/x86/events/perf_event.h
index be78f2765f74..0474ec6f4771 100644
--- a/arch/x86/events/perf_event.h
+++ b/arch/x86/events/perf_event.h
@@ -1024,6 +1024,9 @@ void intel_pmu_store_pebs_lbrs(struct pebs_lbr *lbr);
 
 void intel_ds_init(void);
 
+void intel_pmu_lbr_sync_task_ctx(struct x86_perf_task_context *prev,
+struct x86_perf_task_context *next);
+
 void intel_pmu_lbr_sched_task(struct perf_event_context *ctx, bool sched_in);
 
 u64 lbr_from_signext_quirk_wr(u64 val);
-- 
2.20.1

[PATCH v4 3/3] mmc: host: sdhci-sprd: Add software queue support

[Baolin Wang]

Add software queue support to improve the performance.

Signed-off-by: Baolin Wang 
---
 drivers/mmc/host/Kconfig  |1 +
 drivers/mmc/host/sdhci-sprd.c |   26 ++
 2 files changed, 27 insertions(+)

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index efa4019..54b86f6 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -632,6 +632,7 @@ config MMC_SDHCI_SPRD
depends on ARCH_SPRD
depends on MMC_SDHCI_PLTFM
select MMC_SDHCI_IO_ACCESSORS
+   select MMC_HSQ
help
  This selects the SDIO Host Controller in Spreadtrum
  SoCs, this driver supports R11(IP version: R11P0).
diff --git a/drivers/mmc/host/sdhci-sprd.c b/drivers/mmc/host/sdhci-sprd.c
index d07b979..3cc1277 100644
--- a/drivers/mmc/host/sdhci-sprd.c
+++ b/drivers/mmc/host/sdhci-sprd.c
@@ -19,6 +19,7 @@
 #include 
 
 #include "sdhci-pltfm.h"
+#include "mmc_hsq.h"
 
 /* SDHCI_ARGUMENT2 register high 16bit */
 #define SDHCI_SPRD_ARG2_STUFF  GENMASK(31, 16)
@@ -379,6 +380,16 @@ static unsigned int sdhci_sprd_get_ro(struct sdhci_host 
*host)
return 0;
 }
 
+static void sdhci_sprd_request_done(struct sdhci_host *host,
+   struct mmc_request *mrq)
+{
+   /* Validate if the request was from software queue firstly. */
+   if (mmc_hsq_finalize_request(host->mmc, mrq))
+   return;
+
+mmc_request_done(host->mmc, mrq);
+}
+
 static struct sdhci_ops sdhci_sprd_ops = {
.read_l = sdhci_sprd_readl,
.write_l = sdhci_sprd_writel,
@@ -392,6 +403,7 @@ static unsigned int sdhci_sprd_get_ro(struct sdhci_host 
*host)
.hw_reset = sdhci_sprd_hw_reset,
.get_max_timeout_count = sdhci_sprd_get_max_timeout_count,
.get_ro = sdhci_sprd_get_ro,
+   .request_done = sdhci_sprd_request_done,
 };
 
 static void sdhci_sprd_request(struct mmc_host *mmc, struct mmc_request *mrq)
@@ -521,6 +533,7 @@ static int sdhci_sprd_probe(struct platform_device *pdev)
 {
struct sdhci_host *host;
struct sdhci_sprd_host *sprd_host;
+   struct mmc_hsq *hsq;
struct clk *clk;
int ret = 0;
 
@@ -631,6 +644,16 @@ static int sdhci_sprd_probe(struct platform_device *pdev)
 
sprd_host->flags = host->flags;
 
+   hsq = devm_kzalloc(&pdev->dev, sizeof(*hsq), GFP_KERNEL);
+   if (!hsq) {
+   ret = -ENOMEM;
+   goto err_cleanup_host;
+   }
+
+   ret = mmc_hsq_init(hsq, host->mmc);
+   if (ret)
+   goto err_cleanup_host;
+
ret = __sdhci_add_host(host);
if (ret)
goto err_cleanup_host;
@@ -689,6 +712,7 @@ static int sdhci_sprd_runtime_suspend(struct device *dev)
struct sdhci_host *host = dev_get_drvdata(dev);
struct sdhci_sprd_host *sprd_host = TO_SPRD_HOST(host);
 
+   mmc_hsq_suspend(host->mmc);
sdhci_runtime_suspend_host(host);
 
clk_disable_unprepare(sprd_host->clk_sdio);
@@ -717,6 +741,8 @@ static int sdhci_sprd_runtime_resume(struct device *dev)
goto clk_disable;
 
sdhci_runtime_resume_host(host, 1);
+   mmc_hsq_resume(host->mmc);
+
return 0;
 
 clk_disable:
-- 
1.7.9.5

[PATCH v4 2/3] mmc: host: sdhci: Add request_done ops for struct sdhci_ops

[Baolin Wang]

Add request_done ops for struct sdhci_ops as a preparation in case some
host controllers have different method to complete one request, such as
supporting request completion of MMC software queue.

Signed-off-by: Baolin Wang 
---
 drivers/mmc/host/sdhci.c |   12 ++--
 drivers/mmc/host/sdhci.h |2 ++
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index b056400..850241f 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2729,7 +2729,10 @@ static bool sdhci_request_done(struct sdhci_host *host)
 
spin_unlock_irqrestore(&host->lock, flags);
 
-   mmc_request_done(host->mmc, mrq);
+   if (host->ops->request_done)
+   host->ops->request_done(host, mrq);
+   else
+   mmc_request_done(host->mmc, mrq);
 
return false;
 }
@@ -3157,7 +3160,12 @@ static irqreturn_t sdhci_irq(int irq, void *dev_id)
 
/* Process mrqs ready for immediate completion */
for (i = 0; i < SDHCI_MAX_MRQS; i++) {
-   if (mrqs_done[i])
+   if (!mrqs_done[i])
+   continue;
+
+   if (host->ops->request_done)
+   host->ops->request_done(host, mrqs_done[i]);
+   else
mmc_request_done(host->mmc, mrqs_done[i]);
}
 
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 0ed3e0e..d89cdb9 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -644,6 +644,8 @@ struct sdhci_ops {
void(*voltage_switch)(struct sdhci_host *host);
void(*adma_write_desc)(struct sdhci_host *host, void **desc,
   dma_addr_t addr, int len, unsigned int cmd);
+   void(*request_done)(struct sdhci_host *host,
+   struct mmc_request *mrq);
 };
 
 #ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS
-- 
1.7.9.5

[PATCH v4 1/3] mmc: Add MMC host software queue support

[Baolin Wang]

Now the MMC read/write stack will always wait for previous request is
completed by mmc_blk_rw_wait(), before sending a new request to hardware,
or queue a work to complete request, that will bring context switching
overhead, especially for high I/O per second rates, to affect the IO
performance.

Thus this patch introduces MMC software queue interface based on the
hardware command queue engine's interfaces, which is similar with the
hardware command queue engine's idea, that can remove the context
switching. Moreover we set the default queue depth as 32 for software
queue, which allows more requests to be prepared, merged and inserted
into IO scheduler to improve performance, but we only allow 2 requests
in flight, that is enough to let the irq handler always trigger the
next request without a context switch, as well as avoiding a long latency.

>From the fio testing data in cover letter, we can see the software
queue can improve some performance with 4K block size, increasing
about 16% for random read, increasing about 90% for random write,
though no obvious improvement for sequential read and write.

Moreover we can expand the software queue interface to support MMC
packed request or packed command in future.

Signed-off-by: Baolin Wang 
---
 drivers/mmc/core/block.c   |   61 
 drivers/mmc/core/mmc.c |   13 +-
 drivers/mmc/core/queue.c   |   33 -
 drivers/mmc/host/Kconfig   |7 +
 drivers/mmc/host/Makefile  |1 +
 drivers/mmc/host/mmc_hsq.c |  344 
 drivers/mmc/host/mmc_hsq.h |   30 
 include/linux/mmc/host.h   |3 +
 8 files changed, 482 insertions(+), 10 deletions(-)
 create mode 100644 drivers/mmc/host/mmc_hsq.c
 create mode 100644 drivers/mmc/host/mmc_hsq.h

diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
index 2c71a43..870462c 100644
--- a/drivers/mmc/core/block.c
+++ b/drivers/mmc/core/block.c
@@ -168,6 +168,11 @@ struct mmc_rpmb_data {
 
 static inline int mmc_blk_part_switch(struct mmc_card *card,
  unsigned int part_type);
+static void mmc_blk_rw_rq_prep(struct mmc_queue_req *mqrq,
+  struct mmc_card *card,
+  int disable_multi,
+  struct mmc_queue *mq);
+static void mmc_blk_swq_req_done(struct mmc_request *mrq);
 
 static struct mmc_blk_data *mmc_blk_get(struct gendisk *disk)
 {
@@ -1569,9 +1574,30 @@ static int mmc_blk_cqe_issue_flush(struct mmc_queue *mq, 
struct request *req)
return mmc_blk_cqe_start_req(mq->card->host, mrq);
 }
 
+static int mmc_blk_swq_issue_rw_rq(struct mmc_queue *mq, struct request *req)
+{
+   struct mmc_queue_req *mqrq = req_to_mmc_queue_req(req);
+   struct mmc_host *host = mq->card->host;
+   int err;
+
+   mmc_blk_rw_rq_prep(mqrq, mq->card, 0, mq);
+   mqrq->brq.mrq.done = mmc_blk_swq_req_done;
+   mmc_pre_req(host, &mqrq->brq.mrq);
+
+   err = mmc_cqe_start_req(host, &mqrq->brq.mrq);
+   if (err)
+   mmc_post_req(host, &mqrq->brq.mrq, err);
+
+   return err;
+}
+
 static int mmc_blk_cqe_issue_rw_rq(struct mmc_queue *mq, struct request *req)
 {
struct mmc_queue_req *mqrq = req_to_mmc_queue_req(req);
+   struct mmc_host *host = mq->card->host;
+
+   if (host->swq_enabled)
+   return mmc_blk_swq_issue_rw_rq(mq, req);
 
mmc_blk_data_prep(mq, mqrq, 0, NULL, NULL);
 
@@ -1957,6 +1983,41 @@ static void mmc_blk_urgent_bkops(struct mmc_queue *mq,
mmc_run_bkops(mq->card);
 }
 
+static void mmc_blk_swq_req_done(struct mmc_request *mrq)
+{
+   struct mmc_queue_req *mqrq =
+   container_of(mrq, struct mmc_queue_req, brq.mrq);
+   struct request *req = mmc_queue_req_to_req(mqrq);
+   struct request_queue *q = req->q;
+   struct mmc_queue *mq = q->queuedata;
+   struct mmc_host *host = mq->card->host;
+   unsigned long flags;
+
+   if (mmc_blk_rq_error(&mqrq->brq) ||
+   mmc_blk_urgent_bkops_needed(mq, mqrq)) {
+   spin_lock_irqsave(&mq->lock, flags);
+   mq->recovery_needed = true;
+   mq->recovery_req = req;
+   spin_unlock_irqrestore(&mq->lock, flags);
+
+   host->cqe_ops->cqe_recovery_start(host);
+
+   schedule_work(&mq->recovery_work);
+   return;
+   }
+
+   mmc_blk_rw_reset_success(mq, req);
+
+   /*
+* Block layer timeouts race with completions which means the normal
+* completion path cannot be used during recovery.
+*/
+   if (mq->in_recovery)
+   mmc_blk_cqe_complete_rq(mq, req);
+   else
+   blk_mq_complete_request(req);
+}
+
 void mmc_blk_mq_complete(struct request *req)
 {
struct mmc_queue *mq = req->q->queuedata;
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index c880489..8eac1a2 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc

[PATCH v4 2/4] perf/x86: install platform specific sync_task_ctx adapter

[Alexey Budankov]

Bridge perf core and x86 sync_task_ctx() method calls.

Signed-off-by: Alexey Budankov 
---
 arch/x86/events/core.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
index 7b21455d7504..f51bddf5f48c 100644
--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -2243,6 +2243,12 @@ static void x86_pmu_sched_task(struct perf_event_context 
*ctx, bool sched_in)
x86_pmu.sched_task(ctx, sched_in);
 }
 
+static void x86_pmu_sync_task_ctx(void *prev, void *next)
+{
+   if (x86_pmu.sync_task_ctx)
+   x86_pmu.sync_task_ctx(prev, next);
+}
+
 void perf_check_microcode(void)
 {
if (x86_pmu.check_microcode)
@@ -2297,6 +2303,7 @@ static struct pmu pmu = {
.event_idx  = x86_pmu_event_idx,
.sched_task = x86_pmu_sched_task,
.task_ctx_size  = sizeof(struct x86_perf_task_context),
+   .sync_task_ctx  = x86_pmu_sync_task_ctx,
.check_period   = x86_pmu_check_period,
 
.aux_output_match   = x86_pmu_aux_output_match,
-- 
2.20.1

Re: [RFC][PATCH 2/3] usb: roles: Add usb role switch notifier.

[John Stultz]

On Fri, Oct 18, 2019 at 2:05 PM Hans de Goede  wrote:
> On 18-10-2019 22:37, John Stultz wrote:
> > At least, with the current driver, the functionality is working as
> > expected: remove the USB-C cable, and devices connected to the hub
> > power on, plug something into the USB-C port and devices plugged into
> > the hub shutdown.
> >
> > But maybe I'm missing what you mean?
>
> Ok, so double checking the schematic I do see separate Vbus-es for the
> TypeC port and the TypeA ports, with the TypeC port one being controlled
> by GPIO_202_VBUS_TYPEC. So ideally that gpio would be  controlled to
> enable/disable vbus by the tcpm framework.

So I've given this a shot, adding a gpio regulator for the type-c
vbus, and added a set_vbus hook to the tcpci_rt1711 with logic to
enable and disable the regulator depending on the source state.  I've
also added some debug logic to check the regulator disabling/enabling
is working properly. However, doing the type-c vbus control via the
tcpm logic doesn't seem to be working properly.

The issue seems to be when the USB-C cable is unplugged the device
goes into ROLE_NONE, we switch to the on-board hub. Then when we
connect a USB-C hub to the type-c port, we switch to ROLE_HOST, and
power on the regulator, and that starts to power on the USB-C hub
devices. However, since this disconnects/powers down the on-board hub,
we see the on-board hub device disconnect. I'm guessing the hub
disconnection causes some confusion in the state machine, as then I
see the state change from state change SRC_ATTACHED -> SRC_UNATTACHED,
and set_vbus is immediately called with source=0 and the regulator is
disabled, and we switch back to ROLE_NONE (which powers on the onboard
hub).  The system then seems to quickly oscillate between the
ROLE_HOST and ROLE_NONE switching the regulator on and off fairly
quickly (see log below for more details) and never really settling for
one state or the other.

Any off-hand thoughts on what might be going wrong here? I'm fine to
continue digging and working on this approach, but I also don't want
to have to pollute the core code too much for this oddball hardware
(esp since doing the vbus control in the role-switch intermediary does
work ok - or at least better then this approach so far).

thanks
-john


Starts in ROLE_NONE with nothing connected to type-c port, with the
on-board hub powered on, then we connect a type-c usb hub.

[   57.828323] JDB: tcpm_state_machine_work state chage:
SRC_ATTACH_WAIT->SRC_ATTACH_WAIT
[   58.031325] JDB: state change SRC_ATTACH_WAIT -> SNK_TRY [delayed 200 ms]
[   58.031525] JDB: tcpm_state_machine_work state chage: SNK_TRY->SNK_TRY
[   58.135273] JDB: state change SNK_TRY -> SNK_TRY_WAIT [delayed 100 ms]
[   58.135296] JDB: tcpm_state_machine_work state chage:
SNK_TRY_WAIT->SRC_TRYWAIT
[   58.149344] JDB: tcpm_state_machine_work state chage:
SRC_TRYWAIT->SRC_TRYWAIT
[   58.251273] JDB: state change SRC_TRYWAIT -> SRC_TRYWAIT_UNATTACHED
[delayed 100 ms]
[   58.251297] JDB: tcpm_state_machine_work state chage:
SRC_TRYWAIT_UNATTACHED->SNK_UNATTACHED
[   58.269076] JDB: tcpm_state_machine_work state chage:
SNK_UNATTACHED->TOGGLING
[   58.276789] JDB: tcpm_state_machine_work state chage: TOGGLING->TOGGLING
[   58.323506] JDB: tcpm_state_machine_work state chage:
SRC_ATTACH_WAIT->SRC_ATTACH_WAIT
[   58.527310] JDB: state change SRC_ATTACH_WAIT -> SRC_ATTACHED
[delayed 200 ms]
[   58.527788] JDB: hub_usb_role_switch_set switching to ROLE_HOST!
[   58.541555] usb usb1-port1: disabled by hub (EMI?), re-enabling...
[   58.548654] usb 1-1: USB disconnect, device number 2
[   58.554077] usb 1-1.5: USB disconnect, device number 3
[   58.560133] JDB: rt1711h_set_vbus  source: 1 sink: 0
[   58.565377] JDB: rt1711h_set_vbus enabling regulator!
[   58.570495] type-c-vbus-current-regulator:  being enabled! JDB!
[   58.586202] type-c-vbus-current-regulator:  enabled successfully?! JDB!
[   58.602350] rt1711h_set_vbus: vbus := On
[   58.602354] rt1711h_set_vbus: charge is already Off
[   58.747321] usb 2-1: USB disconnect, device number 2
[   58.819706] JDB: tcpm_state_machine_work state chage:
SRC_ATTACHED->SRC_ATTACHED
[   58.871270] usb 1-1: new high-speed USB device number 4 using xhci-hcd
[   59.030402] usb 1-1: New USB device found, idVendor=2109,
idProduct=2813, bcdDevice=90.11
[   59.038677] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[   59.045881] usb 1-1: Product: USB2.0 Hub
[   59.049838] usb 1-1: Manufacturer: VIA Labs, Inc.
[   59.104926] hub 1-1:1.0: USB hub found
[   59.109112] hub 1-1:1.0: 4 ports detected
[   59.327259] JDB: state change SRC_ATTACHED -> SRC_UNATTACHED [delayed 480 ms]
[   59.327710] JDB: rt1711h_set_vbus  source: 0 sink: 0
[   59.340022] JDB: rt1711h_set_vbus disabling regulator!
[   59.345296] type-c-vbus-current-regulator:  disabled successfully?!
JDB! (ret=0)
[   59.353458] rt1711h_set_vbus: vbus := Off
[   59.353465] rt1711h_set_vbus: charge is already Off
[   59.483278] usb 1-1.1: new 

[PATCH v4 0/3] Add MMC software queue support

[Baolin Wang]

Hi All,

Now the MMC read/write stack will always wait for previous request is
completed by mmc_blk_rw_wait(), before sending a new request to hardware,
or queue a work to complete request, that will bring context switching
overhead, especially for high I/O per second rates, to affect the IO
performance.

Thus this patch set will introduce the MMC software command queue support
based on command queue engine's interfaces, and set the queue depth as 32
to allow more requests can be be prepared, merged and inserted into IO
scheduler, but we only allow 2 requests in flight, that is enough to let
the irq handler always trigger the next request without a context switch,
as well as avoiding a long latency.

Moreover we can expand the MMC software queue interface to support
MMC packed request or packed command instead of adding new interfaces,
according to previosus discussion.

Below are some comparison data with fio tool. The fio command I used
is like below with changing the '--rw' parameter and enabling the direct
IO flag to measure the actual hardware transfer speed in 4K block size.

./fio --filename=/dev/mmcblk0p30 --direct=1 --iodepth=20 --rw=read --bs=4K 
--size=1G --group_reporting --numjobs=20 --name=test_read

My eMMC card working at HS400 Enhanced strobe mode:
[2.229856] mmc0: new HS400 Enhanced strobe MMC card at address 0001
[2.237566] mmcblk0: mmc0:0001 HBG4a2 29.1 GiB 
[2.242621] mmcblk0boot0: mmc0:0001 HBG4a2 partition 1 4.00 MiB
[2.249110] mmcblk0boot1: mmc0:0001 HBG4a2 partition 2 4.00 MiB
[2.255307] mmcblk0rpmb: mmc0:0001 HBG4a2 partition 3 4.00 MiB, chardev 
(248:0)

1. Without MMC software queue
I tested 5 times for each case and output a average speed.

1) Sequential read:
Speed: 59.4MiB/s, 63.4MiB/s, 57.5MiB/s, 57.2MiB/s, 60.8MiB/s
Average speed: 59.66MiB/s

2) Random read:
Speed: 26.9MiB/s, 26.9MiB/s, 27.1MiB/s, 27.1MiB/s, 27.2MiB/s
Average speed: 27.04MiB/s

3) Sequential write:
Speed: 71.6MiB/s, 72.5MiB/s, 72.2MiB/s, 64.6MiB/s, 67.5MiB/s
Average speed: 69.68MiB/s

4) Random write:
Speed: 36.3MiB/s, 35.4MiB/s, 38.6MiB/s, 34MiB/s, 35.5MiB/s
Average speed: 35.96MiB/s

2. With MMC software queue
I tested 5 times for each case and output a average speed.

1) Sequential read:
Speed: 59.2MiB/s, 60.4MiB/s, 63.6MiB/s, 60.3MiB/s, 59.9MiB/s
Average speed: 60.68MiB/s

2) Random read:
Speed: 31.3MiB/s, 31.4MiB/s, 31.5MiB/s, 31.3MiB/s, 31.3MiB/s
Average speed: 31.36MiB/s

3) Sequential write:
Speed: 71MiB/s, 71.8MiB/s, 72.3MiB/s, 72.2MiB/s, 71MiB/s
Average speed: 71.66MiB/s

4) Random write:
Speed: 68.9MiB/s, 68.7MiB/s, 68.8MiB/s, 68.6MiB/s, 68.8MiB/s
Average speed: 68.76MiB/s

Form above data, we can see the MMC software queue can help to improve some
performance obviously for random read and write, though no obvious improvement
for sequential read and write.

Any comments are welcome. Thanks a lot.

Changes from v3:
 - Use host software queue instead of sqhci.
 - Fix random config building issue.
 - Change queue depth to 32, but still only allow 2 requests in flight.
 - Update the testing data.

Changes from v2:
 - Remove reference to 'struct cqhci_host' and 'struct cqhci_slot',
 instead adding 'struct sqhci_host', which is only used by software queue.

Changes from v1:
 - Add request_done ops for sdhci_ops.
 - Replace virtual command queue with software queue for functions and
 variables.
 - Rename the software queue file and add sqhci.h header file.

Baolin Wang (3):
  mmc: Add MMC host software queue support
  mmc: host: sdhci: Add request_done ops for struct sdhci_ops
  mmc: host: sdhci-sprd: Add software queue support

 drivers/mmc/core/block.c  |   61 
 drivers/mmc/core/mmc.c|   13 +-
 drivers/mmc/core/queue.c  |   33 +++-
 drivers/mmc/host/Kconfig  |8 +
 drivers/mmc/host/Makefile |1 +
 drivers/mmc/host/mmc_hsq.c|  344 +
 drivers/mmc/host/mmc_hsq.h|   30 
 drivers/mmc/host/sdhci-sprd.c |   26 
 drivers/mmc/host/sdhci.c  |   12 +-
 drivers/mmc/host/sdhci.h  |2 +
 include/linux/mmc/host.h  |3 +
 11 files changed, 521 insertions(+), 12 deletions(-)
 create mode 100644 drivers/mmc/host/mmc_hsq.c
 create mode 100644 drivers/mmc/host/mmc_hsq.h

-- 
1.7.9.5

[PATCH v4 0/5] add dsa switch support for ar9331

[Oleksij Rempel]

changes v4:
- ag71xx: ag71xx_mac_validate fix always false comparison (&& -> ||)
- tag_ar9331: use skb_pull_rcsum() instead of skb_pull().
- tag_ar9331: drop skb_set_mac_header()

changes v3:
- ag71xx: ag71xx_mac_config: ignore MLO_AN_INBAND mode. It is not
  supported by HW and SW.
- ag71xx: ag71xx_mac_validate: return all supported bits on
  PHY_INTERFACE_MODE_NA

changes v2:
- move Atheros AR9331 TAG format to separate patch
- use netdev_warn_once in the tag driver to reduce potential message spam
- typo fixes
- reorder tag driver alphabetically 
- configure switch to maximal frame size
- use mdiobus_read/write
- fail if mdio sub node is not found
- add comment for post reset state
- remove deprecated comment about device id
- remove phy-handle option for node with fixed-link
- ag71xx: set 1G support only for GMII mode

This patch series provides dsa switch support for Atheros ar9331 WiSoC.
As side effect ag71xx needed to be ported to phylink to make the switch
driver (as well phylink based) work properly.

Oleksij Rempel (5):
  net: ag71xx: port to phylink
  dt-bindings: net: dsa: qca,ar9331 switch documentation
  MIPS: ath79: ar9331: add ar9331-switch node
  net: dsa: add support for Atheros AR9331 TAG format
  net: dsa: add support for Atheros AR9331 build-in switch

 .../devicetree/bindings/net/dsa/ar9331.txt| 148 
 arch/mips/boot/dts/qca/ar9331.dtsi| 127 ++-
 arch/mips/boot/dts/qca/ar9331_dpt_module.dts  |  13 +
 drivers/net/dsa/Kconfig   |   2 +
 drivers/net/dsa/Makefile  |   1 +
 drivers/net/dsa/qca/Kconfig   |  11 +
 drivers/net/dsa/qca/Makefile  |   2 +
 drivers/net/dsa/qca/ar9331.c  | 823 ++
 drivers/net/ethernet/atheros/Kconfig  |   2 +-
 drivers/net/ethernet/atheros/ag71xx.c | 146 ++--
 include/net/dsa.h |   2 +
 net/dsa/Kconfig   |   6 +
 net/dsa/Makefile  |   1 +
 net/dsa/tag_ar9331.c  |  96 ++
 14 files changed, 1320 insertions(+), 60 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/dsa/ar9331.txt
 create mode 100644 drivers/net/dsa/qca/Kconfig
 create mode 100644 drivers/net/dsa/qca/Makefile
 create mode 100644 drivers/net/dsa/qca/ar9331.c
 create mode 100644 net/dsa/tag_ar9331.c

-- 
2.23.0

[PATCH v4 1/4] perf/core,x86: introduce sync_task_ctx() method at struct pmu

[Alexey Budankov]

Declare sync_task_ctx() methods at the generic and x86 specific
pmu types to bridge calls to platform specific pmu code on optimized
context switch path between equivalent task perf event contexts.

Signed-off-by: Alexey Budankov 
---
Changes in v4:
- marked sync_task_ctx() as the optional in code comments;
- renamed params of sync_task_ctx() to prev and next;

---
 arch/x86/events/perf_event.h | 8 
 include/linux/perf_event.h   | 7 +++
 2 files changed, 15 insertions(+)

diff --git a/arch/x86/events/perf_event.h b/arch/x86/events/perf_event.h
index ecacfbf4ebc1..be78f2765f74 100644
--- a/arch/x86/events/perf_event.h
+++ b/arch/x86/events/perf_event.h
@@ -682,6 +682,14 @@ struct x86_pmu {
 */
atomic_tlbr_exclusive[x86_lbr_exclusive_max];
 
+   /*
+* perf task context (i.e. struct perf_event_context::task_ctx_data) 
switch helper
+* to bridge calls from perf/core to perf/x86. See struct 
pmu::sync_task_ctx() usage
+* for examples;
+*/
+   void(*sync_task_ctx)(struct x86_perf_task_context *prev,
+struct x86_perf_task_context *next);
+
/*
 * AMD bits
 */
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 587ae4d002f5..4b96b4a5ac03 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -410,6 +410,13 @@ struct pmu {
 */
size_t  task_ctx_size;
 
+   /*
+* PMU specific parts of task perf event context (i.e. 
ctx->task_ctx_data)
+* can be synchronized using this function. See Intel LBR callstack 
support
+* implementation and Perf core context switch handling callbacks for 
usage
+* examples.
+*/
+   void (*sync_task_ctx)   (void *prev, void *next); /* optional */
 
/*
 * Set up pmu-private data structures for an AUX area
-- 
2.20.1

[PATCH v4 1/5] net: ag71xx: port to phylink

[Oleksij Rempel]

The port to phylink was done as close as possible to initial
functionality.
Theoretically this HW can support flow control, practically seems to be not
enough to just enable it. So, more work should be done.

Signed-off-by: Oleksij Rempel 
---
 drivers/net/ethernet/atheros/Kconfig  |   2 +-
 drivers/net/ethernet/atheros/ag71xx.c | 146 --
 2 files changed, 89 insertions(+), 59 deletions(-)

diff --git a/drivers/net/ethernet/atheros/Kconfig 
b/drivers/net/ethernet/atheros/Kconfig
index 0058051ba925..2720bde5034e 100644
--- a/drivers/net/ethernet/atheros/Kconfig
+++ b/drivers/net/ethernet/atheros/Kconfig
@@ -20,7 +20,7 @@ if NET_VENDOR_ATHEROS
 config AG71XX
tristate "Atheros AR7XXX/AR9XXX built-in ethernet mac support"
depends on ATH79
-   select PHYLIB
+   select PHYLINK
help
  If you wish to compile a kernel for AR7XXX/91XXX and enable
  ethernet support, then you should always answer Y to this.
diff --git a/drivers/net/ethernet/atheros/ag71xx.c 
b/drivers/net/ethernet/atheros/ag71xx.c
index 1b1a09095c0d..9d766d73a89b 100644
--- a/drivers/net/ethernet/atheros/ag71xx.c
+++ b/drivers/net/ethernet/atheros/ag71xx.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -314,6 +315,8 @@ struct ag71xx {
dma_addr_t stop_desc_dma;
 
int phy_if_mode;
+   struct phylink *phylink;
+   struct phylink_config phylink_config;
 
struct delayed_work restart_work;
struct timer_list oom_timer;
@@ -845,24 +848,23 @@ static void ag71xx_hw_start(struct ag71xx *ag)
netif_wake_queue(ag->ndev);
 }
 
-static void ag71xx_link_adjust(struct ag71xx *ag, bool update)
+static void ag71xx_mac_config(struct phylink_config *config, unsigned int mode,
+ const struct phylink_link_state *state)
 {
-   struct phy_device *phydev = ag->ndev->phydev;
+   struct ag71xx *ag = netdev_priv(to_net_dev(config->dev));
u32 cfg2;
u32 ifctl;
u32 fifo5;
 
-   if (!phydev->link && update) {
-   ag71xx_hw_stop(ag);
+   if (phylink_autoneg_inband(mode))
return;
-   }
 
if (!ag71xx_is(ag, AR7100) && !ag71xx_is(ag, AR9130))
ag71xx_fast_reset(ag);
 
cfg2 = ag71xx_rr(ag, AG71XX_REG_MAC_CFG2);
cfg2 &= ~(MAC_CFG2_IF_1000 | MAC_CFG2_IF_10_100 | MAC_CFG2_FDX);
-   cfg2 |= (phydev->duplex) ? MAC_CFG2_FDX : 0;
+   cfg2 |= (state->duplex) ? MAC_CFG2_FDX : 0;
 
ifctl = ag71xx_rr(ag, AG71XX_REG_MAC_IFCTL);
ifctl &= ~(MAC_IFCTL_SPEED);
@@ -870,7 +872,7 @@ static void ag71xx_link_adjust(struct ag71xx *ag, bool 
update)
fifo5 = ag71xx_rr(ag, AG71XX_REG_FIFO_CFG5);
fifo5 &= ~FIFO_CFG5_BM;
 
-   switch (phydev->speed) {
+   switch (state->speed) {
case SPEED_1000:
cfg2 |= MAC_CFG2_IF_1000;
fifo5 |= FIFO_CFG5_BM;
@@ -883,7 +885,6 @@ static void ag71xx_link_adjust(struct ag71xx *ag, bool 
update)
cfg2 |= MAC_CFG2_IF_10_100;
break;
default:
-   WARN(1, "not supported speed %i\n", phydev->speed);
return;
}
 
@@ -897,58 +898,79 @@ static void ag71xx_link_adjust(struct ag71xx *ag, bool 
update)
ag71xx_wr(ag, AG71XX_REG_MAC_CFG2, cfg2);
ag71xx_wr(ag, AG71XX_REG_FIFO_CFG5, fifo5);
ag71xx_wr(ag, AG71XX_REG_MAC_IFCTL, ifctl);
-
-   ag71xx_hw_start(ag);
-
-   if (update)
-   phy_print_status(phydev);
 }
 
-static void ag71xx_phy_link_adjust(struct net_device *ndev)
+static void ag71xx_mac_validate(struct phylink_config *config,
+   unsigned long *supported,
+   struct phylink_link_state *state)
 {
-   struct ag71xx *ag = netdev_priv(ndev);
+   __ETHTOOL_DECLARE_LINK_MODE_MASK(mask) = { 0, };
+
+   if (state->interface != PHY_INTERFACE_MODE_NA &&
+   state->interface != PHY_INTERFACE_MODE_GMII &&
+   state->interface != PHY_INTERFACE_MODE_MII) {
+   bitmap_zero(supported, __ETHTOOL_LINK_MODE_MASK_NBITS);
+   return;
+   }
+
+   phylink_set(mask, MII);
+
+   /* flow control is not supported */
+
+   phylink_set(mask, 10baseT_Half);
+   phylink_set(mask, 10baseT_Full);
+   phylink_set(mask, 100baseT_Half);
+   phylink_set(mask, 100baseT_Full);
 
-   ag71xx_link_adjust(ag, true);
+   if (state->interface == PHY_INTERFACE_MODE_NA ||
+   state->interface == PHY_INTERFACE_MODE_GMII) {
+   phylink_set(mask, 1000baseT_Full);
+   phylink_set(mask, 1000baseX_Full);
+   }
+
+   bitmap_and(supported, supported, mask,
+  __ETHTOOL_LINK_MODE_MASK_NBITS);
+   bitmap_and(state->advertising, state->advertising, mask,
+  __ETHTOOL_LINK_MODE_MASK_NBITS);
 }
 
-static int ag71xx_phy_connect(struct ag

[PATCH v4 5/5] net: dsa: add support for Atheros AR9331 build-in switch

[Oleksij Rempel]

Provide basic support for Atheros AR9331 build-in switch. So far it
works as port multiplexer without any hardware offloading support.

Signed-off-by: Oleksij Rempel 
---
 drivers/net/dsa/Kconfig  |   2 +
 drivers/net/dsa/Makefile |   1 +
 drivers/net/dsa/qca/Kconfig  |  11 +
 drivers/net/dsa/qca/Makefile |   2 +
 drivers/net/dsa/qca/ar9331.c | 823 +++
 5 files changed, 839 insertions(+)
 create mode 100644 drivers/net/dsa/qca/Kconfig
 create mode 100644 drivers/net/dsa/qca/Makefile
 create mode 100644 drivers/net/dsa/qca/ar9331.c

diff --git a/drivers/net/dsa/Kconfig b/drivers/net/dsa/Kconfig
index f6232ce8481f..de9610a3dd5c 100644
--- a/drivers/net/dsa/Kconfig
+++ b/drivers/net/dsa/Kconfig
@@ -52,6 +52,8 @@ source "drivers/net/dsa/microchip/Kconfig"
 
 source "drivers/net/dsa/mv88e6xxx/Kconfig"
 
+source "drivers/net/dsa/qca/Kconfig"
+
 source "drivers/net/dsa/sja1105/Kconfig"
 
 config NET_DSA_QCA8K
diff --git a/drivers/net/dsa/Makefile b/drivers/net/dsa/Makefile
index ae70b79628d6..90e5b1ed69c5 100644
--- a/drivers/net/dsa/Makefile
+++ b/drivers/net/dsa/Makefile
@@ -20,4 +20,5 @@ obj-$(CONFIG_NET_DSA_VITESSE_VSC73XX_SPI) += 
vitesse-vsc73xx-spi.o
 obj-y  += b53/
 obj-y  += microchip/
 obj-y  += mv88e6xxx/
+obj-y  += qca/
 obj-y  += sja1105/
diff --git a/drivers/net/dsa/qca/Kconfig b/drivers/net/dsa/qca/Kconfig
new file mode 100644
index ..7e4978f46642
--- /dev/null
+++ b/drivers/net/dsa/qca/Kconfig
@@ -0,0 +1,11 @@
+# SPDX-License-Identifier: GPL-2.0-only
+config NET_DSA_AR9331
+   tristate "Atheros AR9331 Ethernet switch support"
+   depends on NET_DSA
+   select NET_DSA_TAG_AR9331
+   select REGMAP
+   ---help---
+ This enables support for the Atheros AR9331 build-in Ethernet
+ switch.
+
+
diff --git a/drivers/net/dsa/qca/Makefile b/drivers/net/dsa/qca/Makefile
new file mode 100644
index ..274022319066
--- /dev/null
+++ b/drivers/net/dsa/qca/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0-only
+obj-$(CONFIG_NET_DSA_AR9331)   += ar9331.o
diff --git a/drivers/net/dsa/qca/ar9331.c b/drivers/net/dsa/qca/ar9331.c
new file mode 100644
index ..299c1a966756
--- /dev/null
+++ b/drivers/net/dsa/qca/ar9331.c
@@ -0,0 +1,823 @@
+// SPDX-License-Identifier: GPL-2.0-only
+// Copyright (c) 2019 Pengutronix, Oleksij Rempel 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define AR9331_SW_NAME "ar9331_switch"
+#define AR9331_SW_PORTS6
+
+/* dummy reg to change page */
+#define AR9331_SW_REG_PAGE BIT(18)
+
+/* Global Interrupt */
+#define AR9331_SW_REG_GINT 0x10
+#define AR9331_SW_REG_GINT_MASK0x14
+#define AR9331_SW_GINT_PHY_INT BIT(2)
+
+#define AR9331_SW_REG_FLOOD_MASK   0x2c
+#define AR9331_SW_FLOOD_MASK_BROAD_TO_CPU  BIT(26)
+
+#define AR9331_SW_REG_GLOBAL_CTRL  0x30
+#define AR9331_SW_GLOBAL_CTRL_MFS_MGENMASK(13, 0)
+
+#define AR9331_SW_REG_MDIO_CTRL0x98
+#define AR9331_SW_MDIO_CTRL_BUSY   BIT(31)
+#define AR9331_SW_MDIO_CTRL_MASTER_EN  BIT(30)
+#define AR9331_SW_MDIO_CTRL_CMD_READ   BIT(27)
+#define AR9331_SW_MDIO_CTRL_PHY_ADDR_M GENMASK(25, 21)
+#define AR9331_SW_MDIO_CTRL_REG_ADDR_M GENMASK(20, 16)
+#define AR9331_SW_MDIO_CTRL_DATA_M GENMASK(16, 0)
+
+#define AR9331_SW_REG_PORT_STATUS(_port)   (0x100 + (_port) * 0x100)
+
+/* FLOW_LINK_EN - enable mac flow control config auto-neg with phy.
+ * If not set, mac can be config by software.
+ */
+#define AR9331_SW_PORT_STATUS_FLOW_LINK_EN BIT(12)
+
+/* LINK_EN - If set, MAC is configured from PHY link status.
+ * If not set, MAC should be configured by software.
+ */
+#define AR9331_SW_PORT_STATUS_LINK_EN  BIT(9)
+#define AR9331_SW_PORT_STATUS_DUPLEX_MODE  BIT(6)
+#define AR9331_SW_PORT_STATUS_RX_FLOW_EN   BIT(5)
+#define AR9331_SW_PORT_STATUS_TX_FLOW_EN   BIT(4)
+#define AR9331_SW_PORT_STATUS_RXMACBIT(3)
+#define AR9331_SW_PORT_STATUS_TXMACBIT(2)
+#define AR9331_SW_PORT_STATUS_SPEED_M  GENMASK(1, 0)
+#define AR9331_SW_PORT_STATUS_SPEED_1000   2
+#define AR9331_SW_PORT_STATUS_SPEED_1001
+#define AR9331_SW_PORT_STATUS_SPEED_10 0
+
+#define AR9331_SW_PORT_STATUS_MAC_MASK \
+   (AR9331_SW_PORT_STATUS_TXMAC | AR9331_SW_PORT_STATUS_RXMAC)
+
+#define AR9331_SW_PORT_STATUS_LINK_MASK \
+   (AR9331_SW_PORT_STATUS_LINK_EN | AR9331_SW_PORT_STATUS_FLOW_LINK_EN | \
+AR9331_SW_PORT_STATUS_DUPLEX_MODE | \
+AR9331_SW_PORT_STATUS_RX_FLOW_EN | AR9331_SW_PORT_STATUS_TX_FLOW_EN | \
+AR9331_SW_PORT_STATUS_SPEED_M)
+
+/* Phy bypass mode
+ * ---

[PATCH v4 0/5] add dsa switch support for ar9331

[Oleksij Rempel]

changes v4:
- ag71xx: ag71xx_mac_validate fix always false comparison (&& -> ||)
- tag_ar9331: use skb_pull_rcsum() instead of skb_pull().
- tag_ar9331: drop skb_set_mac_header()

changes v3:
- ag71xx: ag71xx_mac_config: ignore MLO_AN_INBAND mode. It is not
  supported by HW and SW.
- ag71xx: ag71xx_mac_validate: return all supported bits on
  PHY_INTERFACE_MODE_NA

changes v2:
- move Atheros AR9331 TAG format to separate patch
- use netdev_warn_once in the tag driver to reduce potential message spam
- typo fixes
- reorder tag driver alphabetically 
- configure switch to maximal frame size
- use mdiobus_read/write
- fail if mdio sub node is not found
- add comment for post reset state
- remove deprecated comment about device id
- remove phy-handle option for node with fixed-link
- ag71xx: set 1G support only for GMII mode

This patch series provides dsa switch support for Atheros ar9331 WiSoC.
As side effect ag71xx needed to be ported to phylink to make the switch
driver (as well phylink based) work properly.

Oleksij Rempel (5):
  net: ag71xx: port to phylink
  dt-bindings: net: dsa: qca,ar9331 switch documentation
  MIPS: ath79: ar9331: add ar9331-switch node
  net: dsa: add support for Atheros AR9331 TAG format
  net: dsa: add support for Atheros AR9331 build-in switch

 .../devicetree/bindings/net/dsa/ar9331.txt| 148 
 arch/mips/boot/dts/qca/ar9331.dtsi| 127 ++-
 arch/mips/boot/dts/qca/ar9331_dpt_module.dts  |  13 +
 drivers/net/dsa/Kconfig   |   2 +
 drivers/net/dsa/Makefile  |   1 +
 drivers/net/dsa/qca/Kconfig   |  11 +
 drivers/net/dsa/qca/Makefile  |   2 +
 drivers/net/dsa/qca/ar9331.c  | 823 ++
 drivers/net/ethernet/atheros/Kconfig  |   2 +-
 drivers/net/ethernet/atheros/ag71xx.c | 146 ++--
 include/net/dsa.h |   2 +
 net/dsa/Kconfig   |   6 +
 net/dsa/Makefile  |   1 +
 net/dsa/tag_ar9331.c  |  96 ++
 14 files changed, 1320 insertions(+), 60 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/dsa/ar9331.txt
 create mode 100644 drivers/net/dsa/qca/Kconfig
 create mode 100644 drivers/net/dsa/qca/Makefile
 create mode 100644 drivers/net/dsa/qca/ar9331.c
 create mode 100644 net/dsa/tag_ar9331.c

-- 
2.23.0

[PATCH v4 4/5] net: dsa: add support for Atheros AR9331 TAG format

[Oleksij Rempel]

Add support for tag format used in Atheros AR9331 build-in switch.

Signed-off-by: Oleksij Rempel 
---
 include/net/dsa.h|  2 +
 net/dsa/Kconfig  |  6 +++
 net/dsa/Makefile |  1 +
 net/dsa/tag_ar9331.c | 96 
 4 files changed, 105 insertions(+)
 create mode 100644 net/dsa/tag_ar9331.c

diff --git a/include/net/dsa.h b/include/net/dsa.h
index 541fb514e31d..89a334e68d42 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -42,6 +42,7 @@ struct phylink_link_state;
 #define DSA_TAG_PROTO_8021Q_VALUE  12
 #define DSA_TAG_PROTO_SJA1105_VALUE13
 #define DSA_TAG_PROTO_KSZ8795_VALUE14
+#define DSA_TAG_PROTO_AR9331_VALUE 15
 
 enum dsa_tag_protocol {
DSA_TAG_PROTO_NONE  = DSA_TAG_PROTO_NONE_VALUE,
@@ -59,6 +60,7 @@ enum dsa_tag_protocol {
DSA_TAG_PROTO_8021Q = DSA_TAG_PROTO_8021Q_VALUE,
DSA_TAG_PROTO_SJA1105   = DSA_TAG_PROTO_SJA1105_VALUE,
DSA_TAG_PROTO_KSZ8795   = DSA_TAG_PROTO_KSZ8795_VALUE,
+   DSA_TAG_PROTO_AR9331= DSA_TAG_PROTO_AR9331_VALUE,
 };
 
 struct packet_type;
diff --git a/net/dsa/Kconfig b/net/dsa/Kconfig
index 29e2bd5cc5af..617c9607df5f 100644
--- a/net/dsa/Kconfig
+++ b/net/dsa/Kconfig
@@ -29,6 +29,12 @@ config NET_DSA_TAG_8021Q
 
  Drivers which use these helpers should select this as dependency.
 
+config NET_DSA_TAG_AR9331
+   tristate "Tag driver for Atheros AR9331 SoC with build-in switch"
+   help
+ Say Y or M if you want to enable support for tagging frames for
+ the Atheros AR9331 SoC with build-in switch.
+
 config NET_DSA_TAG_BRCM_COMMON
tristate
default n
diff --git a/net/dsa/Makefile b/net/dsa/Makefile
index 2c6d286f0511..6f77bdb5c40c 100644
--- a/net/dsa/Makefile
+++ b/net/dsa/Makefile
@@ -5,6 +5,7 @@ dsa_core-y += dsa.o dsa2.o master.o port.o slave.o switch.o
 
 # tagging formats
 obj-$(CONFIG_NET_DSA_TAG_8021Q) += tag_8021q.o
+obj-$(CONFIG_NET_DSA_TAG_AR9331) += tag_ar9331.o
 obj-$(CONFIG_NET_DSA_TAG_BRCM_COMMON) += tag_brcm.o
 obj-$(CONFIG_NET_DSA_TAG_DSA) += tag_dsa.o
 obj-$(CONFIG_NET_DSA_TAG_EDSA) += tag_edsa.o
diff --git a/net/dsa/tag_ar9331.c b/net/dsa/tag_ar9331.c
new file mode 100644
index ..466ffa92a474
--- /dev/null
+++ b/net/dsa/tag_ar9331.c
@@ -0,0 +1,96 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 Pengutronix, Oleksij Rempel 
+ */
+
+
+#include 
+#include 
+
+#include "dsa_priv.h"
+
+#define AR9331_HDR_LEN 2
+#define AR9331_HDR_VERSION 1
+
+#define AR9331_HDR_VERSION_MASKGENMASK(15, 14)
+#define AR9331_HDR_PRIORITY_MASK   GENMASK(13, 12)
+#define AR9331_HDR_TYPE_MASK   GENMASK(10, 8)
+#define AR9331_HDR_BROADCAST   BIT(7)
+#define AR9331_HDR_FROM_CPUBIT(6)
+/* AR9331_HDR_RESERVED - not used or may be version field.
+ * According to the AR8216 doc it should 0b10. On AR9331 it is 0b11 on RX path
+ * and should be set to 0b11 to make it work.
+ */
+#define AR9331_HDR_RESERVED_MASK   GENMASK(5, 4)
+#define AR9331_HDR_PORT_NUM_MASK   GENMASK(3, 0)
+
+static struct sk_buff *ar9331_tag_xmit(struct sk_buff *skb,
+  struct net_device *dev)
+{
+   struct dsa_port *dp = dsa_slave_to_port(dev);
+   __le16 *phdr;
+   u16 hdr;
+
+   if (skb_cow_head(skb, 0) < 0)
+   return NULL;
+
+   phdr = skb_push(skb, AR9331_HDR_LEN);
+
+   hdr = FIELD_PREP(AR9331_HDR_VERSION_MASK, AR9331_HDR_VERSION);
+   hdr |= AR9331_HDR_FROM_CPU | dp->index;
+   /* 0b10 for AR8216 and 0b11 for AR9331 */
+   hdr |= AR9331_HDR_RESERVED_MASK;
+
+   phdr[0] = cpu_to_le16(hdr);
+
+   return skb;
+}
+
+static struct sk_buff *ar9331_tag_rcv(struct sk_buff *skb,
+ struct net_device *ndev,
+ struct packet_type *pt)
+{
+   u8 ver, port;
+   u16 hdr;
+
+   if (unlikely(!pskb_may_pull(skb, AR9331_HDR_LEN)))
+   return NULL;
+
+   hdr = le16_to_cpu(*(__le16 *)skb_mac_header(skb));
+
+   ver = FIELD_GET(AR9331_HDR_VERSION_MASK, hdr);
+   if (unlikely(ver != AR9331_HDR_VERSION)) {
+   netdev_warn_once(ndev, "%s:%i wrong header version 0x%2x\n",
+__func__, __LINE__, hdr);
+   return NULL;
+   }
+
+   if (unlikely(hdr & AR9331_HDR_FROM_CPU)) {
+   netdev_warn_once(ndev, "%s:%i packet should not be from cpu 
0x%2x\n",
+__func__, __LINE__, hdr);
+   return NULL;
+   }
+
+   skb_pull_rcsum(skb, AR9331_HDR_LEN);
+
+   /* Get source port information */
+   port = FIELD_GET(AR9331_HDR_PORT_NUM_MASK, hdr);
+
+   skb->dev = dsa_master_find_slave(ndev, 0, port);
+   if (!skb->dev)
+   return NULL;
+
+   return skb;
+}
+
+static 

[PATCH v4 2/5] dt-bindings: net: dsa: qca,ar9331 switch documentation

[Oleksij Rempel]

Atheros AR9331 has built-in 5 port switch. The switch can be configured
to use all 5 or 4 ports. One of built-in PHYs can be used by first built-in
ethernet controller or to be used directly by the switch over second ethernet
controller.

Signed-off-by: Oleksij Rempel 
---
 .../devicetree/bindings/net/dsa/ar9331.txt| 148 ++
 1 file changed, 148 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/dsa/ar9331.txt

diff --git a/Documentation/devicetree/bindings/net/dsa/ar9331.txt 
b/Documentation/devicetree/bindings/net/dsa/ar9331.txt
new file mode 100644
index ..40a1f6e1f85f
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/dsa/ar9331.txt
@@ -0,0 +1,148 @@
+Atheros AR9331 built-in switch
+=
+
+It is a switch built-in to Atheros AR9331 WiSoC and addressable over internal
+MDIO bus. All PHYs are build-in as well. 
+
+Required properties:
+
+ - compatible: should be: "qca,ar9331-switch" 
+ - reg: Address on the MII bus for the switch.
+ - resets : Must contain an entry for each entry in reset-names.
+ - reset-names : Must include the following entries: "switch"
+ - interrupt-parent: Phandle to the parent interrupt controller
+ - interrupts: IRQ line for the switch
+ - interrupt-controller: Indicates the switch is itself an interrupt
+   controller. This is used for the PHY interrupts.
+ - #interrupt-cells: must be 1
+ - mdio: Container of PHY and devices on the switches MDIO bus.
+
+See Documentation/devicetree/bindings/net/dsa/dsa.txt for a list of additional
+required and optional properties.
+Examples:
+
+eth0: ethernet@1900 {
+   compatible = "qca,ar9330-eth";
+   reg = <0x1900 0x200>;
+   interrupts = <4>;
+
+   resets = <&rst 9>, <&rst 22>;
+   reset-names = "mac", "mdio";
+   clocks = <&pll ATH79_CLK_AHB>, <&pll ATH79_CLK_AHB>;
+   clock-names = "eth", "mdio";
+
+   phy-mode = "mii";
+   phy-handle = <&phy_port4>;
+};
+
+eth1: ethernet@1a00 {
+   compatible = "qca,ar9330-eth";
+   reg = <0x1a00 0x200>;
+   interrupts = <5>;
+   resets = <&rst 13>, <&rst 23>;
+   reset-names = "mac", "mdio";
+   clocks = <&pll ATH79_CLK_AHB>, <&pll ATH79_CLK_AHB>;
+   clock-names = "eth", "mdio";
+
+   phy-mode = "gmii";
+
+   fixed-link {
+   speed = <1000>;
+   full-duplex;
+   };
+
+   mdio {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   switch10: switch@10 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   compatible = "qca,ar9331-switch";
+   reg = <0x10>;
+   resets = <&rst 8>;
+   reset-names = "switch";
+
+   interrupt-parent = <&miscintc>;
+   interrupts = <12>;
+
+   interrupt-controller;
+   #interrupt-cells = <1>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   switch_port0: port@0 {
+   reg = <0x0>;
+   label = "cpu";
+   ethernet = <ð1>;
+
+   phy-mode = "gmii";
+
+   fixed-link {
+   speed = <1000>;
+   full-duplex;
+   };
+   };
+
+   switch_port1: port@1 {
+   reg = <0x1>;
+   phy-handle = <&phy_port0>;
+   phy-mode = "internal";
+   };
+
+   switch_port2: port@2 {
+   reg = <0x2>;
+   phy-handle = <&phy_port1>;
+   phy-mode = "internal";
+   };
+
+   switch_port3: port@3 {
+   reg = <0x3>;
+   phy-handle = <&phy_port2>;
+   phy-mode = "internal";
+   };
+
+   switch_port4: port@4 {
+   reg = <0x4>;
+   phy-handle = <&phy_port3>;
+   phy-mode = "internal";
+   };
+   };
+
+   mdio {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   interr

[PATCH v4 3/5] MIPS: ath79: ar9331: add ar9331-switch node

[Oleksij Rempel]

Add switch node supported by dsa ar9331 driver.

Signed-off-by: Oleksij Rempel 
---
 arch/mips/boot/dts/qca/ar9331.dtsi   | 127 ++-
 arch/mips/boot/dts/qca/ar9331_dpt_module.dts |  13 ++
 2 files changed, 139 insertions(+), 1 deletion(-)

diff --git a/arch/mips/boot/dts/qca/ar9331.dtsi 
b/arch/mips/boot/dts/qca/ar9331.dtsi
index e0f409dd6acf..84a177c0d053 100644
--- a/arch/mips/boot/dts/qca/ar9331.dtsi
+++ b/arch/mips/boot/dts/qca/ar9331.dtsi
@@ -158,6 +158,9 @@
clocks = <&pll ATH79_CLK_AHB>, <&pll ATH79_CLK_AHB>;
clock-names = "eth", "mdio";
 
+   phy-mode = "mii";
+   phy-handle = <&phy_port4>;
+
status = "disabled";
};
 
@@ -165,13 +168,135 @@
compatible = "qca,ar9330-eth";
reg = <0x1a00 0x200>;
interrupts = <5>;
-
resets = <&rst 13>, <&rst 23>;
reset-names = "mac", "mdio";
clocks = <&pll ATH79_CLK_AHB>, <&pll ATH79_CLK_AHB>;
clock-names = "eth", "mdio";
 
+   phy-mode = "gmii";
+
status = "disabled";
+
+   fixed-link {
+   speed = <1000>;
+   full-duplex;
+   };
+
+   mdio {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   switch10: switch@10 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   compatible = "qca,ar9331-switch";
+   reg = <0x10>;
+   resets = <&rst 8>;
+   reset-names = "switch";
+
+   interrupt-parent = <&miscintc>;
+   interrupts = <12>;
+
+   interrupt-controller;
+   #interrupt-cells = <1>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   switch_port0: port@0 {
+   reg = <0x0>;
+   label = "cpu";
+   ethernet = <ð1>;
+
+   phy-mode = "gmii";
+
+   fixed-link {
+   speed = <1000>;
+   full-duplex;
+   };
+   };
+
+   switch_port1: port@1 {
+   reg = <0x1>;
+   phy-handle = 
<&phy_port0>;
+   phy-mode = "internal";
+
+   status = "disabled";
+   };
+
+   switch_port2: port@2 {
+   reg = <0x2>;
+   phy-handle = 
<&phy_port1>;
+   phy-mode = "internal";
+
+   status = "disabled";
+   };
+
+   switch_port3: port@3 {
+   reg = <0x3>;
+   phy-handle = 
<&phy_port2>;
+   phy-mode = "internal";
+
+   status = "disabled";
+   };
+
+   switch_port4: port@4 {
+   reg = <0x4>;
+   phy-handle = 
<&phy_port3>;
+   phy-mode = "internal";
+
+   status = "disabled";
+   };
+
+   switch_port5: port@5 {
+   

Re: [PATCH v4] perf record: Add support for limit perf output file size

[Jiwei Sun]

Hi Jirka,

On 2019e9410f21f% 21:41, Jiri Olsa wrote:
> On Wed, Sep 25, 2019 at 03:06:37PM +0800, Jiwei Sun wrote:
> 
> SNIP
> 
>>  SEE ALSO
>>  
>>  linkperf:perf-stat[1], linkperf:perf-list[1]
>> diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
>> index 48600c90cc7e..30904d2a3407 100644
>> --- a/tools/perf/builtin-record.c
>> +++ b/tools/perf/builtin-record.c
>> @@ -91,6 +91,7 @@ struct record {
>>  struct switch_outputswitch_output;
>>  unsigned long long  samples;
>>  cpu_set_t   affinity_mask;
>> +unsigned long   output_max_size;/* = 0: unlimited */
>>  };
>>  
>>  static volatile int auxtrace_record__snapshot_started;
>> @@ -120,6 +121,12 @@ static bool switch_output_time(struct record *rec)
>> trigger_is_ready(&switch_output_trigger);
>>  }
>>  
>> +static bool record__output_max_size_exceeded(struct record *rec)
>> +{
>> +return rec->output_max_size &&
>> +   (rec->bytes_written >= rec->output_max_size);
>> +}
>> +
>>  static int record__write(struct record *rec, struct mmap *map 
>> __maybe_unused,
>>   void *bf, size_t size)
>>  {
>> @@ -132,6 +139,12 @@ static int record__write(struct record *rec, struct 
>> mmap *map __maybe_unused,
>>  
>>  rec->bytes_written += size;
>>  
>> +if (record__output_max_size_exceeded(rec)) {
>> +WARN_ONCE(1, "WARNING: The perf data has already reached "
>> + "the limit, stop recording!\n");
> 
> I think the message whouldn't be a warning, the user asked for
> that, maybe something more like:
> 
>   [ perf record: perf size limit reached (XXMB), stopping session ]
> 
>> +raise(SIGTERM);
> 
> could we just set 'done = 1' what's the benefit in killing perf?

Thanks for your suggestions. Yes, if just set "done == 1" is more efficient and 
more concise.
And I will modify it and the output format, and then send a v5 patch.
Thanks again.

Regards,
Jiwei

> 
> thanks,
> jirka
> 
> 

RE: [PATCH net-next 4/4] r8152: support firmware of PHY NC for RTL8153A

[Hayes Wang]

Jakub Kicinski [mailto:jakub.kicin...@netronome.com]
> Sent: Tuesday, October 22, 2019 11:36 AM
> To: Hayes Wang
> Cc: net...@vger.kernel.org; nic_swsd; linux-kernel@vger.kernel.org;
> pmal...@chromium.org; grund...@chromium.org
> Subject: Re: [PATCH net-next 4/4] r8152: support firmware of PHY NC for
> RTL8153A
> 
> On Mon, 21 Oct 2019 11:41:13 +0800, Hayes Wang wrote:
> > Support the firmware of PHY NC which is used to fix the issue found
> > for PHY. Currently, only RTL_VER_04, RTL_VER_05, and RTL_VER_06 need
> > it.
> >
> > The order of loading PHY firmware would be
> >
> > RTL_FW_PHY_START
> > RTL_FW_PHY_NC
> 
> Perhaps that's obvious to others, but what's NC? :)

The PHY has several micro controllers which deal with different features.
The NC is our internal name helping us to know which one is specified.

Best Regards,
Hayes

Re: [PATCH 14/18] arm64: efi: restore x18 if it was corrupted

[Ard Biesheuvel]

On Tue, 22 Oct 2019 at 00:40, Sami Tolvanen  wrote:
>
> On Sun, Oct 20, 2019 at 11:20 PM Ard Biesheuvel
>  wrote:
> > You'll have to elaborate a bit here and explain that this is
> > sufficient, given that we run EFI runtime services with interrupts
> > enabled.
>
> I can add a note about this in v2. This is called with preemption
> disabled and we have a separate interrupt shadow stack, so as far as I
> can tell, this should be sufficient. Did you have concerns about this?
>

No concerns, but we should put the above clarification in the commit log.

Re: [PATCH v2 3/4] watchdog: add meson secure watchdog driver

[Xingyu Chen]

Hi, Guenter

On 2019/10/21 21:38, Guenter Roeck wrote:

On 10/21/19 1:03 AM, Xingyu Chen wrote:

Hi, Guenter

On 2019/10/21 0:56, Guenter Roeck wrote:

On 10/18/19 1:33 AM, Xingyu Chen wrote:

The watchdog controller on the Meson-A/C series SoCs is moved to secure
world, watchdog operation needs to be done in secure EL3 mode via ATF,
Non-secure world can call SMC instruction to trap to AFT for watchdog
operation.

Signed-off-by: Xingyu Chen 
---
  drivers/watchdog/Kconfig |  17 
  drivers/watchdog/Makefile    |   1 +
  drivers/watchdog/meson_sec_wdt.c | 187 
+++

  3 files changed, 205 insertions(+)
  create mode 100644 drivers/watchdog/meson_sec_wdt.c

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 58e7c10..e84be42 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -826,6 +826,23 @@ config MESON_GXBB_WATCHDOG
    To compile this driver as a module, choose M here: the
    module will be called meson_gxbb_wdt.
+config MESON_SEC_WATCHDOG
+    tristate "Amlogic Meson Secure watchdog support"
+    depends on MESON_SM
+    depends on ARCH_MESON || COMPILE_TEST


This dependency is pointless. MESON_SM already depends on ARCH_MESON,
thus specifying "COMPILE_TEST" here adds no value but only
creates confusion.

Thanks for your analysis, perhaps i should remove the line below.
- depends on ARCH_MESON || COMPILE_TEST

Is it ok to modify code above like this ?


Yes.

Thanks, fix it in next version.


[ ... ]

+static unsigned int meson_sec_wdt_get_timeleft(struct 
watchdog_device *wdt_dev)

+{
+    int ret;
+    unsigned int timeleft;
+    struct meson_sec_wdt *data = watchdog_get_drvdata(wdt_dev);
+
+    ret = meson_sm_call(data->fw, SM_WATCHDOG_OPS, Thanks&timeleft,
+    MESON_SIP_WDT_GETTIMELEFT, 0, 0, 0, 0);
+
+    if (ret)
+    return ret;


Meh, that doesn't work. I just realized that the return type is 
unsigned,

so returning a negative error code is pointless. Guess we'll have to
live with returning 0 in this case after all. I wonder if we should
fix the API and return an integer (with negative error code), but that
is a different question.

Thanks for your review.

IMO, if returning an integer, and the value which copy to user buf 
should be formatted with %d instead of %u (see timeleft_show), it will 
cause the max value of timeleft is reduced from 4294967295 to 
2147483647. but i'am not sure whether it will bring risk.


Not that it matters right now, but I don't think that limiting 'timeleft'
reporting to 2147483647 seconds, or ~68 years, would cause any risk.
It would just be a large patch changing several drivers all at once,
that is all.



So i also think returning 0 may be better in this case.


Yes, please do that.

Thanks, fix it in next version.


Thanks,
Guenter

.

[PATCH v4 0/4]: perf/core: fix restoring of Intel LBR call stack on a context switch

[Alexey Budankov]

Restore Intel LBR call stack from cloned inactive task perf context on
a context switch. This change inherently addresses inconsistency in LBR 
call stack data provided on a sample in record profiling mode:

  $ perf record -N -B -T -R --call-graph lbr \
 -e cpu/period=0xcdfe60,event=0x3c,name=\'CPU_CLK_UNHALTED.THREAD\'/Duk 
\
 --clockid=monotonic_raw -- ./miniFE.x nx 25 ny 25 nz 25

Let's assume threads A, B, C belonging to the same process. 
B and C are siblings of A and their perf contexts are treated as equivalent.
At some point B blocks on a futex (non preempt context switch).
B's LBRs are preserved at B's perf context task_ctx_data and B's events 
are removed from PMU and disabled. B's perf context becomes inactive.

Later C gets on a cpu, runs, gets profiled and eventually switches to 
the awaken but not yet running B. The optimized context switch path is 
executed swapping B's and C's task_ctx_data pointers at perf event contexts.
So C's task_ctx_data will refer preserved B's LBRs on the following 
switch-in event.

However, as far B's perf context is inactive there is no enabled events
in there and B's task_ctx_data->lbr_callstack_users is equal to 0.
When B gets on the cpu B's events reviving is skipped following
the optimized context switch path and B's task_ctx_data->lbr_callstack_users
remains 0. Thus B's LBR's are not restored by pmu sched_task() code called 
in the end of perf context switch-in callback for B.

In the report that manifests as having short fragments of B's
call stack, still tracked by LBR's HW between adjacent samples,
but the whole thread call tree doesn't aggregate.

The fix has been evaluated when profiling miniFE [1] (C++, OpenMP)
workload running 64 threads on Intel Skylake EP(64 core, 2 sockets):

  $ perf report --call-graph callee,flat

5.3.0-rc6+ (tip perf/core) - fixed

-   92.66%82.64%  miniFE.x  libiomp5.so [.] 
_INTERNAL_25___src_kmp_barrier_cpp_1d20fae8::__kmp_hyper_barrier_release
   - 69.14% 
_INTERNAL_25___src_kmp_barrier_cpp_1d20fae8::__kmp_hyper_barrier_release
__kmp_fork_barrier
__kmp_launch_thread
_INTERNAL_24___src_z_Linux_util_c_3e0095e6::__kmp_launch_worker
start_thread
__clone
   - 21.89% 
_INTERNAL_25___src_kmp_barrier_cpp_1d20fae8::__kmp_hyper_barrier_release
__kmp_barrier
__kmpc_reduce_nowait
miniFE::cg_solve, 
miniFE::Vector, miniFE::matvec_std, miniFE::Vector, 
miniFE::Vector, miniFE::matvec_std, miniFE::Vector, 
miniFE::Vector, miniFE::matvec_std, miniFE::Vector, 
miniFE::Vector, miniFE::matvec_std, miniFE::Vectorhttps://www.hpcadvisorycouncil.com/pdf/miniFE_Analysis_and_Profiling.pdf

---
Alexey Budankov (4):
  perf/core,x86: introduce sync_task_ctx() method at struct pmu
  perf/x86: install platform specific sync_task_ctx adapter
  perf/x86/intel: implement LBR callstacks context synchronization
  perf/core,x86: synchronize PMU task contexts on optimized context
switches

 arch/x86/events/core.c   |  7 +++
 arch/x86/events/intel/core.c |  7 +++
 arch/x86/events/intel/lbr.c  |  6 ++
 arch/x86/events/perf_event.h | 11 +++
 include/linux/perf_event.h   |  7 +++
 kernel/events/core.c | 13 +
 6 files changed, 51 insertions(+)

---
Changes in v4:
- moved check on simultaneous task_ctx_data objects availability 
  to the perf/core layer;
- marked sync_task_ctx() as the optional in code comments;
- renamed params of sync_task_ctx() to prev and next;

Changes in v3:
- replaced assignment with swap at intel_pmu_lbr_sync_task_ctx()

Changes in v2:
- implemented sync_task_ctx() method at perf,x86,intel pmu types;
- employed the method on the optimized context switch path between 
  equivalent perf event contexts;

-- 
2.20.1

Re: [PATCH v2 1/3] dt-bindings: clock: meson: add A1 clock controller bindings

[Jian Hu]

Hi, Jerome

Thanks for your review.

On 2019/10/21 18:43, Jerome Brunet wrote:


On Fri 18 Oct 2019 at 09:14, Jian Hu  wrote:


Add the documentation to support Amlogic A1 clock driver,
and add A1 clock controller bindings.

Signed-off-by: Jian Hu 
---
  .../devicetree/bindings/clock/amlogic,a1-clkc.yaml | 143
+


Those are 2 different controllers, not variants.
One description (one file) per controller please

OK, I will describe for periphs and PLLs controller separately.



  include/dt-bindings/clock/a1-clkc.h|  98 ++
  include/dt-bindings/clock/a1-pll-clkc.h|  16 +++
  3 files changed, 257 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/clock/amlogic,a1-clkc.yaml
  create mode 100644 include/dt-bindings/clock/a1-clkc.h
  create mode 100644 include/dt-bindings/clock/a1-pll-clkc.h

diff --git a/Documentation/devicetree/bindings/clock/amlogic,a1-clkc.yaml 
b/Documentation/devicetree/bindings/clock/amlogic,a1-clkc.yaml
new file mode 100644
index 000..b382eebe
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/amlogic,a1-clkc.yaml
@@ -0,0 +1,143 @@
+/* SPDX-License-Identifier: (GPL-2.0+ OR MIT) */
+/*
+ * Copyright (c) 2019 Amlogic, Inc. All rights reserved.
+ */
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/clock/amlogic,a1-clkc.yaml#";
+$schema: "http://devicetree.org/meta-schemas/core.yaml#";
+
+title: Amlogic Meson A/C serials Clock Control Unit Device Tree Bindings
+
+maintainers:
+  - Neil Armstrong 
+  - Jerome Brunet 
+  - Jian Hu 
+
+description: |+
+  The clock controller node should be the child of a syscon node with the
+  required property:
+
+  - compatible: Should be one of the following:
+"amlogic,meson-a-analog-sysctrl", "syscon", 
"simple-mfd"
+"amlogic,meson-a-periphs-sysctrl", "syscon", 
"simple-mfd"
+
+  Refer to the the bindings described in
+  Documentation/devicetree/bindings/mfd/syscon.txt
+
+properties:
+  "#clock-cells":
+const: 1
+  compatible:
+- enum:
+- amlogic,a1-periphs-clkc
+- amlogic,a1-pll-clkc
+
+  reg:
+maxItems: 1
+
+  clocks:
+minItems: 2
+maxItems: 6
+
+  clock-names:
+minItems: 2
+maxItems: 6
+
+required:
+  - "#clock-cells"
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+
+if:
+  properties:
+compatible:
+  enum:
+- amlogic,a1-periphs-clkc
+
+then:
+  properties:
+clocks:
+  minItems: 2
+  maxItems: 2
+items:
+ - description: fixed pll gate clock
+ - description: hifi pll gate clock
+
+clock-names:
+  minItems: 2
+  maxItems: 2
+  items:
+- const: xtal_fixpll
+- const: xtal_hifipll
+
+else:
+  if:
+properties:
+  compatible:
+const: amlogic,a1-pll-clkc
+
+  then:
+properties:
+  clocks:
+minItems: 6
+maxItems: 6
+items:
+ - description: Input fixed pll div2
+ - description: Input fixed pll div3
+ - description: Input fixed pll div5
+ - description: Input fixed pll div7
+ - description: Periph Hifi pll
+ - description: Input Oscillator (usually at 24MHz)
+
+  clock-names:
+minItems: 6
+maxItems: 6
+items:
+ - const: fclk_div2
+ - const: fclk_div3
+ - const: fclk_div5
+ - const: fclk_div7
+ - const: hifi_pll
+ - const: xtal
+
+
+additionalProperties: false
+
+examples:
+  - |
+analog: system-controller@0 {
+compatible = "amlogic,meson-a-analog-sysctrl",
+ "simple-mfd", "syscon";
+reg = <0 0x7c00 0 0x21c>;
+
+clkc_pll: pll-clock-controller {
+compatible = "amlogic,a1-pll-clkc";
+#clock-cells = <1>;
+clocks = <&clkc_periphs CLKID_XTAL_FIXPLL>,
+ <&clkc_periphs CLKID_XTAL_HIFIPLL>;
+clock-names = "xtal_fixpll", "xtal_hifipll";
+};
+};
+
+  - |
+periphs: system-controller@1 {
+compatible = "amlogic,meson-a-periphs-sysctrl",
+ "simple-mfd", "syscon";
+reg = <0 0x800 0 0x104>;
+
+clkc_periphs: periphs-clock-controller {
+compatible = "amlogic,a1-periphs-clkc";
+#clock-cells = <1>;
+clocks = <&clkc_pll CLKID_FCLK_DIV2>,
+<&clkc_pll CLKID_FCLK_DIV3>,
+<&clkc_pll CLKID_FCLK_DIV5>,
+<&clkc_pll CLKID_FCLK_DIV7>,
+<&clkc_pll CLKID_HIFI_PLL>,
+<&xtal>;
+clock-names = "fclk_div2", "fclk_div3", "fclk_div5",
+  "fclk_div7", "hifi_pll", "xtal";
+};
+};
diff --git a/include/dt-bindings/clock/a1-clkc.h 
b/include/dt-bindings/clock/a1-clkc.h
new file mode 100644
index 000..1ba0112
--- /dev/null
+++ b/include/dt-bindings/cloc

Re: [PATCH v2 11/13] drivers: irqchip: qcom-pdc: Add irqchip for sc7180

[Maulik Shah]

On 10/21/2019 1:40 PM, Marc Zyngier wrote:

On 2019-10-21 07:55, Rajendra Nayak wrote:

From: Maulik Shah 

Add sc7180 pdc irqchip

Signed-off-by: Maulik Shah 
Signed-off-by: Rajendra Nayak 
Cc: Lina Iyer 
Cc: Marc Zyngier 
---
v2: No change

 drivers/irqchip/qcom-pdc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/irqchip/qcom-pdc.c b/drivers/irqchip/qcom-pdc.c
index faa7d61b9d6c..954fb599fa9c 100644
--- a/drivers/irqchip/qcom-pdc.c
+++ b/drivers/irqchip/qcom-pdc.c
@@ -310,3 +310,4 @@ static int qcom_pdc_init(struct device_node
*node, struct device_node *parent)
 }

 IRQCHIP_DECLARE(pdc_sdm845, "qcom,sdm845-pdc", qcom_pdc_init);
+IRQCHIP_DECLARE(pdc_sc7180, "qcom,sc7180-pdc", qcom_pdc_init);


What I gather from these 3 irq-related patches is that as far as
the PDC is concerned, SDM845/850 and SC7180 are strictly identical.

Why the churn?

    M.


Hi Marc,

Different compatible were used to distinguish since interrupt mapping 
(PDC to GIC) was earlier kept in driver.


Now since mapping is kept in DTSI, we can continue to use 
qcom,sdm845-pdc for sc7180.


i will submit another patch to make it more generic for all SoCs like 
"qcom,pdc".


Thanks,

Maulik

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

linux-next: Tree for Oct 22

[Stephen Rothwell]

Hi all,

Changes since 20191021:

The tip tree lost its build failure.

The char-misc tree gained a conflict against the keys tree.

Non-merge commits (relative to Linus' tree): 5034
 5044 files changed, 178274 insertions(+), 83401 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (7d194c2100ad Linux 5.4-rc4)
Merging fixes/master (54ecb8f7028c Linux 5.4-rc1)
Merging kbuild-current/fixes (7d194c2100ad Linux 5.4-rc4)
Merging arc-current/for-curr (41277ba7eb4e ARC: mm: tlb flush optim: elide 
redundant uTLB invalidates for MMUv3)
Merging arm-current/fixes (2ecb287998a4 ARM: 8926/1: v7m: remove register save 
to stack before svc)
Merging arm-soc-fixes/arm/fixes (6813a9ce1f99 Merge tag 
'arm-soc/for-5.4/devicetree-fixes' of https://github.com/Broadcom/stblinux into 
arm/fixes)
Merging arm64-fixes/for-next/fixes (777d062e5bee Merge branch 'errata/tx2-219' 
into for-next/fixes)
Merging m68k-current/for-linus (0f1979b402df m68k: Remove ioremap_fullcache())
Merging powerpc-fixes/fixes (d10f60ae27d2 powerpc/32s: fix 
allow/prevent_user_access() when crossing segment boundaries.)
Merging s390-fixes/fixes (062795fcdcb2 s390/uaccess: avoid (false positive) 
compiler warnings)
Merging sparc/master (038029c03e21 sparc: remove unneeded uapi/asm/statfs.h)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (b30605319794 r8152: add device id for Lenovo ThinkPad USB-C 
Dock Gen 2)
Merging bpf/master (05679ca6feeb xdp: Prevent overflow in devmap_hash cost 
calculation for 32-bit builds)
Merging ipsec/master (68ce6688a5ba net: sched: taprio: Fix potential integer 
overflow in taprio_set_picos_per_byte)
Merging netfilter/master (503c9addef61 ptp: fix typo of "mechanism" in Kconfig 
help text)
Merging ipvs/master (503c9addef61 ptp: fix typo of "mechanism" in Kconfig help 
text)
Merging wireless-drivers/master (d79749f7716d ath10k: fix latency issue for 
QCA988x)
Merging mac80211/master (82ad862115c2 Merge branch 'smc-fixes')
Merging rdma-fixes/for-rc (777a8b32bc0f IB/core: Use rdma_read_gid_l2_fields to 
compare GID L2 fields)
Merging sound-current/for-linus (c8d2dcb3e941 Merge tag 'asoc-fix-v5.4-rc4' of 
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus)
Merging sound-asoc-fixes/for-linus (e8485d88376c Merge branch 'asoc-5.4' into 
asoc-linus)
Merging regmap-fixes/for-linus (da0c9ea146cb Linux 5.4-rc2)
Merging regulator-fixes/for-linus (d730b0dd62b4 Merge branch 'regulator-5.4' 
into regulator-linus)
Merging spi-fixes/for-linus (fed8d8c7a6dc spi: atmel: fix handling of cs_change 
set on non-last xfer)
Merging pci-current/for-linus (54ecb8f7028c Linux 5.4-rc1)
Merging driver-core.current/driver-core-linus (82af5b660967 sysfs: Fixes 
__BIN_ATTR_WO() macro)
Merging tty.current/tty-linus (f50b6805dbb9 8250-men-mcb: fix error checking 
when get_num_ports returns -ENODEV)
Merging usb.current/usb-linus (9794476942d8 usb: cdns3: Error out if 
USB_DR_MODE_UNKNOWN in cdns3_core_init_role())
Merging usb-gadget-fixes/fixes (4a56a478a525 usb: gadget: mass_storage: Fix 
races between fsg_disabl

Re: [PATCH v4 3/3] powerpc/prom_init: Use -ffreestanding to avoid a reference to bcmp

[Nathan Chancellor]

On Fri, Oct 18, 2019 at 03:02:10PM -0500, Segher Boessenkool wrote:
> On Fri, Oct 18, 2019 at 12:00:22PM -0700, Nathan Chancellor wrote:
> > Just as an FYI, there was some more discussion around the availablity
> > and use of bcmp in this LLVM bug which spawned
> > commit 5f074f3e192f ("lib/string.c: implement a basic bcmp").
> > 
> > https://bugs.llvm.org/show_bug.cgi?id=41035#c13
> > 
> > I believe this is the proper solution but I am fine with whatever works,
> > I just want our CI to be green without any out of tree patches again...
> 
> I think the proper solution is for the kernel to *do* use -ffreestanding,
> and then somehow tell the kernel that memcpy etc. are the standard
> functions.  A freestanding GCC already requires memcpy, memmove, memset,
> memcmp, and sometimes abort to exist and do the standard thing; why cannot
> programs then also rely on it to be the standard functions.
> 
> What exact functions are the reason the kernel does not use -ffreestanding?
> Is it just memcpy?  Is more wanted?
> 
> 
> Segher

I think Linus summarized it pretty well here:

https://lore.kernel.org/lkml/CAHk-=wi-epJZfBHDbKKDZ64us7WkF=lpufhvybmzsteo8q0...@mail.gmail.com/

Cheers,
Nathan

Re: [PATCH v9 18/22] RISC-V: KVM: Simplify stage2 page table programming

[Anup Patel]

On Mon, Oct 21, 2019 at 11:01 PM Paolo Bonzini  wrote:
>
> On 16/10/19 18:11, Anup Patel wrote:
> > Instead of dealing with PGD, PMD, and PTE differently in stage2
> > page table progamming, we can simply use iterative and recursive
> > helper functions to program stage2 page tables of any level.
> >
> > This patch re-implements stage2_get_leaf_entry(), stage2_set_pte(),
> > stage2_map_page(), stage2_op_pte(), stage2_unmap_range(), and
> > stage2_wp_range() helper functions as mentioned above.
> >
> > Signed-off-by: Anup Patel 
>
> I honestly haven't reviewed this in depth, but I definitely agree with
> the idea.  Please squash it with the original implementation though.

Sure, I will squash patch18 (this patch) onto patch11.

Regards,
Anup

>
> Paolo
>
> > ---
> >  arch/riscv/kvm/mmu.c | 469 +++
> >  1 file changed, 164 insertions(+), 305 deletions(-)
> >
> > diff --git a/arch/riscv/kvm/mmu.c b/arch/riscv/kvm/mmu.c
> > index 5aa5ea5ef8f6..fe86cae4cf42 100644
> > --- a/arch/riscv/kvm/mmu.c
> > +++ b/arch/riscv/kvm/mmu.c
> > @@ -21,15 +21,56 @@
> >  #ifdef CONFIG_64BIT
> >  #define stage2_have_pmd  true
> >  #define stage2_gpa_size  ((phys_addr_t)(1ULL << 39))
> > -#define stage2_cache_min_pages   2
> > +#define stage2_pgd_levels3
> > +#define stage2_index_bits9
> >  #else
> > -#define pmd_index(x) 0
> > -#define pfn_pmd(x, y)({ pmd_t __x = { 0 }; __x; })
> >  #define stage2_have_pmd  false
> >  #define stage2_gpa_size  ((phys_addr_t)(1ULL << 32))
> > -#define stage2_cache_min_pages   1
> > +#define stage2_pgd_levels2
> > +#define stage2_index_bits10
> >  #endif
> >
> > +#define stage2_pte_index(addr, level) \
> > +(((addr) >> (PAGE_SHIFT + stage2_index_bits * (level))) & (PTRS_PER_PTE - 
> > 1))
> > +
> > +static inline unsigned long stage2_pte_page_vaddr(pte_t pte)
> > +{
> > + return (unsigned long)pfn_to_virt(pte_val(pte) >> _PAGE_PFN_SHIFT);
> > +}
> > +
> > +static int stage2_page_size_to_level(unsigned long page_size, u32 
> > *out_level)
> > +{
> > + if (page_size == PAGE_SIZE)
> > + *out_level = 0;
> > + else if (page_size == PMD_SIZE)
> > + *out_level = 1;
> > + else if (page_size == PGDIR_SIZE)
> > + *out_level = (stage2_have_pmd) ? 2 : 1;
> > + else
> > + return -EINVAL;
> > +
> > + return 0;
> > +}
> > +
> > +static int stage2_level_to_page_size(u32 level, unsigned long *out_pgsize)
> > +{
> > + switch (level) {
> > + case 0:
> > + *out_pgsize = PAGE_SIZE;
> > + break;
> > + case 1:
> > + *out_pgsize = (stage2_have_pmd) ? PMD_SIZE : PGDIR_SIZE;
> > + break;
> > + case 2:
> > + *out_pgsize = PGDIR_SIZE;
> > + break;
> > + default:
> > + return -EINVAL;
> > + }
> > +
> > + return 0;
> > +}
> > +
> >  static int stage2_cache_topup(struct kvm_mmu_page_cache *pcache,
> > int min, int max)
> >  {
> > @@ -67,61 +108,30 @@ static void *stage2_cache_alloc(struct 
> > kvm_mmu_page_cache *pcache)
> >   return p;
> >  }
> >
> > -static int stage2_pgdp_test_and_clear_young(pgd_t *pgd)
> > -{
> > - return ptep_test_and_clear_young(NULL, 0, (pte_t *)pgd);
> > -}
> > -
> > -static int stage2_pmdp_test_and_clear_young(pmd_t *pmd)
> > -{
> > - return ptep_test_and_clear_young(NULL, 0, (pte_t *)pmd);
> > -}
> > -
> > -static int stage2_ptep_test_and_clear_young(pte_t *pte)
> > -{
> > - return ptep_test_and_clear_young(NULL, 0, pte);
> > -}
> > -
> >  static bool stage2_get_leaf_entry(struct kvm *kvm, gpa_t addr,
> > -   pgd_t **pgdpp, pmd_t **pmdpp, pte_t **ptepp)
> > +   pte_t **ptepp, u32 *ptep_level)
> >  {
> > - pgd_t *pgdp;
> > - pmd_t *pmdp;
> >   pte_t *ptep;
> > -
> > - *pgdpp = NULL;
> > - *pmdpp = NULL;
> > - *ptepp = NULL;
> > -
> > - pgdp = &kvm->arch.pgd[pgd_index(addr)];
> > - if (!pgd_val(*pgdp))
> > - return false;
> > - if (pgd_val(*pgdp) & _PAGE_LEAF) {
> > - *pgdpp = pgdp;
> > - return true;
> > - }
> > -
> > - if (stage2_have_pmd) {
> > - pmdp = (void *)pgd_page_vaddr(*pgdp);
> > - pmdp = &pmdp[pmd_index(addr)];
> > - if (!pmd_present(*pmdp))
> > - return false;
> > - if (pmd_val(*pmdp) & _PAGE_LEAF) {
> > - *pmdpp = pmdp;
> > + u32 current_level = stage2_pgd_levels - 1;
> > +
> > + *ptep_level = current_level;
> > + ptep = (pte_t *)kvm->arch.pgd;
> > + ptep = &ptep[stage2_pte_index(addr, current_level)];
> > + while (ptep && pte_val(*ptep)) {
> > + if (pte_val(*ptep) & _PAGE_LEAF) {
> > + *ptep_level = current_level;
> > + *ptepp = ptep;
> >

Re: [PATCH v3 1/5] net: ag71xx: port to phylink

[Oleksij Rempel]

On 22.10.19 00:21, Russell King - ARM Linux admin wrote:

On Mon, Oct 21, 2019 at 07:38:07AM +0200, Oleksij Rempel wrote:

+static void ag71xx_mac_validate(struct phylink_config *config,
+   unsigned long *supported,
+   struct phylink_link_state *state)
  {
-   struct ag71xx *ag = netdev_priv(ndev);
+   __ETHTOOL_DECLARE_LINK_MODE_MASK(mask) = { 0, };
+
+   if (state->interface != PHY_INTERFACE_MODE_NA &&
+   state->interface != PHY_INTERFACE_MODE_GMII &&
+   state->interface != PHY_INTERFACE_MODE_MII) {
+   bitmap_zero(supported, __ETHTOOL_LINK_MODE_MASK_NBITS);
+   return;
+   }
+
+   phylink_set(mask, MII);
+
+   /* flow control is not supported */
+
+   phylink_set(mask, 10baseT_Half);
+   phylink_set(mask, 10baseT_Full);
+   phylink_set(mask, 100baseT_Half);
+   phylink_set(mask, 100baseT_Full);
  
-	ag71xx_link_adjust(ag, true);

+   if (state->interface == PHY_INTERFACE_MODE_NA &&
+   state->interface == PHY_INTERFACE_MODE_GMII) {


This is always false.


... I shame to myself :(


Apart from that, from just reading the patch I have no further concerns.


ok. thx!

Kind regards,
Oleksij Rempel

--
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [PATCH v3 1/6] perf cs-etm: Fix unsigned variable comparison to zero

[Leo Yan]

Hi Mathieu,

On Fri, Oct 11, 2019 at 02:16:06PM -0600, Mathieu Poirier wrote:
> On Sat, Oct 05, 2019 at 05:16:09PM +0800, Leo Yan wrote:
> > If the u64 variable 'offset' is a negative integer, comparison it with
> > bigger than zero is always going to be true because it is unsigned.
> > Fix this by using s64 type for variable 'offset'.
> > 
> > Signed-off-by: Leo Yan 
> > ---
> >  tools/perf/util/cs-etm.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
> > index 4ba0f871f086..4bc2d9709d4f 100644
> > --- a/tools/perf/util/cs-etm.c
> > +++ b/tools/perf/util/cs-etm.c
> > @@ -940,7 +940,7 @@ u64 cs_etm__last_executed_instr(const struct 
> > cs_etm_packet *packet)
> >  static inline u64 cs_etm__instr_addr(struct cs_etm_queue *etmq,
> >  u64 trace_chan_id,
> >  const struct cs_etm_packet *packet,
> > -u64 offset)
> > +s64 offset)
> 
> In Suzuki's reply there was two choices, 1) move the while(offset > 0) to
> while (offset) or change the type of @offset to an s64.  Here we know offset
> can't be negative because of the 
> tidq->period_instructions >= etm->instructions_sample_period 
> 
> in function cs_etm__sample().  As such I think option #1 is the right way to
> deal with this rather than changing the type of the variable.

I took sometime to use formulas to prove that 'offset' is possible to
be a negative value :)

Just paste the updated commit log at here for review:

  Pi: period_instructions
  Ie: instrs_executed
  Io: instrs_over
  Ip: instructions_sample_period

  Pi' = Pi + Ie   -> New period_instructions equals to the old
 period_instructions + instrs_executed
  Io  = Pi' - Ip  -> period_instructions - instructions_sample_period

  offset = Ie - Io - 1
 = Ie - (Pi' - Ip) -1
 = Ie - (Pi + Ie - Ip) -1
 = Ip - Pi - 1

In theory, if Ip (instructions_sample_period) is small enough and Pi
(period_instructions) is bigger than Ip, then it will lead to the
negative value for 'offset'.

So let's see below command:

  perf inject --itrace=i1il128 -i perf.data -o perf.data.new

With this command, 'offset' is very easily to be a negative value when
handling packets; this is because if use the inject option 'i1', then
instructions_sample_period equals to 1; so:

  offset = 1 - Pi - 1
 = -Pi

Any Pi bigger than zero leads 'offset' to a negative value.

Thanks,
Leo Yan

> >  {
> > if (packet->isa == CS_ETM_ISA_T32) {
> > u64 addr = packet->start_addr;
> > @@ -1372,7 +1372,7 @@ static int cs_etm__sample(struct cs_etm_queue *etmq,
> >  * sample is reported as though instruction has just been
> >  * executed, but PC has not advanced to next instruction)
> >  */
> > -   u64 offset = (instrs_executed - instrs_over - 1);
> > +   s64 offset = (instrs_executed - instrs_over - 1);
> > u64 addr = cs_etm__instr_addr(etmq, trace_chan_id,
> >   tidq->packet, offset);
> >  
> > -- 
> > 2.17.1
> > 

Re: [PATCH v9 19/22] RISC-V: KVM: Remove per-CPU vsip_shadow variable

[Anup Patel]

On Mon, Oct 21, 2019 at 10:58 PM Paolo Bonzini  wrote:
>
> On 16/10/19 18:12, Anup Patel wrote:
> > Currently, we track last value wrote to VSIP CSR using per-CPU
> > vsip_shadow variable but this easily goes out-of-sync because
> > Guest can update VSIP.SSIP bit directly.
> >
> > To simplify things, we remove per-CPU vsip_shadow variable and
> > unconditionally write vcpu->arch.guest_csr.vsip to VSIP CSR in
> > run-loop.
> >
> > Signed-off-by: Anup Patel 
>
> Please squash this and patch 20 into the corresponding patches earlier
> in the series.

Sure, I will squash patch20 and patch19 onto patch5.

Regards,
Anup


>
> Paolo
>
> > ---
> >  arch/riscv/include/asm/kvm_host.h |  3 ---
> >  arch/riscv/kvm/main.c |  6 --
> >  arch/riscv/kvm/vcpu.c | 24 +---
> >  3 files changed, 1 insertion(+), 32 deletions(-)
> >
> > diff --git a/arch/riscv/include/asm/kvm_host.h 
> > b/arch/riscv/include/asm/kvm_host.h
> > index ec1ca4bc98f2..cd86acaed055 100644
> > --- a/arch/riscv/include/asm/kvm_host.h
> > +++ b/arch/riscv/include/asm/kvm_host.h
> > @@ -202,9 +202,6 @@ static inline void kvm_arch_vcpu_uninit(struct kvm_vcpu 
> > *vcpu) {}
> >  static inline void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu) {}
> >  static inline void kvm_arch_vcpu_block_finish(struct kvm_vcpu *vcpu) {}
> >
> > -int kvm_riscv_setup_vsip(void);
> > -void kvm_riscv_cleanup_vsip(void);
> > -
> >  #define KVM_ARCH_WANT_MMU_NOTIFIER
> >  int kvm_unmap_hva_range(struct kvm *kvm,
> >   unsigned long start, unsigned long end);
> > diff --git a/arch/riscv/kvm/main.c b/arch/riscv/kvm/main.c
> > index 55df85184241..002301a27d29 100644
> > --- a/arch/riscv/kvm/main.c
> > +++ b/arch/riscv/kvm/main.c
> > @@ -61,17 +61,11 @@ void kvm_arch_hardware_disable(void)
> >
> >  int kvm_arch_init(void *opaque)
> >  {
> > - int ret;
> > -
> >   if (!riscv_isa_extension_available(NULL, h)) {
> >   kvm_info("hypervisor extension not available\n");
> >   return -ENODEV;
> >   }
> >
> > - ret = kvm_riscv_setup_vsip();
> > - if (ret)
> > - return ret;
> > -
> >   kvm_riscv_stage2_vmid_detect();
> >
> >   kvm_info("hypervisor extension available\n");
> > diff --git a/arch/riscv/kvm/vcpu.c b/arch/riscv/kvm/vcpu.c
> > index fd77cd39dd8c..f1a218d3a8cf 100644
> > --- a/arch/riscv/kvm/vcpu.c
> > +++ b/arch/riscv/kvm/vcpu.c
> > @@ -111,8 +111,6 @@ static void kvm_riscv_vcpu_host_fp_restore(struct 
> > kvm_cpu_context *cntx) {}
> >riscv_isa_extension_mask(s) | \
> >riscv_isa_extension_mask(u))
> >
> > -static unsigned long __percpu *vsip_shadow;
> > -
> >  static void kvm_riscv_reset_vcpu(struct kvm_vcpu *vcpu)
> >  {
> >   struct kvm_vcpu_csr *csr = &vcpu->arch.guest_csr;
> > @@ -765,7 +763,6 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu 
> > *vcpu,
> >  void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
> >  {
> >   struct kvm_vcpu_csr *csr = &vcpu->arch.guest_csr;
> > - unsigned long *vsip = raw_cpu_ptr(vsip_shadow);
> >
> >   csr_write(CSR_VSSTATUS, csr->vsstatus);
> >   csr_write(CSR_VSIE, csr->vsie);
> > @@ -775,7 +772,6 @@ void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
> >   csr_write(CSR_VSCAUSE, csr->vscause);
> >   csr_write(CSR_VSTVAL, csr->vstval);
> >   csr_write(CSR_VSIP, csr->vsip);
> > - *vsip = csr->vsip;
> >   csr_write(CSR_VSATP, csr->vsatp);
> >
> >   kvm_riscv_stage2_update_hgatp(vcpu);
> > @@ -843,26 +839,8 @@ static void kvm_riscv_check_vcpu_requests(struct 
> > kvm_vcpu *vcpu)
> >  static void kvm_riscv_update_vsip(struct kvm_vcpu *vcpu)
> >  {
> >   struct kvm_vcpu_csr *csr = &vcpu->arch.guest_csr;
> > - unsigned long *vsip = raw_cpu_ptr(vsip_shadow);
> > -
> > - if (*vsip != csr->vsip) {
> > - csr_write(CSR_VSIP, csr->vsip);
> > - *vsip = csr->vsip;
> > - }
> > -}
> > -
> > -int kvm_riscv_setup_vsip(void)
> > -{
> > - vsip_shadow = alloc_percpu(unsigned long);
> > - if (!vsip_shadow)
> > - return -ENOMEM;
> >
> > - return 0;
> > -}
> > -
> > -void kvm_riscv_cleanup_vsip(void)
> > -{
> > - free_percpu(vsip_shadow);
> > + csr_write(CSR_VSIP, csr->vsip);
> >  }
> >
> >  int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
> >
>

Re: [PATCH v9 20/22] RISC-V: KVM: Fix race-condition in kvm_riscv_vcpu_sync_interrupts()

[Anup Patel]

On Mon, Oct 21, 2019 at 10:57 PM Paolo Bonzini  wrote:
>
> On 16/10/19 18:12, Anup Patel wrote:
> > + /* Read current VSIP and VSIE CSRs */
> > + vsip = csr_read(CSR_VSIP);
> > + csr->vsie = csr_read(CSR_VSIE);
> > +
> > + /* Sync-up VSIP.SSIP bit changes does by Guest */
> > + if ((csr->vsip ^ vsip) & (1UL << IRQ_S_SOFT)) {
> > + if (!test_and_set_bit(IRQ_S_SOFT, &v->irqs_pending_mask)) {
> > + if (vsip & (1UL << IRQ_S_SOFT))
> > + set_bit(IRQ_S_SOFT, &v->irqs_pending);
> > + else
> > + clear_bit(IRQ_S_SOFT, &v->irqs_pending);
> > + }
>
> Looks good, but I wonder if this could just be "csr->vsip =
> csr_read(CSR_VSIP)", which will be fixed up by flush_interrupts on the
> next entry.

It's not just "csr->vsip = csr_read(CSR_VSIP" because "irqs_pending"
bitmap has to be in-sync with Guest updates to VSIP because WFI
trap-n-emulate will check for pending interrupts which in-turn checks
"irqs_pending" bitmap.

Regards,
Anup

Re: [PATCH v3 3/6] perf cs-etm: Support thread stack

[Leo Yan]

Hi Mathieu,

On Fri, Oct 11, 2019 at 11:53:53AM -0600, Mathieu Poirier wrote:
> On Sat, Oct 05, 2019 at 05:16:11PM +0800, Leo Yan wrote:
> > Since Arm CoreSight doesn't support thread stack, the decoding cannot
> > display symbols with indented spaces to reflect the stack depth.
> > 
> > This patch adds support thread stack for Arm CoreSight, this allows
> > 'perf script' to display properly for option '-F,+callindent'.
> > 
> > Before:
> > 
> >   # perf script -F,+callindent
> > main  2808  1  branches: coresight_test1
> >   8634f5c8 coresight_test1+0x3c 
> > (/root/coresight_test/libcstest.so)
> > main  2808  1  branches: printf@plt 
> >   ba8d37ec main+0x28 (/root/coresight_test/main)
> > main  2808  1  branches: printf@plt 
> >   ba8d36bc printf@plt+0xc (/root/coresight_test/main)
> > main  2808  1  branches: _init  
> >   ba8d3650 _init+0x30 (/root/coresight_test/main)
> > main  2808  1  branches: _dl_fixup  
> >   86373b4c _dl_runtime_resolve+0x40 
> > (/lib/aarch64-linux-gnu/ld-2.28.so)
> > main  2808  1  branches: _dl_lookup_symbol_x
> >   8636e078 _dl_fixup+0xb8 
> > (/lib/aarch64-linux-gnu/ld-2.28.so)
> >   [...]
> > 
> > After:
> > 
> >   # perf script -F,+callindent
> > main  2808  1  branches: 
> > coresight_test1  8634f5c8 
> > coresight_test1+0x3c (/root/coresight_test/libcstest.so)
> > main  2808  1  branches: 
> > printf@plt   ba8d37ec main+0x28 
> > (/root/coresight_test/main)
> > main  2808  1  branches: 
> > printf@plt   ba8d36bc 
> > printf@plt+0xc (/root/coresight_test/main)
> > main  2808  1  branches: 
> > _initba8d3650 _init+0x30 
> > (/root/coresight_test/main)
> > main  2808  1  branches: 
> > _dl_fixup86373b4c 
> > _dl_runtime_resolve+0x40 (/lib/aarch64-linux-gnu/ld-2.28.s
> > main  2808  1  branches:
> >  _dl_lookup_symbol_x  8636e078 _dl_fixup+0xb8 
> > (/lib/aarch64-linux-gnu/ld-2.28.so)
> >   [...]
> > 
> > Signed-off-by: Leo Yan 
> > ---
> >  tools/perf/util/cs-etm.c | 44 
> >  1 file changed, 44 insertions(+)
> > 
> > diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
> > index 58ceba7b91d5..780abbfd1833 100644
> > --- a/tools/perf/util/cs-etm.c
> > +++ b/tools/perf/util/cs-etm.c
> > @@ -1117,6 +1117,45 @@ static void cs_etm__copy_insn(struct cs_etm_queue 
> > *etmq,
> >sample->insn_len, (void *)sample->insn);
> >  }
> >  
> > +static void cs_etm__add_stack_event(struct cs_etm_queue *etmq,
> > +   struct cs_etm_traceid_queue *tidq)
> > +{
> > +   struct cs_etm_auxtrace *etm = etmq->etm;
> > +   u8 trace_chan_id = tidq->trace_chan_id;
> > +   int insn_len;
> > +   u64 from_ip, to_ip;
> > +
> > +   if (etm->synth_opts.thread_stack) {
> > +   from_ip = cs_etm__last_executed_instr(tidq->prev_packet);
> > +   to_ip = cs_etm__first_executed_instr(tidq->packet);
> > +
> > +   insn_len = cs_etm__instr_size(etmq, trace_chan_id,
> > + tidq->prev_packet->isa, from_ip);
> > +
> > +   /*
> > +* Create thread stacks by keeping track of calls and returns;
> > +* any call pushes thread stack, return pops the stack, and
> > +* flush stack when the trace is discontinuous.
> > +*/
> > +   thread_stack__event(tidq->thread, tidq->prev_packet->cpu,
> > +   tidq->prev_packet->flags,
> > +   from_ip, to_ip, insn_len,
> > +   etmq->buffer->buffer_nr);
> 
> Details are a little fuzzy in my head but I'm pretty sure
> we want trace_chan_id here.  

I spent some time to look into this question, and I think we don't
need to add extra info for trace_chan_id.

The main reason is for CPU wide tracing, if one task is migrated from
CPU_a to CPU_b, if we append 'trace_chan_id' for the buffer number, then
it will tell the thread_stack that the buffer has been changed (or it
will be considered the trace is discontinuous), then thread stack will
be flushed.  Actually, this is not what we want; if a task is migrated
from one CPU to another, we still need to kee

[PATCH] 802.11n IBSS: wlan0 stops receiving packets due to aggregation after sender reboot

[Krzysztof Hałasa]

Fix a bug where the mac80211 RX aggregation code sets a new aggregation
"session" at the remote station's request, but the head_seq_num
(the sequence number the receiver expects to receive) isn't reset.

Spotted on a pair of AR9580 in IBSS mode.

Signed-off-by: Krzysztof Halasa 

diff --git a/net/mac80211/agg-rx.c b/net/mac80211/agg-rx.c
index 4d1c335e06e5..775a51cc51c9 100644
--- a/net/mac80211/agg-rx.c
+++ b/net/mac80211/agg-rx.c
@@ -354,9 +354,11 @@ void ___ieee80211_start_rx_ba_session(struct sta_info *sta,
 */
rcu_read_lock();
tid_rx = rcu_dereference(sta->ampdu_mlme.tid_rx[tid]);
-   if (tid_rx && tid_rx->timeout == timeout)
+   if (tid_rx && tid_rx->timeout == timeout) {
+   tid_rx->ssn = start_seq_num;
+   tid_rx->head_seq_num = start_seq_num;
status = WLAN_STATUS_SUCCESS;
-   else
+   } else
status = WLAN_STATUS_REQUEST_DECLINED;
rcu_read_unlock();
goto end;

-- 
Krzysztof Hałasa

ŁUKASIEWICZ Research Network
Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland

Re: [alsa-devel] [PATCH v2 4/5] soundwire: intel/cadence: add flag for interrupt enable

[Vinod Koul]

On 21-10-19, 05:26, Pierre-Louis Bossart wrote:
> On 10/20/19 11:14 PM, Vinod Koul wrote:
> > On 16-09-19, 14:09, Pierre-Louis Bossart wrote:
> > > Prepare for future PM support and fix error handling by disabling
> > > interrupts as needed.
> > > 
> > > Signed-off-by: Pierre-Louis Bossart 
> > > ---
> > >   drivers/soundwire/cadence_master.c | 18 --
> > >   drivers/soundwire/cadence_master.h |  2 +-
> > >   drivers/soundwire/intel.c  | 12 +++-
> > >   3 files changed, 20 insertions(+), 12 deletions(-)
> > > 
> > > diff --git a/drivers/soundwire/cadence_master.c 
> > > b/drivers/soundwire/cadence_master.c
> > > index 5f900cf2acb9..a71df99ca18f 100644
> > > --- a/drivers/soundwire/cadence_master.c
> > > +++ b/drivers/soundwire/cadence_master.c
> > > @@ -819,14 +819,17 @@ EXPORT_SYMBOL(sdw_cdns_exit_reset);
> > >* sdw_cdns_enable_interrupt() - Enable SDW interrupts and update config
> > >* @cdns: Cadence instance
> > >*/
> > > -int sdw_cdns_enable_interrupt(struct sdw_cdns *cdns)
> > > +int sdw_cdns_enable_interrupt(struct sdw_cdns *cdns, bool state)
> > >   {
> > > - u32 mask;
> > > + u32 slave_intmask0 = 0;
> > > + u32 slave_intmask1 = 0;
> > > + u32 mask = 0;
> > > +
> > > + if (!state)
> > > + goto update_masks;
> > > - cdns_writel(cdns, CDNS_MCP_SLAVE_INTMASK0,
> > > - CDNS_MCP_SLAVE_INTMASK0_MASK);
> > > - cdns_writel(cdns, CDNS_MCP_SLAVE_INTMASK1,
> > > - CDNS_MCP_SLAVE_INTMASK1_MASK);
> > > + slave_intmask0 = CDNS_MCP_SLAVE_INTMASK0_MASK;
> > > + slave_intmask1 = CDNS_MCP_SLAVE_INTMASK1_MASK;
> > >   /* enable detection of all slave state changes */
> > >   mask = CDNS_MCP_INT_SLAVE_MASK;
> > > @@ -849,6 +852,9 @@ int sdw_cdns_enable_interrupt(struct sdw_cdns *cdns)
> > >   if (interrupt_mask) /* parameter override */
> > >   mask = interrupt_mask;
> > > +update_masks:
> > > + cdns_writel(cdns, CDNS_MCP_SLAVE_INTMASK0, slave_intmask0);
> > > + cdns_writel(cdns, CDNS_MCP_SLAVE_INTMASK1, slave_intmask1);
> > >   cdns_writel(cdns, CDNS_MCP_INTMASK, mask);
> > >   /* commit changes */
> > > diff --git a/drivers/soundwire/cadence_master.h 
> > > b/drivers/soundwire/cadence_master.h
> > > index 1a67728c5000..302351808098 100644
> > > --- a/drivers/soundwire/cadence_master.h
> > > +++ b/drivers/soundwire/cadence_master.h
> > > @@ -162,7 +162,7 @@ int sdw_cdns_init(struct sdw_cdns *cdns);
> > >   int sdw_cdns_pdi_init(struct sdw_cdns *cdns,
> > > struct sdw_cdns_stream_config config);
> > >   int sdw_cdns_exit_reset(struct sdw_cdns *cdns);
> > > -int sdw_cdns_enable_interrupt(struct sdw_cdns *cdns);
> > > +int sdw_cdns_enable_interrupt(struct sdw_cdns *cdns, bool state);
> > >   #ifdef CONFIG_DEBUG_FS
> > >   void sdw_cdns_debugfs_init(struct sdw_cdns *cdns, struct dentry *root);
> > > diff --git a/drivers/soundwire/intel.c b/drivers/soundwire/intel.c
> > > index cdb3243e8823..08530c136c5f 100644
> > > --- a/drivers/soundwire/intel.c
> > > +++ b/drivers/soundwire/intel.c
> > > @@ -1036,7 +1036,7 @@ static int intel_probe(struct platform_device *pdev)
> > >   ret = sdw_add_bus_master(&sdw->cdns.bus);
> > >   if (ret) {
> > >   dev_err(&pdev->dev, "sdw_add_bus_master fail: %d\n", 
> > > ret);
> > > - goto err_master_reg;
> > > + return ret;
> > 
> > I am not sure I like this line change, before this IIRC the function and
> > single place of return, so changing this doesn't seem to improve
> > anything here..?
> 
> Doing a goto to do a return is not very nice either.

Hrmm, isn't that what you are doing few lines below. The point here is
that this line of change here doesnt change anything, doesnt improve
anything so why change :)

> I can change this, but it doesn't really matter: this entire code will be
> removed anyways to get rid of platform_devices and the probe itself will be
> split in two.
> 
> > 
> > >   }
> > >   if (sdw->cdns.bus.prop.hw_disabled) {
> > > @@ -1067,7 +1067,7 @@ static int intel_probe(struct platform_device *pdev)
> > >   goto err_init;
> > >   }
> > > - ret = sdw_cdns_enable_interrupt(&sdw->cdns);
> > > + ret = sdw_cdns_enable_interrupt(&sdw->cdns, true);
> > >   if (ret < 0) {
> > >   dev_err(sdw->cdns.dev, "cannot enable interrupts\n");
> > >   goto err_init;
> > > @@ -1076,7 +1076,7 @@ static int intel_probe(struct platform_device *pdev)
> > >   ret = sdw_cdns_exit_reset(&sdw->cdns);
> > >   if (ret < 0) {
> > >   dev_err(sdw->cdns.dev, "unable to exit bus reset 
> > > sequence\n");
> > > - goto err_init;
> > > + goto err_interrupt;
> > >   }
> > >   /* Register DAIs */
> > > @@ -1084,18 +1084,19 @@ static int intel_probe(struct platform_device 
> > > *pdev)
> > >   if (ret) {
> > >   dev_err(sdw->cdns.dev, "DAI reg

Re: [alsa-devel] [PATCH v2 2/5] soundwire: cadence_master: add hw_reset capability in debugfs

[Vinod Koul]

On 21-10-19, 05:20, Pierre-Louis Bossart wrote:
> On 10/20/19 11:04 PM, Vinod Koul wrote:
> > On 16-09-19, 14:09, Pierre-Louis Bossart wrote:
> > > Provide debugfs capability to kick link and devices into hard-reset
> > > (as defined by MIPI). This capability is really useful when some
> > > devices are no longer responsive and/or to check the software handling
> > > of resynchronization.
> > > 
> > > Signed-off-by: Pierre-Louis Bossart 
> > > ---
> > >   drivers/soundwire/cadence_master.c | 20 
> > >   1 file changed, 20 insertions(+)
> > > 
> > > diff --git a/drivers/soundwire/cadence_master.c 
> > > b/drivers/soundwire/cadence_master.c
> > > index e3d06330d125..5f900cf2acb9 100644
> > > --- a/drivers/soundwire/cadence_master.c
> > > +++ b/drivers/soundwire/cadence_master.c
> > > @@ -340,6 +340,23 @@ static int cdns_reg_show(struct seq_file *s, void 
> > > *data)
> > >   }
> > >   DEFINE_SHOW_ATTRIBUTE(cdns_reg);
> > > +static int cdns_hw_reset(void *data, u64 value)
> > > +{
> > > + struct sdw_cdns *cdns = data;
> > > + int ret;
> > > +
> > > + if (value != 1)
> > > + return -EINVAL;
> > > +
> > > + ret = sdw_cdns_exit_reset(cdns);
> > 
> > So we are performing reset of the device behind the kernel, so I think
> > it makes sense to mark the kernel as tainted.
> 
> This is a bit ironic. This reset is the only way to prove that the
> enumeration is done right and that all the subsystem fully recovers, and yet
> we'd mark the kernel as 'untrustworthy' and all bug reports would be
> ignored.

Nope you dont expect this would be done on a production system and for
you own testing you can choose not to ignore the reports!

> I don't mind doing this but we'd have to agree on a code. The only one I see
> relevant is "taint requested by userspace application", which is not exactly
> super useful.

But it does tell you that userspace did something so watch out!

> > > + dev_dbg(cdns->dev, "link hw_reset done: %d\n", ret);
> > > +
> > > + return ret;
> > 
> > We may want to get rid of the debug and do:
> >  return sdw_cdns_exit_reset();
> 
> this debug line is useful, it marks the start of the reset sequence and
> that's valuable information. Remove it and you've lost the ability to
> analyze the dmesg logs. It's even more useful if we mark the kernel as
> tainted as you suggested above.

ok

> 
> > 
> > > +}
> > > +
> > > +DEFINE_DEBUGFS_ATTRIBUTE(cdns_hw_reset_fops, NULL, cdns_hw_reset, 
> > > "%llu\n");
> > > +
> > >   /**
> > >* sdw_cdns_debugfs_init() - Cadence debugfs init
> > >* @cdns: Cadence instance
> > > @@ -348,6 +365,9 @@ DEFINE_SHOW_ATTRIBUTE(cdns_reg);
> > >   void sdw_cdns_debugfs_init(struct sdw_cdns *cdns, struct dentry *root)
> > >   {
> > >   debugfs_create_file("cdns-registers", 0400, root, cdns, 
> > > &cdns_reg_fops);
> > > +
> > > + debugfs_create_file("cdns-hw-reset", 0200, root, cdns,
> > > + &cdns_hw_reset_fops);
> > >   }
> > >   EXPORT_SYMBOL_GPL(sdw_cdns_debugfs_init);
> > > -- 
> > > 2.20.1
> > 

-- 
~Vinod

Re: [PATCH v3 6/6] perf cs-etm: Synchronize instruction sample with the thread stack

[Leo Yan]

Hi Mathieu,

On Fri, Oct 11, 2019 at 02:17:50PM -0600, Mathieu Poirier wrote:
> On Sat, Oct 05, 2019 at 05:16:14PM +0800, Leo Yan wrote:
> > The synthesized flow use 'tidq->packet' for instruction samples; on the
> > other hand, 'tidp->prev_packet' is used to generate the thread stack and
> > the branch samples, this results in the instruction samples using one
> > packet ahead than thread stack and branch samples ('tidp->prev_packet'
> > vs 'tidq->packet').
> > 
> > This leads to an instruction's callchain error as shows in below
> > example:
> > 
> >   main  1579100  instructions:
> > 10214854 perf_event_update_userpage+0x4c ([kernel.kallsyms])
> > 10214850 perf_event_update_userpage+0x48 ([kernel.kallsyms])
> > 10219360 perf_swevent_add+0x88 ([kernel.kallsyms])
> > 102135f4 event_sched_in.isra.57+0xbc ([kernel.kallsyms])
> > 102137a0 group_sched_in+0x60 ([kernel.kallsyms])
> > 10213b84 flexible_sched_in+0xfc ([kernel.kallsyms])
> > 1020c0b4 visit_groups_merge+0x12c ([kernel.kallsyms])
> > 
> > In the callchain log, for the two continuous lines the up line contains
> > one child function info and the followed line contains the caller
> > function info, and so forth.  So the first two lines are:
> > 
> >   perf_event_update_userpage+0x4c  => the sampled instruction
> >   perf_event_update_userpage+0x48  => the parent function's calling
> > 
> > The child function and parent function both are the same function
> > perf_event_update_userpage(), but this isn't a recursive function, thus
> > the sequence for perf_event_update_userpage() calling itself shouldn't
> > never happen.  This callchain error is caused by the instruction sample
> > using an ahead packet than the thread stack, the thread stack is deferred
> > to process the new packet and misses to pop stack if it is just a return
> > packet.
> > 
> > To fix this issue, we can simply change to use 'tidq->prev_packet' to
> > generate the instruction samples, this allows the thread stack to push
> > and pop synchronously with instruction sample.  Finally, the callchain
> > can be displayed correctly as below:
> > 
> >   main  1579100  instructions:
> > 10214854 perf_event_update_userpage+0x4c ([kernel.kallsyms])
> > 10219360 perf_swevent_add+0x88 ([kernel.kallsyms])
> > 102135f4 event_sched_in.isra.57+0xbc ([kernel.kallsyms])
> > 102137a0 group_sched_in+0x60 ([kernel.kallsyms])
> > 10213b84 flexible_sched_in+0xfc ([kernel.kallsyms])
> > 1020c0b4 visit_groups_merge+0x12c ([kernel.kallsyms])
> > 
> > Signed-off-by: Leo Yan 
> > ---
> >  tools/perf/util/cs-etm.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
> > index 56e501cd2f5f..fa969dcb45d2 100644
> > --- a/tools/perf/util/cs-etm.c
> > +++ b/tools/perf/util/cs-etm.c
> > @@ -1419,7 +1419,7 @@ static int cs_etm__sample(struct cs_etm_queue *etmq,
> > struct cs_etm_packet *tmp;
> > int ret;
> > u8 trace_chan_id = tidq->trace_chan_id;
> > -   u64 instrs_executed = tidq->packet->instr_count;
> > +   u64 instrs_executed = tidq->prev_packet->instr_count;
> >  
> > tidq->period_instructions += instrs_executed;
> >  
> > @@ -1450,7 +1450,7 @@ static int cs_etm__sample(struct cs_etm_queue *etmq,
> >  */
> > s64 offset = (instrs_executed - instrs_over - 1);
> > u64 addr = cs_etm__instr_addr(etmq, trace_chan_id,
> > - tidq->packet, offset);
> > + tidq->prev_packet, offset);
> 
> I have tested this set in --per-thread mode and things are working as
> advertised. Did you see how things look like in CPU-wide scenarios?

After some testing, I can confirm this patch set can works well for
CPU-wide trace; the reason is in the arch/arm/util/cs-etm.c, function
cs_etm_recording_options() has enabled option 'ETM_OPT_CTXTID' for
CPU-wide trace:

 /*
  * In the case of per-cpu mmaps, we need the CPU on the
  * AUX event.  We also need the contextID in order to be notified
  * when a context switch happened.
  */
 if (!perf_cpu_map__empty(cpus)) {
 perf_evsel__set_sample_bit(cs_etm_evsel, CPU);

 err = cs_etm_set_option(itr, cs_etm_evsel,
 ETM_OPT_CTXTID | ETM_OPT_TS);
 if (err)
 goto out;
 }

As result, we don't need to specify extra option to enable CTXID
configuration.  So below two commands have the same behaviour:

  # perf record -e cs_etm/@tmc_etr0/ -a -- sh test.sh
  # perf record -e cs_etm/@tmc_etr0,config=0x4000/ -a -- sh test.sh
   `-> bit 14: for ETM_OPT_CTXTID

Since the decoding will set tid when receive the packet
'OCSD_

[PATCH] dt-bindings: serial: lpuart: Drop unsupported RS485 bindings

[Andrey Smirnov]

LPUART driver does not support 'rs485-rts-delay' or
'rs485-rx-during-tx' properties. Remove them.

Signed-off-by: Andrey Smirnov 
Cc: Stefan Agner 
Cc: Chris Healy 
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Cc: linux-...@nxp.com
Cc: linux-ser...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 Documentation/devicetree/bindings/serial/fsl-lpuart.txt | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/serial/fsl-lpuart.txt 
b/Documentation/devicetree/bindings/serial/fsl-lpuart.txt
index 3495eee81d53..f5f5ab0fd14e 100644
--- a/Documentation/devicetree/bindings/serial/fsl-lpuart.txt
+++ b/Documentation/devicetree/bindings/serial/fsl-lpuart.txt
@@ -21,8 +21,7 @@ Required properties:
 Optional properties:
 - dmas: A list of two dma specifiers, one for each entry in dma-names.
 - dma-names: should contain "tx" and "rx".
-- rs485-rts-delay, rs485-rts-active-low, rs485-rx-during-tx,
-  linux,rs485-enabled-at-boot-time: see rs485.txt
+- rs485-rts-active-low, linux,rs485-enabled-at-boot-time: see rs485.txt
 
 Note: Optional properties for DMA support. Write them both or both not.
 
-- 
2.21.0

[PATCH] cpufreq: imx-cpufreq-dt: Correct i.MX8MN's default speed grade value

[Anson Huang]

i.MX8MN has different speed grade definition compared to
i.MX8MQ/i.MX8MM, when fuses are NOT written, the default
speed_grade should be set to minimum available OPP defined
in DT which is 1.2GHz, the corresponding speed_grade value
should be 0xb.

Fixes: 5b8010ba70d5 ("cpufreq: imx-cpufreq-dt: Add i.MX8MN support")
Signed-off-by: Anson Huang 
---
 drivers/cpufreq/imx-cpufreq-dt.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/cpufreq/imx-cpufreq-dt.c b/drivers/cpufreq/imx-cpufreq-dt.c
index 35db14c..26531f0 100644
--- a/drivers/cpufreq/imx-cpufreq-dt.c
+++ b/drivers/cpufreq/imx-cpufreq-dt.c
@@ -44,19 +44,19 @@ static int imx_cpufreq_dt_probe(struct platform_device 
*pdev)
mkt_segment = (cell_value & OCOTP_CFG3_MKT_SEGMENT_MASK) >> 
OCOTP_CFG3_MKT_SEGMENT_SHIFT;
 
/*
-* Early samples without fuses written report "0 0" which means
-* consumer segment and minimum speed grading.
-*
-* According to datasheet minimum speed grading is not supported for
-* consumer parts so clamp to 1 to avoid warning for "no OPPs"
+* Early samples without fuses written report "0 0" which may NOT
+* match any OPP defined in DT. So clamp to minimum OPP defined in
+* DT to avoid warning for "no OPPs".
 *
 * Applies to i.MX8M series SoCs.
 */
-   if (mkt_segment == 0 && speed_grade == 0 && (
-   of_machine_is_compatible("fsl,imx8mm") ||
-   of_machine_is_compatible("fsl,imx8mn") ||
-   of_machine_is_compatible("fsl,imx8mq")))
-   speed_grade = 1;
+   if (mkt_segment == 0 && speed_grade == 0) {
+   if (of_machine_is_compatible("fsl,imx8mm") ||
+   of_machine_is_compatible("fsl,imx8mq"))
+   speed_grade = 1;
+   if (of_machine_is_compatible("fsl,imx8mn"))
+   speed_grade = 0xb;
+   }
 
supported_hw[0] = BIT(speed_grade);
supported_hw[1] = BIT(mkt_segment);
-- 
2.7.4

Re: [PATCH v2] scripts/nsdeps: use alternative sed delimiter

[Masahiro Yamada]

On Tue, Oct 22, 2019 at 1:05 AM Jessica Yu  wrote:
>
> When doing an out of tree build with O=, the nsdeps script constructs
> the absolute pathname of the module source file so that it can insert
> MODULE_IMPORT_NS statements in the right place. However, ${srctree}
> contains an unescaped path to the source tree, which, when used in a sed
> substitution, makes sed complain:
>
> ++ sed 's/[^ ]* *//home/jeyu/jeyu-linux\/&/g'
> sed: -e expression #1, char 12: unknown option to `s'
>
> The sed substitution command 's' ends prematurely with the forward
> slashes in the pathname, and sed errors out when it encounters the 'h',
> which is an invalid sed substitution option. To avoid escaping forward
> slashes in ${srctree}, we can use '|' as an alternative delimiter for
> sed to avoid this error.
>
> Signed-off-by: Jessica Yu 
> ---
>
> This is an alternative to my first patch here:
>
>   http://lore.kernel.org/r/20191021145137.31672-1-j...@kernel.org
>
> Matthias suggested using an alternative sed delimiter instead to avoid the
> ugly/unreadable ${srctree//\//\\\/} substitution.
>
>  scripts/nsdeps | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/nsdeps b/scripts/nsdeps
> index 3754dac13b31..63da30a33422 100644
> --- a/scripts/nsdeps
> +++ b/scripts/nsdeps
> @@ -33,7 +33,7 @@ generate_deps() {
> if [ ! -f "$ns_deps_file" ]; then return; fi
> local mod_source_files=`cat $mod_file | sed -n 1p 
>  \
>   | sed -e 's/\.o/\.c/g'  
>  \
> - | sed "s/[^ ]* 
> */${srctree}\/&/g"`
> + | sed "s|[^ ]* 
> *|${srctree}\/&|g"`


You no longer need to escape the '/'.

s|[^ ]* *|${srctree}/&|g

is enough.


BTW, connecting multiple sed commands with pipes
is not efficient.


sed -n 1p | sed -e 's/\.o/\.c/g'

can be replaced with

sed -n '1s/\.o/\.c/gp'



This script can be improved a whole
if somebody is interested in the refactoring.




> for ns in `cat $ns_deps_file`; do
> echo "Adding namespace $ns to module $mod_name (if needed)."
> generate_deps_for_ns $ns $mod_source_files
> --
> 2.16.4
>


-- 
Best Regards
Masahiro Yamada

Re: [PATCH v6 11/43] compat_ioctl: move drivers to compat_ptr_ioctl

[Al Viro]

On Wed, Oct 09, 2019 at 09:10:11PM +0200, Arnd Bergmann wrote:
> Each of these drivers has a copy of the same trivial helper function to
> convert the pointer argument and then call the native ioctl handler.
> 
> We now have a generic implementation of that, so use it.

I'd rather flipped your #7 (ceph_compat_ioctl() introduction) past
that one...

Re: [Y2038] [PATCH v6 10/43] compat_ioctl: move rtc handling into rtc-dev.c

[Al Viro]

On Thu, Oct 17, 2019 at 04:33:09PM +0200, Arnd Bergmann wrote:

> However, looking at this again after your comment I found a rather
> more serious bug in my new RTC_IRQP_SET handling: Any 64-bit
> machine can now bypass the permission check for RTC_IRQP_SET by
> calling RTC_IRQP_SET32 instead.

You've lost the check on RTC_EPOCH_SET as well.

Another potential issue is drivers/input/misc/hp_sdc_rtc.c,
provided that the hardware in question might possibly exist
on hppa64 boxen - CONFIG_GSC defaults to y and it's not
32bit-only, so that thing is at least selectable on 64bit
kernels.

[v5,1/3] dt-bindings: i2c: support property idle-state

[Biwen Li]

This supports property idle-state

Signed-off-by: Biwen Li 
---
Change in v5:
- none

Change in v4:
- none

Change in v3:
- update subject and description
- add some information for property idle-state

Change in v2:
- update subject and description
- add property idle-state

 Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt 
b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt
index 30ac6a60f041..7abda506b828 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt
@@ -25,6 +25,8 @@ Required Properties:
 Optional Properties:
 
   - reset-gpios: Reference to the GPIO connected to the reset input.
+  - idle-state: if present, overrides i2c-mux-idle-disconnect,
+Please refer to Documentation/devicetree/bindings/mux/mux-controller.txt
   - i2c-mux-idle-disconnect: Boolean; if defined, forces mux to disconnect all
 children in idle state. This is necessary for example, if there are several
 multiplexers on the bus and the devices behind them use same I2C addresses.
-- 
2.17.1

[v5,2/3] i2c: mux: pca954x: support property idle-state

[Biwen Li]

This supports property idle-state,if present,
overrides i2c-mux-idle-disconnect.

My use cases:
- Use the property idle-state to fix
  an errata on LS2085ARDB and LS2088ARDB.
- Errata id: E-00013(board LS2085ARDB and
  LS2088ARDB revision on Rev.B, Rev.C and Rev.D).
- About E-00013:
  - Description: I2C1 and I2C3 buses
are missing pull-up.
  - Impact: When the PCA954x device is tri-stated, the I2C bus
will float. This makes the I2C bus and its associated
downstream devices inaccessible.
  - Hardware fix: Populate resistors R189 and R190 for I2C1
and resistors R228 and R229 for I2C3.
  - Software fix: Remove the tri-state option from the PCA954x
driver(PCA954x always on enable status, specify a
channel zero in dts to fix the errata E-00013).

Signed-off-by: Biwen Li 
---
Change in v5:
- add extra precaution for pca954x_init 

Change in v4:
- rename function
  pca954x_calculate_chan -> pca954x_regval

Change in v3:
- update subject and description
- add a helper function pca954x_calculate_chan()

Change in v2:
- update subject and description
- add property idle-state

 drivers/i2c/muxes/i2c-mux-pca954x.c | 67 +++--
 1 file changed, 44 insertions(+), 23 deletions(-)

diff --git a/drivers/i2c/muxes/i2c-mux-pca954x.c 
b/drivers/i2c/muxes/i2c-mux-pca954x.c
index 923aa3a5a3dc..218ba1a5ed7e 100644
--- a/drivers/i2c/muxes/i2c-mux-pca954x.c
+++ b/drivers/i2c/muxes/i2c-mux-pca954x.c
@@ -86,7 +86,7 @@ struct pca954x {
 
u8 last_chan;   /* last register value */
/* MUX_IDLE_AS_IS, MUX_IDLE_DISCONNECT or >= 0 for channel */
-   s8 idle_state;
+   s32 idle_state;
 
struct i2c_client *client;
 
@@ -229,20 +229,23 @@ static int pca954x_reg_write(struct i2c_adapter *adap,
I2C_SMBUS_BYTE, &dummy);
 }
 
+static u8 pca954x_regval(struct pca954x *data, u8 chan)
+{
+   /* We make switches look like muxes, not sure how to be smarter. */
+   if (data->chip->muxtype == pca954x_ismux)
+   return chan | data->chip->enable;
+   else
+   return 1 << chan;
+}
+
 static int pca954x_select_chan(struct i2c_mux_core *muxc, u32 chan)
 {
struct pca954x *data = i2c_mux_priv(muxc);
struct i2c_client *client = data->client;
-   const struct chip_desc *chip = data->chip;
u8 regval;
int ret = 0;
 
-   /* we make switches look like muxes, not sure how to be smarter */
-   if (chip->muxtype == pca954x_ismux)
-   regval = chan | chip->enable;
-   else
-   regval = 1 << chan;
-
+   regval = pca954x_regval(data, chan);
/* Only select the channel if its different from the last channel */
if (data->last_chan != regval) {
ret = pca954x_reg_write(muxc->parent, client, regval);
@@ -256,7 +259,7 @@ static int pca954x_deselect_mux(struct i2c_mux_core *muxc, 
u32 chan)
 {
struct pca954x *data = i2c_mux_priv(muxc);
struct i2c_client *client = data->client;
-   s8 idle_state;
+   s32 idle_state;
 
idle_state = READ_ONCE(data->idle_state);
if (idle_state >= 0)
@@ -402,6 +405,25 @@ static void pca954x_cleanup(struct i2c_mux_core *muxc)
i2c_mux_del_adapters(muxc);
 }
 
+static int pca954x_init(struct i2c_client *client, struct pca954x *data)
+{
+   int ret;
+   if (data->idle_state >= 0) {
+   data->last_chan = pca954x_regval(data, data->idle_state);
+   } else {
+   /* Disconnect multiplexer */
+   data->last_chan = 0;
+   }
+   ret = i2c_smbus_write_byte(client, data->last_chan);
+   if (ret < 0) {
+   data->last_chan = 0;
+   dev_err(&client->dev, "failed to verify the mux, \
+   the mux maybe not present in fact\n");
+   }
+
+   return ret;
+}
+
 /*
  * I2C init/probing/exit functions
  */
@@ -411,7 +433,6 @@ static int pca954x_probe(struct i2c_client *client,
struct i2c_adapter *adap = client->adapter;
struct device *dev = &client->dev;
struct device_node *np = dev->of_node;
-   bool idle_disconnect_dt;
struct gpio_desc *gpio;
struct i2c_mux_core *muxc;
struct pca954x *data;
@@ -462,23 +483,24 @@ static int pca954x_probe(struct i2c_client *client,
}
}
 
-   /* Write the mux register at addr to verify
+   data->idle_state = MUX_IDLE_AS_IS;
+   if (of_property_read_u32(np, "idle-state", &data->idle_state)) {
+   if (np && of_property_read_bool(np, "i2c-mux-idle-disconnect"))
+   data->idle_state = MUX_IDLE_DISCONNECT;
+   }
+
+   /*
+* Write the mux register at addr to verify
 * that the mux is in fact present. This also
- 

[v5,3/3] arm64: dts: fsl-ls208xa-rdb: fix an errata E-00013

[Biwen Li]

Specify a channel zero in idle state to
avoid enterring tri-stated state for PCA9547.
About E-00013:
- Description: I2C1 and I2C3 buses
  are missing pull-up.
- Impact: When the PCA954x device is tri-stated, the I2C bus
  will float. This makes the I2C bus and its associated
  downstream devices inaccessible.
- Hardware fix: Populate resistors R189 and R190 for I2C1
  and resistors R228 and R229 for I2C3.
- Software fix: Remove the tri-state option from the PCA954x
  driver(PCA954x always on enable status, specify a
  channel zero in dts to fix the errata E-00013).

Signed-off-by: Biwen Li 
---
Change in v5:
- specify a channel zero when pca9547 in idle state.

 arch/arm64/boot/dts/freescale/fsl-ls208xa-rdb.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa-rdb.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls208xa-rdb.dtsi
index 6fd7f63085c9..412f1bc0db5f 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa-rdb.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa-rdb.dtsi
@@ -49,6 +49,7 @@
reg = <0x75>;
#address-cells = <1>;
#size-cells = <0>;
+   idle-state = <0>;
i2c@1 {
#address-cells = <1>;
#size-cells = <0>;
-- 
2.17.1

[PATCH v2] ARM: imx: Drop imx_anatop_usb_chrg_detect_disable()

[Andrey Smirnov]

With commit b5bbe2235361 ("usb: phy: mxs: Disable external charger
detect in mxs_phy_hw_init()") in tree all of the necessary charger
setup is done by the USB PHY driver which covers all of the affected
i.MX6 SoCs.

NOTE: imx_anatop_usb_chrg_detect_disable() was also called for i.MX7D,
but looking at its datasheet it appears to have a different USB PHY IP
block, so executing i.MX6 charger disable configuration seems
unnecessary.

Signed-off-by: Andrey Smirnov 
Cc: Chris Healy 
Cc: Shawn Guo 
Cc: Fabio Estevam 
Cc: Peter Chen 
Cc: linux-...@nxp.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---

Changes since [v1]:

- Scope of the patch reduced to remove only
  imx_anatop_usb_chrg_detect_disable() instead of
  imx_anatop_init()

[v1] lore.kernel.org/lkml/20190731180131.8597-1-andrew.smir...@gmail.com

 arch/arm/mach-imx/anatop.c | 20 +---
 1 file changed, 1 insertion(+), 19 deletions(-)

diff --git a/arch/arm/mach-imx/anatop.c b/arch/arm/mach-imx/anatop.c
index 777d8c255501..8fb68c0ec34c 100644
--- a/arch/arm/mach-imx/anatop.c
+++ b/arch/arm/mach-imx/anatop.c
@@ -19,8 +19,6 @@
 #define ANADIG_REG_2P5 0x130
 #define ANADIG_REG_CORE0x140
 #define ANADIG_ANA_MISC0   0x150
-#define ANADIG_USB1_CHRG_DETECT0x1b0
-#define ANADIG_USB2_CHRG_DETECT0x210
 #define ANADIG_DIGPROG 0x260
 #define ANADIG_DIGPROG_IMX6SL  0x280
 #define ANADIG_DIGPROG_IMX7D   0x800
@@ -33,8 +31,6 @@
 #define BM_ANADIG_ANA_MISC0_STOP_MODE_CONFIG   0x1000
 /* Below MISC0_DISCON_HIGH_SNVS is only for i.MX6SL */
 #define BM_ANADIG_ANA_MISC0_DISCON_HIGH_SNVS   0x2000
-#define BM_ANADIG_USB_CHRG_DETECT_CHK_CHRG_B   0x8
-#define BM_ANADIG_USB_CHRG_DETECT_EN_B 0x10
 
 static struct regmap *anatop;
 
@@ -96,16 +92,6 @@ void imx_anatop_post_resume(void)
 
 }
 
-static void imx_anatop_usb_chrg_detect_disable(void)
-{
-   regmap_write(anatop, ANADIG_USB1_CHRG_DETECT,
-   BM_ANADIG_USB_CHRG_DETECT_EN_B
-   | BM_ANADIG_USB_CHRG_DETECT_CHK_CHRG_B);
-   regmap_write(anatop, ANADIG_USB2_CHRG_DETECT,
-   BM_ANADIG_USB_CHRG_DETECT_EN_B |
-   BM_ANADIG_USB_CHRG_DETECT_CHK_CHRG_B);
-}
-
 void __init imx_init_revision_from_anatop(void)
 {
struct device_node *np;
@@ -171,10 +157,6 @@ void __init imx_init_revision_from_anatop(void)
 void __init imx_anatop_init(void)
 {
anatop = syscon_regmap_lookup_by_compatible("fsl,imx6q-anatop");
-   if (IS_ERR(anatop)) {
+   if (IS_ERR(anatop))
pr_err("%s: failed to find imx6q-anatop regmap!\n", __func__);
-   return;
-   }
-
-   imx_anatop_usb_chrg_detect_disable();
 }
-- 
2.21.0

Re: [PATCH 3/3] x86/ftrace: Use text_poke()

[Alexei Starovoitov]

On Mon, Oct 21, 2019 at 11:19:04PM -0400, Steven Rostedt wrote:
> On Mon, 21 Oct 2019 23:16:30 -0400
> Steven Rostedt  wrote:
> 
> > > what bugs you're seeing?
> > > The IPI frequency that was mentioned in this thread or something else?
> > > I'm hacking ftrace+bpf stuff in the same spot and would like to
> > > base my work on the latest and greatest.  
> 
> I'm also going to be touching some of this code too, as I'm waiting for
> Peter's code to settle down. What are you touching? I'm going to be
> working on making the dyn_ftrace records smaller, and this is going to
> change the way the iterations work on modifying the code.

I'm not touching dyn_ftrace.
Actually calling my stuff ftrace+bpf is probably not correct either.
I'm reusing code patching of nop into call that ftrace does. That's it.
Turned out I cannot use 99% of ftrace facilities.
ftrace_caller, ftrace_call, ftrace_ops_list_func and the whole ftrace api
with ip, parent_ip and pt_regs cannot be used for this part of the work.
bpf prog needs to access raw function arguments. To achieve that I'm
generating code on the fly. Just like bpf jits do.
As soon as I have something reviewable I'll share it.
That's the stuff I mentioned to you at KR.
First nop of a function will be replaced with a call into bpf.
Very similar to what existing kprobe+bpf does, but faster and safer.
Second part of calling real ftrace from bpf is on todo list.

[PATCH 3/3] ARM: dts: imx6qdl-zii-rdu2: Specify supplies for accelerometer

[Andrey Smirnov]

Specify 'vdd' and 'vddio' supplies for accelerometer to avoid warnings
during boot.

Signed-off-by: Andrey Smirnov 
Cc: Fabio Estevam 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: Shawn Guo 
Cc: linux-arm-ker...@lists.infradead.org,
Cc: linux-kernel@vger.kernel.org
---
 arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi 
b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
index a8c86e621b49..42c0a728216d 100644
--- a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
@@ -360,6 +360,8 @@
interrupt-parent = <&gpio1>;
interrupt-names = "INT2";
interrupts = <20 IRQ_TYPE_LEVEL_LOW>;
+   vdd-supply = <®_3p3v>;
+   vddio-supply = <®_3p3v>;
};
 
hpa2: amp@60 {
-- 
2.21.0

[PATCH 2/3] ARM: dts: imx6qdl-zii-rdu2: Fix accelerometer interrupt-names

[Andrey Smirnov]

According to Documentation/devicetree/bindings/iio/accel/mma8452.txt,
the correct interrupt-names are "INT1" and "INT2", so fix them
accordingly.

While at it, modify the node to only specify "INT2" since providing
two interrupts is not necessary or useful (the driver will only use
one).

Signed-off-by: Fabio Estevam 
[andrew.smir...@gmail.com modified the patch to drop INT1]
Signed-off-by: Andrey Smirnov 
Cc: Fabio Estevam 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: Shawn Guo 
Cc: linux-arm-ker...@lists.infradead.org,
Cc: linux-kernel@vger.kernel.org
---

Original patch from Fabio can be seen here:

https://lore.kernel.org/linux-arm-kernel/20191010125300.2822-1-feste...@gmail.com/

 arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi 
b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
index 8d46f7b2722b..a8c86e621b49 100644
--- a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
@@ -358,8 +358,8 @@
compatible = "fsl,mma8451";
reg = <0x1c>;
interrupt-parent = <&gpio1>;
-   interrupt-names = "int1", "int2";
-   interrupts = <18 IRQ_TYPE_LEVEL_LOW>, <20 IRQ_TYPE_LEVEL_LOW>;
+   interrupt-names = "INT2";
+   interrupts = <20 IRQ_TYPE_LEVEL_LOW>;
};
 
hpa2: amp@60 {
@@ -849,7 +849,6 @@
 &iomuxc {
pinctrl_accel: accelgrp {
fsl,pins = <
-   MX6QDL_PAD_SD1_CMD__GPIO1_IO18  0x4001b000
MX6QDL_PAD_SD1_CLK__GPIO1_IO20  0x4001b000
>;
};
-- 
2.21.0

[PATCH 1/3] ARM: dts: imx6qdl-zii-rdu2: Drop GPIO_ACTIVE_LOW form reg_5p0v_user_usb

[Andrey Smirnov]

Drop GPIO_ACTIVE_LOW form reg_5p0v_user_usb since it is ignored by the
gpiolib and results in a warning.

Signed-off-by: Andrey Smirnov 
Cc: Fabio Estevam 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: Shawn Guo 
Cc: linux-arm-ker...@lists.infradead.org,
Cc: linux-kernel@vger.kernel.org
---
 arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi 
b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
index 93be00a60c88..8d46f7b2722b 100644
--- a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
@@ -68,7 +68,7 @@
regulator-name = "5V_USER_USB";
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
-   gpio = <&gpio3 22 GPIO_ACTIVE_LOW>;
+   gpio = <&gpio3 22 0>;
startup-delay-us = <1000>;
};
 
-- 
2.21.0

[PATCH v4 3/3] iio: documentation: light: Add veml6030 sysfs documentation

[Rishi Gupta]

The driver for veml6030 light sensor provides custom sysfs entries
used to know parameters supported by the driver and to configure
sensor like setting power saving mode and persistence etc. This
commit document them.

Signed-off-by: Rishi Gupta 
---
Changes in v4:
* None

Changes in v3:
* Updated Date from September to October
* Updated KernelVersion from 5.3.1 to 5.4
* in_illuminance_period_available is now in events directory

Changes in v2:
* None

 .../ABI/testing/sysfs-bus-iio-light-veml6030   | 49 ++
 1 file changed, 49 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-light-veml6030

diff --git a/Documentation/ABI/testing/sysfs-bus-iio-light-veml6030 
b/Documentation/ABI/testing/sysfs-bus-iio-light-veml6030
new file mode 100644
index 000..13cd321
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-iio-light-veml6030
@@ -0,0 +1,49 @@
+What:  /sys/bus/iio/devices/iio:deviceX/in_illuminance_psm_available
+Date:  October 2019
+KernelVersion: 5.4
+Contact:   Rishi Gupta 
+Description:
+   Provides list of valid values that can be used to activate a
+   particular power saving mode in sensor. For ex; 1 means psm
+   mode 1 and 2 means psm mode 2 and so on.
+
+What:  /sys/bus/iio/devices/iio:deviceX/in_illuminance_psm
+Date:  October 2019
+KernelVersion: 5.4
+Contact:   Rishi Gupta 
+Description:
+   Writing '1' will activate power saving mode 1 in sensor.
+   Similarly, 2 is to activate psm mode 2 and so on.
+
+What:  
/sys/bus/iio/devices/iio:deviceX/events/in_illuminance_period_available
+Date:  October 2019
+KernelVersion: 5.4
+Contact:   Rishi Gupta 
+Description:
+   List of valid values available in multiples of integration time
+   for which the light intensity must be above the cutoff level
+   before interrupt is asserted. This refers to persistence values.
+
+What:  
/sys/bus/iio/devices/iio:deviceX/events/in_illuminance_thresh_either_period
+Date:  October 2019
+KernelVersion: 5.4
+Contact:   Rishi Gupta 
+Description:
+   Value in multiple of integration time for which the light 
intensity must
+   be above the cutoff level before interrupt is asserted.
+
+What:  
/sys/bus/iio/devices/iio:deviceX/events/in_illuminance_thresh_rising_value
+Date:  October 2019
+KernelVersion: 5.4
+Contact:   Rishi Gupta 
+Description:
+   Raw threshold value from 0 to 0x. An interrupt will be 
asserted whenever
+   light intensity is above this value.
+
+What:  
/sys/bus/iio/devices/iio:deviceX/events/in_illuminance_thresh_falling_value
+Date:  October 2019
+KernelVersion: 5.4
+Contact:   Rishi Gupta 
+Description:
+   Raw threshold value from 0 to 0x. An interrupt will be 
asserted whenever
+   light intensity is below this value.
-- 
2.7.4

[PATCH v4 2/3] dt-bindings: iio: light: add veml6030 ALS bindings

[Rishi Gupta]

This commit adds device tree bindings for veml6030 ambient
light sensor.

Signed-off-by: Rishi Gupta 
---
Changes in v4:
* Added enum in reg property
* Removed maxItems from reg property

Changes in v3:
* None

Changes in v2:
* Corrected grammatical mistake from 'is' to 'are' in description of bindings

 .../devicetree/bindings/iio/light/veml6030.yaml| 62 ++
 1 file changed, 62 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/light/veml6030.yaml

diff --git a/Documentation/devicetree/bindings/iio/light/veml6030.yaml 
b/Documentation/devicetree/bindings/iio/light/veml6030.yaml
new file mode 100644
index 000..0ff9b11
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/veml6030.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: GPL-2.0+
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/light/veml6030.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: VEML6030 Ambient Light Sensor (ALS)
+
+maintainers:
+  - Rishi Gupta 
+
+description: |
+  Bindings for the ambient light sensor veml6030 from Vishay
+  Semiconductors over an i2c interface.
+
+  Irrespective of whether interrupt is used or not, application
+  can get the ALS and White channel reading from IIO raw interface.
+
+  If the interrupts are used, application will receive an IIO event
+  whenever configured threshold is crossed.
+
+  Specifications about the sensor can be found at:
+https://www.vishay.com/docs/84366/veml6030.pdf
+
+properties:
+  compatible:
+enum:
+  - vishay,veml6030
+
+  reg:
+description:
+  I2C address of the device.
+enum:
+  - 0x10 # ADDR pin pulled down
+  - 0x48 # ADDR pin pulled up
+
+  interrupts:
+description:
+  interrupt mapping for IRQ. Configure with IRQ_TYPE_LEVEL_LOW.
+  Refer to interrupt-controller/interrupts.txt for generic
+  interrupt client node bindings.
+maxItems: 1
+
+required:
+  - compatible
+  - reg
+
+examples:
+  - |
+#include 
+
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+light-sensor@10 {
+compatible = "vishay,veml6030";
+reg = <0x10>;
+interrupts = <12 IRQ_TYPE_LEVEL_LOW>;
+};
+};
+...
-- 
2.7.4

[PATCH] dt-bindings: mma8452: Re-word 'interrupt-names' description

[Andrey Smirnov]

Current wording in the binding documentation doesn't make it 100%
clear that only one of "INT1" and "INT2" will ever be used by the
driver and that specifying both has no advantages. Re-word it to make
this aspect a bit more explicit.

Signed-off-by: Andrey Smirnov 
Cc: Chris Healy 
Cc: Jonathan Cameron 
Cc: Hartmut Knaack 
Cc: Lars-Peter Clausen 
Cc: Peter Meerwald-Stadler 
Cc: linux-...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 Documentation/devicetree/bindings/iio/accel/mma8452.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/iio/accel/mma8452.txt 
b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
index e132394375a1..b27b6bee9eb6 100644
--- a/Documentation/devicetree/bindings/iio/accel/mma8452.txt
+++ b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
@@ -17,7 +17,7 @@ Optional properties:
 
   - interrupts: interrupt mapping for GPIO IRQ
 
-  - interrupt-names: should contain "INT1" and/or "INT2", the accelerometer's
+  - interrupt-names: should contain "INT1" or "INT2", the accelerometer's
 interrupt line in use.
 
   - vdd-supply: phandle to the regulator that provides vdd power to the 
accelerometer.
-- 
2.21.0

[PATCH v4 1/3] iio: light: add driver for veml6030 ambient light sensor

[Rishi Gupta]

veml6030 is an ambient light sensor from Vishay semiconductors.
It has 16-bit resolution, supports both ambient light measurement
and white channel which is more responsive to wider wavelength
spectrum. It has flexible power saving, integration time and
gain options. Communication with host is over I2C.

Signed-off-by: Rishi Gupta 
---
Changes in v4:
* None

Changes in v3:
* Added appnote link in topmost comments section
* Dropped 'return ret' statements wherever not needed
* Removed .scan_index from channel specifications, not needed
* If irq is not enabled, events interfaces are not exposed now
* Return IRQ_NONE for spurious interrupt
* Removed CONFIG_PM, added __maybe_unused in power routines
* Removed of_match_ptr when specifying DT device id to match
* Corrected & documented sequence in veml6030_write_interrupt_config()
* Removed veml6030_remove() & added devm_add_action_or_reset functionality
* Added support to read integration time, gain, thresholds, period
* Removed including mutex.h not needed
* Set 100 ms integration & 1/8 gain during probe for better accuracy
* Used IIO_CONST_ATTR to create sysfs entries "_available"
* Minor cosmetics like everything in lower case

Changes in v2:
* Added comma after CH_WHITE in enum veml6030_chan so it can be extended
* Removed .scan_type as driver doesn't use buffered mode
* Removed iio_device_unregister() as kernel will take care of cleaning

 drivers/iio/light/Kconfig|  11 +
 drivers/iio/light/Makefile   |   1 +
 drivers/iio/light/veml6030.c | 903 +++
 3 files changed, 915 insertions(+)
 create mode 100644 drivers/iio/light/veml6030.c

diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
index 4a1a883..f9d27ef 100644
--- a/drivers/iio/light/Kconfig
+++ b/drivers/iio/light/Kconfig
@@ -496,6 +496,17 @@ config VCNL4035
  To compile this driver as a module, choose M here: the
  module will be called vcnl4035.

+config VEML6030
+   tristate "VEML6030 ambient light sensor"
+   select REGMAP_I2C
+   depends on I2C
+   help
+ Say Y here if you want to build a driver for the Vishay VEML6030
+ ambient light sensor (ALS).
+
+ To compile this driver as a module, choose M here: the
+ module will be called veml6030.
+
 config VEML6070
tristate "VEML6070 UV A light sensor"
depends on I2C
diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile
index 00d1f9b..5e0c40b 100644
--- a/drivers/iio/light/Makefile
+++ b/drivers/iio/light/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_TSL4531) += tsl4531.o
 obj-$(CONFIG_US5182D)  += us5182d.o
 obj-$(CONFIG_VCNL4000) += vcnl4000.o
 obj-$(CONFIG_VCNL4035) += vcnl4035.o
+obj-$(CONFIG_VEML6030) += veml6030.o
 obj-$(CONFIG_VEML6070) += veml6070.o
 obj-$(CONFIG_VL6180)   += vl6180.o
 obj-$(CONFIG_ZOPT2201) += zopt2201.o
diff --git a/drivers/iio/light/veml6030.c b/drivers/iio/light/veml6030.c
new file mode 100644
index 000..d0d4e42
--- /dev/null
+++ b/drivers/iio/light/veml6030.c
@@ -0,0 +1,903 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * VEML6030 Ambient Light Sensor
+ *
+ * Copyright (c) 2019, Rishi Gupta 
+ *
+ * Datasheet: https://www.vishay.com/docs/84366/veml6030.pdf
+ * Appnote-84367: https://www.vishay.com/docs/84367/designingveml6030.pdf
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Device registers */
+#define VEML6030_REG_ALS_CONF   0x00
+#define VEML6030_REG_ALS_WH 0x01
+#define VEML6030_REG_ALS_WL 0x02
+#define VEML6030_REG_ALS_PSM0x03
+#define VEML6030_REG_ALS_DATA   0x04
+#define VEML6030_REG_WH_DATA0x05
+#define VEML6030_REG_ALS_INT0x06
+
+/* Bit masks for specific functionality */
+#define VEML6030_ALS_IT   GENMASK(9, 6)
+#define VEML6030_PSM  GENMASK(2, 1)
+#define VEML6030_ALS_PERS GENMASK(5, 4)
+#define VEML6030_ALS_GAIN GENMASK(12, 11)
+#define VEML6030_PSM_EN   BIT(0)
+#define VEML6030_INT_TH_LOW   BIT(15)
+#define VEML6030_INT_TH_HIGH  BIT(14)
+#define VEML6030_ALS_INT_EN   BIT(1)
+#define VEML6030_ALS_SD   BIT(0)
+
+/*
+ * The resolution depends on both gain and integration time. The
+ * cur_resolution stores one of the resolution mentioned in the
+ * table during startup and gets updated whenever integration time
+ * or gain is changed.
+ *
+ * Table 'resolution and maximum detection range' in appnote 84367
+ * is visualized as a 2D array. The cur_gain stores index of gain
+ * in this table (0-3) while the cur_integration_time holds index
+ * of integration time (0-5).
+ */
+struct veml6030_data {
+   struct i2c_client *client;
+   struct regmap *regmap;
+   int cur_resolution;
+   int cur_gain;
+   int cur_integration_time;
+};
+
+/* Integration time available in seconds */
+static IIO_CONST_ATTR(in_illuminance_integration_time_available,
+   "0

Re: [PATCH v8 5/5] media: imx: Try colorimetry at both sink and source pads

[Steve Longerbeam]

On 10/21/19 8:26 PM, Steve Longerbeam wrote:

Hi Laurent,

On 10/21/19 6:44 PM, Laurent Pinchart wrote:

Hi Steve,

On Tue, May 21, 2019 at 06:03:17PM -0700, Steve Longerbeam wrote:
Retask imx_media_fill_default_mbus_fields() to try colorimetry 
parameters,
renaming it to to imx_media_try_colorimetry(), and call it at both 
sink and
source pad try_fmt's. The unrelated check for uninitialized field 
value is

moved out to appropriate places in each subdev try_fmt.

The IC now supports Rec.709 and BT.601 Y'CbCr encoding, and both 
limited

and full range quantization for both YUV and RGB space, so allow those
for pipelines that route through the IC.

Signed-off-by: Steve Longerbeam 
---
Changes in v7:
- squashed with "media: imx: Allow Rec.709 encoding for IC routes".
- remove the RGB full-range quantization restriction for IC routes.
---
  drivers/staging/media/imx/imx-ic-prp.c  |  6 +-
  drivers/staging/media/imx/imx-ic-prpencvf.c |  8 +--
  drivers/staging/media/imx/imx-media-csi.c   | 19 +++---
  drivers/staging/media/imx/imx-media-utils.c | 73 
++---

  drivers/staging/media/imx/imx-media-vdic.c  |  5 +-
  drivers/staging/media/imx/imx-media.h   |  5 +-
  drivers/staging/media/imx/imx7-media-csi.c  |  8 +--
  7 files changed, 62 insertions(+), 62 deletions(-)

diff --git a/drivers/staging/media/imx/imx-ic-prp.c 
b/drivers/staging/media/imx/imx-ic-prp.c

index 10ffe00f1a54..f87fe0203720 100644
--- a/drivers/staging/media/imx/imx-ic-prp.c
+++ b/drivers/staging/media/imx/imx-ic-prp.c
@@ -193,8 +193,8 @@ static int prp_set_fmt(struct v4l2_subdev *sd,
  sdformat->format.code = cc->codes[0];
  }
  - imx_media_fill_default_mbus_fields(&sdformat->format, infmt,
-   true);
+    if (sdformat->format.field == V4L2_FIELD_ANY)
+    sdformat->format.field = V4L2_FIELD_NONE;
  break;
  case PRP_SRC_PAD_PRPENC:
  case PRP_SRC_PAD_PRPVF:
@@ -203,6 +203,8 @@ static int prp_set_fmt(struct v4l2_subdev *sd,
  break;
  }
  +    imx_media_try_colorimetry(&sdformat->format, true);
+
  fmt = __prp_get_fmt(priv, cfg, sdformat->pad, sdformat->which);
  *fmt = sdformat->format;
  out:
diff --git a/drivers/staging/media/imx/imx-ic-prpencvf.c 
b/drivers/staging/media/imx/imx-ic-prpencvf.c

index e8b36a181ccc..f2fe3c11c70e 100644
--- a/drivers/staging/media/imx/imx-ic-prpencvf.c
+++ b/drivers/staging/media/imx/imx-ic-prpencvf.c
@@ -907,8 +907,6 @@ static void prp_try_fmt(struct prp_priv *priv,
  /* propagate colorimetry from sink */
  sdformat->format.colorspace = infmt->colorspace;
  sdformat->format.xfer_func = infmt->xfer_func;
-    sdformat->format.quantization = infmt->quantization;
-    sdformat->format.ycbcr_enc = infmt->ycbcr_enc;
  } else {
v4l_bound_align_image(&sdformat->format.width,
    MIN_W_SINK, MAX_W_SINK, W_ALIGN_SINK,
@@ -916,9 +914,11 @@ static void prp_try_fmt(struct prp_priv *priv,
    MIN_H_SINK, MAX_H_SINK, H_ALIGN_SINK,
    S_ALIGN);
  - imx_media_fill_default_mbus_fields(&sdformat->format, infmt,
-   true);
+    if (sdformat->format.field == V4L2_FIELD_ANY)
+    sdformat->format.field = V4L2_FIELD_NONE;
  }
+
+    imx_media_try_colorimetry(&sdformat->format, true);
  }
    static int prp_set_fmt(struct v4l2_subdev *sd,
diff --git a/drivers/staging/media/imx/imx-media-csi.c 
b/drivers/staging/media/imx/imx-media-csi.c

index 1d248aca40a9..dce4addadff4 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -1375,9 +1375,15 @@ static void csi_try_field(struct csi_priv *priv,
  struct v4l2_mbus_framefmt *infmt =
  __csi_get_fmt(priv, cfg, CSI_SINK_PAD, sdformat->which);
  -    /* no restrictions on sink pad field type */
-    if (sdformat->pad == CSI_SINK_PAD)
+    /*
+ * no restrictions on sink pad field type except must
+ * be initialized.
+ */
+    if (sdformat->pad == CSI_SINK_PAD) {
+    if (sdformat->format.field == V4L2_FIELD_ANY)
+    sdformat->format.field = V4L2_FIELD_NONE;
  return;
+    }
    switch (infmt->field) {
  case V4L2_FIELD_SEQ_TB:
@@ -1455,8 +1461,6 @@ static void csi_try_fmt(struct csi_priv *priv,
  /* propagate colorimetry from sink */
  sdformat->format.colorspace = infmt->colorspace;
  sdformat->format.xfer_func = infmt->xfer_func;
-    sdformat->format.quantization = infmt->quantization;
-    sdformat->format.ycbcr_enc = infmt->ycbcr_enc;
    break;
  case CSI_SINK_PAD:
@@ -1476,10 +1480,6 @@ static void csi_try_fmt(struct csi_priv *priv,
    csi_try_field(priv, cfg, sdformat);
  -    imx_media_fill_default_mbus_fields(
-    &sdformat->format, infmt,
-    priv->active_output_pad == CSI_SRC_PAD_DIRECT);
-
  /* Reset crop and compose rectangles */

Re: [PATCH 3/3] x86/ftrace: Use text_poke()

[Alexei Starovoitov]

On Mon, Oct 21, 2019 at 11:16:30PM -0400, Steven Rostedt wrote:
> On Mon, 21 Oct 2019 20:10:09 -0700
> Alexei Starovoitov  wrote:
> 
> > On Mon, Oct 21, 2019 at 5:43 PM Steven Rostedt  wrote:
> > >
> > > On Mon, 21 Oct 2019 17:36:54 -0700
> > > Alexei Starovoitov  wrote:
> > >
> > >  
> > > > What is the status of this set ?
> > > > Steven, did you apply it ?  
> > >
> > > There's still bugs to figure out.  
> > 
> > what bugs you're seeing?
> > The IPI frequency that was mentioned in this thread or something else?
> > I'm hacking ftrace+bpf stuff in the same spot and would like to
> > base my work on the latest and greatest.
> 
> There's real bugs (crashes), talked about in later versions of the
> patch set:
> 
>  https://lore.kernel.org/r/20191009224135.2dcf7...@oasis.local.home
> 
> And there was another crash on Peter's latest I just reported:
> 
>  https://lore.kernel.org/r/20191021222110.49044...@oasis.local.home

ahh. I missed the whole thread. Thanks for pointers.

[RFC PATCH 1/2] dt-bindings: soc: mediatek: Add document for mmdvfs driver

[Anthony Huang]

This document describes the properties what mtk mmdvfs
device node support.

Signed-off-by: Anthony Huang 
---
 .../devicetree/bindings/soc/mediatek/mmdvfs.txt|  149 
 1 file changed, 149 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/mediatek/mmdvfs.txt

diff --git a/Documentation/devicetree/bindings/soc/mediatek/mmdvfs.txt 
b/Documentation/devicetree/bindings/soc/mediatek/mmdvfs.txt
new file mode 100644
index 000..bf33d79
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/mediatek/mmdvfs.txt
@@ -0,0 +1,149 @@
+Mediatek MMDVFS driver binding
+=
+
+The Mediatek MMDVFS(Multimedia Dynamic Voltage and Frequency Scaling) driver
+is used to set clk for Mediatek multimedia hardwares, such as display, camera,
+mdp and video codec. MMDVFS driver reads which clock muxes and clock sources
+are used on this platform from DTS, and sets current clock according to current
+voltage informed by regulator callback.
+
+
+Required properties:
+- compatible : shall contain "mediatek,mmdvfs".
+- operating-points-v2: contains any one of opp tables for multimedia modules.
+   MMDVFS uses it to get voltage setting on this platform.
+- mediatek,support_mux: contains a list of clock mux names defined
+in clock-names.
+- mediatek,mux_*: a series of properties with "mediatek,mux_" prefix.
+ Each property represents one clock mux, and its value is a
+ list of all the clock sources for it. The postfix * and every
+ item in the property must be from the clock-names.
+- clock, clock-names: lists all clock muxes and clock sources for multimedia
+ hardwares.
+
+Optional properties:
+If the platform needs frequency hopping for some clock sources, these following
+properties should be set.
+
+- mediatek,support_hopping: a list of clock names supporting frequency hopping.
+- mediatek,hopping_*: a cell with the same size as opp numbers of an opp table
+ for any MM module and each entry represents the clock
+ rate for each opp. For example, the first entry is the
+ clock rate set in opp-0, and the second entry is the
+ clock rate set in opp-1.
+- mediatek,action: a cell with one entry.
+  It represents the action taken when setting clocks.
+  0 or this property is not set:
+   Do not set frequency hopping and just set clock mux.
+  1:
+   If the voltage is increasing, set frequency hopping
+   first. If the voltage is decreasing, set clock mux
+   first.
+
+Example:
+   opp_table_mm: opp-table-mm {
+   compatible = "operating-points-v2";
+
+   opp-0 {
+   opp-hz = /bits/ 64 <31500>;
+   opp-microvolt = <65>;
+   };
+   opp-1 {
+   opp-hz = /bits/ 64 <45000>;
+   opp-microvolt = <725000>;
+   };
+   opp-2 {
+   opp-hz = /bits/ 64 <60600>;
+   opp-microvolt = <825000>;
+   };
+   };
+
+   opp_table_cam: opp-table-cam {
+   compatible = "operating-points-v2";
+
+   opp-0 {
+   opp-hz = /bits/ 64 <31500>;
+   opp-microvolt = <65>;
+   };
+   opp-1 {
+   opp-hz = /bits/ 64 <41600>;
+   opp-microvolt = <725000>;
+   };
+   opp-2 {
+   opp-hz = /bits/ 64 <56000>;
+   opp-microvolt = <825000>;
+   };
+   };
+    /* Other opp tables for multimedia modules */
+
+   mmdvfs {
+   compatible = "mediatek,mmdvfs";
+
+   operating-points-v2 = <&opp_table_mm>;
+
+   mediatek,support_mux = "mm", "cam", "img", "ipe",
+   "venc", "vdec", "dpe", "ccu";
+
+   mediatek,mux_mm = "clk_mmpll_d5_d2",
+   "clk_mmpll_d7", "clk_tvdpll_mainpll_d2_ck";
+   mediatek,mux_cam = "clk_mmpll_d5_d2",
+   "clk_univpll_d3", "clk_adsppll_d5";
+   mediatek,mux_img = "clk_mmpll_d5_d2",
+   "clk_univpll_d3", "clk_tvdpll_mainpll_d2_ck";
+   mediatek,mux_ipe = "clk_mmpll_d5_d2",
+   "clk_univpll_d3", "clk_mainpll_d2";
+   mediatek,mux_venc = "clk_mainpll_d3",
+   "clk_mmpll_d7", "clk_mmpll_d5";
+   mediatek,mux_vdec = "clk_univpll_d2_d2",
+   "clk_univpll_d3", "clk_univpll_d2";
+   mediatek,mux_dpe = "clk_mainpll_d3",
+   "clk_mmpll_d7", "clk_ma

[RFC PATCH 2/2] soc: mediatek: Add mtk-mmdvfs driver

[Anthony Huang]

Mediatek MMDVFS driver is used to set clk for Mediatek multimedia
hardwares. The MMDVFS registers a regulator callback and multimedia
hardwares set voltage by regulator API and then this callback will be
triggered. The MMDVFS will get current opp level from opp table according
to the voltage, and then the MMDVFS sets all the clock MUXs to the clock
sources according to the opp level.

On some platforms, both clock MUX and frequency hopping need to be used
together. The MMDVFS supports these two clock setting methods and the
execution sequence of them can be configured in DTS.

Signed-off-by: Anthony Huang 
---
 drivers/soc/mediatek/Kconfig  |9 ++
 drivers/soc/mediatek/Makefile |1 +
 drivers/soc/mediatek/mtk-mmdvfs.c |  313 +
 3 files changed, 323 insertions(+)
 create mode 100644 drivers/soc/mediatek/mtk-mmdvfs.c

diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
index 2114b56..e92762b 100644
--- a/drivers/soc/mediatek/Kconfig
+++ b/drivers/soc/mediatek/Kconfig
@@ -44,4 +44,13 @@ config MTK_SCPSYS
  Say yes here to add support for the MediaTek SCPSYS power domain
  driver.
 
+config MTK_MMDVFS
+   tristate "MediaTek MMDVFS Support"
+   depends on ARCH_MEDIATEK || COMPILE_TEST
+   help
+ Say yes here to add support for the MediaTek Multimedia DVFS (MMDVFS)
+ driver. The MMDVFS is used to set clk for Mediatek multimedia 
hardwares
+ , such as display, camera, mdp and video codec. Say no if your device
+ does not need to do DVFS for Multimedia hardwares.
+
 endmenu
diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
index b017330..faf52944 100644
--- a/drivers/soc/mediatek/Makefile
+++ b/drivers/soc/mediatek/Makefile
@@ -1,5 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0-only
 obj-$(CONFIG_MTK_CMDQ) += mtk-cmdq-helper.o
 obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o
+obj-$(CONFIG_MTK_MMDVFS) += mtk-mmdvfs.o
 obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
 obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
diff --git a/drivers/soc/mediatek/mtk-mmdvfs.c 
b/drivers/soc/mediatek/mtk-mmdvfs.c
new file mode 100644
index 000..f6e45b0
--- /dev/null
+++ b/drivers/soc/mediatek/mtk-mmdvfs.c
@@ -0,0 +1,313 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 MediaTek Inc.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MAX_OPP_NUM (6)
+#define MAX_MUX_NUM (10)
+#define MAX_HOPPING_CLK_NUM (2)
+
+enum {
+   ACTION_DEFAULT,
+   ACTION_IHDM, /* Voltage Increase: Hopping First, Decrease: MUX First*/
+};
+
+struct mmdvfs_mux_data {
+   const char *mux_name;
+   struct clk *mux;
+   struct clk *clk_src[MAX_OPP_NUM];
+};
+
+struct mmdvfs_hopping_data {
+   const char *hopping_name;
+   struct clk *hopping_clk;
+   u32 hopping_rate[MAX_OPP_NUM];
+};
+
+struct mmdvfs_drv_data {
+   bool need_change_voltage;
+   u32 request_voltage;
+   u32 num_muxes;
+   struct mmdvfs_mux_data muxes[MAX_MUX_NUM];
+   u32 num_hoppings;
+   struct mmdvfs_hopping_data hoppings[MAX_HOPPING_CLK_NUM];
+   u32 action;
+   struct notifier_block nb;
+   u32 voltages[MAX_OPP_NUM];
+};
+
+static void set_all_muxes(struct mmdvfs_drv_data *drv_data, u32 opp_level)
+{
+   u32 num_muxes = drv_data->num_muxes;
+   u32 i;
+   struct clk *mux, *clk_src;
+   s32 err;
+
+   for (i = 0; i < num_muxes; i++) {
+   mux = drv_data->muxes[i].mux;
+   clk_src = drv_data->muxes[i].clk_src[opp_level];
+   err = clk_prepare_enable(mux);
+
+   if (err) {
+   pr_notice("prepare mux(%s) fail:%d opp_level:%d\n",
+ drv_data->muxes[i].mux_name, err, opp_level);
+   continue;
+   }
+   err = clk_set_parent(mux, clk_src);
+   if (err)
+   pr_notice("set parent(%s) fail:%d opp_level:%d\n",
+ drv_data->muxes[i].mux_name, err, opp_level);
+   clk_disable_unprepare(mux);
+   }
+}
+
+static void set_all_hoppings(struct mmdvfs_drv_data *drv_data, u32 opp_level)
+{
+   u32 num_hoppings = drv_data->num_hoppings;
+   u32 i, hopping_rate;
+   struct clk *hopping;
+   s32 err;
+
+   for (i = 0; i < num_hoppings; i++) {
+   hopping = drv_data->hoppings[i].hopping_clk;
+   hopping_rate = drv_data->hoppings[i].hopping_rate[opp_level];
+   err = clk_prepare_enable(hopping);
+
+   if (err) {
+   pr_notice("prepare hopping(%s) fail:%d opp_level:%d\n",
+ drv_data->hoppings[i].hopping_name,
+ err, opp_level);
+   continue;
+   }
+   err = clk_set_rate(hopping, hopping_rate);
+  

[RFC PATCH 0/2] Add Mediatek MMDVFS driver

[Anthony Huang]

This RFC patch adds the Mediatek MMDVFS(Multimedia Dynamic Voltage and
Frequency Scaling) driver. The multimedia HWs, such as display, camera,
share the same power supplier, and on some platforms, they share the
same clock MUX. If each HW needs different clock frequency at the same
time, the clock MUX must be set to the clock source which can meet the
highest required clock frequency.

Following implementation is used to achieve the goal. There are OPP tables
for all the clock MUXs for MM HWs defined in DTS, ant these OPP tables have
the same number of levels. The MMDVFS registers the regulator callback and
the MM HWs can get available clock frequencies from OPP tables and set
corresponding voltage by regulor API. The MMDVFS's callback will be
triggered if the voltage is changed and this voltage represents the highest
required OPP level. The MMDVFS has a mapping table: which clock source
should be set to each clock MUX for every OPP level. So all the clock MUXs
will be set to the clock sources according to the current OPP level in the
MMDVFS's regulator callback.



Anthony Huang (2):
  dt-bindings: soc: mediatek: Add document for mmdvfs driver
  soc: mediatek: Add mtk-mmdvfs driver

 .../devicetree/bindings/soc/mediatek/mmdvfs.txt|  149 ++
 drivers/soc/mediatek/Kconfig   |9 +
 drivers/soc/mediatek/Makefile  |1 +
 drivers/soc/mediatek/mtk-mmdvfs.c  |  313 
 4 files changed, 472 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/mediatek/mmdvfs.txt
 create mode 100644 drivers/soc/mediatek/mtk-mmdvfs.c

-- 
1.7.9.5

RE: [EXT] Re: [v4,2/2] i2c: mux: pca954x: support property idle-state

[Biwen Li]

> Caution: EXT Email
> 
> On 2019-10-21 10:00, Biwen Li wrote:
> > This supports property idle-state
> >
> 
> You should expand this a little bit to explain that idle-state, if present, 
> overrides
> i2c-mux-idle-disconnect. You could also mention your use case where you need
> to avoid disconnects on probe/resume.
Okay, got it. I will add some information in v5.
> 
> > Signed-off-by: Biwen Li 
> > ---
> > Change in v4:
> >   - rename function
> > pca954x_calculate_chan -> pca954x_regval
> >
> > Change in v3:
> >   - update subject and description
> >   - add a helper function pca954x_calculate_chan()
> >
> > Change in v2:
> >   - update subject and description
> >   - add property idle-state
> >
> >  drivers/i2c/muxes/i2c-mux-pca954x.c | 59
> > ++---
> >  1 file changed, 36 insertions(+), 23 deletions(-)
> >
> > diff --git a/drivers/i2c/muxes/i2c-mux-pca954x.c
> > b/drivers/i2c/muxes/i2c-mux-pca954x.c
> > index 923aa3a5a3dc..e566c4cd8ba5 100644
> > --- a/drivers/i2c/muxes/i2c-mux-pca954x.c
> > +++ b/drivers/i2c/muxes/i2c-mux-pca954x.c
> > @@ -86,7 +86,7 @@ struct pca954x {
> >
> >   u8 last_chan;   /* last register value */
> >   /* MUX_IDLE_AS_IS, MUX_IDLE_DISCONNECT or >= 0 for channel */
> > - s8 idle_state;
> > + s32 idle_state;
> >
> >   struct i2c_client *client;
> >
> > @@ -229,20 +229,23 @@ static int pca954x_reg_write(struct i2c_adapter
> *adap,
> >   I2C_SMBUS_BYTE, &dummy);  }
> >
> > +static u8 pca954x_regval(struct pca954x *data, u8 chan) {
> > + /* we make switches look like muxes, not sure how to be smarter
> > +*/
> 
> I know you are just moving the comment around, but please fix the sentence to
> start with a capital letter and end with a period. Sorry I didn't catch this 
> in v3.
Okay, got it, I will fix it in v5.
> 
> > + if (data->chip->muxtype == pca954x_ismux)
> > + return chan | data->chip->enable;
> > + else
> > + return 1 << chan;
> > +}
> > +
> >  static int pca954x_select_chan(struct i2c_mux_core *muxc, u32 chan)
> > {
> >   struct pca954x *data = i2c_mux_priv(muxc);
> >   struct i2c_client *client = data->client;
> > - const struct chip_desc *chip = data->chip;
> >   u8 regval;
> >   int ret = 0;
> >
> > - /* we make switches look like muxes, not sure how to be smarter */
> > - if (chip->muxtype == pca954x_ismux)
> > - regval = chan | chip->enable;
> > - else
> > - regval = 1 << chan;
> > -
> > + regval = pca954x_regval(data, (u8)(chan & 0xff));
> 
> Both a mask and a cast to do what the compiler should be doing all by itself?
> If you need to kill a warning, or something, please do just one or them. But
> personally I prefer the short, sweet and uncluttered:
Okay, got it, thanks. I will adjust it in v5.
> 
> regval = pca954x_regval(data, chan);
> 
> >   /* Only select the channel if its different from the last channel */
> >   if (data->last_chan != regval) {
> >   ret = pca954x_reg_write(muxc->parent, client, regval);
> > @@ -256,7 +259,7 @@ static int pca954x_deselect_mux(struct
> > i2c_mux_core *muxc, u32 chan)  {
> >   struct pca954x *data = i2c_mux_priv(muxc);
> >   struct i2c_client *client = data->client;
> > - s8 idle_state;
> > + s32 idle_state;
> >
> >   idle_state = READ_ONCE(data->idle_state);
> >   if (idle_state >= 0)
> > @@ -402,6 +405,17 @@ static void pca954x_cleanup(struct i2c_mux_core
> *muxc)
> >   i2c_mux_del_adapters(muxc);
> >  }
> >
> > +static int pca954x_init(struct i2c_client *client, struct pca954x
> > +*data) {
> > + if (data->idle_state >= 0) {
> > + data->last_chan = pca954x_regval(data,
> > +(u8)(data->idle_state & 0xff));
> 
> Dito.

Got it, thanks.
> 
> > + } else {
> > + /* Disconnect multiplexer */
> > + data->last_chan = 0;
> > + }
> > + return i2c_smbus_write_byte(client, data->last_chan);
> 
> Here's another thing I missed in the earlier iterations. If 
> i2c_smbus_write_byte
> fails here, I think you should set data->last_chan to zero. For the call from 
> probe
> it obviously doesn't matter much, but I think the call during resume is 
> better off
> with such extra precaution in place.
You are right. I will add extra precaution in v5.
> 
> Cheers,
> Peter
> 
> > +}
> > +
> >  /*
> >   * I2C init/probing/exit functions
> >   */
> > @@ -411,7 +425,6 @@ static int pca954x_probe(struct i2c_client *client,
> >   struct i2c_adapter *adap = client->adapter;
> >   struct device *dev = &client->dev;
> >   struct device_node *np = dev->of_node;
> > - bool idle_disconnect_dt;
> >   struct gpio_desc *gpio;
> >   struct i2c_mux_core *muxc;
> >   struct pca954x *data;
> > @@ -462,23 +475,24 @@ static int pca954x_probe(struct i2c_client *client,
> >   }
> >   }
> >
> > - /* Write the mux register

Re: [PATCHv1] arm64: dts: agilex: add service layer, fpga manager and fpga region

[Dinh Nguyen]

On 10/17/19 2:34 PM, richard.g...@linux.intel.com wrote:
> From: Richard Gong 
> 
> Add service layer, fpga manager and fpga region to the device tree
> on Intel Agilex platform.
> 
> Signed-off-by: Richard Gong 
> ---
>  arch/arm64/boot/dts/intel/socfpga_agilex.dtsi | 32 
> +++
>  1 file changed, 32 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex.dtsi 
> b/arch/arm64/boot/dts/intel/socfpga_agilex.dtsi
> index 36abc25..94090c6 100644
> --- a/arch/arm64/boot/dts/intel/socfpga_agilex.dtsi
> +++ b/arch/arm64/boot/dts/intel/socfpga_agilex.dtsi
> @@ -12,6 +12,19 @@
>   #address-cells = <2>;
>   #size-cells = <2>;
>  
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + service_reserved: svcbuffer@0 {
> + compatible = "shared-dma-pool";
> + reg = <0x0 0x0 0x0 0x100>;
> + alignment = <0x1000>;
> + no-map;
> + };
> + };
> +
>   cpus {
>   #address-cells = <1>;
>   #size-cells = <0>;
> @@ -81,6 +94,13 @@
>   interrupt-parent = <&intc>;
>   ranges = <0 0 0 0x>;
>  
> + base_fpga_region {
> + #address-cells = <0x1>;
> + #size-cells = <0x1>;
> + compatible = "fpga-region";
> + fpga-mgr = <&fpga_mgr>;
> + };
> +
>   gmac0: ethernet@ff80 {
>   compatible = "altr,socfpga-stmmac", "snps,dwmac-3.74a", 
> "snps,dwmac";
>   reg = <0xff80 0x2000>;
> @@ -442,5 +462,17 @@
>  
>   status = "disabled";
>   };
> +
> + firmware {
> + svc {
> + compatible = "intel,stratix10-svc";
> + method = "smc";
> + memory-region = <&service_reserved>;
> +
> + fpga_mgr: fpga-mgr {
> + compatible = 
> "intel,stratix10-soc-fpga-mgr";
> + };
> + };
> + };
>   };
>  };
> 

Applied.

Dinh

Re: [PATCHv2] arm64: dts: agilex: add QSPI support for Intel Agilex

[Dinh Nguyen]

On 10/17/19 8:00 PM, Ley Foon Tan wrote:
> On Wed, 2019-10-16 at 02:40 -0700, Ooi, Joyce wrote:
>> This patch adds QSPI flash interface in device tree for Intel Agilex
>>
>> Signed-off-by: Ooi, Joyce 
>> ---
>> v2: update the qspi_rootfs partition size
>> ---
>>  arch/arm64/boot/dts/intel/socfpga_agilex_socdk.dts | 35
>> ++
>>  1 file changed, 35 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex_socdk.dts
>> b/arch/arm64/boot/dts/intel/socfpga_agilex_socdk.dts
>> index 7814a9e..8de8118 100644
>> --- a/arch/arm64/boot/dts/intel/socfpga_agilex_socdk.dts
>> +++ b/arch/arm64/boot/dts/intel/socfpga_agilex_socdk.dts
>> @@ -73,3 +73,38 @@
>>  &watchdog0 {
>>  status = "okay";
>>  };
>> +
>> +&qspi {
>> +flash@0 {
>> +#address-cells = <1>;
>> +#size-cells = <1>;
>> +compatible = "mt25qu02g";
>> +reg = <0>;
>> +spi-max-frequency = <5000>;
> QSPI can support up to 100MHz.

I've updated the patch accordingly.

Dinh

Re: [PATCH net-next 4/4] r8152: support firmware of PHY NC for RTL8153A

[Jakub Kicinski]

On Mon, 21 Oct 2019 11:41:13 +0800, Hayes Wang wrote:
> Support the firmware of PHY NC which is used to fix the issue found
> for PHY. Currently, only RTL_VER_04, RTL_VER_05, and RTL_VER_06 need
> it.
> 
> The order of loading PHY firmware would be
> 
>   RTL_FW_PHY_START
>   RTL_FW_PHY_NC

Perhaps that's obvious to others, but what's NC? :)

>   RTL_FW_PHY_STOP
> 
> The RTL_FW_PHY_START/RTL_FW_PHY_STOP are used to lock/unlock the PHY,
> and set/clear the patch key from the firmware file.
> 
> Signed-off-by: Hayes Wang 

Re: [PATCH v8 5/5] media: imx: Try colorimetry at both sink and source pads

[Steve Longerbeam]

Hi Laurent,

On 10/21/19 6:44 PM, Laurent Pinchart wrote:

Hi Steve,

On Tue, May 21, 2019 at 06:03:17PM -0700, Steve Longerbeam wrote:

Retask imx_media_fill_default_mbus_fields() to try colorimetry parameters,
renaming it to to imx_media_try_colorimetry(), and call it at both sink and
source pad try_fmt's. The unrelated check for uninitialized field value is
moved out to appropriate places in each subdev try_fmt.

The IC now supports Rec.709 and BT.601 Y'CbCr encoding, and both limited
and full range quantization for both YUV and RGB space, so allow those
for pipelines that route through the IC.

Signed-off-by: Steve Longerbeam 
---
Changes in v7:
- squashed with "media: imx: Allow Rec.709 encoding for IC routes".
- remove the RGB full-range quantization restriction for IC routes.
---
  drivers/staging/media/imx/imx-ic-prp.c  |  6 +-
  drivers/staging/media/imx/imx-ic-prpencvf.c |  8 +--
  drivers/staging/media/imx/imx-media-csi.c   | 19 +++---
  drivers/staging/media/imx/imx-media-utils.c | 73 ++---
  drivers/staging/media/imx/imx-media-vdic.c  |  5 +-
  drivers/staging/media/imx/imx-media.h   |  5 +-
  drivers/staging/media/imx/imx7-media-csi.c  |  8 +--
  7 files changed, 62 insertions(+), 62 deletions(-)

diff --git a/drivers/staging/media/imx/imx-ic-prp.c 
b/drivers/staging/media/imx/imx-ic-prp.c
index 10ffe00f1a54..f87fe0203720 100644
--- a/drivers/staging/media/imx/imx-ic-prp.c
+++ b/drivers/staging/media/imx/imx-ic-prp.c
@@ -193,8 +193,8 @@ static int prp_set_fmt(struct v4l2_subdev *sd,
sdformat->format.code = cc->codes[0];
}
  
-		imx_media_fill_default_mbus_fields(&sdformat->format, infmt,

-  true);
+   if (sdformat->format.field == V4L2_FIELD_ANY)
+   sdformat->format.field = V4L2_FIELD_NONE;
break;
case PRP_SRC_PAD_PRPENC:
case PRP_SRC_PAD_PRPVF:
@@ -203,6 +203,8 @@ static int prp_set_fmt(struct v4l2_subdev *sd,
break;
}
  
+	imx_media_try_colorimetry(&sdformat->format, true);

+
fmt = __prp_get_fmt(priv, cfg, sdformat->pad, sdformat->which);
*fmt = sdformat->format;
  out:
diff --git a/drivers/staging/media/imx/imx-ic-prpencvf.c 
b/drivers/staging/media/imx/imx-ic-prpencvf.c
index e8b36a181ccc..f2fe3c11c70e 100644
--- a/drivers/staging/media/imx/imx-ic-prpencvf.c
+++ b/drivers/staging/media/imx/imx-ic-prpencvf.c
@@ -907,8 +907,6 @@ static void prp_try_fmt(struct prp_priv *priv,
/* propagate colorimetry from sink */
sdformat->format.colorspace = infmt->colorspace;
sdformat->format.xfer_func = infmt->xfer_func;
-   sdformat->format.quantization = infmt->quantization;
-   sdformat->format.ycbcr_enc = infmt->ycbcr_enc;
} else {
v4l_bound_align_image(&sdformat->format.width,
  MIN_W_SINK, MAX_W_SINK, W_ALIGN_SINK,
@@ -916,9 +914,11 @@ static void prp_try_fmt(struct prp_priv *priv,
  MIN_H_SINK, MAX_H_SINK, H_ALIGN_SINK,
  S_ALIGN);
  
-		imx_media_fill_default_mbus_fields(&sdformat->format, infmt,

-  true);
+   if (sdformat->format.field == V4L2_FIELD_ANY)
+   sdformat->format.field = V4L2_FIELD_NONE;
}
+
+   imx_media_try_colorimetry(&sdformat->format, true);
  }
  
  static int prp_set_fmt(struct v4l2_subdev *sd,

diff --git a/drivers/staging/media/imx/imx-media-csi.c 
b/drivers/staging/media/imx/imx-media-csi.c
index 1d248aca40a9..dce4addadff4 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -1375,9 +1375,15 @@ static void csi_try_field(struct csi_priv *priv,
struct v4l2_mbus_framefmt *infmt =
__csi_get_fmt(priv, cfg, CSI_SINK_PAD, sdformat->which);
  
-	/* no restrictions on sink pad field type */

-   if (sdformat->pad == CSI_SINK_PAD)
+   /*
+* no restrictions on sink pad field type except must
+* be initialized.
+*/
+   if (sdformat->pad == CSI_SINK_PAD) {
+   if (sdformat->format.field == V4L2_FIELD_ANY)
+   sdformat->format.field = V4L2_FIELD_NONE;
return;
+   }
  
  	switch (infmt->field) {

case V4L2_FIELD_SEQ_TB:
@@ -1455,8 +1461,6 @@ static void csi_try_fmt(struct csi_priv *priv,
/* propagate colorimetry from sink */
sdformat->format.colorspace = infmt->colorspace;
sdformat->format.xfer_func = infmt->xfer_func;
-   sdformat->format.quantization = infmt->quantization;
-   sdformat->format.ycbcr_enc = infmt->ycbcr_enc;
  
  		break;

case CSI_SINK_PAD:
@@ -1476,10 +1480,6 @@ static void csi_try_fmt(struct csi_priv *priv,
  
  		

Re: [PATCH 3/3] x86/ftrace: Use text_poke()

[Steven Rostedt]

On Mon, 21 Oct 2019 23:16:30 -0400
Steven Rostedt  wrote:

> > what bugs you're seeing?
> > The IPI frequency that was mentioned in this thread or something else?
> > I'm hacking ftrace+bpf stuff in the same spot and would like to
> > base my work on the latest and greatest.  

I'm also going to be touching some of this code too, as I'm waiting for
Peter's code to settle down. What are you touching? I'm going to be
working on making the dyn_ftrace records smaller, and this is going to
change the way the iterations work on modifying the code.

This is what I discussed on stage at Kernel Recipes with Willy Tarreau.

-- Steve

Re: [PATCH 3/3] x86/ftrace: Use text_poke()

[Steven Rostedt]

On Mon, 21 Oct 2019 20:10:09 -0700
Alexei Starovoitov  wrote:

> On Mon, Oct 21, 2019 at 5:43 PM Steven Rostedt  wrote:
> >
> > On Mon, 21 Oct 2019 17:36:54 -0700
> > Alexei Starovoitov  wrote:
> >
> >  
> > > What is the status of this set ?
> > > Steven, did you apply it ?  
> >
> > There's still bugs to figure out.  
> 
> what bugs you're seeing?
> The IPI frequency that was mentioned in this thread or something else?
> I'm hacking ftrace+bpf stuff in the same spot and would like to
> base my work on the latest and greatest.

There's real bugs (crashes), talked about in later versions of the
patch set:

 https://lore.kernel.org/r/20191009224135.2dcf7...@oasis.local.home

And there was another crash on Peter's latest I just reported:

 https://lore.kernel.org/r/20191021222110.49044...@oasis.local.home

-- Steve

Re: [PATCH 3/3] x86/ftrace: Use text_poke()

[Alexei Starovoitov]

On Mon, Oct 21, 2019 at 5:43 PM Steven Rostedt  wrote:
>
> On Mon, 21 Oct 2019 17:36:54 -0700
> Alexei Starovoitov  wrote:
>
>
> > What is the status of this set ?
> > Steven, did you apply it ?
>
> There's still bugs to figure out.

what bugs you're seeing?
The IPI frequency that was mentioned in this thread or something else?
I'm hacking ftrace+bpf stuff in the same spot and would like to
base my work on the latest and greatest.

[PATCH] KVM: x86/vPMU: Declare kvm_pmu->reprogram_pmi field using DECLARE_BITMAP

[Like Xu]

Replace the explicit declaration of "u64 reprogram_pmi" with the generic
macro DECLARE_BITMAP for all possible appropriate number of bits.

Suggested-by: Paolo Bonzini 
Signed-off-by: Like Xu 
---
 arch/x86/include/asm/kvm_host.h |  2 +-
 arch/x86/kvm/pmu.c  | 15 +--
 2 files changed, 6 insertions(+), 11 deletions(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 50eb430b0ad8..236a876a5a2e 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -469,7 +469,7 @@ struct kvm_pmu {
struct kvm_pmc gp_counters[INTEL_PMC_MAX_GENERIC];
struct kvm_pmc fixed_counters[INTEL_PMC_MAX_FIXED];
struct irq_work irq_work;
-   u64 reprogram_pmi;
+   DECLARE_BITMAP(reprogram_pmi, X86_PMC_IDX_MAX);
 };
 
 struct kvm_pmu_ops;
diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c
index 46875bbd0419..75e8f9fae031 100644
--- a/arch/x86/kvm/pmu.c
+++ b/arch/x86/kvm/pmu.c
@@ -62,8 +62,7 @@ static void kvm_perf_overflow(struct perf_event *perf_event,
struct kvm_pmc *pmc = perf_event->overflow_handler_context;
struct kvm_pmu *pmu = pmc_to_pmu(pmc);
 
-   if (!test_and_set_bit(pmc->idx,
- (unsigned long *)&pmu->reprogram_pmi)) {
+   if (!test_and_set_bit(pmc->idx, pmu->reprogram_pmi)) {
__set_bit(pmc->idx, (unsigned long *)&pmu->global_status);
kvm_make_request(KVM_REQ_PMU, pmc->vcpu);
}
@@ -76,8 +75,7 @@ static void kvm_perf_overflow_intr(struct perf_event 
*perf_event,
struct kvm_pmc *pmc = perf_event->overflow_handler_context;
struct kvm_pmu *pmu = pmc_to_pmu(pmc);
 
-   if (!test_and_set_bit(pmc->idx,
- (unsigned long *)&pmu->reprogram_pmi)) {
+   if (!test_and_set_bit(pmc->idx, pmu->reprogram_pmi)) {
__set_bit(pmc->idx, (unsigned long *)&pmu->global_status);
kvm_make_request(KVM_REQ_PMU, pmc->vcpu);
 
@@ -137,7 +135,7 @@ static void pmc_reprogram_counter(struct kvm_pmc *pmc, u32 
type,
}
 
pmc->perf_event = event;
-   clear_bit(pmc->idx, (unsigned long*)&pmc_to_pmu(pmc)->reprogram_pmi);
+   clear_bit(pmc->idx, pmc_to_pmu(pmc)->reprogram_pmi);
 }
 
 void reprogram_gp_counter(struct kvm_pmc *pmc, u64 eventsel)
@@ -253,16 +251,13 @@ EXPORT_SYMBOL_GPL(reprogram_counter);
 void kvm_pmu_handle_event(struct kvm_vcpu *vcpu)
 {
struct kvm_pmu *pmu = vcpu_to_pmu(vcpu);
-   u64 bitmask;
int bit;
 
-   bitmask = pmu->reprogram_pmi;
-
-   for_each_set_bit(bit, (unsigned long *)&bitmask, X86_PMC_IDX_MAX) {
+   for_each_set_bit(bit, pmu->reprogram_pmi, X86_PMC_IDX_MAX) {
struct kvm_pmc *pmc = kvm_x86_ops->pmu_ops->pmc_idx_to_pmc(pmu, 
bit);
 
if (unlikely(!pmc || !pmc->perf_event)) {
-   clear_bit(bit, (unsigned long *)&pmu->reprogram_pmi);
+   clear_bit(bit, pmu->reprogram_pmi);
continue;
}
 
-- 
2.21.0

RE:PERSONAL LETTER FROM MRS RASHIA AMIRA

[Mr Barrister Hans Erich]

Greetings

My name is Barrister Hans Erich.

I have a client who is interested to invest in your country, she is a well 
known politician in her country and deserve a lucrative investment partnership 
with you outside her country without any delay   Please can you manage such 
investment please Kindly reply for further details.

Your full names -


Your urgent response will be appreciated

Thank you and God bless you.

Barrister Hans Erich

Yours sincerely,
Barrister Hans Erich

Re: [PATCH] mmc: fix mmc dma operation

[Nan Li]

在 2019/10/21 17:17, Jerome Brunet 写道:
> On Mon 21 Oct 2019 at 09:57, Neil Armstrong  wrote:
>
>> Hi,
>>
>> Thanks for the fix.
>>
>> First, you should add "mmc: meson-gx:" in the subject.
>>
>> On 21/10/2019 07:59, Jianxin Pan wrote:
>>> From: Nan Li 
>>>
>>> In MMC dma transfer, the region requested by dma_map_sg() may be released
>>> by dma_unmap_sg() before the transfer is completed.
>>>
>>> Put the unmap operation in front of mmc_request_done() to avoid this.
> Since we have seen this problem (yet), could you briefly how you've
> triggered it ?

The problem we found in the stress test was that the sdio device was 
constantly operated on and off electricity to make it repeatedly 
initialized.

During the test, we found that there was a chance that the information 
read by the controller from the sdio device side was wrong, which made 
the sdio initialization fail.

>> You should add a "Fixes:" tag so it can be backported on stable kernels.
>>
>>> Signed-off-by: Nan Li 
>>> Signed-off-by: Jianxin Pan 
>>> ---
>>>   drivers/mmc/host/meson-gx-mmc.c | 15 ---
>>>   1 file changed, 8 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/mmc/host/meson-gx-mmc.c 
>>> b/drivers/mmc/host/meson-gx-mmc.c
>>> index e712315..7667e8a 100644
>>> --- a/drivers/mmc/host/meson-gx-mmc.c
>>> +++ b/drivers/mmc/host/meson-gx-mmc.c
>>> @@ -173,6 +173,7 @@ struct meson_host {
>>> int irq;
>>>   
>>> bool vqmmc_enabled;
>>> +   bool needs_pre_post_req;
>>>   };
>>>   
>>>   #define CMD_CFG_LENGTH_MASK GENMASK(8, 0)
>>> @@ -654,6 +655,8 @@ static void meson_mmc_request_done(struct mmc_host *mmc,
>>> struct meson_host *host = mmc_priv(mmc);
>>>   
>>> host->cmd = NULL;
>>> +   if (host->needs_pre_post_req)
>>> +   meson_mmc_post_req(mmc, mrq, 0);
>>> mmc_request_done(host->mmc, mrq);
>>>   }
>>>   
>>> @@ -803,25 +806,23 @@ static void meson_mmc_start_cmd(struct mmc_host *mmc, 
>>> struct mmc_command *cmd)
>>>   static void meson_mmc_request(struct mmc_host *mmc, struct mmc_request 
>>> *mrq)
>>>   {
>>> struct meson_host *host = mmc_priv(mmc);
>>> -   bool needs_pre_post_req = mrq->data &&
>>> +
>>> +   host->needs_pre_post_req = mrq->data &&
>>> !(mrq->data->host_cookie & SD_EMMC_PRE_REQ_DONE);
>>>   
>>> -   if (needs_pre_post_req) {
>>> +   if (host->needs_pre_post_req) {
>>> meson_mmc_get_transfer_mode(mmc, mrq);
>>> if (!meson_mmc_desc_chain_mode(mrq->data))
>>> -   needs_pre_post_req = false;
>>> +   host->needs_pre_post_req = false;
>>> }
>>>   
>>> -   if (needs_pre_post_req)
>>> +   if (host->needs_pre_post_req)
>>> meson_mmc_pre_req(mmc, mrq);
>>>   
>>> /* Stop execution */
>>> writel(0, host->regs + SD_EMMC_START);
>>>   
>>> meson_mmc_start_cmd(mmc, mrq->sbc ?: mrq->cmd);
>>> -
>>> -   if (needs_pre_post_req)
>>> -   meson_mmc_post_req(mmc, mrq, 0);
>>>   }
> The code around all this is getting quite difficult to follow eventhough
> it does not actually do much
>
> The root of the problem seems be that meson_mmc_pre_req() and
> meson_mmc_post_req() are passed to framework but also called manually
> from meson_mmc_request().
>
> Because of this, some code is added to make sure we don't do things twice.
> Maybe I'm missing something but it look weird ? Ulf, could you give us
> your view ?
>
> As far as I can tell:
>   * pre_req : determine if we use CHAIN_MODE or not AND
>   dma_map_sg() if we do
>   * post_req : dma_unmap_sg() if previously allocated
>
> Do we really need to do all this meson_mmc_request() ? Shouldn't we let the
> framework do the calls to pre/post_req for us ?
>
>>>   
>>>   static void meson_mmc_read_resp(struct mmc_host *mmc, struct mmc_command 
>>> *cmd)
>>>
>> Neil

[PATCH v3 ] iommu/vt-d: Fix panic after kexec -p for kdump

[John Donnelly]

This cures a panic on restart after a kexec operation on 5.3 and 5.4 
kernels.


The underlying state of the iommu registers (iommu->flags &
VTD_FLAG_TRANS_PRE_ENABLED) on a restart results in a domain being marked as
"DEFER_DEVICE_DOMAIN_INFO" that produces an Oops in identity_mapping().

[   43.654737] BUG: kernel NULL pointer dereference, address:
0056
[   43.655720] #PF: supervisor read access in kernel mode
[   43.655720] #PF: error_code(0x) - not-present page
[   43.655720] PGD 0 P4D 0
[   43.655720] Oops:  [#1] SMP PTI
[   43.655720] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
5.3.2-1940.el8uek.x86_64 #1
[   43.655720] Hardware name: Oracle Corporation ORACLE SERVER
X5-2/ASM,MOTHERBOARD,1U, BIOS 30140300 09/20/2018
[   43.655720] RIP: 0010:iommu_need_mapping+0x29/0xd0
[   43.655720] Code: 00 0f 1f 44 00 00 48 8b 97 70 02 00 00 48 83 fa ff
74 53 48 8d 4a ff b8 01 00 00 00 48 83 f9 fd 76 01 c3 48 8b 35 7f 58 e0
01 <48> 39 72 58 75 f2 55 48 89 e5 41 54 53 48 8b 87 28 02 00 00 4c 8b
[   43.655720] RSP: 0018:c901b9b0 EFLAGS: 00010246
[   43.655720] RAX: 0001 RBX: 1000 RCX:
fffd
[   43.655720] RDX: fffe RSI: 8880719b8000 RDI:
8880477460b0
[   43.655720] RBP: c901b9e8 R08:  R09:
888047c01700
[   43.655720] R10: 2194036fc692 R11:  R12:

[   43.655720] R13: 8880477460b0 R14: 0cc0 R15:
888072d2b558
[   43.655720] FS:  () GS:888071c0()
knlGS:
[   43.655720] CS:  0010 DS:  ES:  CR0: 80050033
[   43.655720] CR2: 0056 CR3: 7440a002 CR4:
001606b0
[   43.655720] Call Trace:
[   43.655720]  ? intel_alloc_coherent+0x2a/0x180
[   43.655720]  ? __schedule+0x2c2/0x650
[   43.655720]  dma_alloc_attrs+0x8c/0xd0
[   43.655720]  dma_pool_alloc+0xdf/0x200
[   43.655720]  ehci_qh_alloc+0x58/0x130
[   43.655720]  ehci_setup+0x287/0x7ba
[   43.655720]  ? _dev_info+0x6c/0x83
[   43.655720]  ehci_pci_setup+0x91/0x436
[   43.655720]  usb_add_hcd.cold.48+0x1d4/0x754
[   43.655720]  usb_hcd_pci_probe+0x2bc/0x3f0
[   43.655720]  ehci_pci_probe+0x39/0x40
[   43.655720]  local_pci_probe+0x47/0x80
[   43.655720]  pci_device_probe+0xff/0x1b0
[   43.655720]  really_probe+0xf5/0x3a0
[   43.655720]  driver_probe_device+0xbb/0x100
[   43.655720]  device_driver_attach+0x58/0x60
[   43.655720]  __driver_attach+0x8f/0x150
[   43.655720]  ? device_driver_attach+0x60/0x60
[   43.655720]  bus_for_each_dev+0x74/0xb0
[   43.655720]  driver_attach+0x1e/0x20
[   43.655720]  bus_add_driver+0x151/0x1f0
[   43.655720]  ? ehci_hcd_init+0xb2/0xb2
[   43.655720]  ? do_early_param+0x95/0x95
[   43.655720]  driver_register+0x70/0xc0
[   43.655720]  ? ehci_hcd_init+0xb2/0xb2
[   43.655720]  __pci_register_driver+0x57/0x60
[   43.655720]  ehci_pci_init+0x6a/0x6c
[   43.655720]  do_one_initcall+0x4a/0x1fa
[   43.655720]  ? do_early_param+0x95/0x95
[   43.655720]  kernel_init_freeable+0x1bd/0x262
[   43.655720]  ? rest_init+0xb0/0xb0
[   43.655720]  kernel_init+0xe/0x110
[   43.655720]  ret_from_fork+0x24/0x50


Fixes: 8af46c784ecfe ("iommu/vt-d: Implement is_attach_deferred iommu 
ops entry")

Cc: sta...@vger.kernel.org # v5.3+

Signed-off-by: John Donnelly 
Reviewed-by: Lu Baolu 


---
 drivers/iommu/intel-iommu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index c4e0e4a9ee9e..f83a9a302f8e 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -2783,7 +2783,7 @@ static int identity_mapping(struct device *dev)
struct device_domain_info *info;

info = dev->archdata.iommu;
-   if (info && info != DUMMY_DEVICE_DOMAIN_INFO)
+	if (info && info != DUMMY_DEVICE_DOMAIN_INFO && info != 
DEFER_DEVICE_DOMAIN_INFO)

return (info->domain == si_domain);

return 0;
--
2.20.1


--
Thank You,
John

Re: [PATCH RFC] net: vlan: reverse 4 bytes of vlan header when setting initial MTU

[David Ahern]

On 10/21/19 7:31 PM, Yunsheng Lin wrote:
> Or we just leave it as it is, and expect user to manually configure the MTU
> of vlan netdev to the MTU of thelower device minus vlan header when the
> performace in the above case is a concern to user?
> 

for now, I would think so. vlan on a vxlan device ... you are going
after q-in-q'ish with vxlan? that can not be a common deployment.

Re: [PATCH v6 3/5] x86/kvm: Add "nopvspin" parameter to disable PV spinlocks

[Zhenzhong Duan]

On 2019/10/21 19:14, Vitaly Kuznetsov wrote:

index 249f14a..e9c76d8 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -825,18 +825,44 @@ __visible bool __kvm_vcpu_is_preempted(long cpu)
   */
  void __init kvm_spinlock_init(void)
  {
-   /* Does host kernel support KVM_FEATURE_PV_UNHALT? */
-   if (!kvm_para_has_feature(KVM_FEATURE_PV_UNHALT))
+   /*
+* PV spinlocks is disabled if no host side support, then native
+* qspinlock will be used. As native qspinlock is a fair lock, there is
+* lock holder preemption issue using it in a guest, imaging one pCPU
+* running 10 vCPUs of same guest contending same lock.
+*
+* virt_spin_lock() is introduced as an optimization for that scenario
+* which is enabled by virt_spin_lock_key key. To use that optimization,
+* virt_spin_lock_key isn't disabled here.
+*/

My take (if I properly understood what you say) would be:

"In case host doesn't support KVM_FEATURE_PV_UNHALT there is still an
advantage of keeping virt_spin_lock_key enabled: virt_spin_lock() is
preferred over native qspinlock when vCPU is preempted."


Yes, that's what I mean, maybe I didn't explain clearly due to my pool 
english,


I'll use your explanation instead.




+   if (!kvm_para_has_feature(KVM_FEATURE_PV_UNHALT)) {
+   pr_info("PV spinlocks disabled, no host support.\n");
return;
+   }
  
+	/*

+* Disable PV qspinlock and use native qspinlock when dedicated pCPUs
+* are available.
+*/
if (kvm_para_has_hint(KVM_HINTS_REALTIME)) {
+   pr_info("PV spinlocks disabled with KVM_HINTS_REALTIME 
hints.\n");
+   static_branch_disable(&virt_spin_lock_key);
+   return;
+   }
+
+   if (num_possible_cpus() == 1) {
+   pr_info("PV spinlocks disabled, single CPU.\n");
static_branch_disable(&virt_spin_lock_key);
return;
}
  
-	/* Don't use the pvqspinlock code if there is only 1 vCPU. */

-   if (num_possible_cpus() == 1)
+   if (nopvspin) {
+   pr_info("PV spinlocks disabled, forced by \"nopvspin\" 
parameter.\n");
+   static_branch_disable(&virt_spin_lock_key);
return;

You could've replaced this 'static_branch_disable(); return;' pattern
with a goto to the end of the function to save a few lines but this
looks good anyways.

Reviewed-by: Vitaly Kuznetsov


Ok, will do, thanks for review.

Zhenzhong

linux-next: manual merge of the char-misc tree with the keys tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the char-misc tree got conflicts in:

  samples/Kconfig
  samples/Makefile

between commit:

  0b9c31597d81 ("Add sample notification program")

from the keys tree and commit:

  6859eba4f6fb ("samples: mei: use hostprogs kbuild constructs")

from the char-misc tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc samples/Kconfig
index d0761f29ccb0,b663d9d24114..
--- a/samples/Kconfig
+++ b/samples/Kconfig
@@@ -169,11 -169,11 +169,17 @@@ config SAMPLE_VF
  as mount API and statx().  Note that this is restricted to the x86
  arch whilst it accesses system calls that aren't yet in all arches.
  
 +config SAMPLE_WATCH_QUEUE
 +  bool "Build example /dev/watch_queue notification consumer"
 +  depends on HEADERS_INSTALL
 +  help
 +Build example userspace program to use the new mount_notify(),
 +sb_notify() syscalls and the KEYCTL_WATCH_KEY keyctl() function.
 +
+ config SAMPLE_INTEL_MEI
+   bool "Build example program working with intel mei driver"
+   depends on INTEL_MEI
+   help
+ Build a sample program to work with mei device.
+ 
 -
  endif # SAMPLES
diff --cc samples/Makefile
index a61a39047d02,d6062ab25347..
--- a/samples/Makefile
+++ b/samples/Makefile
@@@ -20,4 -20,4 +20,5 @@@ obj-$(CONFIG_SAMPLE_TRACE_PRINTK) += tr
  obj-$(CONFIG_VIDEO_PCI_SKELETON)  += v4l/
  obj-y += vfio-mdev/
  subdir-$(CONFIG_SAMPLE_VFS)   += vfs
 +subdir-$(CONFIG_SAMPLE_WATCH_QUEUE)   += watch_queue
+ obj-$(CONFIG_SAMPLE_INTEL_MEI)+= mei/


pgpzBDgUlCXww.pgp
Description: OpenPGP digital signature

Re: [PATCH 110/110] lib/vdso: Improve do_hres() and update vdso data unconditionally

[Huacai Chen]

Hi, Thomas,

If we use (s64)cycles < 0, then how to solve the problem that a 64bit
counter become negative?

Maybe we can change the "invalid" value from U64_MAX to 0?  I think
the performance of "cycles == 0" is better than "cycles == U64_MAX".

Huacai

On Mon, Oct 21, 2019 at 10:58 PM Thomas Gleixner  wrote:
>
> On Mon, 21 Oct 2019, Thomas Gleixner wrote:
>
> > On Mon, 21 Oct 2019, Huacai Chen wrote:
> > > @@ -50,7 +50,7 @@ static int do_hres(const struct vdso_data *vd, 
> > > clockid_t clk,
> > > cycles = __arch_get_hw_counter(vd->clock_mode);
> > > ns = vdso_ts->nsec;
> > > last = vd->cycle_last;
> > > -   if (unlikely((s64)cycles < 0))
> > > +   if (unlikely(cycles == U64_MAX))
> > > return -1;
> >
> > That used to create worse code than the weird (s64) type cast which has the
> > same effect. Did you double check that there is no change?
>
> It still does for 32bit.

RE: [PATCH] ethernet/intel: release the local packet buffer

[Brown, Aaron F]

> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Navid Emamdoost
> Sent: Tuesday, September 17, 2019 5:00 PM
> Cc: emamd...@umn.edu; smcca...@umn.edu; k...@umn.edu; Navid
> Emamdoost ; Kirsher, Jeffrey T
> ; David S. Miller ;
> intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: [PATCH] ethernet/intel: release the local packet bufferq
> 
> In e100_loopback_test the buffer allocated for the local packet needs to
> be released.
> 
> Signed-off-by: Navid Emamdoost 
> ---
>  drivers/net/ethernet/intel/e100.c | 1 +
>  1 file changed, 1 insertion(+)

Sorry for the delay getting to this, took me a bit to get the hardware together.

NAK, this patch introduces a trace to my test machines when I run the ethtool 
diagnostic on an e100 port, the system will sometimes survive a bit after the 
trace, however if I try to run traffic across the interface after the trace the 
system panics and locks up with a kernel not syncing message.  I do not have a 
capture of the lock up panic (I can probably get one via serial port or 
netconsole if really necessary.)  The trace before the lock up panic is as 
follows:
---
[  102.460446] BUG: Bad page state in process ethtool  pfn:78db8
[  102.460474] page:d5bf41e36e00 refcount:-1 mapcount:0 
mapping: index:0x0
[  102.460505] flags: 0xfc000()
[  102.460523] raw: 000fc000 dead0100 dead0122 

[  102.460553] raw:    

[  102.460582] page dumped because: nonzero _refcount
[  102.460602] Modules linked in: snd_hda_codec_realtek snd_hda_codec_generic 
snd_hda_intel snd_intel_nhlt snd_hda_codec
 snd_hwdep snd_hda_core snd_seq snd_seq_device snd_pcm mei_wdt snd_timer 
iTCO_wdt mei_me snd iTCO_vendor_support gpio_ic
h mei coretemp lpc_ich pcspkr sg soundcore i2c_i801 joydev acpi_cpufreq nfsd 
auth_rpcgss nfs_acl lockd grace sunrpc ip_t
ables xfs libcrc32c sd_mod sr_mod cdrom i915 video i2c_algo_bit drm_kms_helper 
syscopyarea sysfillrect sysimgblt fb_sys_
fops e1000e ata_generic firewire_ohci pata_marvell ata_piix drm pata_acpi 
serio_raw e100 firewire_core libata ptp pps_co
re mii crc_itu_t
[  102.460800] CPU: 3 PID: 1541 Comm: ethtool Not tainted 
5.4.0-rc1_next-queue_dev-queue_regress-00576-g16390e0 #3
[  102.460836] Hardware name:  /DQ35JO, BIOS JOQ3510J.86A.0954.2008.0922.2331 
09/22/2008
[  102.460865] Call Trace:
[  102.460883]  dump_stack+0x5a/0x73
[  102.460900]  bad_page+0xf5/0x10f
[  102.460916]  get_page_from_freelist+0x103e/0x1290
[  102.460936]  ? __switch_to_asm+0x40/0x70
[  102.460955]  ? __build_skb+0x20/0x190
[  102.460972]  __alloc_pages_nodemask+0x17d/0x320
[  102.460991]  page_frag_alloc+0x87/0x130
[  102.461008]  __netdev_alloc_skb+0x10b/0x130
[  102.461029]  e100_rx_alloc_skb+0x20/0x180 [e100]
[  102.461050]  e100_rx_alloc_list+0x98/0x160 [e100]
[  102.461070]  e100_up+0x11/0x120 [e100]
[  102.461088]  e100_diag_test+0x14e/0x157 [e100]
[  102.461107]  ? _cond_resched+0x15/0x30
[  102.461125]  ? dev_ethtool+0x1133/0x2c30
[  102.461143]  dev_ethtool+0x1159/0x2c30
[  102.461161]  ? inet_ioctl+0x1a0/0x1d0
[  102.461178]  ? netdev_run_todo+0x5d/0x2d0
[  102.461196]  dev_ioctl+0xb3/0x4e0
[  102.461212]  sock_do_ioctl+0xa0/0x140
[  102.461228]  ? do_anonymous_page+0x361/0x670
[  102.461247]  sock_ioctl+0x26e/0x380
[  102.461264]  do_vfs_ioctl+0xa9/0x630
[  102.461281]  ? handle_mm_fault+0xe2/0x1f0
[  102.462101]  ? __do_page_fault+0x247/0x490
[  102.462911]  ksys_ioctl+0x60/0x90
[  102.463715]  __x64_sys_ioctl+0x16/0x20
[  102.464519]  do_syscall_64+0x5b/0x1b0
[  102.465321]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  102.466134] RIP: 0033:0x7f03e53f32f7
[  102.466948] Code: 44 00 00 48 8b 05 79 1b 2d 00 64 c7 00 26 00 00 00 48 c7 
c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 
f0 ff ff 73 01 c3 48 8b 0d 49 1b 2d 00 f7 d8 64 89 01 48
[  102.468728] RSP: 002b:7c72ebf8 EFLAGS: 0246 ORIG_RAX: 
0010
[  102.469657] RAX: ffda RBX: 7c72ec50 RCX: 7f03e53f32f7
[  102.470595] RDX: 7c72ec60 RSI: 8946 RDI: 0003
[  102.471532] RBP: 0001 R08: 0002 R09: 0038
[  102.472453] R10: 7c72e7c0 R11: 0246 R12: 0038
[  102.473359] R13: 01428010 R14: 014280d0 R15: 7c72edc8
[  102.474260] Disabling lock debugging due to kernel taint
[  104.924447] e100 :06:00.0 eth0: NIC Link is Up 100 Mbps Full Duplex
---

Re: [RFC] kasan: include the hashed pointer for an object's location

[Dmitry Vyukov]

On Tue, Oct 22, 2019 at 4:19 AM Lyude Paul  wrote:
>
> The vast majority of the kernel that needs to print out pointers as a
> way to keep track of a specific object in the kernel for debugging
> purposes does so using hashed pointers, since these are "good enough".
> Ironically, the one place we don't do this is within kasan. While
> simply printing a hashed version of where an out of bounds memory access
> occurred isn't too useful, printing out the hashed address of the object
> in question usually is since that's the format most of the kernel is
> likely to be using in debugging output.
>
> Of course this isn't perfect though-having the object's originating
> address doesn't help users at all that need to do things like printing
> the address of a struct which is embedded within another struct, but
> it's certainly better then not printing any hashed addresses. And users
> which need to handle less trivial cases like that can simply fall back
> to careful usage of %px.
>
> Signed-off-by: Lyude Paul 
> Cc: Sean Paul 
> Cc: Daniel Vetter 
> Cc: Andrey Ryabinin 
> Cc: Alexander Potapenko 
> Cc: Dmitry Vyukov 
> Cc: kasan-...@googlegroups.com
> ---
>  mm/kasan/report.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/mm/kasan/report.c b/mm/kasan/report.c
> index 621782100eaa..0a5663fee1f7 100644
> --- a/mm/kasan/report.c
> +++ b/mm/kasan/report.c
> @@ -128,8 +128,9 @@ static void describe_object_addr(struct kmem_cache 
> *cache, void *object,
> int rel_bytes;
>
> pr_err("The buggy address belongs to the object at %px\n"
> -  " which belongs to the cache %s of size %d\n",
> -   object, cache->name, cache->object_size);
> +  " (aka %p) which belongs to the cache\n"
> +  " %s of size %d\n",
> +  object, object, cache->name, cache->object_size);

Hi Lyude,

This only prints hashed address for heap objects, but
print_address_description() has 4 different code paths for different
types of addresses (heap, global, stack, page). Plus there is a case
for address without shadow.
Should we print the hashed address at least for all cases in
print_address_description()?


> if (!addr)
> return;
> --
> 2.21.0
>

RE:PERSONAL LETTER FROM MRS RASHIA AMIRA

[Mr Barrister Hans Erich]

Greetings

My name is Barrister Hans Erich.

I have a client who is interested to invest in your country, she is a well 
known politician in her country and deserve a lucrative investment partnership 
with you outside her country without any delay   Please can you manage such 
investment please Kindly reply for further details.

Your full names -


Your urgent response will be appreciated

Thank you and God bless you.

Barrister Hans Erich

Yours sincerely,
Barrister Hans Erich

Re: [PATCH] cpufreq: Move cancelling of policy update work just after removing notifiers

[Viresh Kumar]

On 21-10-19, 14:28, Sudeep Holla wrote:
> Commit 099967699ad9 ("cpufreq: Cancel policy update work scheduled before 
> freeing")
> added cancel_work_sync(policy->update) after the frequency QoS were
> removed. We can cancel the work just after taking the last CPU in the
> policy offline and unregistering the notifiers as policy->update cannot
> be scheduled from anywhere at this point.
> 
> However, due to other bugs, doing so still triggered the race between
> freeing of policy and scheduled policy update work. Now that all those
> issues are resolved, we can move this cancelling of any scheduled policy
> update work just after removing min/max notifiers.
> 
> Signed-off-by: Sudeep Holla 
> ---
>  drivers/cpufreq/cpufreq.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> Hi Rafael,
> 
> Based on Viresh's suggestion, I am posting a patch to move this
> cancel_work_sync earlier though it's not a must have change.

For me it is :)

> I will leave it up to your preference.
> 
> Regards,
> Sudeep
> 
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 829a3764df1b..48a224a6b178 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -1268,6 +1268,9 @@ static void cpufreq_policy_free(struct cpufreq_policy 
> *policy)
>   freq_qos_remove_notifier(&policy->constraints, FREQ_QOS_MIN,
>&policy->nb_min);
>  
> + /* Cancel any pending policy->update work before freeing the policy. */
> + cancel_work_sync(&policy->update);
> +
>   if (policy->max_freq_req) {
>   /*
>* CPUFREQ_CREATE_POLICY notification is sent only after
> @@ -1279,8 +1282,6 @@ static void cpufreq_policy_free(struct cpufreq_policy 
> *policy)
>   }
>  
>   freq_qos_remove_request(policy->min_freq_req);
> - /* Cancel any pending policy->update work before freeing the policy. */
> - cancel_work_sync(&policy->update);
>   kfree(policy->min_freq_req);
>  
>   cpufreq_policy_put_kobj(policy);

Thanks for doing this.

Acked-by: Viresh Kumar 

-- 
viresh

RE: [PATCH 0/7] towards QE support on ARM

[Qiang Zhao]

On Mon, Oct 22, 2019 at 6:11 AM Leo Li wrote
> -Original Message-
> From: Li Yang 
> Sent: 2019年10月22日 6:11
> To: Rasmus Villemoes 
> Cc: Timur Tabi ; Greg Kroah-Hartman
> ; linux-kernel@vger.kernel.org;
> linux-ser...@vger.kernel.org; Jiri Slaby ;
> linuxppc-...@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org; Qiang
> Zhao 
> Subject: Re: [PATCH 0/7] towards QE support on ARM
> 
> On Mon, Oct 21, 2019 at 3:46 AM Rasmus Villemoes
>  wrote:
> >
> > On 18/10/2019 23.52, Li Yang wrote:
> > > On Fri, Oct 18, 2019 at 3:54 PM Rasmus Villemoes
> > >  wrote:
> > >>
> > >> On 18/10/2019 22.16, Leo Li wrote:
> > >>>
> > 
> >  There have been several attempts in the past few years to allow
> >  building the QUICC engine drivers for platforms other than PPC.
> >  This is (the beginning of) yet another attempt. I hope I can get
> >  someone to pick up these relatively trivial patches (I _think_
> >  they shouldn't change functionality at all), and then I'll
> >  continue slowly working towards removing the PPC32 dependency for
> CONFIG_QUICC_ENGINE.
> > >>>
> > >>> Hi Rasmus,
> > >>>
> > >>> I don't fully understand the motivation of this work.  As far as I know
> the QUICC ENGINE is only used on PowerPC based SoCs.
> > >>
> > >> Hm, you're not the Leo Li that participated in this thread
> > >>
>  rnel.org%2Flkml%2FAM3PR04MB11857AE8D2B0BE56121B97D391C90%40A
> M3PR04MB1185.eurprd04.prod.outlook.com%2FT%2F%23u&data=02%7
> C01%7Cqiang.zhao%40nxp.com%7C1ba8c50c2db14b22bef608d756739d82%
> 7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6370729268771788
> 75&sdata=k4zM75OczXwZF%2Br9ec4RxiVR2a%2F8GhSZmK70JYddIck%3
> D&reserved=0>?
> > >
> > > Oops, I totally forgot about this discussion which is just three
> > > years ago.  :)  The QE-HDLC on LS1021a is kind of a special case.
> > >
> > >>
> > >>
> > >>  Can you give an example on how is it used on ARM system?
> > >>
> > >> LS1021A, for example, which is the one I'm aiming for getting fully
> > >> supported in mainline.
> > >>  > >>
> www.nxp.com%2Fproducts%2Fprocessors-and-microcontrollers%2Farm-proc
> > >> essors%2Flayerscape-communication-process%2Fqoriq-layerscape-1021a-
> > >>
> dual-core-communications-processor-with-lcd-controller%3ALS1021A&am
> > >>
> p;data=02%7C01%7Cqiang.zhao%40nxp.com%7C1ba8c50c2db14b22bef608d
> 7567
> > >>
> 39d82%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6370729268
> 771788
> > >>
> 75&sdata=vqPYSZqEv6vCEIxJshLuA4gngh9J4IsFAQrTwJKMjm4%3D&r
> es
> > >> erved=0>
> > >>
> > >> The forks at
> > >>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.
> com%2Fqoriq-open-source%2Flinux.git&data=02%7C01%7Cqiang.zhao%
> 40nxp.com%7C1ba8c50c2db14b22bef608d756739d82%7C686ea1d3bc2b4c6
> fa92cd99c5c301635%7C0%7C0%7C637072926877178875&sdata=v4eG
> 4KqGTWQkQHp%2FYg2OHCKITLWaOgH64JYpY%2B1LilA%3D&reserved=0
> have various degrees of support (grep for commits saying stuff like "remove
> PPCisms"
> > >> - some versions can be found on
> > >>  > >>
> lore.kernel.org%2Flkml%2F%3Fq%3Dremove%2Bppcisms&data=02%7C0
> 1%7
> > >>
> Cqiang.zhao%40nxp.com%7C1ba8c50c2db14b22bef608d756739d82%7C686e
> a1d3
> > >>
> bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637072926877178875&sdat
> a=i2WdKNHLV68a1mTOMQ%2FoMr0y5ee8edS07xq61M8%2BvPU%3D&r
> eserved=0>). Our current kernel is based on commits from the now-vanished
> 4.1 branch, and unfortunately at least the 4.14 branch (LSDK-18.06-V4.14)
> trivially doesn't build on ARM, despite the PPC32 dependency having been
> removed from CONFIG_QUICC_ENGINE.
> > >
> > > Can you try the 4.14 branch from a newer LSDK release?  LS1021a
> > > should be supported platform on LSDK.  If it is broken, something is
> wrong.
> >
> > What newer release? LSDK-18.06-V4.14 is the latest -V4.14 tag at
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> >
> ub.com%2Fqoriq-open-source%2Flinux.git&data=02%7C01%7Cqiang.zha
> o%4
> >
> 0nxp.com%7C1ba8c50c2db14b22bef608d756739d82%7C686ea1d3bc2b4c6f
> a92cd99c
> >
> 5c301635%7C0%7C0%7C637072926877188868&sdata=vdm4qPoTzfIpXL
> mRrv17EW
> > noxG3n91qELMGqvRh9we4%3D&reserved=0, and identical to the
> 
> That tree has been abandoned for a while, we probably should state that in the
> github.  The latest tree can be found at
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsource.
> codeaurora.org%2Fexternal%2Fqoriq%2Fqoriq-components%2Flinux%2F&
> ;data=02%7C01%7Cqiang.zhao%40nxp.com%7C1ba8c50c2db14b22bef608d7
> 56739d82%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6370729
> 26877188868&sdata=NooBFUWnceTG2OF24pCuP0AYgKfr0Df%2BtrcCY6
> X6Dog%3D&reserved=0
> 
> > linux-4.14 branch. And despite commit 4c33e2d0576b removing the PPC32
> > dependency from QUICC_ENGINE, it clearly hasn't been built on arm,
> > si

Re: [PATCH v2 2/2] usb: cdns3: Add TI specific wrapper driver

[Peter Chen]

On 19-10-21 16:13:05, Roger Quadros wrote:
> The J721e platform comes with 2 Cadence USB3 controller
> instances. This driver supports the TI specific wrapper
> on this platform.
> 
> Signed-off-by: Roger Quadros 
> Signed-off-by: Sekhar Nori 
> ---
>  drivers/usb/cdns3/Kconfig|  10 ++
>  drivers/usb/cdns3/Makefile   |   1 +
>  drivers/usb/cdns3/cdns3-ti.c | 236 +++
>  3 files changed, 247 insertions(+)
>  create mode 100644 drivers/usb/cdns3/cdns3-ti.c
> 
> diff --git a/drivers/usb/cdns3/Kconfig b/drivers/usb/cdns3/Kconfig
> index d0331613a355..2a1e89d12ed9 100644
> --- a/drivers/usb/cdns3/Kconfig
> +++ b/drivers/usb/cdns3/Kconfig
> @@ -43,4 +43,14 @@ config USB_CDNS3_PCI_WRAP
> If you choose to build this driver as module it will
> be dynamically linked and module will be called cdns3-pci.ko
>  
> +config USB_CDNS3_TI
> + tristate "Cadence USB3 support on TI platforms"
> + depends on ARCH_K3 || COMPILE_TEST
> + default USB_CDNS3
> + help
> +   Say 'Y' or 'M' here if you are building for Texas Instruments
> +   platforms that contain Cadence USB3 controller core.
> +
> +   e.g. J721e.
> +
>  endif
> diff --git a/drivers/usb/cdns3/Makefile b/drivers/usb/cdns3/Makefile
> index a703547350bb..948e6b88d1a9 100644
> --- a/drivers/usb/cdns3/Makefile
> +++ b/drivers/usb/cdns3/Makefile
> @@ -14,3 +14,4 @@ endif
>  cdns3-$(CONFIG_USB_CDNS3_HOST)   += host.o
>  
>  obj-$(CONFIG_USB_CDNS3_PCI_WRAP) += cdns3-pci-wrap.o
> +obj-$(CONFIG_USB_CDNS3_TI)   += cdns3-ti.o
> diff --git a/drivers/usb/cdns3/cdns3-ti.c b/drivers/usb/cdns3/cdns3-ti.c
> new file mode 100644
> index ..5541cba71965
> --- /dev/null
> +++ b/drivers/usb/cdns3/cdns3-ti.c
> @@ -0,0 +1,236 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/**
> + * cdns_ti-ti.c - TI specific Glue layer for Cadence USB Controller

cdns3-ti.c

> + *
> + * Copyright (C) 2019 Texas Instruments Incorporated - 
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ti.com&data=02%7C01%7Cpeter.chen%40nxp.com%7C94aad23d5a294c5cdaf808d75628931c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637072604595033025&sdata=Lye5SayAKcqAMaNGbZ%2Fq5OkUZ8IsWMVgGmeh8IhA69M%3D&reserved=0
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* USB Wrapper register offsets */
> +#define USBSS_PID0x0
> +#define  USBSS_W10x4
> +#define USBSS_STATIC_CONFIG  0x8
> +#define USBSS_PHY_TEST   0xc
> +#define  USBSS_DEBUG_CTRL0x10
> +#define  USBSS_DEBUG_INFO0x14
> +#define  USBSS_DEBUG_LINK_STATE  0x18
> +#define  USBSS_DEVICE_CTRL   0x1c
> +
> +/* Wrapper 1 register bits */
> +#define USBSS_W1_PWRUP_RST   BIT(0)
> +#define USBSS_W1_OVERCURRENT_SEL BIT(8)
> +#define USBSS_W1_MODESTRAP_SEL   BIT(9)
> +#define USBSS_W1_OVERCURRENT BIT(16)
> +#define USBSS_W1_MODESTRAP_MASK  GENMASK(18, 17)
> +#define USBSS_W1_MODESTRAP_SHIFT 17
> +#define USBSS_W1_USB2_ONLY   BIT(19)
> +
> +/* Static config register bits */
> +#define USBSS1_STATIC_PLL_REF_SEL_MASK   GENMASK(8, 5)
> +#define USBSS1_STATIC_PLL_REF_SEL_SHIFT  5
> +#define USBSS1_STATIC_LOOPBACK_MODE_MASK GENMASK(4, 3)
> +#define USBSS1_STATIC_LOOPBACK_MODE_SHIFT3
> +#define USBSS1_STATIC_VBUS_SEL_MASK  GENMASK(2, 1)
> +#define USBSS1_STATIC_VBUS_SEL_SHIFT 1
> +#define USBSS1_STATIC_LANE_REVERSE   BIT(0)
> +
> +/* Modestrap modes */
> +enum modestrap_mode { USBSS_MODESTRAP_MODE_NONE,
> +   USBSS_MODESTRAP_MODE_HOST,
> +   USBSS_MODESTRAP_MODE_PERIPHERAL};
> +
> +struct cdns_ti {
> + struct device *dev;
> + void __iomem *usbss;
> + int usb2_only:1;
> + int vbus_divider:1;
> + struct clk *usb2_refclk;
> + struct clk *lpm_clk;
> +};
> +
> +static const int cdns_ti_rate_table[] = {/* in KHZ */
> + 9600,
> + 1,
> + 12000,
> + 19200,
> + 2,
> + 24000,
> + 25000,
> + 26000,
> + 38400,
> + 4,
> + 58000,
> + 5,
> + 52000,
> +};
> +
> +static inline u32 cdns_ti_readl(struct cdns_ti *data, u32 offset)
> +{
> + return readl(data->usbss + offset);
> +}
> +
> +static inline void cdns_ti_writel(struct cdns_ti *data, u32 offset, u32 
> value)
> +{
> + writel(value, data->usbss + offset);
> +}
> +
> +static int cdns_ti_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct device_node *node = pdev->dev.of_node;
> + struct cdns_ti *data;
> + struct resource *res;
> + int error;
> + u32 reg;
> + int rate_code, i;
> + unsigned long rate;
> +
> + data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> + if (!data)
> + return -ENOMEM;
> +
> + platform_set_drvdata(pdev, data);
> +
> + data->de

Re: [PATCH v4 15/16] module: Move where we mark modules RO,X

[Steven Rostedt]

On Fri, 18 Oct 2019 09:35:40 +0200
Peter Zijlstra  wrote:

> Now that set_all_modules_text_*() is gone, nothing depends on the
> relation between ->state = COMING and the protection state anymore.
> This enables moving the protection changes later, such that the COMING
> notifier callbacks can more easily modify the text.
> 
> Signed-off-by: Peter Zijlstra (Intel) 
> Cc: Jessica Yu 
> ---

This triggered the following bug:

 BUG: unable to handle page fault for address: a01501f1
 #PF: supervisor instruction fetch in kernel mode
 #PF: error_code(0x0011) - permissions violation
 PGD 2a16067 P4D 2a16067 PUD 2a17063 PMD c230c067 PTE 8000c4d74063
 Oops: 0011 [#1] PREEMPT SMP KASAN PTI
 CPU: 2 PID: 638 Comm: systemd-udevd Not tainted 5.4.0-rc3-test+ #98
 ACPI: If an ACPI driver is available for this device, you should use it 
instead of the native driver
 ACPI Warning: SystemIO range 0x0530-0x053F conflicts 
with OpRegion 0x0500-0x0563 (\GPIO) 
(20190816/utaddress-213)
 ACPI: If an ACPI driver is available for this device, you should use it 
instead of the native driver
 ACPI Warning: SystemIO range 0x0500-0x052F conflicts 
with OpRegion 0x0500-0x0563 (\GPIO) 
(20190816/utaddress-213)
 ACPI: If an ACPI driver is available for this device, you should use it 
instead of the native driver
 lpc_ich: Resource conflict(s) found affecting gpio_ich
 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03 
07/14/2016
 RIP: 0010:trace_event_define_fields_i2c_result+0x0/0x86 [i2c_core]
 Code: 27 6a 00 48 c7 c2 60 34 13 a0 45 31 c9 48 89 df 41 b8 02 00 00 00 b9 12 
00 00 00 48 c7 c6 a0 33 13 a0 e8 02 ec 14 e1 5a 5b c3 <53> 48 c7 c6 20 33 13 a0 
b9 08 00 00 00 41
0 6a 00 41
 RSP: 0018:8880cba07950 EFLAGS: 00010246
 RAX: a01501f1 RBX: a013da40 RCX: 812a147c
 RDX: dc00 RSI: 0008 RDI: a013da40
 RBP: a0142be0 R08: ed1017fde1ab R09: ed1017fde1ab
 R10: ed1017fde1aa R11: 8880bfef0d57 R12: 8880cc22a000
 R13: a013da50 R14: a0137aa8 R15: 8880cd372c60
 FS:  7f062a48f940() GS:8880d468() knlGS:
 CS:  0010 DS:  ES:  CR0: 80050033
 CR2: a01501f1 CR3: cb632003 CR4: 001606e0
 Call Trace:
  event_create_dir+0x358/0x7b0
  trace_module_notify+0x20b/0x240
  notifier_call_chain+0x6d/0xa0
  blocking_notifier_call_chain+0x5e/0x80
  load_module+0x39a5/0x3d80
  ? module_frob_arch_sections+0x20/0x20
  ? vfs_read+0xcc/0x1b0
  ? kernel_read+0x95/0xb0
  ? kernel_read_file+0x187/0x310
  ? find_held_lock+0xac/0xd0
  ? syscall_trace_enter+0x369/0x590
  ? __do_sys_finit_module+0x11a/0x1b0
  __do_sys_finit_module+0x11a/0x1b0
  ? __ia32_sys_init_module+0x40/0x40
  ? trace_hardirqs_on+0x2e/0x120
  ? ktime_get_coarse_real_ts64+0x6c/0xf0
  ? syscall_trace_enter+0x233/0x590
  ? do_syscall_64+0x14/0x1a0
  do_syscall_64+0x68/0x1a0
  entry_SYSCALL_64_after_hwframe+0x49/0xbe

Attached config, but it seems to be triggered with modules that have
trace events defined in them.

The trace_event_define_fields_() is defined in
include/trace/trace_events.h and is an init function called by the
trace_events event_create_dir() via the module notifier:
MODULE_STATE_COMING

-- Steve


config.gz
Description: application/gzip

[RFC] kasan: include the hashed pointer for an object's location

[Lyude Paul]

The vast majority of the kernel that needs to print out pointers as a
way to keep track of a specific object in the kernel for debugging
purposes does so using hashed pointers, since these are "good enough".
Ironically, the one place we don't do this is within kasan. While
simply printing a hashed version of where an out of bounds memory access
occurred isn't too useful, printing out the hashed address of the object
in question usually is since that's the format most of the kernel is
likely to be using in debugging output.

Of course this isn't perfect though-having the object's originating
address doesn't help users at all that need to do things like printing
the address of a struct which is embedded within another struct, but
it's certainly better then not printing any hashed addresses. And users
which need to handle less trivial cases like that can simply fall back
to careful usage of %px.

Signed-off-by: Lyude Paul 
Cc: Sean Paul 
Cc: Daniel Vetter 
Cc: Andrey Ryabinin 
Cc: Alexander Potapenko 
Cc: Dmitry Vyukov 
Cc: kasan-...@googlegroups.com
---
 mm/kasan/report.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/mm/kasan/report.c b/mm/kasan/report.c
index 621782100eaa..0a5663fee1f7 100644
--- a/mm/kasan/report.c
+++ b/mm/kasan/report.c
@@ -128,8 +128,9 @@ static void describe_object_addr(struct kmem_cache *cache, 
void *object,
int rel_bytes;
 
pr_err("The buggy address belongs to the object at %px\n"
-  " which belongs to the cache %s of size %d\n",
-   object, cache->name, cache->object_size);
+  " (aka %p) which belongs to the cache\n"
+  " %s of size %d\n",
+  object, object, cache->name, cache->object_size);
 
if (!addr)
return;
-- 
2.21.0

Re: [GIT PULL] SafeSetID LSM changes for 5.4

[Paul E. McKenney]

On Mon, Oct 21, 2019 at 08:58:11AM +0200, Ingo Molnar wrote:
> 
> * Paul E. McKenney  wrote:
> 
> > --- a/include/linux/rcupdate.h
> > +++ b/include/linux/rcupdate.h
> > @@ -383,20 +383,22 @@ do {  
> >   \
> >  } while (0)
> >  
> >  /**
> > - * rcu_swap_protected() - swap an RCU and a regular pointer
> > - * @rcu_ptr: RCU pointer
> > + * rcu_replace() - replace an RCU pointer, returning its old value
> > + * @rcu_ptr: RCU pointer, whose old value is returned
> >   * @ptr: regular pointer
> > - * @c: the conditions under which the dereference will take place
> > + * @c: the lockdep conditions under which the dereference will take place
> >   *
> > - * Perform swap(@rcu_ptr, @ptr) where @rcu_ptr is an RCU-annotated pointer 
> > and
> > - * @c is the argument that is passed to the rcu_dereference_protected() 
> > call
> > - * used to read that pointer.
> > + * Perform a replacement, where @rcu_ptr is an RCU-annotated
> > + * pointer and @c is the lockdep argument that is passed to the
> > + * rcu_dereference_protected() call used to read that pointer.  The old
> > + * value of @rcu_ptr is returned, and @rcu_ptr is set to @ptr.
> >   */
> > -#define rcu_swap_protected(rcu_ptr, ptr, c) do {   \
> > +#define rcu_replace(rcu_ptr, ptr, c)   
> > \
> > +({ \
> > typeof(ptr) __tmp = rcu_dereference_protected((rcu_ptr), (c));  \
> > rcu_assign_pointer((rcu_ptr), (ptr));   \
> > -   (ptr) = __tmp;  \
> > -} while (0)
> > +   __tmp;  \
> > +})
> 
> One small suggestion, would it make sense to name it "rcu_replace_pointer()"?
> 
> This would make it fit into the pointer handling family of RCU functions: 
> rcu_assign_pointer(), rcu_access_pointer(), RCU_INIT_POINTER() et al?

Easy enough to make the change.  I will do that tomorrow and test over
the following night.

> rcu_swap() would also look a bit weird if used in MM code. ;-)

How much RCU swap should we configure on this system?  About same amount
as reader-writer swap!  ;-)

Thanx, Paul

RE:PERSONAL LETTER FROM MRS RASHIA AMIRA

[Mr Barrister Hans Erich]

Greetings

My name is Barrister Hans Erich.

I have a client who is interested to invest in your country, she is a well 
known politician in her country and deserve a lucrative investment partnership 
with you outside her country without any delay   Please can you manage such 
investment please Kindly reply for further details.

Your full names -


Your urgent response will be appreciated

Thank you and God bless you.

Barrister Hans Erich

Yours sincerely,
Barrister Hans Erich

Re: [PATCH v1 1/2] usb: chipidea: use of extcon framework to work for non OTG case

[Peter Chen]

On 19-10-21 19:16:53, Igor Opaniuk wrote:
> From: Stefan Agner 
> 
> The existing usage of extcon in chipidea driver freezes the kernel
> presumably due to OTGSC register access.
> 
> Prevent accessing any OTG registers for SoC with dual role devices
> but no true OTG support. Use the flag CI_HDRC_DUAL_ROLE_NOT_OTG for
> those devices and in case extcon is present, do the role switch
> using extcon only.

Hi Igor & Stefan,

I have several questions about the problem you met:
- Which vendor's controller you have used?
- What do you mean "no true OTG"? Does it mean no "OTGSC" register?

>   if (dr_mode == USB_DR_MODE_OTG || dr_mode == USB_DR_MODE_HOST) {
>   ret = ci_hdrc_host_init(ci);
> @@ -1145,8 +1208,18 @@ static int ci_hdrc_probe(struct platform_device *pdev)
>  
>   if (!ci_otg_is_fsm_mode(ci)) {
>   /* only update vbus status for peripheral */
> - if (ci->role == CI_ROLE_GADGET)
> - ci_handle_vbus_change(ci);
> + if (dr_mode == USB_DR_MODE_PERIPHERAL) {
> + usb_gadget_vbus_connect(&ci->gadget);

We only use ci->role at runtime, since it has already considered the
dts setting, kernel configuration and hardware setting.

If your controller doesn't otgsc register, but do need to support
role switch, you may enhance the function ci_get_role

Peter

> + } else if (ci->role == CI_ROLE_GADGET) {
> + struct ci_hdrc_cable *vbus = &ci->platdata->vbus_extcon;
> +
> + /* Use vbus state from extcon if provided */
> + if (!IS_ERR(vbus->edev) &&
> + extcon_get_state(vbus->edev, EXTCON_USB))
> + usb_gadget_vbus_connect(&ci->gadget);
> + else
> + ci_handle_vbus_change(ci);
> + }
>  
>   ret = ci_role_start(ci, ci->role);
>   if (ret) {
> @@ -1161,10 +1234,6 @@ static int ci_hdrc_probe(struct platform_device *pdev)
>   if (ret)
>   goto stop;
>  
> - ret = ci_extcon_register(ci);
> - if (ret)
> - goto stop;
> -
>   if (ci->supports_runtime_pm) {
>   pm_runtime_set_active(&pdev->dev);
>   pm_runtime_enable(&pdev->dev);
> -- 
> 2.17.1
> 

-- 

Thanks,
Peter Chen