Re: [Tee-dev] [PATCHv8 1/3] optee: use uuid for sysfs driver entry

2020-06-17 Thread Jerome Forissier
On 6/18/20 6:59 AM, Sumit Garg wrote:
> Hi Jerome,
> 
> On Wed, 17 Jun 2020 at 20:46, Jerome Forissier  wrote:
>>
>>
>>
>> On 6/17/20 3:58 PM, Sumit Garg wrote:
>>> Hi Maxim,
>>>
>>> On Thu, 4 Jun 2020 at 23:28, Maxim Uvarov  wrote:

 With the evolving use-cases for TEE bus, now it's required to support
 multi-stage enumeration process. But using a simple index doesn't
 suffice this requirement and instead leads to duplicate sysfs entries.
 So instead switch to use more informative device UUID for sysfs entry
 like:
 /sys/bus/tee/devices/optee-ta-

 Signed-off-by: Maxim Uvarov 
 Reviewed-by: Sumit Garg 
 ---
  Documentation/ABI/testing/sysfs-bus-optee-devices | 8 
  MAINTAINERS   | 1 +
  drivers/tee/optee/device.c| 9 ++---
  3 files changed, 15 insertions(+), 3 deletions(-)
  create mode 100644 Documentation/ABI/testing/sysfs-bus-optee-devices

 diff --git a/Documentation/ABI/testing/sysfs-bus-optee-devices 
 b/Documentation/ABI/testing/sysfs-bus-optee-devices
 new file mode 100644
 index ..0ae04ae5374a
 --- /dev/null
 +++ b/Documentation/ABI/testing/sysfs-bus-optee-devices
 @@ -0,0 +1,8 @@
 +What:  /sys/bus/tee/devices/optee-ta-/
 +Date:   May 2020
 +KernelVersion   5.7
 +Contact:tee-...@lists.linaro.org
 +Description:
 +   OP-TEE bus provides reference to registered drivers under 
 this directory. The 
 +   matches Trusted Application (TA) driver and corresponding 
 TA in secure OS. Drivers
 +   are free to create needed API under optee-ta- 
 directory.
 diff --git a/MAINTAINERS b/MAINTAINERS
 index ecc0749810b0..6717afef2de3 100644
 --- a/MAINTAINERS
 +++ b/MAINTAINERS
 @@ -12516,6 +12516,7 @@ OP-TEE DRIVER
  M: Jens Wiklander 
  L: tee-...@lists.linaro.org
  S: Maintained
 +F: Documentation/ABI/testing/sysfs-bus-optee-devices
  F: drivers/tee/optee/

  OP-TEE RANDOM NUMBER GENERATOR (RNG) DRIVER
 diff --git a/drivers/tee/optee/device.c b/drivers/tee/optee/device.c
 index e3a148521ec1..23d264c8146e 100644
 --- a/drivers/tee/optee/device.c
 +++ b/drivers/tee/optee/device.c
 @@ -65,7 +65,7 @@ static int get_devices(struct tee_context *ctx, u32 
 session,
 return 0;
  }

 -static int optee_register_device(const uuid_t *device_uuid, u32 device_id)
 +static int optee_register_device(const uuid_t *device_uuid)
  {
 struct tee_client_device *optee_device = NULL;
 int rc;
 @@ -75,7 +75,10 @@ static int optee_register_device(const uuid_t 
 *device_uuid, u32 device_id)
 return -ENOMEM;

 optee_device->dev.bus = &tee_bus_type;
 -   dev_set_name(&optee_device->dev, "optee-clnt%u", device_id);
 +   if (dev_set_name(&optee_device->dev, "optee-ta-%pUl", 
 device_uuid)) {
>>>
>>> You should be using format specifier as: "%pUb" instead of "%pUl" as
>>> UUID representation for TAs is in big endian format. See below:
>>
>> Where does device_uuid come from? If it comes directly from OP-TEE, then
>> it should be a pointer to the following struct:
>>
>> typedef struct
>> {
>> uint32_t timeLow;
>> uint16_t timeMid;
>> uint16_t timeHiAndVersion;
>> uint8_t clockSeqAndNode[8];
>> } TEE_UUID;
>>
>> (GlobalPlatform TEE Internal Core API spec v1.2.1 section 3.2.4)
>>
>> - The spec does not mandate any particular endianness and simply warns
>> about possible issues if secure and non-secure worlds differ in endianness.
>> - OP-TEE uses %pUl assuming that host order is little endian (that is
>> true for the Arm platforms that run OP-TEE currently). By the same logic
>> %pUl should be fine in the kernel.
>> - On the other hand, the UUID in a Trusted App header is always encoded
>> big endian by the Python script that signs and optionally encrypts the
>> TA. This should not have any visible impact on UUIDs exchanged between
>> the secure and non-secure world though.
>>
>> So I am wondering why you had to use %pUb. There must be some
>> inconsistency somewhere :-/
> 
> Yes there is. Linux stores UUID in big endian format (16 byte octets)
> and OP-TEE stores UUID in little endian format (in form of struct you
> referenced above).
> 
> And format conversion APIs [1] in OP-TEE OS are used while passing
> UUID among Linux and OP-TEE.
> 
> So we need to use %pUb in case of Linux and %pUl in case of OP-TEE.
> 
> [1] https://github.com/OP-TEE/optee_os/blob/master/core/tee/uuid.c


Got it now. The TA enumeration function in OP-TEE performs  the
conversion here:
https://github.com/OP-TEE/optee_os/blob/3.9.0/core/pta/device.c#L34

Thanks for clarifying.

-- 
Jerome


Re: [PATCH 0/4] arm64: dts: imx8m: dtb aliases update

2020-06-17 Thread Shawn Guo
On Wed, May 20, 2020 at 10:02:42AM +0800, peng@nxp.com wrote:
> From: Peng Fan 
> 
> Minor patchset to update device tree aliases
> 
> Peng Fan (4):
>   arm64: dts: imx8mq: Add mmc aliases
>   arm64: dts: imx8mq: Add ethernet alias
>   arm64: dts: imx8mm: sort the aliases
>   arm64: dts: imx8mp: add i2c aliases

Applied all, thanks.


Re: [PATCH 0/3] zone-append support in aio and io-uring

2020-06-17 Thread Christoph Hellwig
On Wed, Jun 17, 2020 at 10:53:36PM +0530, Kanchan Joshi wrote:
> This patchset enables issuing zone-append using aio and io-uring direct-io 
> interface.
> 
> For aio, this introduces opcode IOCB_CMD_ZONE_APPEND. Application uses start 
> LBA
> of the zone to issue append. On completion 'res2' field is used to return
> zone-relative offset.
> 
> For io-uring, this introduces three opcodes: 
> IORING_OP_ZONE_APPEND/APPENDV/APPENDV_FIXED.
> Since io_uring does not have aio-like res2, cqe->flags are repurposed to 
> return zone-relative offset

And what exactly are the semantics supposed to be?  Remember the
unix file abstractions does not know about zones at all.

I really don't think squeezing low-level not quite block storage
protocol details into the Linux read/write path is a good idea.

What could be a useful addition is a way for O_APPEND/RWF_APPEND writes
to report where they actually wrote, as that comes close to Zone Append
while still making sense at our usual abstraction level for file I/O.


[PATCH] drm/lima: Expose job_hang_limit module parameter

2020-06-17 Thread Andrey Lebedev
From: Andrey Lebedev 

Some pp or gp jobs can be successfully repeated even after they time outs.
Introduce lima module parameter to specify number of times a job can hang
before being dropped.

Signed-off-by: Andrey Lebedev 
---

Changed type of lima_job_hang_limit to unsigned int.

 drivers/gpu/drm/lima/lima_drv.c   | 4 
 drivers/gpu/drm/lima/lima_drv.h   | 1 +
 drivers/gpu/drm/lima/lima_sched.c | 5 +++--
 3 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/lima/lima_drv.c b/drivers/gpu/drm/lima/lima_drv.c
index a831565af813..2400b8d52d92 100644
--- a/drivers/gpu/drm/lima/lima_drv.c
+++ b/drivers/gpu/drm/lima/lima_drv.c
@@ -19,6 +19,7 @@
 int lima_sched_timeout_ms;
 uint lima_heap_init_nr_pages = 8;
 uint lima_max_error_tasks;
+uint lima_job_hang_limit;
 
 MODULE_PARM_DESC(sched_timeout_ms, "task run timeout in ms");
 module_param_named(sched_timeout_ms, lima_sched_timeout_ms, int, 0444);
@@ -29,6 +30,9 @@ module_param_named(heap_init_nr_pages, 
lima_heap_init_nr_pages, uint, 0444);
 MODULE_PARM_DESC(max_error_tasks, "max number of error tasks to save");
 module_param_named(max_error_tasks, lima_max_error_tasks, uint, 0644);
 
+MODULE_PARM_DESC(job_hang_limit, "number of times to allow a job to hang 
before dropping it (default 0)");
+module_param_named(job_hang_limit, lima_job_hang_limit, int, 0444);
+
 static int lima_ioctl_get_param(struct drm_device *dev, void *data, struct 
drm_file *file)
 {
struct drm_lima_get_param *args = data;
diff --git a/drivers/gpu/drm/lima/lima_drv.h b/drivers/gpu/drm/lima/lima_drv.h
index fdbd4077c768..39fd98e3b14d 100644
--- a/drivers/gpu/drm/lima/lima_drv.h
+++ b/drivers/gpu/drm/lima/lima_drv.h
@@ -11,6 +11,7 @@
 extern int lima_sched_timeout_ms;
 extern uint lima_heap_init_nr_pages;
 extern uint lima_max_error_tasks;
+extern int lima_job_hang_limit;
 
 struct lima_vm;
 struct lima_bo;
diff --git a/drivers/gpu/drm/lima/lima_sched.c 
b/drivers/gpu/drm/lima/lima_sched.c
index e6cefda00279..1602985dfa04 100644
--- a/drivers/gpu/drm/lima/lima_sched.c
+++ b/drivers/gpu/drm/lima/lima_sched.c
@@ -503,8 +503,9 @@ int lima_sched_pipe_init(struct lima_sched_pipe *pipe, 
const char *name)
 
INIT_WORK(&pipe->recover_work, lima_sched_recover_work);
 
-   return drm_sched_init(&pipe->base, &lima_sched_ops, 1, 0,
- msecs_to_jiffies(timeout), name);
+   return drm_sched_init(&pipe->base, &lima_sched_ops, 1,
+ lima_job_hang_limit, msecs_to_jiffies(timeout),
+ name);
 }
 
 void lima_sched_pipe_fini(struct lima_sched_pipe *pipe)
-- 
2.25.1



[v4][PATCH] e1000e: continue to init phy even when failed to disable ULP

2020-06-17 Thread Aaron Ma
After 'commit e086ba2fccda4 ("e1000e: disable s0ix entry and exit flows
 for ME systems")',
ThinkPad P14s always failed to disable ULP by ME.
'commit 0c80cdbf3320 ("e1000e: Warn if disabling ULP failed")'
break out of init phy:

error log:
[   42.364753] e1000e :00:1f.6 enp0s31f6: Failed to disable ULP
[   42.524626] e1000e :00:1f.6 enp0s31f6: PHY Wakeup cause - Unicast Packet
[   42.822476] e1000e :00:1f.6 enp0s31f6: Hardware Error

When disable s0ix, E1000_FWSM_ULP_CFG_DONE will never be 1.
If continue to init phy like before, it can work as before.
iperf test result good too.

Fixes: 0c80cdbf3320 ("e1000e: Warn if disabling ULP failed")
Signed-off-by: Aaron Ma 
---
 drivers/net/ethernet/intel/e1000e/ich8lan.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.c 
b/drivers/net/ethernet/intel/e1000e/ich8lan.c
index f999cca37a8a..be7475c5529d 100644
--- a/drivers/net/ethernet/intel/e1000e/ich8lan.c
+++ b/drivers/net/ethernet/intel/e1000e/ich8lan.c
@@ -303,7 +303,6 @@ static s32 e1000_init_phy_workarounds_pchlan(struct 
e1000_hw *hw)
ret_val = e1000_disable_ulp_lpt_lp(hw, true);
if (ret_val) {
e_warn("Failed to disable ULP\n");
-   goto out;
}
 
ret_val = hw->phy.ops.acquire(hw);
-- 
2.26.2



Re: [PATCH 6/6] smp: Cleanup smp_call_function*()

2020-06-17 Thread Christoph Hellwig
On Wed, Jun 17, 2020 at 01:04:01PM +0200, Peter Zijlstra wrote:
> On Wed, Jun 17, 2020 at 01:23:49AM -0700, Christoph Hellwig wrote:
> 
> > > @@ -178,9 +178,7 @@ static void zpci_handle_fallback_irq(voi
> > >   if (atomic_inc_return(&cpu_data->scheduled) > 1)
> > >   continue;
> > >  
> > > - cpu_data->csd.func = zpci_handle_remote_irq;
> > > - cpu_data->csd.info = &cpu_data->scheduled;
> > > - cpu_data->csd.flags = 0;
> > > + cpu_data->csd = CSD_INIT(zpci_handle_remote_irq, 
> > > &cpu_data->scheduled);
> > 
> > This looks weird.  I'd much rather see an initialization ala INIT_WORK:
> > 
> > INIT_CSD(&cpu_data->csd, zpci_handle_remote_irq,
> >  &cpu_data->scheduled);
> 
> 
> like so then?

Much better.  Although if we touch all the callers we might as well
pass the csd as the argument to the callback, as with that we can
pretty trivially remove the private data field later.

Btw, it seems the callers that don't have the CSD embedded into the
containing structure seems to be of these two kinds:

 - reimplementing on_each_cpumask (mostly because they can be called
   from irq context)
 - reimplenenting smp_call_function_single because they want
   to sleep instead of busy wait

I wonder if those would be useful primitives for smp.c..


[v3][PATCH] e1000e: continue to init phy even when failed to disable ULP

2020-06-17 Thread Aaron Ma
After commit: e086ba2fccda4 ("e1000e: disable s0ix entry and exit flows
 for ME systems").
ThinkPad P14s always failed to disable ULP by ME.
commit: 0c80cdbf3320 ("e1000e: Warn if disabling ULP failed")
break out of init phy:

error log:
[   42.364753] e1000e :00:1f.6 enp0s31f6: Failed to disable ULP
[   42.524626] e1000e :00:1f.6 enp0s31f6: PHY Wakeup cause - Unicast Packet
[   42.822476] e1000e :00:1f.6 enp0s31f6: Hardware Error

When disable s0ix, E1000_FWSM_ULP_CFG_DONE will never be 1.
If continue to init phy like before, it can work as before.
iperf test result good too.

Fixes: 0c80cdbf3320 ("e1000e: Warn if disabling ULP failed")
Signed-off-by: Aaron Ma 
---
 drivers/net/ethernet/intel/e1000e/ich8lan.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.c 
b/drivers/net/ethernet/intel/e1000e/ich8lan.c
index f999cca37a8a..be7475c5529d 100644
--- a/drivers/net/ethernet/intel/e1000e/ich8lan.c
+++ b/drivers/net/ethernet/intel/e1000e/ich8lan.c
@@ -303,7 +303,6 @@ static s32 e1000_init_phy_workarounds_pchlan(struct 
e1000_hw *hw)
ret_val = e1000_disable_ulp_lpt_lp(hw, true);
if (ret_val) {
e_warn("Failed to disable ULP\n");
-   goto out;
}
 
ret_val = hw->phy.ops.acquire(hw);
-- 
2.26.2



Re: [PATCH] drm/lima: Expose job_hang_limit module parameter

2020-06-17 Thread Qiang Yu
On Thu, Jun 18, 2020 at 1:57 AM Andrey Lebedev  wrote:
>
> From: Andrey Lebedev 
>
> Some pp or gp jobs can be successfully repeated even after they time outs.
> Introduce lima module parameter to specify number of times a job can hang
> before being dropped.
>
> Signed-off-by: Andrey Lebedev 
> ---
>
> Hello,
>
> This patch allows to work around a freezing problem as discussed in
> https://gitlab.freedesktop.org/lima/linux/-/issues/33
>
>  drivers/gpu/drm/lima/lima_drv.c   | 4 
>  drivers/gpu/drm/lima/lima_drv.h   | 1 +
>  drivers/gpu/drm/lima/lima_sched.c | 5 +++--
>  3 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/lima/lima_drv.c b/drivers/gpu/drm/lima/lima_drv.c
> index a831565af813..2807eba26c55 100644
> --- a/drivers/gpu/drm/lima/lima_drv.c
> +++ b/drivers/gpu/drm/lima/lima_drv.c
> @@ -19,6 +19,7 @@
>  int lima_sched_timeout_ms;
>  uint lima_heap_init_nr_pages = 8;
>  uint lima_max_error_tasks;
> +int lima_job_hang_limit;

Better be an "uint" to avoid negative check. With this fixed, patch is:
Reviewed-by: Qiang Yu 

Regards,
Qiang

>
>  MODULE_PARM_DESC(sched_timeout_ms, "task run timeout in ms");
>  module_param_named(sched_timeout_ms, lima_sched_timeout_ms, int, 0444);
> @@ -29,6 +30,9 @@ module_param_named(heap_init_nr_pages, 
> lima_heap_init_nr_pages, uint, 0444);
>  MODULE_PARM_DESC(max_error_tasks, "max number of error tasks to save");
>  module_param_named(max_error_tasks, lima_max_error_tasks, uint, 0644);
>
> +MODULE_PARM_DESC(job_hang_limit, "number of times to allow a job to hang 
> before dropping it (default 0)");
> +module_param_named(job_hang_limit, lima_job_hang_limit, int, 0444);
> +
>  static int lima_ioctl_get_param(struct drm_device *dev, void *data, struct 
> drm_file *file)
>  {
> struct drm_lima_get_param *args = data;
> diff --git a/drivers/gpu/drm/lima/lima_drv.h b/drivers/gpu/drm/lima/lima_drv.h
> index fdbd4077c768..39fd98e3b14d 100644
> --- a/drivers/gpu/drm/lima/lima_drv.h
> +++ b/drivers/gpu/drm/lima/lima_drv.h
> @@ -11,6 +11,7 @@
>  extern int lima_sched_timeout_ms;
>  extern uint lima_heap_init_nr_pages;
>  extern uint lima_max_error_tasks;
> +extern int lima_job_hang_limit;
>
>  struct lima_vm;
>  struct lima_bo;
> diff --git a/drivers/gpu/drm/lima/lima_sched.c 
> b/drivers/gpu/drm/lima/lima_sched.c
> index e6cefda00279..1602985dfa04 100644
> --- a/drivers/gpu/drm/lima/lima_sched.c
> +++ b/drivers/gpu/drm/lima/lima_sched.c
> @@ -503,8 +503,9 @@ int lima_sched_pipe_init(struct lima_sched_pipe *pipe, 
> const char *name)
>
> INIT_WORK(&pipe->recover_work, lima_sched_recover_work);
>
> -   return drm_sched_init(&pipe->base, &lima_sched_ops, 1, 0,
> - msecs_to_jiffies(timeout), name);
> +   return drm_sched_init(&pipe->base, &lima_sched_ops, 1,
> + lima_job_hang_limit, msecs_to_jiffies(timeout),
> + name);
>  }
>
>  void lima_sched_pipe_fini(struct lima_sched_pipe *pipe)
> --
> 2.25.1
>


[PATCH 1/3] x86/hyperv: allocate the hypercall page with only read and execute bits

2020-06-17 Thread Christoph Hellwig
Avoid a W^X violation cause by the fact that PAGE_KERNEL_EXEC includes the
writable bit.

For this resurrect the removed PAGE_KERNEL_RX definitіon, but as
PAGE_KERNEL_ROX to match arm64 and powerpc.

Fixes: 78bb17f76edc ("x86/hyperv: use vmalloc_exec for the hypercall page")
Reported-by: Dexuan Cui 
Signed-off-by: Christoph Hellwig 
Tested-by: Vitaly Kuznetsov 
---
 arch/x86/hyperv/hv_init.c| 4 +++-
 arch/x86/include/asm/pgtable_types.h | 2 ++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index a54c6a401581dd..2bdc72e6890eca 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -375,7 +375,9 @@ void __init hyperv_init(void)
guest_id = generate_guest_id(0, LINUX_VERSION_CODE, 0);
wrmsrl(HV_X64_MSR_GUEST_OS_ID, guest_id);
 
-   hv_hypercall_pg = vmalloc_exec(PAGE_SIZE);
+   hv_hypercall_pg = __vmalloc_node_range(PAGE_SIZE, 1, VMALLOC_START,
+   VMALLOC_END, GFP_KERNEL, PAGE_KERNEL_ROX,
+   VM_FLUSH_RESET_PERMS, NUMA_NO_NODE, __func__);
if (hv_hypercall_pg == NULL) {
wrmsrl(HV_X64_MSR_GUEST_OS_ID, 0);
goto remove_cpuhp_state;
diff --git a/arch/x86/include/asm/pgtable_types.h 
b/arch/x86/include/asm/pgtable_types.h
index 2da1f95b88d761..816b31c685505f 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -194,6 +194,7 @@ enum page_cache_mode {
 #define _PAGE_TABLE_NOENC   (__PP|__RW|_USR|___A|   0|___D|   0|   0)
 #define _PAGE_TABLE (__PP|__RW|_USR|___A|   0|___D|   0|   0| _ENC)
 #define __PAGE_KERNEL_RO(__PP|   0|   0|___A|__NX|___D|   0|___G)
+#define __PAGE_KERNEL_ROX   (__PP|   0|   0|___A|   0|___D|   0|___G)
 #define __PAGE_KERNEL_NOCACHE   (__PP|__RW|   0|___A|__NX|___D|   0|___G| __NC)
 #define __PAGE_KERNEL_VVAR  (__PP|   0|_USR|___A|__NX|___D|   0|___G)
 #define __PAGE_KERNEL_LARGE (__PP|__RW|   0|___A|__NX|___D|_PSE|___G)
@@ -219,6 +220,7 @@ enum page_cache_mode {
 #define PAGE_KERNEL_RO __pgprot_mask(__PAGE_KERNEL_RO | _ENC)
 #define PAGE_KERNEL_EXEC   __pgprot_mask(__PAGE_KERNEL_EXEC   | _ENC)
 #define PAGE_KERNEL_EXEC_NOENC __pgprot_mask(__PAGE_KERNEL_EXEC   |0)
+#define PAGE_KERNEL_ROX__pgprot_mask(__PAGE_KERNEL_ROX
| _ENC)
 #define PAGE_KERNEL_NOCACHE__pgprot_mask(__PAGE_KERNEL_NOCACHE| _ENC)
 #define PAGE_KERNEL_LARGE  __pgprot_mask(__PAGE_KERNEL_LARGE  | _ENC)
 #define PAGE_KERNEL_LARGE_EXEC __pgprot_mask(__PAGE_KERNEL_LARGE_EXEC | _ENC)
-- 
2.26.2



[PATCH 2/3] arm64: use PAGE_KERNEL_ROX directly in alloc_insn_page

2020-06-17 Thread Christoph Hellwig
Use PAGE_KERNEL_ROX directly instead of allocating RWX and setting the
page read-only just after the allocation.

Signed-off-by: Christoph Hellwig 
---
 arch/arm64/kernel/probes/kprobes.c | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/kernel/probes/kprobes.c 
b/arch/arm64/kernel/probes/kprobes.c
index d1c95dcf1d7833..cbe49cd117cfec 100644
--- a/arch/arm64/kernel/probes/kprobes.c
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -120,15 +120,9 @@ int __kprobes arch_prepare_kprobe(struct kprobe *p)
 
 void *alloc_insn_page(void)
 {
-   void *page;
-
-   page = vmalloc_exec(PAGE_SIZE);
-   if (page) {
-   set_memory_ro((unsigned long)page, 1);
-   set_vm_flush_reset_perms(page);
-   }
-
-   return page;
+   return __vmalloc_node_range(PAGE_SIZE, 1, VMALLOC_START, VMALLOC_END,
+   GFP_KERNEL, PAGE_KERNEL_ROX, VM_FLUSH_RESET_PERMS,
+   NUMA_NO_NODE, __func__);
 }
 
 /* arm kprobe: install breakpoint in text */
-- 
2.26.2



[PATCH 3/3] mm: remove vmalloc_exec

2020-06-17 Thread Christoph Hellwig
Merge vmalloc_exec into its only caller.  Note that for !CONFIG_MMU
__vmalloc_node_range maps to __vmalloc, which directly clears the
__GFP_HIGHMEM added by the vmalloc_exec stub anyway.

Signed-off-by: Christoph Hellwig 
---
 include/linux/vmalloc.h |  1 -
 kernel/module.c |  4 +++-
 mm/nommu.c  | 17 -
 mm/vmalloc.c| 20 
 4 files changed, 3 insertions(+), 39 deletions(-)

diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h
index 48bb681e6c2aed..0221f852a7e1a3 100644
--- a/include/linux/vmalloc.h
+++ b/include/linux/vmalloc.h
@@ -106,7 +106,6 @@ extern void *vzalloc(unsigned long size);
 extern void *vmalloc_user(unsigned long size);
 extern void *vmalloc_node(unsigned long size, int node);
 extern void *vzalloc_node(unsigned long size, int node);
-extern void *vmalloc_exec(unsigned long size);
 extern void *vmalloc_32(unsigned long size);
 extern void *vmalloc_32_user(unsigned long size);
 extern void *__vmalloc(unsigned long size, gfp_t gfp_mask);
diff --git a/kernel/module.c b/kernel/module.c
index e8a198588f26ee..0c6573b98c3662 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2783,7 +2783,9 @@ static void dynamic_debug_remove(struct module *mod, 
struct _ddebug *debug)
 
 void * __weak module_alloc(unsigned long size)
 {
-   return vmalloc_exec(size);
+   return __vmalloc_node_range(size, 1, VMALLOC_START, VMALLOC_END,
+   GFP_KERNEL, PAGE_KERNEL_EXEC, VM_FLUSH_RESET_PERMS,
+   NUMA_NO_NODE, __func__);
 }
 
 bool __weak module_init_section(const char *name)
diff --git a/mm/nommu.c b/mm/nommu.c
index cdcad5d61dd194..f32a69095d509e 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -290,23 +290,6 @@ void *vzalloc_node(unsigned long size, int node)
 }
 EXPORT_SYMBOL(vzalloc_node);
 
-/**
- * vmalloc_exec  -  allocate virtually contiguous, executable memory
- * @size:  allocation size
- *
- * Kernel-internal function to allocate enough pages to cover @size
- * the page level allocator and map them into contiguous and
- * executable kernel virtual space.
- *
- * For tight control over page level allocator and protection flags
- * use __vmalloc() instead.
- */
-
-void *vmalloc_exec(unsigned long size)
-{
-   return __vmalloc(size, GFP_KERNEL | __GFP_HIGHMEM);
-}
-
 /**
  * vmalloc_32  -  allocate virtually contiguous memory (32bit addressable)
  * @size:  allocation size
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 3091c2ca60dfd1..f60948aac0d0e4 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -2696,26 +2696,6 @@ void *vzalloc_node(unsigned long size, int node)
 }
 EXPORT_SYMBOL(vzalloc_node);
 
-/**
- * vmalloc_exec - allocate virtually contiguous, executable memory
- * @size:allocation size
- *
- * Kernel-internal function to allocate enough pages to cover @size
- * the page level allocator and map them into contiguous and
- * executable kernel virtual space.
- *
- * For tight control over page level allocator and protection flags
- * use __vmalloc() instead.
- *
- * Return: pointer to the allocated memory or %NULL on error
- */
-void *vmalloc_exec(unsigned long size)
-{
-   return __vmalloc_node_range(size, 1, VMALLOC_START, VMALLOC_END,
-   GFP_KERNEL, PAGE_KERNEL_EXEC, VM_FLUSH_RESET_PERMS,
-   NUMA_NO_NODE, __builtin_return_address(0));
-}
-
 #if defined(CONFIG_64BIT) && defined(CONFIG_ZONE_DMA32)
 #define GFP_VMALLOC32 (GFP_DMA32 | GFP_KERNEL)
 #elif defined(CONFIG_64BIT) && defined(CONFIG_ZONE_DMA)
-- 
2.26.2



fix a hyperv W^X violation and remove vmalloc_exec

2020-06-17 Thread Christoph Hellwig
Hi all,

Dexuan reported a W^X violation due to the fact that the hyper hypercall
page due switching it to be allocated using vmalloc_exec.  The problem
is that PAGE_KERNEL_EXEC as used by vmalloc_exec actually sets writable
permissions in the pte.  This series fixes the issue by switching to the
low-level __vmalloc_node_range interface that allows specifing more
detailed permissions instead.  It then also open codes the other two
callers and removes the somewhat confusing vmalloc_exec interface.

Peter noted that the hyper hypercall page allocation also has another
long standing issue in that it shouldn't use the full vmalloc but just
the module space.  This issue is so far theoretical as the allocation is
done early in the boot process.  I plan to fix it with another bigger
series for 5.9.


Re: [PATCH v5 1/4] KEYS: trusted: Add generic trusted keys framework

2020-06-17 Thread Sumit Garg
On Thu, 18 Jun 2020 at 04:44, Jarkko Sakkinen
 wrote:
>
> On Tue, Jun 16, 2020 at 07:02:37PM +0530, Sumit Garg wrote:
> > + Luke
> >
> > Hi Jarkko,
> >
> > Prior to addressing your comments below which seems to show your
> > preference for compile time selection of trust source (TPM or TEE), I
> > would just like to hear the reasons for this preference especially if
> > it makes distro vendor's life difficult [1] to make opinionated
> > selection which could rather be achieved dynamically based on platform
> > capability.
> >
> > [1] https://lkml.org/lkml/2020/6/3/405
> >
> > -Sumit
>
> Hmm... I do get the distribution kernel point. OK, lets revert to
> dynamic then. Thanks for the remark.
>
> /Jarkko

Thanks, will revert to dynamic mode in v6.

-Sumit


[PATCH 1/5] f2fs: fix to wait page writeback before update

2020-06-17 Thread Chao Yu
to make page content stable for special device like raid.

Signed-off-by: Chao Yu 
---
 fs/f2fs/dir.c  |  2 ++
 fs/f2fs/extent_cache.c | 18 +-
 fs/f2fs/f2fs.h |  2 +-
 fs/f2fs/file.c |  1 +
 fs/f2fs/inline.c   |  2 ++
 fs/f2fs/inode.c|  3 +--
 6 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
index d35976785e8c..91e86747a604 100644
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -495,6 +495,8 @@ static int make_empty_dir(struct inode *inode,
if (IS_ERR(dentry_page))
return PTR_ERR(dentry_page);
 
+   f2fs_bug_on(F2FS_I_SB(inode), PageWriteback(dentry_page));
+
dentry_blk = page_address(dentry_page);
 
make_dentry_ptr_block(NULL, &d, dentry_blk);
diff --git a/fs/f2fs/extent_cache.c b/fs/f2fs/extent_cache.c
index e60078460ad1..686c68b98610 100644
--- a/fs/f2fs/extent_cache.c
+++ b/fs/f2fs/extent_cache.c
@@ -325,9 +325,10 @@ static void __drop_largest_extent(struct extent_tree *et,
 }
 
 /* return true, if inode page is changed */
-static bool __f2fs_init_extent_tree(struct inode *inode, struct f2fs_extent 
*i_ext)
+static void __f2fs_init_extent_tree(struct inode *inode, struct page *ipage)
 {
struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
+   struct f2fs_extent *i_ext = ipage ? &F2FS_INODE(ipage)->i_ext : NULL;
struct extent_tree *et;
struct extent_node *en;
struct extent_info ei;
@@ -335,16 +336,18 @@ static bool __f2fs_init_extent_tree(struct inode *inode, 
struct f2fs_extent *i_e
if (!f2fs_may_extent_tree(inode)) {
/* drop largest extent */
if (i_ext && i_ext->len) {
+   f2fs_wait_on_page_writeback(ipage, NODE, true, true);
i_ext->len = 0;
-   return true;
+   set_page_dirty(ipage);
+   return;
}
-   return false;
+   return;
}
 
et = __grab_extent_tree(inode);
 
if (!i_ext || !i_ext->len)
-   return false;
+   return;
 
get_extent_info(&ei, i_ext);
 
@@ -360,17 +363,14 @@ static bool __f2fs_init_extent_tree(struct inode *inode, 
struct f2fs_extent *i_e
}
 out:
write_unlock(&et->lock);
-   return false;
 }
 
-bool f2fs_init_extent_tree(struct inode *inode, struct f2fs_extent *i_ext)
+void f2fs_init_extent_tree(struct inode *inode, struct page *ipage)
 {
-   bool ret =  __f2fs_init_extent_tree(inode, i_ext);
+   __f2fs_init_extent_tree(inode, ipage);
 
if (!F2FS_I(inode)->extent_tree)
set_inode_flag(inode, FI_NO_EXTENT);
-
-   return ret;
 }
 
 static bool f2fs_lookup_extent_tree(struct inode *inode, pgoff_t pgofs,
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index b35a50f4953c..326c12fa0da5 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -3795,7 +3795,7 @@ struct rb_entry *f2fs_lookup_rb_tree_ret(struct 
rb_root_cached *root,
 bool f2fs_check_rb_tree_consistence(struct f2fs_sb_info *sbi,
struct rb_root_cached *root);
 unsigned int f2fs_shrink_extent_tree(struct f2fs_sb_info *sbi, int nr_shrink);
-bool f2fs_init_extent_tree(struct inode *inode, struct f2fs_extent *i_ext);
+void f2fs_init_extent_tree(struct inode *inode, struct page *ipage);
 void f2fs_drop_extent_tree(struct inode *inode);
 unsigned int f2fs_destroy_extent_node(struct inode *inode);
 void f2fs_destroy_extent_tree(struct inode *inode);
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index 3268f8dd59bb..1862073b96d2 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -1250,6 +1250,7 @@ static int __clone_blkaddrs(struct inode *src_inode, 
struct inode *dst_inode,
f2fs_put_page(psrc, 1);
return PTR_ERR(pdst);
}
+   f2fs_wait_on_page_writeback(pdst, DATA, true, true);
f2fs_copy_page(psrc, pdst);
set_page_dirty(pdst);
f2fs_put_page(pdst, 1);
diff --git a/fs/f2fs/inline.c b/fs/f2fs/inline.c
index dbade310dc79..4bcbc486c9e2 100644
--- a/fs/f2fs/inline.c
+++ b/fs/f2fs/inline.c
@@ -340,6 +340,8 @@ int f2fs_make_empty_inline_dir(struct inode *inode, struct 
inode *parent,
struct f2fs_dentry_ptr d;
void *inline_dentry;
 
+   f2fs_wait_on_page_writeback(ipage, NODE, true, true);
+
inline_dentry = inline_data_addr(inode, ipage);
 
make_dentry_ptr_inline(inode, &d, inline_dentry);
diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c
index 44582a4db513..7c156eb26dd7 100644
--- a/fs/f2fs/inode.c
+++ b/fs/f2fs/inode.c
@@ -367,8 +367,7 @@ static int do_read_inode(struct inode *inode)
fi->i_pino = le32_to_cpu(ri->i_pino);
fi->i_dir_level = ri->i_dir_level;
 
-   if (f2fs_init_extent_tree(inode, &ri->i_ext))
-   set

[PATCH 5/5] f2fs: show more debug info for per-temperature log

2020-06-17 Thread Chao Yu
- Add to account and show per-log dirty_seg, full_seg and valid_blocks
in debugfs.
- reformat printed info.

TYPEsegnosecno   zoneno  dirty_seg   full_seg  valid_blk
  - COLD   data: 1523 1523 1523  1  0399
  - WARM   data:  769  769  769 20255 133098
  - HOTdata:  767  767  767  9  0167
  - Dir   dnode:   22   22   22  3  0 70
  - File  dnode:  722  722  722 14 10   6505
  - Indir nodes:222  1  0  3

Signed-off-by: Chao Yu 
---
 fs/f2fs/debug.c | 67 -
 fs/f2fs/f2fs.h  |  3 +++
 2 files changed, 58 insertions(+), 12 deletions(-)

diff --git a/fs/f2fs/debug.c b/fs/f2fs/debug.c
index 0dbcb0f9c019..aa1fd2de11ba 100644
--- a/fs/f2fs/debug.c
+++ b/fs/f2fs/debug.c
@@ -174,6 +174,29 @@ static void update_general_status(struct f2fs_sb_info *sbi)
for (i = META_CP; i < META_MAX; i++)
si->meta_count[i] = atomic_read(&sbi->meta_count[i]);
 
+   for (i = 0; i < NO_CHECK_TYPE; i++) {
+   si->dirty_seg[i] = 0;
+   si->full_seg[i] = 0;
+   si->valid_blks[i] = 0;
+   }
+
+   for (i = 0; i < MAIN_SEGS(sbi); i++) {
+   int blks = get_seg_entry(sbi, i)->valid_blocks;
+   int type = get_seg_entry(sbi, i)->type;
+
+   if (!blks)
+   continue;
+
+   if (IS_CURSEG(sbi, i))
+   continue;
+
+   if (blks == sbi->blocks_per_seg)
+   si->full_seg[type]++;
+   else
+   si->dirty_seg[type]++;
+   si->valid_blks[type] += blks;
+   }
+
for (i = 0; i < 2; i++) {
si->segment_count[i] = sbi->segment_count[i];
si->block_count[i] = sbi->block_count[i];
@@ -329,30 +352,50 @@ static int stat_show(struct seq_file *s, void *v)
seq_printf(s, "\nMain area: %d segs, %d secs %d zones\n",
   si->main_area_segs, si->main_area_sections,
   si->main_area_zones);
-   seq_printf(s, "  - COLD  data: %d, %d, %d\n",
+   seq_printf(s, "TYPE %8s %8s %8s %10s %10s %10s\n",
+  "segno", "secno", "zoneno", "dirty_seg", "full_seg", 
"valid_blk");
+   seq_printf(s, "  - COLD   data: %8d %8d %8d %10u %10u %10u\n",
   si->curseg[CURSEG_COLD_DATA],
   si->cursec[CURSEG_COLD_DATA],
-  si->curzone[CURSEG_COLD_DATA]);
-   seq_printf(s, "  - WARM  data: %d, %d, %d\n",
+  si->curzone[CURSEG_COLD_DATA],
+  si->dirty_seg[CURSEG_COLD_DATA],
+  si->full_seg[CURSEG_COLD_DATA],
+  si->valid_blks[CURSEG_COLD_DATA]);
+   seq_printf(s, "  - WARM   data: %8d %8d %8d %10u %10u %10u\n",
   si->curseg[CURSEG_WARM_DATA],
   si->cursec[CURSEG_WARM_DATA],
-  si->curzone[CURSEG_WARM_DATA]);
-   seq_printf(s, "  - HOT   data: %d, %d, %d\n",
+  si->curzone[CURSEG_WARM_DATA],
+  si->dirty_seg[CURSEG_WARM_DATA],
+  si->full_seg[CURSEG_WARM_DATA],
+  si->valid_blks[CURSEG_WARM_DATA]);
+   seq_printf(s, "  - HOTdata: %8d %8d %8d %10u %10u %10u\n",
   si->curseg[CURSEG_HOT_DATA],
   si->cursec[CURSEG_HOT_DATA],
-  si->curzone[CURSEG_HOT_DATA]);
-   seq_printf(s, "  - Dir   dnode: %d, %d, %d\n",
+  si->curzone[CURSEG_HOT_DATA],
+  si->dirty_seg[CURSEG_HOT_DATA],
+  si->full_seg[CURSEG_HOT_DATA],
+  si->valid_blks[CURSEG_HOT_DATA]);
+   seq_printf(s, "  - Dir   dnode: %8d %8d %8d %10u %10u %10u\n",
   si->curseg[CURSEG_HOT_NODE],
   si->cursec[CURSEG_HOT_NODE],
-  si->curzone[CURSEG_HOT_NODE]);
-   seq_printf(s, "  - File   dnode: %d, %d, %d\n",
+  si->curzone[CURSEG_HOT_NODE],
+  si->dirty_seg[CURSEG_HOT_NODE],
+  si->full_seg[CURSEG_HOT_NODE],
+  si->valid_blks[CURSEG_HOT_NODE]);
+   seq_printf(s, "  - File  dnode: %8d %8d %8d %10u %10u %10u\n",
   si->curseg[CURSEG_WARM_NODE],
   si->cursec[CURSEG_WARM_NODE],
-  si->curzone[CURSEG_WARM_NODE]);
-   seq_printf(s, "  

[PATCH 4/5] f2fs: clean up parameter of f2fs_allocate_data_block()

2020-06-17 Thread Chao Yu
Use validation of @fio to inidcate whether caller want to serialize IOs
in io.io_list or not, then @add_list will be redundant, remove it.

Signed-off-by: Chao Yu 
---
 fs/f2fs/data.c| 2 +-
 fs/f2fs/f2fs.h| 2 +-
 fs/f2fs/gc.c  | 2 +-
 fs/f2fs/segment.c | 6 +++---
 4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index cbdf062d3562..dfd322515357 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -1366,7 +1366,7 @@ static int __allocate_data_block(struct dnode_of_data 
*dn, int seg_type)
set_summary(&sum, dn->nid, dn->ofs_in_node, ni.version);
old_blkaddr = dn->data_blkaddr;
f2fs_allocate_data_block(sbi, NULL, old_blkaddr, &dn->data_blkaddr,
-   &sum, seg_type, NULL, false);
+   &sum, seg_type, NULL);
if (GET_SEGNO(sbi, old_blkaddr) != NULL_SEGNO)
invalidate_mapping_pages(META_MAPPING(sbi),
old_blkaddr, old_blkaddr);
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index b74f0f5fcf3a..72a667f1d678 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -3350,7 +3350,7 @@ void f2fs_replace_block(struct f2fs_sb_info *sbi, struct 
dnode_of_data *dn,
 void f2fs_allocate_data_block(struct f2fs_sb_info *sbi, struct page *page,
block_t old_blkaddr, block_t *new_blkaddr,
struct f2fs_summary *sum, int type,
-   struct f2fs_io_info *fio, bool add_list);
+   struct f2fs_io_info *fio);
 void f2fs_wait_on_page_writeback(struct page *page,
enum page_type type, bool ordered, bool locked);
 void f2fs_wait_on_block_writeback(struct inode *inode, block_t blkaddr);
diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index 3d27b939627e..bfc4eb2d8038 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -859,7 +859,7 @@ static int move_data_block(struct inode *inode, block_t 
bidx,
}
 
f2fs_allocate_data_block(fio.sbi, NULL, fio.old_blkaddr, &newaddr,
-   &sum, CURSEG_COLD_DATA, NULL, false);
+   &sum, CURSEG_COLD_DATA, NULL);
 
fio.encrypted_page = f2fs_pagecache_get_page(META_MAPPING(fio.sbi),
newaddr, FGP_LOCK | FGP_CREAT, GFP_NOFS);
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index cb861ed98ee3..113114f98087 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -3089,7 +3089,7 @@ static int __get_segment_type(struct f2fs_io_info *fio)
 void f2fs_allocate_data_block(struct f2fs_sb_info *sbi, struct page *page,
block_t old_blkaddr, block_t *new_blkaddr,
struct f2fs_summary *sum, int type,
-   struct f2fs_io_info *fio, bool add_list)
+   struct f2fs_io_info *fio)
 {
struct sit_info *sit_i = SIT_I(sbi);
struct curseg_info *curseg = CURSEG_I(sbi, type);
@@ -3157,7 +3157,7 @@ void f2fs_allocate_data_block(struct f2fs_sb_info *sbi, 
struct page *page,
if (F2FS_IO_ALIGNED(sbi))
fio->retry = false;
 
-   if (add_list) {
+   if (fio) {
struct f2fs_bio_info *io;
 
INIT_LIST_HEAD(&fio->list);
@@ -3206,7 +3206,7 @@ static void do_write_page(struct f2fs_summary *sum, 
struct f2fs_io_info *fio)
down_read(&fio->sbi->io_order_lock);
 reallocate:
f2fs_allocate_data_block(fio->sbi, fio->page, fio->old_blkaddr,
-   &fio->new_blkaddr, sum, type, fio, true);
+   &fio->new_blkaddr, sum, type, fio);
if (GET_SEGNO(fio->sbi, fio->old_blkaddr) != NULL_SEGNO)
invalidate_mapping_pages(META_MAPPING(fio->sbi),
fio->old_blkaddr, fio->old_blkaddr);
-- 
2.18.0.rc1



[PATCH 3/5] f2fs: shrink node_write lock coverage

2020-06-17 Thread Chao Yu
- to avoid race between checkpoint and quota file writeback, it
just needs to hold read lock of node_write in writeback path.
- node_write lock has covered all LFS data write paths, it's not
necessary, we only need to hold node_write lock at write path of
quota file.

Signed-off-by: Chao Yu 
---
 fs/f2fs/compress.c | 18 +++---
 fs/f2fs/data.c | 12 
 fs/f2fs/segment.c  | 11 ---
 3 files changed, 27 insertions(+), 14 deletions(-)

diff --git a/fs/f2fs/compress.c b/fs/f2fs/compress.c
index 36b51795b0c3..3ff6c0305ec6 100644
--- a/fs/f2fs/compress.c
+++ b/fs/f2fs/compress.c
@@ -1096,8 +1096,16 @@ static int f2fs_write_compressed_pages(struct 
compress_ctx *cc,
loff_t psize;
int i, err;
 
-   if (!IS_NOQUOTA(inode) && !f2fs_trylock_op(sbi))
+   if (IS_NOQUOTA(inode)) {
+   /*
+* We need to wait for node_write to avoid block allocation 
during
+* checkpoint. This can only happen to quota writes which can 
cause
+* the below discard race condition.
+*/
+   down_read(&sbi->node_write);
+   } else if (!f2fs_trylock_op(sbi)) {
return -EAGAIN;
+   }
 
set_new_dnode(&dn, cc->inode, NULL, NULL, 0);
 
@@ -1203,7 +1211,9 @@ static int f2fs_write_compressed_pages(struct 
compress_ctx *cc,
set_inode_flag(inode, FI_FIRST_BLOCK_WRITTEN);
 
f2fs_put_dnode(&dn);
-   if (!IS_NOQUOTA(inode))
+   if (IS_NOQUOTA(inode))
+   up_read(&sbi->node_write);
+   else
f2fs_unlock_op(sbi);
 
spin_lock(&fi->i_size_lock);
@@ -1230,7 +1240,9 @@ static int f2fs_write_compressed_pages(struct 
compress_ctx *cc,
 out_put_dnode:
f2fs_put_dnode(&dn);
 out_unlock_op:
-   if (!IS_NOQUOTA(inode))
+   if (IS_NOQUOTA(inode))
+   up_read(&sbi->node_write);
+   else
f2fs_unlock_op(sbi);
return -EAGAIN;
 }
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index c78ce08f6400..cbdf062d3562 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -2719,8 +2719,20 @@ int f2fs_write_single_data_page(struct page *page, int 
*submitted,
 
/* Dentry/quota blocks are controlled by checkpoint */
if (S_ISDIR(inode->i_mode) || IS_NOQUOTA(inode)) {
+   /*
+* We need to wait for node_write to avoid block allocation 
during
+* checkpoint. This can only happen to quota writes which can 
cause
+* the below discard race condition.
+*/
+   if (IS_NOQUOTA(inode))
+   down_read(&sbi->node_write);
+
fio.need_lock = LOCK_DONE;
err = f2fs_do_write_data_page(&fio);
+
+   if (IS_NOQUOTA(inode))
+   up_read(&sbi->node_write);
+
goto done;
}
 
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 5b2a6f865a6d..cb861ed98ee3 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -3107,14 +3107,6 @@ void f2fs_allocate_data_block(struct f2fs_sb_info *sbi, 
struct page *page,
type = CURSEG_COLD_DATA;
}
 
-   /*
-* We need to wait for node_write to avoid block allocation during
-* checkpoint. This can only happen to quota writes which can cause
-* the below discard race condition.
-*/
-   if (IS_DATASEG(type))
-   down_write(&sbi->node_write);
-
down_read(&SM_I(sbi)->curseg_lock);
 
mutex_lock(&curseg->curseg_mutex);
@@ -3180,9 +3172,6 @@ void f2fs_allocate_data_block(struct f2fs_sb_info *sbi, 
struct page *page,
 
up_read(&SM_I(sbi)->curseg_lock);
 
-   if (IS_DATASEG(type))
-   up_write(&sbi->node_write);
-
if (put_pin_sem)
up_read(&sbi->pin_sem);
 }
-- 
2.18.0.rc1



[PATCH 2/5] f2fs: add prefix for exported symbols

2020-06-17 Thread Chao Yu
to avoid polluting global symbol namespace.

Signed-off-by: Chao Yu 
---
 fs/f2fs/compress.c |  4 ++--
 fs/f2fs/data.c | 14 +++---
 fs/f2fs/f2fs.h |  4 ++--
 fs/f2fs/file.c |  4 ++--
 fs/f2fs/gc.c   |  2 +-
 fs/f2fs/segment.c  |  2 +-
 6 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/fs/f2fs/compress.c b/fs/f2fs/compress.c
index 1e02a8c106b0..36b51795b0c3 100644
--- a/fs/f2fs/compress.c
+++ b/fs/f2fs/compress.c
@@ -949,7 +949,7 @@ static int prepare_compress_overwrite(struct compress_ctx 
*cc,
}
 
if (prealloc) {
-   __do_map_lock(sbi, F2FS_GET_BLOCK_PRE_AIO, true);
+   f2fs_do_map_lock(sbi, F2FS_GET_BLOCK_PRE_AIO, true);
 
set_new_dnode(&dn, cc->inode, NULL, NULL, 0);
 
@@ -964,7 +964,7 @@ static int prepare_compress_overwrite(struct compress_ctx 
*cc,
break;
}
 
-   __do_map_lock(sbi, F2FS_GET_BLOCK_PRE_AIO, false);
+   f2fs_do_map_lock(sbi, F2FS_GET_BLOCK_PRE_AIO, false);
}
 
if (likely(!ret)) {
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 326c63879ddc..c78ce08f6400 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -1426,7 +1426,7 @@ int f2fs_preallocate_blocks(struct kiocb *iocb, struct 
iov_iter *from)
return err;
 }
 
-void __do_map_lock(struct f2fs_sb_info *sbi, int flag, bool lock)
+void f2fs_do_map_lock(struct f2fs_sb_info *sbi, int flag, bool lock)
 {
if (flag == F2FS_GET_BLOCK_PRE_AIO) {
if (lock)
@@ -1491,7 +1491,7 @@ int f2fs_map_blocks(struct inode *inode, struct 
f2fs_map_blocks *map,
 
 next_dnode:
if (map->m_may_create)
-   __do_map_lock(sbi, flag, true);
+   f2fs_do_map_lock(sbi, flag, true);
 
/* When reading holes, we need its node page */
set_new_dnode(&dn, inode, NULL, NULL, 0);
@@ -1640,7 +1640,7 @@ int f2fs_map_blocks(struct inode *inode, struct 
f2fs_map_blocks *map,
f2fs_put_dnode(&dn);
 
if (map->m_may_create) {
-   __do_map_lock(sbi, flag, false);
+   f2fs_do_map_lock(sbi, flag, false);
f2fs_balance_fs(sbi, dn.node_changed);
}
goto next_dnode;
@@ -1666,7 +1666,7 @@ int f2fs_map_blocks(struct inode *inode, struct 
f2fs_map_blocks *map,
f2fs_put_dnode(&dn);
 unlock_out:
if (map->m_may_create) {
-   __do_map_lock(sbi, flag, false);
+   f2fs_do_map_lock(sbi, flag, false);
f2fs_balance_fs(sbi, dn.node_changed);
}
 out:
@@ -3217,7 +3217,7 @@ static int prepare_write_begin(struct f2fs_sb_info *sbi,
 
if (f2fs_has_inline_data(inode) ||
(pos & PAGE_MASK) >= i_size_read(inode)) {
-   __do_map_lock(sbi, flag, true);
+   f2fs_do_map_lock(sbi, flag, true);
locked = true;
}
 
@@ -3254,7 +3254,7 @@ static int prepare_write_begin(struct f2fs_sb_info *sbi,
err = f2fs_get_dnode_of_data(&dn, index, LOOKUP_NODE);
if (err || dn.data_blkaddr == NULL_ADDR) {
f2fs_put_dnode(&dn);
-   __do_map_lock(sbi, F2FS_GET_BLOCK_PRE_AIO,
+   f2fs_do_map_lock(sbi, F2FS_GET_BLOCK_PRE_AIO,
true);
WARN_ON(flag != F2FS_GET_BLOCK_PRE_AIO);
locked = true;
@@ -3270,7 +3270,7 @@ static int prepare_write_begin(struct f2fs_sb_info *sbi,
f2fs_put_dnode(&dn);
 unlock_out:
if (locked)
-   __do_map_lock(sbi, flag, false);
+   f2fs_do_map_lock(sbi, flag, false);
return err;
 }
 
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 326c12fa0da5..b74f0f5fcf3a 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -3325,7 +3325,7 @@ block_t f2fs_get_unusable_blocks(struct f2fs_sb_info 
*sbi);
 int f2fs_disable_cp_again(struct f2fs_sb_info *sbi, block_t unusable);
 void f2fs_release_discard_addrs(struct f2fs_sb_info *sbi);
 int f2fs_npages_for_summary_flush(struct f2fs_sb_info *sbi, bool for_ra);
-void allocate_segment_for_resize(struct f2fs_sb_info *sbi, int type,
+void f2fs_allocate_segment_for_resize(struct f2fs_sb_info *sbi, int type,
unsigned int start, unsigned int end);
 void f2fs_allocate_new_segments(struct f2fs_sb_info *sbi, int type);
 int f2fs_trim_fs(struct f2fs_sb_info *sbi, struct fstrim_range *range);
@@ -3448,7 +3448,7 @@ struct page *f2fs_get_lock_data_page(struct inode *inode, 
pgoff_t index,
 struct page *f2fs_get_new_data_page(struct inode *inode,
struct page *ipage, pgoff_t index, bool new_i_size);
 int f2fs_do_write_data_page(struct f2fs_io_info *fio);
-void __do_map_lock(struct f2fs_sb_info *sbi, int flag, bool lock);
+void f2fs_do_map_lock(struct f2fs_sb_info *sbi, i

Re: [PATCH V4 2/2] mmc: sdhci-msm: Use internal voltage control

2020-06-17 Thread Veerabhadrarao Badiganti



On 6/17/2020 7:46 PM, Ulf Hansson wrote:

On Wed, 17 Jun 2020 at 14:46, Veerabhadrarao Badiganti
 wrote:

Thanks for comments Uffe.

On 6/17/2020 3:04 PM, Ulf Hansson wrote:

On Tue, 16 Jun 2020 at 17:38, Veerabhadrarao Badiganti
 wrote:

On qcom SD host controllers voltage switching be done after the HW
is ready for it. The HW informs its readiness through power irq.
The voltage switching should happen only then.

Use the internal voltage switching and then control the voltage
switching using power irq.

IO-bus supply of eMMC would be kept always-on. So set the load
for this supply to configure it in LPM when eMMC is suspend state
   and in HPM when eMMC is active.

Co-developed-by: Asutosh Das 
Signed-off-by: Asutosh Das 
Co-developed-by: Vijay Viswanath 
Signed-off-by: Vijay Viswanath 
Co-developed-by: Veerabhadrarao Badiganti 
Signed-off-by: Veerabhadrarao Badiganti 
---
   drivers/mmc/host/sdhci-msm.c | 208 
+--
   1 file changed, 199 insertions(+), 9 deletions(-)

diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index 15c42b059240..8297b2142748 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -37,7 +37,9 @@
   #define CORE_PWRCTL_IO_LOW BIT(2)
   #define CORE_PWRCTL_IO_HIGHBIT(3)
   #define CORE_PWRCTL_BUS_SUCCESS BIT(0)
+#define CORE_PWRCTL_BUS_FAILBIT(1)
   #define CORE_PWRCTL_IO_SUCCESS BIT(2)
+#define CORE_PWRCTL_IO_FAIL BIT(3)
   #define REQ_BUS_OFFBIT(0)
   #define REQ_BUS_ON BIT(1)
   #define REQ_IO_LOW BIT(2)
@@ -127,6 +129,9 @@
   /* Timeout value to avoid infinite waiting for pwr_irq */
   #define MSM_PWR_IRQ_TIMEOUT_MS 5000

+/* Max load for eMMC Vdd-io supply */
+#define MMC_VQMMC_MAX_LOAD_UA  325000
+
   #define msm_host_readl(msm_host, host, offset) \
  msm_host->var_ops->msm_readl_relaxed(host, offset)

@@ -278,6 +283,7 @@ struct sdhci_msm_host {
  bool uses_tassadar_dll;
  u32 dll_config;
  u32 ddr_config;
+   bool vqmmc_enabled;
   };

   static const struct sdhci_msm_offset *sdhci_priv_msm_offset(struct 
sdhci_host *host)
@@ -1346,6 +1352,88 @@ static void sdhci_msm_set_uhs_signaling(struct 
sdhci_host *host,
  sdhci_msm_hs400(host, &mmc->ios);
   }

+static int sdhci_msm_set_vmmc(struct mmc_host *mmc)
+{
+   if (IS_ERR(mmc->supply.vmmc))
+   return 0;
+
+   return mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, mmc->ios.vdd);
+}
+
+static int msm_toggle_vqmmc(struct sdhci_msm_host *msm_host,
+ struct mmc_host *mmc, bool level)
+{
+   int ret;
+   struct mmc_ios ios;
+
+   if (msm_host->vqmmc_enabled == level)
+   return 0;
+
+   if (level) {
+   /* Set the IO voltage regulator to default voltage level */
+   if (msm_host->caps_0 & CORE_3_0V_SUPPORT)
+   ios.signal_voltage = MMC_SIGNAL_VOLTAGE_330;
+   else if (msm_host->caps_0 & CORE_1_8V_SUPPORT)
+   ios.signal_voltage = MMC_SIGNAL_VOLTAGE_180;
+
+   if (msm_host->caps_0 & CORE_VOLT_SUPPORT) {
+   ret = mmc_regulator_set_vqmmc(mmc, &ios);
+   if (ret < 0) {
+   dev_err(mmc_dev(mmc), "%s: vqmmc set volgate failed: 
%d\n",
+   mmc_hostname(mmc), ret);
+   goto out;
+   }
+   }
+   ret = regulator_enable(mmc->supply.vqmmc);
+   } else {
+   ret = regulator_disable(mmc->supply.vqmmc);
+   }
+
+   if (ret)
+   dev_err(mmc_dev(mmc), "%s: vqmm %sable failed: %d\n",
+   mmc_hostname(mmc), level ? "en":"dis", ret);
+   else
+   msm_host->vqmmc_enabled = level;
+out:
+   return ret;
+}
+
+static int msm_config_vqmmc_mode(struct sdhci_msm_host *msm_host,
+ struct mmc_host *mmc, bool hpm)
+{
+   int load, ret;
+
+   load = hpm ? MMC_VQMMC_MAX_LOAD_UA : 0;
+   ret = regulator_set_load(mmc->supply.vqmmc, load);
+   if (ret)
+   dev_err(mmc_dev(mmc), "%s: vqmmc set load failed: %d\n",
+   mmc_hostname(mmc), ret);
+   return ret;
+}
+
+static int sdhci_msm_set_vqmmc(struct sdhci_msm_host *msm_host,
+ struct mmc_host *mmc, bool level)
+{
+   int ret;
+   bool always_on;
+
+   if (IS_ERR(mmc->supply.vqmmc)   ||

White space.


+   (mmc->ios.power_mode == MMC_POWER_UNDEFINED))
+   return 0;
+   /*
+* For eMMC don't turn off Vqmmc, Instead just configure it in LPM
+* and HPM modes by setting the right amonut of load.

/s/right amonut of load/corresponding load


+*/
+   always_on = mmc->card && mmc_card_mmc(mmc->card);
+
+   if (always_on)
+   ret = msm_c

Re: [PATCH net-next 0/3] add MP_PRIO, MP_FAIL and MP_FASTCLOSE suboptions handling

2020-06-17 Thread Geliang Tang
On Tue, Jun 16, 2020 at 05:18:56PM +0200, Matthieu Baerts wrote:
> Hi Geliang
> 
> On 16/06/2020 08:47, Geliang Tang wrote:
> > Add handling for sending and receiving the MP_PRIO, MP_FAIL, and
> > MP_FASTCLOSE suboptions.
> 
> Thank you for the patches!
> 
> Unfortunately, I don't think it would be wise to accept them now: for the
> moment, these suboptions are ignored at the reception. If we accept them and
> change some variables like you did, we would need to make sure the kernel is
> still acting correctly. In other words, we would need tests:
> * For MP_PRIO, there are still quite some works to do regarding the
> scheduling of the packets between the different MPTCP subflows to do before
> supporting this.
> * For MP_FAIL, we should forward the info to the path manager.
> * For MP_FASTCLOSE, we should close connections and ACK this.
> 
> Also, net-next is closed for the moment:
> http://vger.kernel.org/~davem/net-next.html
> 
> I would suggest you to discuss about that on MPTCP mailing list. We also
> have meetings every Thursday. New devs are always welcome to contribute to
> new features and bug-fixes!
> 

Hi Matt,

Thanks for your reply. I will do these tests and improve my patches.

-Geliang

> Cheers,
> Matt
> -- 
> Tessares | Belgium | Hybrid Access Solutions
> www.tessares.net


[RESEND PATCH] drm/msm/dpu: fix error return code in dpu_encoder_init

2020-06-17 Thread Chen Tao
Fix to return negative error code -ENOMEM with the use of
ERR_PTR from dpu_encoder_init.

Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Chen Tao 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index a1b79ee2bd9d..a2f6b688a976 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -2173,7 +2173,7 @@ struct drm_encoder *dpu_encoder_init(struct drm_device 
*dev,
 
dpu_enc = devm_kzalloc(dev->dev, sizeof(*dpu_enc), GFP_KERNEL);
if (!dpu_enc)
-   return ERR_PTR(ENOMEM);
+   return ERR_PTR(-ENOMEM);
 
rc = drm_encoder_init(dev, &dpu_enc->base, &dpu_encoder_funcs,
drm_enc_mode, NULL);
-- 
2.22.0



RE: [RFC PATCH v2 3/5] scsi: ufs: Introduce HPB module

2020-06-17 Thread Avri Altman
 
> 
> > > > implemented
> > > > > as a module parameter, so that it can be configurable by the
> > > > > user.
> > > > >
> > > > > To gurantee a minimum memory pool size of 4MB:
> > > > > $ insmod ufshpb.ko ufshpb_host_map_kbytes=4096
> > > >
> > > > You are going through a lot of troubles to make it a loadable
> > > > module.
> > > > What are, in your opinion, the pros and cons of this design
> > > > decision?
> > >
> > > In my opinion...
> > >
> > > pros:
> > > 1. A user can unload an unnecessary module when there is an
> > > insufficient
> > > memory situation (HPB case).
> > > 2. Since each UFS vendor has a different way of implementing UFS
> > > features,
> > > it can be supported as a separate module. Otherwise, many quirks must
> > > be attached to module, which is not desirable way.
> > > 3. It is possible to distinguish parts that are not necessary for
> > > essential
> > > ufs operation.
> > > 4. It is advantageous to implement the latest functions according to
> > > the
> > > development speed of UFS.
> > >
> > > cons:
> > > 1. It is difficult work to be implemented as a module.
> > > 2. Modifying "ufsfeature.c" is required to implement the feature that
> > > can
> > > not supported by the exsiting "ufsf_operation".
> > >
> > > Thanks,
> > > Daejun
> >
> > Dear Avri, Daejun, Bart
> >
> > It is true that it is very difficult to make everyone happy.
> > We now have three HPB drivers in the patchwork, but I still didn't see
> > a final agreement. Please tell me which one do you want to focus on?
> The HPB driver has been greatly improved in the process of being applied to
> mobile devices since the release of the first HPB version in openMPDK. We
> want to contribute to the linux mainline with the knowledge obtained
> through the experience.
> I find it difficult to make everyone happy, but I think it is possible that
> everyone can accept the HPB driver through several revisions.
Ack on that.
For me, it was very clear that Bart prefers the Samsung approach,
Hence I withdrew from my RFC and switch to support Daejun's.

Thanks,
Avri


Re: [PATCH 4/4] pci: export untrusted attribute in sysfs

2020-06-17 Thread Greg Kroah-Hartman
On Wed, Jun 17, 2020 at 12:53:03PM -0700, Rajat Jain wrote:
> Hi Greg, Christoph,
> 
> On Wed, Jun 17, 2020 at 12:31 AM Christoph Hellwig  wrote:
> >
> > On Tue, Jun 16, 2020 at 12:27:35PM -0700, Rajat Jain wrote:
> > > Need clarification. The flag "untrusted" is currently a part of
> > > pci_dev struct, and is populated within the PCI subsystem.
> >
> > Yes, and that is the problem.
> >
> > >
> > > 1) Is your suggestion to move this flag as well as the attribute to
> > > device core (in "struct device")? This would allow other buses to
> > > populate/use this flag if they want. By default it'll be set to 0 for
> > > all devices (PCI subsystem will populate it based on platform info,
> > > like it does today).
> > >
> > > OR
> > >
> > > 2) Are you suggesting to keep the "untrusted" flag within PCI, but
> > > attach the sysfs attribute to the base device? (&pci_dev->dev)?
> >
> > (1).  As for IOMMUs and userspace policy it really should not matter
> > what bus a device is on if it is external and not trustworthy.
> 
> Sure. I can move the flag to the "struct device" (and likely call
> it "external" instead of "untrusted" so as to make it suitable for
> more use cases later).  The buses can fill this up if they know which
> devices are external and which ones are not (otherwise it will be 0 by
> default). The PCI can fill this up like it does today, from platform
> info (ACPI / Device tree). Greg, how does this sound?

That's fine, convert USB over to use it at the same time if you get the
chance :)

thanks,

greg k-h


Re: [LKP] Re: [mm] 1431d4d11a: vm-scalability.throughput -11.5% regression

2020-06-17 Thread Xing Zhengjun




On 6/16/2020 10:45 PM, Johannes Weiner wrote:

On Tue, Jun 16, 2020 at 03:57:50PM +0800, kernel test robot wrote:

Greeting,

FYI, we noticed a -11.5% regression of vm-scalability.throughput due to commit:


commit: 1431d4d11abb265e79cd44bed2f5ea93f1bcc57b ("mm: base LRU balancing on an 
explicit cost model")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master


That's a really curious result.

An bit of an increase in system time is expected in the series as a
whole:

1. When thrashing is detected in the file cache, it intentionally
makes more effort to find reclaimable anon pages than before - in an
effort to converge on a stable state that has *neither* page reclaim
nor refault IO.

2. There are a couple of XXX about unrealized lock batching
opportunities. Those weren't/aren't expected to have too much of a
practical impact, and require a bit more infrastructure work that
would have interferred with other ongoing work in the area.

However, this patch in particular doesn't add any locked sections (it
adds a function call to an existing one, I guess?), and the workload
is doing streaming mmapped IO and shouldn't experience any thrashing.

In addition, we shouldn't even scan anon pages - from below:


swap_partitions:
rootfs_partition: "/dev/disk/by-id/wwn-0x5000c50067b47753-part1"


Does that mean that no swap space (not even a file) is configured?



In this case, the swap is disabled (if enabled, you should find the 
"swap:" in the job file), "swap_patitions:" is just the description of 
the hardware.



in testcase: vm-scalability
on test machine: 160 threads Intel(R) Xeon(R) CPU E7-8890 v4 @ 2.20GHz with 
256G memory
with following parameters:

runtime: 300s
test: lru-file-mmap-read
cpufreq_governor: performance
ucode: 0xb38

test-description: The motivation behind this suite is to exercise functions and 
regions of the mm/ of the Linux kernel which are of interest to us.
test-url: https://git.kernel.org/cgit/linux/kernel/git/wfg/vm-scalability.git/



If you fix the issue, kindly add following tag
Reported-by: kernel test robot 


Details are as below:
-->


To reproduce:

 git clone https://github.com/intel/lkp-tests.git
 cd lkp-tests
 bin/lkp install job.yaml  # job file is attached in this email
 bin/lkp run job.yaml

=
compiler/cpufreq_governor/kconfig/rootfs/runtime/tbox_group/test/testcase/ucode:
   
gcc-9/performance/x86_64-rhel-7.6/debian-x86_64-20191114.cgz/300s/lkp-bdw-ex2/lru-file-mmap-read/vm-scalability/0xb38

commit:
   a4fe1631f3 ("mm: vmscan: drop unnecessary div0 avoidance rounding in 
get_scan_count()")
   1431d4d11a ("mm: base LRU balancing on an explicit cost model")

a4fe1631f313f75c 1431d4d11abb265e79cd44bed2f
 ---
  %stddev %change %stddev
  \  |\
   0.23 ±  2% +11.7%   0.26vm-scalability.free_time


What's free_time?


The average of the time to free memory(unit: second) , you can see the 
output of vm-scalability( 
https://git.kernel.org/cgit/linux/kernel/git/wfg/vm-scalability.git/) 
benchamrk log "xxx usecs to free memory"



 103991   -11.6%  91935vm-scalability.median
   20717269   -11.5%   18336098vm-scalability.throughput
 376.47+8.3% 407.78vm-scalability.time.elapsed_time
 376.47+8.3% 407.78
vm-scalability.time.elapsed_time.max
 392226+7.2% 420612
vm-scalability.time.involuntary_context_switches
  11731+4.4%  12247
vm-scalability.time.percent_of_cpu_this_job_got
  41005   +14.5%  46936vm-scalability.time.system_time
   3156-4.8%   3005vm-scalability.time.user_time
   52662860 ±  5% -14.0%   45266760 ±  5%  meminfo.DirectMap2M
   4.43-0.53.90 ±  2%  mpstat.cpu.all.usr%
   1442 ±  5% -14.9%   1227 ± 10%  
slabinfo.kmalloc-rcl-96.active_objs
   1442 ±  5% -14.9%   1227 ± 10%  slabinfo.kmalloc-rcl-96.num_objs
  37.50 ±  2%  -7.3%  34.75vmstat.cpu.id
  57.25+5.2%  60.25vmstat.cpu.sy
  54428 ± 60% -96.5%   1895 ±173%  numa-meminfo.node1.AnonHugePages
 116516 ± 48% -88.2%  13709 ± 26%  numa-meminfo.node1.AnonPages
 132303 ± 84% -88.9%  14731 ± 61%  numa-meminfo.node3.Inactive(anon)


These counters capture present state, not history. Are these averages
or snapshots? If snapshots, when are they taken during the test?


These are averages.




 311.75 ±  8% +16.0% 361.75 ±  2%  
numa-vmstat.node0.nr_isolated_file
  29136 ± 48% -

[PATCH 1/5] ARM: dts: imx6sx: Enable ASRC device

2020-06-17 Thread Shengjiu Wang
Add compatible string, update the clock table,
add fsl,asrc-rate and fsl,asrc-width property.

Signed-off-by: Shengjiu Wang 
---
 arch/arm/boot/dts/imx6sx.dtsi | 26 ++
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index 94e3df47d1ad..7d4856ffd239 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -390,18 +390,28 @@
};
 
asrc: asrc@2034000 {
+   compatible = "fsl,imx6sx-asrc", 
"fsl,imx53-asrc";
reg = <0x02034000 0x4000>;
interrupts = ;
-   clocks = <&clks IMX6SX_CLK_ASRC_MEM>,
-<&clks IMX6SX_CLK_ASRC_IPG>,
-<&clks IMX6SX_CLK_SPDIF>,
-<&clks IMX6SX_CLK_SPBA>;
-   clock-names = "mem", "ipg", "asrck", 
"spba";
-   dmas = <&sdma 17 20 1>, <&sdma 18 20 1>,
-  <&sdma 19 20 1>, <&sdma 20 20 1>,
-  <&sdma 21 20 1>, <&sdma 22 20 1>;
+   clocks = <&clks IMX6SX_CLK_ASRC_IPG>,
+   <&clks IMX6SX_CLK_ASRC_MEM>, 
<&clks 0>,
+   <&clks 0>, <&clks 0>, <&clks 
0>, <&clks 0>,
+   <&clks 0>, <&clks 0>, <&clks 
0>, <&clks 0>,
+   <&clks 0>, <&clks 0>, <&clks 
0>, <&clks 0>,
+   <&clks IMX6SX_CLK_SPDIF>, 
<&clks 0>, <&clks 0>,
+   <&clks IMX6SX_CLK_SPBA>;
+   clock-names = "mem", "ipg", "asrck_0",
+   "asrck_1", "asrck_2", 
"asrck_3", "asrck_4",
+   "asrck_5", "asrck_6", 
"asrck_7", "asrck_8",
+   "asrck_9", "asrck_a", 
"asrck_b", "asrck_c",
+   "asrck_d", "asrck_e", 
"asrck_f", "spba";
+   dmas = <&sdma 17 23 1>, <&sdma 18 23 1>,
+  <&sdma 19 23 1>, <&sdma 20 23 1>,
+  <&sdma 21 23 1>, <&sdma 22 23 1>;
dma-names = "rxa", "rxb", "rxc",
"txa", "txb", "txc";
+   fsl,asrc-rate  = <48000>;
+   fsl,asrc-width = <16>;
status = "okay";
};
};
-- 
2.21.0



[PATCH 3/5] ARM: dts: imx6sx-sdb: Add SPDIF support

2020-06-17 Thread Shengjiu Wang
Add SPDIF support.

Signed-off-by: Shengjiu Wang 
---
 arch/arm/boot/dts/imx6sx-sdb.dtsi | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm/boot/dts/imx6sx-sdb.dtsi 
b/arch/arm/boot/dts/imx6sx-sdb.dtsi
index 69a502b369c5..976fa8691007 100644
--- a/arch/arm/boot/dts/imx6sx-sdb.dtsi
+++ b/arch/arm/boot/dts/imx6sx-sdb.dtsi
@@ -179,6 +179,15 @@
};
};
};
+
+   sound-spdif {
+   compatible = "fsl,imx-audio-spdif",
+  "fsl,imx6sx-sdb-spdif";
+   model = "imx-spdif";
+   spdif-controller = <&spdif>;
+   spdif-out;
+   };
+
 };
 
 &audmux {
@@ -296,6 +305,14 @@
status = "disabled";
 };
 
+&spdif {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_spdif>;
+   assigned-clocks = <&clks IMX6SX_CLK_SPDIF_PODF>;
+   assigned-clock-rates = <24576000>;
+   status = "okay";
+};
+
 &ssi2 {
status = "okay";
 };
@@ -569,6 +586,12 @@
>;
};
 
+   pinctrl_spdif: spdifgrp {
+   fsl,pins = <
+   MX6SX_PAD_SD4_DATA4__SPDIF_OUT  0x1b0b0
+   >;
+   };
+
pinctrl_uart1: uart1grp {
fsl,pins = <
MX6SX_PAD_GPIO1_IO04__UART1_DCE_TX  0x1b0b1
-- 
2.21.0



[PATCH 5/5] ARM: dts: imx6sx-sabreauto: Add cs42888 sound card support

2020-06-17 Thread Shengjiu Wang
Complete the ESAI node and Add cs42888 sound card support.

Signed-off-by: Shengjiu Wang 
---
 arch/arm/boot/dts/imx6sx-sabreauto.dts | 75 ++
 arch/arm/boot/dts/imx6sx.dtsi  |  4 ++
 2 files changed, 79 insertions(+)

diff --git a/arch/arm/boot/dts/imx6sx-sabreauto.dts 
b/arch/arm/boot/dts/imx6sx-sabreauto.dts
index 772b8ac5d637..76a4c06e0ff2 100644
--- a/arch/arm/boot/dts/imx6sx-sabreauto.dts
+++ b/arch/arm/boot/dts/imx6sx-sabreauto.dts
@@ -67,6 +67,36 @@
vin-supply = <®_can_en>;
};
 
+   reg_cs42888: cs42888_supply {
+   compatible = "regulator-fixed";
+   regulator-name = "cs42888_supply";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-always-on;
+   };
+
+   sound-cs42888 {
+   compatible = "fsl,imx6-sabreauto-cs42888",
+"fsl,imx-audio-cs42888";
+   model = "imx-cs42888";
+   audio-cpu = <&esai>;
+   audio-asrc = <&asrc>;
+   audio-codec = <&cs42888>;
+   audio-routing =
+   "Line Out Jack", "AOUT1L",
+   "Line Out Jack", "AOUT1R",
+   "Line Out Jack", "AOUT2L",
+   "Line Out Jack", "AOUT2R",
+   "Line Out Jack", "AOUT3L",
+   "Line Out Jack", "AOUT3R",
+   "Line Out Jack", "AOUT4L",
+   "Line Out Jack", "AOUT4R",
+   "AIN1L", "Line In Jack",
+   "AIN1R", "Line In Jack",
+   "AIN2L", "Line In Jack",
+   "AIN2R", "Line In Jack";
+   };
+
sound-spdif {
compatible = "fsl,imx-audio-spdif";
model = "imx-spdif";
@@ -79,6 +109,25 @@
clock-frequency = <24576000>;
 };
 
+&clks {
+   assigned-clocks = <&clks IMX6SX_PLL4_BYPASS_SRC>,
+ <&clks IMX6SX_PLL4_BYPASS>,
+ <&clks IMX6SX_CLK_PLL4_POST_DIV>;
+   assigned-clock-parents = <&clks IMX6SX_CLK_LVDS2_IN>,
+<&clks IMX6SX_PLL4_BYPASS_SRC>;
+   assigned-clock-rates = <0>, <0>, <24576000>;
+};
+
+&esai {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_esai>;
+   assigned-clocks = <&clks IMX6SX_CLK_ESAI_SEL>,
+   <&clks IMX6SX_CLK_ESAI_EXTAL>;
+   assigned-clock-parents = <&clks IMX6SX_CLK_PLL4_AUDIO_DIV>;
+   assigned-clock-rates = <0>, <24576000>;
+   status = "okay";
+};
+
 &fec1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_enet1>;
@@ -200,6 +249,21 @@
>;
};
 
+   pinctrl_esai: esaigrp {
+   fsl,pins = <
+   MX6SX_PAD_CSI_DATA00__ESAI_TX_CLK   0x1b030
+   MX6SX_PAD_CSI_DATA01__ESAI_TX_FS0x1b030
+   MX6SX_PAD_CSI_HSYNC__ESAI_TX0   0x1b030
+   MX6SX_PAD_CSI_DATA04__ESAI_TX1  0x1b030
+   MX6SX_PAD_CSI_DATA06__ESAI_TX2_RX3  0x1b030
+   MX6SX_PAD_CSI_DATA07__ESAI_TX3_RX2  0x1b030
+   MX6SX_PAD_CSI_DATA02__ESAI_RX_CLK   0x1b030
+   MX6SX_PAD_CSI_DATA03__ESAI_RX_FS0x1b030
+   MX6SX_PAD_CSI_VSYNC__ESAI_TX5_RX0   0x1b030
+   MX6SX_PAD_CSI_DATA05__ESAI_TX4_RX1  0x1b030
+   >;
+   };
+
pinctrl_flexcan1: flexcan1grp {
fsl,pins = <
MX6SX_PAD_QSPI1B_DQS__CAN1_TX   0x1b020
@@ -326,6 +390,17 @@
pinctrl-0 = <&pinctrl_i2c2>;
status = "okay";
 
+   cs42888: cs42888@48 {
+   compatible = "cirrus,cs42888";
+   reg = <0x48>;
+   clocks = <&anaclk2 0>;
+   clock-names = "mclk";
+   VA-supply = <®_cs42888>;
+   VD-supply = <®_cs42888>;
+   VLS-supply = <®_cs42888>;
+   VLC-supply = <®_cs42888>;
+   };
+
touchscreen@4 {
compatible = "eeti,egalax_ts";
reg = <0x04>;
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index 8dc412b3862b..9f4f3c0aace5 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -341,6 +341,7 @@
};
 
esai: esai@2024000 {
+   compatible = "fsl,imx6sx-esai", 
"fsl,imx35-esai";
reg = <0x02024000 0x4000>;
interrupts = ;
clocks = <&clks IMX6SX_CLK_ESAI_IPG>,
@@ -350,6 +351,9 @@
 <&clks IMX6SX_CLK_SPBA>;
clock-names = "core", "me

[PATCH 4/5] ARM: dts: imx6sx-sabreauto: Add SPDIF support

2020-06-17 Thread Shengjiu Wang
Add SPDIF support.

Signed-off-by: Shengjiu Wang 
---
 arch/arm/boot/dts/imx6sx-sabreauto.dts | 21 +
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/boot/dts/imx6sx-sabreauto.dts 
b/arch/arm/boot/dts/imx6sx-sabreauto.dts
index 825924448ab4..772b8ac5d637 100644
--- a/arch/arm/boot/dts/imx6sx-sabreauto.dts
+++ b/arch/arm/boot/dts/imx6sx-sabreauto.dts
@@ -66,6 +66,13 @@
enable-active-high;
vin-supply = <®_can_en>;
};
+
+   sound-spdif {
+   compatible = "fsl,imx-audio-spdif";
+   model = "imx-spdif";
+   spdif-controller = <&spdif>;
+   spdif-in;
+   };
 };
 
 &anaclk2 {
@@ -227,6 +234,12 @@
>;
};
 
+   pinctrl_spdif: spdifgrp {
+   fsl,pins = <
+   MX6SX_PAD_ENET2_COL__SPDIF_IN   0x1b0b0
+   >;
+   };
+
pinctrl_uart1: uart1grp {
fsl,pins = <
MX6SX_PAD_GPIO1_IO04__UART1_DCE_TX  0x1b0b1
@@ -454,6 +467,14 @@
};
 };
 
+&spdif {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_spdif>;
+   assigned-clocks = <&clks IMX6SX_CLK_SPDIF_PODF>;
+   assigned-clock-rates = <24576000>;
+   status = "okay";
+};
+
 &wdog1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_wdog>;
-- 
2.21.0



[PATCH 2/5] ARM: dts: imx6sx-sdb: Add MQS support

2020-06-17 Thread Shengjiu Wang
Add MQS support. As the pin conflict with usdhc2, then need
to add a separate dts.

Signed-off-by: Shengjiu Wang 
---
 arch/arm/boot/dts/Makefile   |  1 +
 arch/arm/boot/dts/imx6sx-sdb-mqs.dts | 48 
 arch/arm/boot/dts/imx6sx-sdb.dtsi|  7 
 arch/arm/boot/dts/imx6sx.dtsi|  6 
 4 files changed, 62 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6sx-sdb-mqs.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e6a1cac0bfc7..04f85d6a2af3 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -592,6 +592,7 @@ dtb-$(CONFIG_SOC_IMX6SX) += \
imx6sx-sdb-reva.dtb \
imx6sx-sdb-sai.dtb \
imx6sx-sdb.dtb \
+   imx6sx-sdb-mqs.dtb \
imx6sx-softing-vining-2000.dtb \
imx6sx-udoo-neo-basic.dtb \
imx6sx-udoo-neo-extended.dtb \
diff --git a/arch/arm/boot/dts/imx6sx-sdb-mqs.dts 
b/arch/arm/boot/dts/imx6sx-sdb-mqs.dts
new file mode 100644
index ..a4ab2d3e960c
--- /dev/null
+++ b/arch/arm/boot/dts/imx6sx-sdb-mqs.dts
@@ -0,0 +1,48 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (C) 2014 Freescale Semiconductor, Inc.
+
+#include "imx6sx-sdb.dts"
+/ {
+
+   sound {
+   status = "disabled";
+   };
+
+   sound-mqs {
+   compatible = "fsl,imx6sx-sdb-mqs",
+"fsl,imx-audio-mqs";
+   model = "mqs-audio";
+   audio-cpu = <&sai1>;
+   audio-asrc = <&asrc>;
+   audio-codec = <&mqs>;
+   };
+};
+
+&usdhc2 {
+   /* pin conflict with mqs*/
+   status = "disabled";
+};
+
+&mqs {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_mqs>;
+   clocks = <&clks IMX6SX_CLK_SAI1>;
+   clock-names = "mclk";
+   status = "okay";
+};
+
+&sai1 {
+   pinctrl-0 = <>;
+   status = "okay";
+};
+
+&ssi2 {
+   status = "disabled";
+};
+
+&sdma {
+   gpr = <&gpr>;
+   /* SDMA event remap for SAI1 */
+   fsl,sdma-event-remap = <0 15 1>, <0 16 1>;
+};
diff --git a/arch/arm/boot/dts/imx6sx-sdb.dtsi 
b/arch/arm/boot/dts/imx6sx-sdb.dtsi
index 3e5fb72f21fc..69a502b369c5 100644
--- a/arch/arm/boot/dts/imx6sx-sdb.dtsi
+++ b/arch/arm/boot/dts/imx6sx-sdb.dtsi
@@ -450,6 +450,13 @@
>;
};
 
+   pinctrl_mqs: mqsgrp {
+   fsl,pins = <
+   MX6SX_PAD_SD2_CLK__MQS_RIGHT 0x120b0
+   MX6SX_PAD_SD2_CMD__MQS_LEFT  0x120b0
+   >;
+   };
+
pinctrl_i2c1: i2c1grp {
fsl,pins = <
MX6SX_PAD_GPIO1_IO01__I2C1_SDA  
0x4001b8b1
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index 7d4856ffd239..8dc412b3862b 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -134,6 +134,12 @@
clock-output-names = "anaclk2";
};
 
+   mqs: mqs {
+   compatible = "fsl,imx6sx-mqs";
+   gpr = <&gpr>;
+   status = "disabled";
+   };
+
tempmon: tempmon {
compatible = "fsl,imx6sx-tempmon", "fsl,imx6q-tempmon";
interrupt-parent = <&gpc>;
-- 
2.21.0



[PATCH 0/5] Add audio support for imx6sx platform

2020-06-17 Thread Shengjiu Wang
Add audio support for imx6sx platform.
Enable ASRC, ESAI, SPDIF, MQS.

Shengjiu Wang (5):
  ARM: dts: imx6sx: Enable ASRC device
  ARM: dts: imx6sx-sdb: Add MQS support
  ARM: dts: imx6sx-sdb: Add SPDIF support
  ARM: dts: imx6sx-sabreauto: Add SPDIF support
  ARM: dts: imx6sx-sabreauto: Add cs42888 sound card support

 arch/arm/boot/dts/Makefile |  1 +
 arch/arm/boot/dts/imx6sx-sabreauto.dts | 96 ++
 arch/arm/boot/dts/imx6sx-sdb-mqs.dts   | 48 +
 arch/arm/boot/dts/imx6sx-sdb.dtsi  | 30 
 arch/arm/boot/dts/imx6sx.dtsi  | 36 +++---
 5 files changed, 203 insertions(+), 8 deletions(-)
 create mode 100644 arch/arm/boot/dts/imx6sx-sdb-mqs.dts

-- 
2.21.0



Re: [PATCH 2/2] cpufreq: arm_scmi: Set fast_switch_possible conditionally

2020-06-17 Thread Viresh Kumar
On 17-06-20, 13:47, Sudeep Holla wrote:
> This is first step towards avoiding polling based cpufreq set if firmware
> has fast access registers that bypass normal mailbox based messaging.
> 
> If you happy with this and provide ack, I will take this along with scmi
> changes via ARM SoC. Hope that is fine by you.

Sudeep,

I am not sure how it concerns me frankly :)

AFAICT, this is enabling fast switch based on some mechanism (internal
to scmi) and so either the cpufreq driver will have fast-switch
enabled or not, and both are fine by the cpufreq core.

And so I am confused on why my Ack is important here :)

-- 
viresh


RE: [RFC PATCH v2 4/5] scsi: ufs: L2P map management for HPB read

2020-06-17 Thread Avri Altman
 
> > +
> > > +static struct ufshpb_map_ctx *ufshpb_get_map_ctx(struct ufshpb_lu
> *hpb)
> > > +{
> > > +   struct ufshpb_map_ctx *mctx;
> > > +   int i, j;
> > > +
> > > +   mctx = mempool_alloc(ufshpb_drv.ufshpb_mctx_pool, GFP_KERNEL);
> > > +   if (!mctx)
> > > +   return NULL;
> > So you use ufshpb_host_map_kbytes as the min_nr in your
> mempool_create,
> > But you know that you need max_lru_active_cnt x srgns_per_rgn such
> mapping context elements.
> > So you are
> > a) failing to provide the slab allocator an information that you already 
> > have,
> and
> > b) selecting from a finite pool will assure that you'll never exceed max-
> active-regions,
> >even if some corner case fails your logic.
> It was intend to provide user-configurable pre-allocated memory to reduce
> latency due to memory allocation. The value of ufshpb_host_map_kbytes can
> be set to max_lru_active_cnt x srgns_per_rgn, if the user want to.
Ok, I see your point.
It is as if you expect that a "user" will query the unit descriptors first,
Make some calculations, and then will run modprobe with the proper value.
Are you assuming that an "intelligent" user does all that?

The reasonable scenario IMO, is that OEMs will initiate a service in their
ramdisk/init.rc with some default value.

Don't you see the damage potential in using a wrong value here?


Re: [PATCH] [net/sched]: Remove redundant condition in qdisc_graft

2020-06-17 Thread kernel test robot
Hi Gaurav,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v5.8-rc1 next-20200617]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use  as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Gaurav-Singh/Remove-redundant-condition-in-qdisc_graft/20200618-085703
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
1b5044021070efa3259f3e9548dc35d1eb6aa844
config: s390-randconfig-r016-20200618 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 
487ca07fcc75d52755c9fe2ee05bcb3b6c44)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install s390 cross compiling tool for clang build
# apt-get install binutils-s390-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=s390 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):


vim +1097 net/sched/sch_api.c

  1019  
  1020  /* Graft qdisc "new" to class "classid" of qdisc "parent" or
  1021   * to device "dev".
  1022   *
  1023   * When appropriate send a netlink notification using 'skb'
  1024   * and "n".
  1025   *
  1026   * On success, destroy old qdisc.
  1027   */
  1028  
  1029  static int qdisc_graft(struct net_device *dev, struct Qdisc *parent,
  1030 struct sk_buff *skb, struct nlmsghdr *n, u32 
classid,
  1031 struct Qdisc *new, struct Qdisc *old,
  1032 struct netlink_ext_ack *extack)
  1033  {
  1034  struct Qdisc *q = old;
  1035  struct net *net = dev_net(dev);
  1036  
  1037  if (parent == NULL) {
  1038  unsigned int i, num_q, ingress;
  1039  
  1040  ingress = 0;
  1041  num_q = dev->num_tx_queues;
  1042  if ((q && q->flags & TCQ_F_INGRESS) ||
  1043  (new && new->flags & TCQ_F_INGRESS)) {
  1044  num_q = 1;
  1045  ingress = 1;
  1046  if (!dev_ingress_queue(dev)) {
  1047  NL_SET_ERR_MSG(extack, "Device does not 
have an ingress queue");
  1048  return -ENOENT;
  1049  }
  1050  }
  1051  
  1052  if (dev->flags & IFF_UP)
  1053  dev_deactivate(dev);
  1054  
  1055  qdisc_offload_graft_root(dev, new, old, extack);
  1056  
  1057  if (new && new->ops->attach)
  1058  goto skip;
  1059  
  1060  for (i = 0; i < num_q; i++) {
  1061  struct netdev_queue *dev_queue = 
dev_ingress_queue(dev);
  1062  
  1063  if (!ingress)
  1064  dev_queue = netdev_get_tx_queue(dev, i);
  1065  
  1066  old = dev_graft_qdisc(dev_queue, new);
  1067  if (new && i > 0)
  1068  qdisc_refcount_inc(new);
  1069  
  1070  if (!ingress)
  1071  qdisc_put(old);
  1072  }
  1073  
  1074  skip:
  1075  if (!ingress) {
  1076  notify_and_destroy(net, skb, n, classid,
  1077 dev->qdisc, new);
  1078  if (new && !new->ops->attach)
  1079  qdisc_refcount_inc(new);
  1080  dev->qdisc = new ? : &noop_qdisc;
  1081  
  1082  if (new && new->ops->attach)
  1083  new->ops->attach(new);
  1084  } else {
  1085  notify_and_destroy(net, skb, n, classid, old, 
new);
  1086  }
  1087  
  1088  if (dev->flags & IFF_UP)
  1089  dev_activate(dev);
  1090  } else {
  1091  const struct Qdisc_class_ops *cops = 
parent->ops->cl_ops;
  1092  unsigned long cl;
  1093  int err;
  1094  
  1095  /* Only support running class lockless if parent is 
lockless */
  1096  if (new && (new->flags & TCQ_F_NOLOCK) &&
> 1097  

Re: [PATCH v3] seccomp: Add find_notification helper

2020-06-17 Thread Nathan Chancellor
On Thu, Jun 18, 2020 at 05:44:14AM +, Sargun Dhillon wrote:
> On Wed, Jun 17, 2020 at 01:08:44PM -0700, Nathan Chancellor wrote:
> > On Mon, Jun 01, 2020 at 04:25:32AM -0700, Sargun Dhillon wrote:
> > > This adds a helper which can iterate through a seccomp_filter to
> > > find a notification matching an ID. It removes several replicated
> > > chunks of code.
> > > 
> > > Signed-off-by: Sargun Dhillon 
> > > Acked-by: Christian Brauner 
> > > Reviewed-by: Tycho Andersen 
> > > Cc: Matt Denton 
> > > Cc: Kees Cook ,
> > > Cc: Jann Horn ,
> > > Cc: Robert Sesek ,
> > > Cc: Chris Palmer 
> > > Cc: Christian Brauner 
> > > Cc: Tycho Andersen 
> > > ---
> > >  kernel/seccomp.c | 55 
> > >  1 file changed, 28 insertions(+), 27 deletions(-)
> > > 
> > > diff --git a/kernel/seccomp.c b/kernel/seccomp.c
> > > index 55a6184f5990..cc6b47173a95 100644
> > > --- a/kernel/seccomp.c
> > > +++ b/kernel/seccomp.c
> > > @@ -41,6 +41,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >  
> > >  enum notify_state {
> > >   SECCOMP_NOTIFY_INIT,
> > > @@ -1021,10 +1022,27 @@ static int seccomp_notify_release(struct inode 
> > > *inode, struct file *file)
> > >   return 0;
> > >  }
> > >  
> > > +/* must be called with notif_lock held */
> > > +static inline struct seccomp_knotif *
> > > +find_notification(struct seccomp_filter *filter, u64 id)
> > > +{
> > > + struct seccomp_knotif *cur;
> > > +
> > > + lockdep_assert_held(&filter->notify_lock);
> > > +
> > > + list_for_each_entry(cur, &filter->notif->notifications, list) {
> > > + if (cur->id == id)
> > > + return cur;
> > > + }
> > > +
> > > + return NULL;
> > > +}
> > > +
> > > +
> > >  static long seccomp_notify_recv(struct seccomp_filter *filter,
> > >   void __user *buf)
> > >  {
> > > - struct seccomp_knotif *knotif = NULL, *cur;
> > > + struct seccomp_knotif *knotif, *cur;
> > >   struct seccomp_notif unotif;
> > >   ssize_t ret;
> > >  
> > > @@ -1078,15 +1096,8 @@ static long seccomp_notify_recv(struct 
> > > seccomp_filter *filter,
> > >* may have died when we released the lock, so we need to make
> > >* sure it's still around.
> > >*/
> > > - knotif = NULL;
> > >   mutex_lock(&filter->notify_lock);
> > > - list_for_each_entry(cur, &filter->notif->notifications, list) {
> > > - if (cur->id == unotif.id) {
> > > - knotif = cur;
> > > - break;
> > > - }
> > > - }
> > > -
> > > + knotif = find_notification(filter, unotif.id);
> > >   if (knotif) {
> > >   knotif->state = SECCOMP_NOTIFY_INIT;
> > >   up(&filter->notif->request);
> > > @@ -1101,7 +1112,7 @@ static long seccomp_notify_send(struct 
> > > seccomp_filter *filter,
> > >   void __user *buf)
> > >  {
> > >   struct seccomp_notif_resp resp = {};
> > > - struct seccomp_knotif *knotif = NULL, *cur;
> > > + struct seccomp_knotif *knotif;
> > >   long ret;
> > >  
> > >   if (copy_from_user(&resp, buf, sizeof(resp)))
> > > @@ -1118,13 +1129,7 @@ static long seccomp_notify_send(struct 
> > > seccomp_filter *filter,
> > >   if (ret < 0)
> > >   return ret;
> > >  
> > > - list_for_each_entry(cur, &filter->notif->notifications, list) {
> > > - if (cur->id == resp.id) {
> > > - knotif = cur;
> > > - break;
> > > - }
> > > - }
> > > -
> > > + knotif = find_notification(filter, resp.id);
> > >   if (!knotif) {
> > >   ret = -ENOENT;
> > >   goto out;
> > > @@ -1150,7 +1155,7 @@ static long seccomp_notify_send(struct 
> > > seccomp_filter *filter,
> > >  static long seccomp_notify_id_valid(struct seccomp_filter *filter,
> > >   void __user *buf)
> > >  {
> > > - struct seccomp_knotif *knotif = NULL;
> > 
> > I don't know that this should have been removed, clang now warns:
> > 
> > kernel/seccomp.c:1063:2: warning: variable 'knotif' is used uninitialized 
> > whenever 'for' loop exits because its condition is false 
> > [-Wsometimes-uninitialized]
> > list_for_each_entry(cur, &filter->notif->notifications, list) {
> > ^
> > include/linux/list.h:602:7: note: expanded from macro 'list_for_each_entry'
> >  &pos->member != (head);\
> >  ^~
> > kernel/seccomp.c:1075:7: note: uninitialized use occurs here
> > if (!knotif) {
> >  ^~
> > kernel/seccomp.c:1063:2: note: remove the condition if it is always true
> > list_for_each_entry(cur, &filter->notif->notifications, list) {
> > ^
> > include/linux/list.h:602:7: note: expanded from macro 'list_for_each_entry'
> >  &pos->member != (head);  

[PATCH RFC 5/5] vdpasim: support batch updating

2020-06-17 Thread Jason Wang
The vDPA simulator support both set_map() and dma_map()/dma_unmap()
operations. But vhost-vdpa can only use one of them. So this patch
introduce a module parameter (batch_mapping) that let vpda_sim to
support only one of those dma operations. The batched mapping via
set_map() is enabled by default.

Signed-off-by: Jason Wang 
---
 drivers/vdpa/vdpa_sim/vdpa_sim.c | 40 +---
 1 file changed, 37 insertions(+), 3 deletions(-)

diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index c7334cc65bb2..a7a0962ed8a8 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -33,6 +33,10 @@
 #define DRV_DESC "vDPA Device Simulator"
 #define DRV_LICENSE  "GPL v2"
 
+static int batch_mapping = 1;
+module_param(batch_mapping, int, 0444);
+MODULE_PARM_DESC(batch_mapping, "Batched mapping 1 -Enable; 0 - Disable");
+
 struct vdpasim_virtqueue {
struct vringh vring;
struct vringh_kiov iov;
@@ -303,16 +307,22 @@ static const struct dma_map_ops vdpasim_dma_ops = {
 };
 
 static const struct vdpa_config_ops vdpasim_net_config_ops;
+static const struct vdpa_config_ops vdpasim_net_batch_config_ops;
 
 static struct vdpasim *vdpasim_create(void)
 {
+   const struct vdpa_config_ops *ops;
struct virtio_net_config *config;
struct vdpasim *vdpasim;
struct device *dev;
int ret = -ENOMEM;
 
-   vdpasim = vdpa_alloc_device(struct vdpasim, vdpa, NULL,
-   &vdpasim_net_config_ops);
+   if (batch_mapping)
+   ops = &vdpasim_net_batch_config_ops;
+   else
+   ops = &vdpasim_net_config_ops;
+
+   vdpasim = vdpa_alloc_device(struct vdpasim, vdpa, NULL, ops);
if (!vdpasim)
goto err_alloc;
 
@@ -597,12 +607,36 @@ static const struct vdpa_config_ops 
vdpasim_net_config_ops = {
.get_config = vdpasim_get_config,
.set_config = vdpasim_set_config,
.get_generation = vdpasim_get_generation,
-   .set_map= vdpasim_set_map,
.dma_map= vdpasim_dma_map,
.dma_unmap  = vdpasim_dma_unmap,
.free   = vdpasim_free,
 };
 
+static const struct vdpa_config_ops vdpasim_net_batch_config_ops = {
+   .set_vq_address = vdpasim_set_vq_address,
+   .set_vq_num = vdpasim_set_vq_num,
+   .kick_vq= vdpasim_kick_vq,
+   .set_vq_cb  = vdpasim_set_vq_cb,
+   .set_vq_ready   = vdpasim_set_vq_ready,
+   .get_vq_ready   = vdpasim_get_vq_ready,
+   .set_vq_state   = vdpasim_set_vq_state,
+   .get_vq_state   = vdpasim_get_vq_state,
+   .get_vq_align   = vdpasim_get_vq_align,
+   .get_features   = vdpasim_get_features,
+   .set_features   = vdpasim_set_features,
+   .set_config_cb  = vdpasim_set_config_cb,
+   .get_vq_num_max = vdpasim_get_vq_num_max,
+   .get_device_id  = vdpasim_get_device_id,
+   .get_vendor_id  = vdpasim_get_vendor_id,
+   .get_status = vdpasim_get_status,
+   .set_status = vdpasim_set_status,
+   .get_config = vdpasim_get_config,
+   .set_config = vdpasim_set_config,
+   .get_generation = vdpasim_get_generation,
+   .set_map= vdpasim_set_map,
+   .free   = vdpasim_free,
+};
+
 static int __init vdpasim_dev_init(void)
 {
vdpasim_dev = vdpasim_create();
-- 
2.20.1



[PATCH RFC 4/5] vhost-vdpa: support IOTLB batching hints

2020-06-17 Thread Jason Wang
This patches extend the vhost IOTLB API to accept batch updating hints
form userspace. When userspace wants update the device IOTLB in a
batch, it may do:

1) Write vhost_iotlb_msg with VHOST_IOTLB_BATCH_BEGIN flag
2) Perform a batch of IOTLB updating via VHOST_IOTLB_UPDATE/INVALIDATE
3) Write vhost_iotlb_msg with VHOST_IOTLB_BATCH_END flag

Vhost-vdpa may decide to batch the IOMMU/IOTLB updating in step 3 when
vDPA device support set_map() ops. This is useful for the vDPA device
that want to know all the mappings to tweak their own DMA translation
logic.

For vDPA device that doesn't require set_map(), no behavior changes.

This capability is advertised via VHOST_BACKEND_F_IOTLB_BATCH capability.

Signed-off-by: Jason Wang 
---
 drivers/vhost/vdpa.c | 30 +++---
 include/uapi/linux/vhost.h   |  2 ++
 include/uapi/linux/vhost_types.h |  7 +++
 3 files changed, 32 insertions(+), 7 deletions(-)

diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index 453057421f80..8f624bbafee7 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -56,7 +56,9 @@ enum {
 };
 
 enum {
-   VHOST_VDPA_BACKEND_FEATURES = (1ULL << VHOST_BACKEND_F_IOTLB_MSG_V2)
+   VHOST_VDPA_BACKEND_FEATURES =
+   (1ULL << VHOST_BACKEND_F_IOTLB_MSG_V2) |
+   (1ULL << VHOST_BACKEND_F_IOTLB_BATCH),
 };
 
 /* Currently, only network backend w/o multiqueue is supported. */
@@ -77,6 +79,7 @@ struct vhost_vdpa {
int virtio_id;
int minor;
struct eventfd_ctx *config_ctx;
+   int in_batch;
 };
 
 static DEFINE_IDA(vhost_vdpa_ida);
@@ -125,6 +128,7 @@ static void vhost_vdpa_reset(struct vhost_vdpa *v)
const struct vdpa_config_ops *ops = vdpa->config;
 
ops->set_status(vdpa, 0);
+   v->in_batch = 0;
 }
 
 static long vhost_vdpa_get_device_id(struct vhost_vdpa *v, u8 __user *argp)
@@ -540,9 +544,10 @@ static int vhost_vdpa_map(struct vhost_vdpa *v,
 
if (ops->dma_map)
r = ops->dma_map(vdpa, iova, size, pa, perm);
-   else if (ops->set_map)
-   r = ops->set_map(vdpa, dev->iotlb);
-   else
+   else if (ops->set_map) {
+   if (!v->in_batch)
+   r = ops->set_map(vdpa, dev->iotlb);
+   } else
r = iommu_map(v->domain, iova, pa, size,
  perm_to_iommu_flags(perm));
 
@@ -559,9 +564,10 @@ static void vhost_vdpa_unmap(struct vhost_vdpa *v, u64 
iova, u64 size)
 
if (ops->dma_map)
ops->dma_unmap(vdpa, iova, size);
-   else if (ops->set_map)
-   ops->set_map(vdpa, dev->iotlb);
-   else
+   else if (ops->set_map) {
+   if (!v->in_batch)
+   ops->set_map(vdpa, dev->iotlb);
+   } else
iommu_unmap(v->domain, iova, size);
 }
 
@@ -655,6 +661,8 @@ static int vhost_vdpa_process_iotlb_msg(struct vhost_dev 
*dev,
struct vhost_iotlb_msg *msg)
 {
struct vhost_vdpa *v = container_of(dev, struct vhost_vdpa, vdev);
+   struct vdpa_device *vdpa = v->vdpa;
+   const struct vdpa_config_ops *ops = vdpa->config;
int r = 0;
 
r = vhost_dev_check_owner(dev);
@@ -668,6 +676,14 @@ static int vhost_vdpa_process_iotlb_msg(struct vhost_dev 
*dev,
case VHOST_IOTLB_INVALIDATE:
vhost_vdpa_unmap(v, msg->iova, msg->size);
break;
+   case VHOST_IOTLB_BATCH_BEGIN:
+   v->in_batch = true;
+   break;
+   case VHOST_IOTLB_BATCH_END:
+   if (v->in_batch && ops->set_map)
+   ops->set_map(vdpa, dev->iotlb);
+   v->in_batch = false;
+   break;
default:
r = -EINVAL;
break;
diff --git a/include/uapi/linux/vhost.h b/include/uapi/linux/vhost.h
index 0c2349612e77..565da96f55d5 100644
--- a/include/uapi/linux/vhost.h
+++ b/include/uapi/linux/vhost.h
@@ -91,6 +91,8 @@
 
 /* Use message type V2 */
 #define VHOST_BACKEND_F_IOTLB_MSG_V2 0x1
+/* IOTLB can accpet batching hints */
+#define VHOST_BACKEND_F_IOTLB_BATCH  0x2
 
 #define VHOST_SET_BACKEND_FEATURES _IOW(VHOST_VIRTIO, 0x25, __u64)
 #define VHOST_GET_BACKEND_FEATURES _IOR(VHOST_VIRTIO, 0x26, __u64)
diff --git a/include/uapi/linux/vhost_types.h b/include/uapi/linux/vhost_types.h
index 669457ce5c48..5c12faffdde9 100644
--- a/include/uapi/linux/vhost_types.h
+++ b/include/uapi/linux/vhost_types.h
@@ -60,6 +60,13 @@ struct vhost_iotlb_msg {
 #define VHOST_IOTLB_UPDATE 2
 #define VHOST_IOTLB_INVALIDATE 3
 #define VHOST_IOTLB_ACCESS_FAIL4
+/* VHOST_IOTLB_BATCH_BEGIN is a hint that userspace will update
+ * several mappings afterwards. VHOST_IOTLB_BATCH_END is a hint that
+ * userspace had finished the mapping updating. When those two flags
+ * were set, kernel will ignore the rest fileds of the IOTLB message.
+ */
+#define VHOST_IOTLB_BATCH_BEGIN5
+#define VHOST_IOTLB_B

[PATCH RFC 3/5] vhost-vdpa: support get/set backend features

2020-06-17 Thread Jason Wang
This patch makes userspace can get and set backend features to
vhost-vdpa.

Signed-off-by: Cindy Lu 
Signed-off-by: Jason Wang 
---
 drivers/vhost/vdpa.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index db4c9cb44c61..453057421f80 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -55,6 +55,10 @@ enum {
(1ULL << VIRTIO_NET_F_SPEED_DUPLEX),
 };
 
+enum {
+   VHOST_VDPA_BACKEND_FEATURES = (1ULL << VHOST_BACKEND_F_IOTLB_MSG_V2)
+};
+
 /* Currently, only network backend w/o multiqueue is supported. */
 #define VHOST_VDPA_VQ_MAX  2
 
@@ -340,6 +344,8 @@ static long vhost_vdpa_vring_ioctl(struct vhost_vdpa *v, 
unsigned int cmd,
struct vdpa_callback cb;
struct vhost_virtqueue *vq;
struct vhost_vring_state s;
+   u64 __user *featurep = argp;
+   u64 features;
u32 idx;
long r;
 
@@ -362,6 +368,18 @@ static long vhost_vdpa_vring_ioctl(struct vhost_vdpa *v, 
unsigned int cmd,
case VHOST_GET_VRING_BASE:
vq->last_avail_idx = ops->get_vq_state(v->vdpa, idx);
break;
+   case VHOST_GET_BACKEND_FEATURES:
+   features = VHOST_VDPA_BACKEND_FEATURES;
+   if (copy_to_user(featurep, &features, sizeof(features)))
+   return -EFAULT;
+   return 0;
+   case VHOST_SET_BACKEND_FEATURES:
+   if (copy_from_user(&features, featurep, sizeof(features)))
+   return -EFAULT;
+   if (features & ~VHOST_VDPA_BACKEND_FEATURES)
+   return -EOPNOTSUPP;
+   vhost_set_backend_features(&v->vdev, features);
+   return 0;
}
 
r = vhost_vring_ioctl(&v->vdev, cmd, argp);
-- 
2.20.1



[PATCH RFC 2/5] vhost: generialize backend features setting/getting

2020-06-17 Thread Jason Wang
Move the backend features setting/getting from net.c to vhost.c to be
reused by vhost-vdpa.

Signed-off-by: Jason Wang 
---
 drivers/vhost/net.c   | 18 ++
 drivers/vhost/vhost.c | 15 +++
 drivers/vhost/vhost.h |  2 ++
 3 files changed, 19 insertions(+), 16 deletions(-)

diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 0b509be8d7b1..d88afe3f6060 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -1622,21 +1622,6 @@ static long vhost_net_reset_owner(struct vhost_net *n)
return err;
 }
 
-static int vhost_net_set_backend_features(struct vhost_net *n, u64 features)
-{
-   int i;
-
-   mutex_lock(&n->dev.mutex);
-   for (i = 0; i < VHOST_NET_VQ_MAX; ++i) {
-   mutex_lock(&n->vqs[i].vq.mutex);
-   n->vqs[i].vq.acked_backend_features = features;
-   mutex_unlock(&n->vqs[i].vq.mutex);
-   }
-   mutex_unlock(&n->dev.mutex);
-
-   return 0;
-}
-
 static int vhost_net_set_features(struct vhost_net *n, u64 features)
 {
size_t vhost_hlen, sock_hlen, hdr_len;
@@ -1737,7 +1722,8 @@ static long vhost_net_ioctl(struct file *f, unsigned int 
ioctl,
return -EFAULT;
if (features & ~VHOST_NET_BACKEND_FEATURES)
return -EOPNOTSUPP;
-   return vhost_net_set_backend_features(n, features);
+   vhost_set_backend_features(&n->dev, features);
+   return 0;
case VHOST_RESET_OWNER:
return vhost_net_reset_owner(n);
case VHOST_SET_OWNER:
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index dc510dc2b1ef..ba61f499d420 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -2700,6 +2700,21 @@ struct vhost_msg_node *vhost_dequeue_msg(struct 
vhost_dev *dev,
 }
 EXPORT_SYMBOL_GPL(vhost_dequeue_msg);
 
+void vhost_set_backend_features(struct vhost_dev *dev, u64 features)
+{
+   struct vhost_virtqueue *vq;
+   int i;
+
+   mutex_lock(&dev->mutex);
+   for (i = 0; i < dev->nvqs; ++i) {
+   vq = dev->vqs[i];
+   mutex_lock(&vq->mutex);
+   vq->acked_backend_features = features;
+   mutex_unlock(&vq->mutex);
+   }
+   mutex_unlock(&dev->mutex);
+}
+EXPORT_SYMBOL_GPL(vhost_set_backend_features);
 
 static int __init vhost_init(void)
 {
diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
index 264a2a2fae97..52753aecd82a 100644
--- a/drivers/vhost/vhost.h
+++ b/drivers/vhost/vhost.h
@@ -223,6 +223,8 @@ void vhost_enqueue_msg(struct vhost_dev *dev,
   struct vhost_msg_node *node);
 struct vhost_msg_node *vhost_dequeue_msg(struct vhost_dev *dev,
 struct list_head *head);
+void vhost_set_backend_features(struct vhost_dev *dev, u64 features);
+
 __poll_t vhost_chr_poll(struct file *file, struct vhost_dev *dev,
poll_table *wait);
 ssize_t vhost_chr_read_iter(struct vhost_dev *dev, struct iov_iter *to,
-- 
2.20.1



[PATCH RFC 1/5] vhost-vdpa: refine ioctl pre-processing

2020-06-17 Thread Jason Wang
Switch to use 'switch' to make the codes more easier to be extended.

Signed-off-by: Jason Wang 
---
 drivers/vhost/vdpa.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index 77a0c9fb6cc3..db4c9cb44c61 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -353,15 +353,16 @@ static long vhost_vdpa_vring_ioctl(struct vhost_vdpa *v, 
unsigned int cmd,
idx = array_index_nospec(idx, v->nvqs);
vq = &v->vqs[idx];
 
-   if (cmd == VHOST_VDPA_SET_VRING_ENABLE) {
+   switch (cmd) {
+   case VHOST_VDPA_SET_VRING_ENABLE:
if (copy_from_user(&s, argp, sizeof(s)))
return -EFAULT;
ops->set_vq_ready(vdpa, idx, s.num);
return 0;
-   }
-
-   if (cmd == VHOST_GET_VRING_BASE)
+   case VHOST_GET_VRING_BASE:
vq->last_avail_idx = ops->get_vq_state(v->vdpa, idx);
+   break;
+   }
 
r = vhost_vring_ioctl(&v->vdev, cmd, argp);
if (r)
-- 
2.20.1



[PATCH RFC 0/5] support batched IOTLB updating in vhost-vdpa

2020-06-17 Thread Jason Wang
Hi all:

This series tries to support batched IOTLB updating vhost-vdpa.

Currently vhost-vdpa accepts userspace mapping via IOTLB API, and it
can only forward one mapping to IOMMU or device through IOMMU API or
dma_map(). Though set_map() is deisgend to have the capability to pass
an rbtree based mapping to vDPA device, it's still be called at least
once for each VHOST_IOTLB_UPDATE or VHOST_IOTLB_INVALIDATE. This is
because vhost-vdpa doesn't know the userspace start or stop then
updating.

So this patch introduces two flags as hints for vhost-vdpa to call
set_map() only when userspace finish a batch of IOTLB updating.

So instead of:

1) VHOST_IOTLB_UPDATE/VHOST_IOTLB_INVALIDATE -> set_map() (s)
2) VHOST_IOTLB_UPDATE/VHOST_IOTLB_INVALIDATE -> set_map() (s)
...
n) VHOST_IOTLB_UPDATE/VHOST_IOTLB_INVALIDATE -> set_map() (s)

With the help of hints, we do:

0) VHOST_IOTLB_BATCH_START

1) VHOST_IOTLB_UPDATE/INVALIDATE
...
n) VHOST_IOTLB_UPDATE/INVALIDATE

n+1) VHOST_IOTLB_BATCH_END -> set_map()

One one call of set_map() to vDPA device for a batch of IOTLB
mappings. So for the device that has its own DMA translation logic, it
can efficiently structure the memory mapping to get best performance.

Note, this only impact the devices that want its own DMA
translation. For other type of device, no changes in behaviour.

Please reivew.

Jason Wang (5):
  vhost-vdpa: refine ioctl pre-processing
  vhost: generialize backend features setting/getting
  vhost-vdpa: support get/set backend features
  vhost-vdpa: support IOTLB batching hints
  vdpasim: support batch updating

 drivers/vdpa/vdpa_sim/vdpa_sim.c | 40 +--
 drivers/vhost/net.c  | 18 ++-
 drivers/vhost/vdpa.c | 55 ++--
 drivers/vhost/vhost.c| 15 +
 drivers/vhost/vhost.h|  2 ++
 include/uapi/linux/vhost.h   |  2 ++
 include/uapi/linux/vhost_types.h |  7 
 7 files changed, 110 insertions(+), 29 deletions(-)

-- 
2.20.1



Re: + scripts-deprecated_terms-recommend-denylist-allowlist-instead-of-blacklist-whitelist.patch added to -mm tree

2020-06-17 Thread Joe Perches
On Wed, 2020-06-17 at 14:32 -0700, a...@linux-foundation.org wrote:
> The patch titled
>  Subject: scripts/deprecated_terms: recommend denylist/allowlist instead 
> of blacklist/whitelist
> has been added to the -mm tree.  Its filename is
>  
> scripts-deprecated_terms-recommend-denylist-allowlist-instead-of-blacklist-whitelist.patch
[]
> --
> From: SeongJae Park 
> Subject: scripts/deprecated_terms: recommend denylist/allowlist instead of 
> blacklist/whitelist
> 
> This commit recommends that patches replace 'blacklist' and 'whitelist'
> with 'denylist' and 'allowlist', because the new suggestions are
> incontrovertible, doesn't make people hurt, and are more self-explanatory.
[]
> --- 
> a/scripts/deprecated_terms.txt~scripts-deprecated_terms-recommend-denylist-allowlist-instead-of-blacklist-whitelist
> +++ a/scripts/deprecated_terms.txt
> @@ -3,3 +3,5 @@
>  # The format of each line is:
>  # deprecated||suggested
>  #
> +blacklist||denylist
> +whitelist||allowlist

I think this is a poor use of deprecated terms
as it has nothing to do with skin color.




Re: [PATCH v5 3/7] fs: Add fd_install_received() wrapper for __fd_install_received()

2020-06-17 Thread Sargun Dhillon
On Wed, Jun 17, 2020 at 03:03:23PM -0700, Kees Cook wrote:
> For both pidfd and seccomp, the __user pointer is not used. Update
> __fd_install_received() to make writing to ufd optional via a NULL check.
> However, for the fd_install_received_user() wrapper, ufd is NULL checked
> so an -EFAULT can be returned to avoid changing the SCM_RIGHTS interface
> behavior. Add new wrapper fd_install_received() for pidfd and seccomp
> that does not use the ufd argument. For the new helper, the new fd needs
> to be returned on success. Update the existing callers to handle it.
> 
> Signed-off-by: Kees Cook 
> ---
>  fs/file.c| 22 ++
>  include/linux/file.h |  7 +++
>  net/compat.c |  2 +-
>  net/core/scm.c   |  2 +-
>  4 files changed, 23 insertions(+), 10 deletions(-)
> 
> diff --git a/fs/file.c b/fs/file.c
> index f2167d6feec6..de85a42defe2 100644
> --- a/fs/file.c
> +++ b/fs/file.c
> @@ -942,9 +942,10 @@ int replace_fd(unsigned fd, struct file *file, unsigned 
> flags)
>   * @o_flags: the O_* flags to apply to the new fd entry
>   *
>   * Installs a received file into the file descriptor table, with appropriate
> - * checks and count updates. Writes the fd number to userspace.
> + * checks and count updates. Optionally writes the fd number to userspace, if
> + * @ufd is non-NULL.
>   *
> - * Returns -ve on error.
> + * Returns newly install fd or -ve on error.
>   */
>  int __fd_install_received(struct file *file, int __user *ufd, unsigned int 
> o_flags)
>  {
> @@ -960,20 +961,25 @@ int __fd_install_received(struct file *file, int __user 
> *ufd, unsigned int o_fla
>   if (new_fd < 0)
>   return new_fd;
>  
> - error = put_user(new_fd, ufd);
> - if (error) {
> - put_unused_fd(new_fd);
> - return error;
> + if (ufd) {
> + error = put_user(new_fd, ufd);
> + if (error) {
> + put_unused_fd(new_fd);
> + return error;
> + }
>   }
>  
> - /* Bump the usage count and install the file. */
> + /* Bump the usage count and install the file. The resulting value of
> +  * "error" is ignored here since we only need to take action when
> +  * the file is a socket and testing "sock" for NULL is sufficient.
> +  */
>   sock = sock_from_file(file, &error);
>   if (sock) {
>   sock_update_netprioidx(&sock->sk->sk_cgrp_data);
>   sock_update_classid(&sock->sk->sk_cgrp_data);
>   }
>   fd_install(new_fd, get_file(file));
> - return 0;
> + return new_fd;
>  }
>  
>  static int ksys_dup3(unsigned int oldfd, unsigned int newfd, int flags)
> diff --git a/include/linux/file.h b/include/linux/file.h
> index fe18a1a0d555..e19974ed9322 100644
> --- a/include/linux/file.h
> +++ b/include/linux/file.h
> @@ -9,6 +9,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  struct file;
>  
> @@ -96,8 +97,14 @@ extern int __fd_install_received(struct file *file, int 
> __user *ufd,
>  static inline int fd_install_received_user(struct file *file, int __user 
> *ufd,
>  unsigned int o_flags)
>  {
> + if (ufd == NULL)
> + return -EFAULT;
Isn't this *technically* a behvaiour change? Nonetheless, I think this is a 
much better
approach than forcing everyone to do null checking, and avoids at least one 
error case
where the kernel installs FDs for SCM_RIGHTS, and they're not actualy usable.

>   return __fd_install_received(file, ufd, o_flags);
>  }
> +static inline int fd_install_received(struct file *file, unsigned int 
> o_flags)
> +{
> + return __fd_install_received(file, NULL, o_flags);
> +}
>  
>  extern void flush_delayed_fput(void);
>  extern void __fput_sync(struct file *);
> diff --git a/net/compat.c b/net/compat.c
> index 94f288e8dac5..71494337cca7 100644
> --- a/net/compat.c
> +++ b/net/compat.c
> @@ -299,7 +299,7 @@ void scm_detach_fds_compat(struct msghdr *msg, struct 
> scm_cookie *scm)
>  
>   for (i = 0; i < fdmax; i++) {
>   err = fd_install_received_user(scm->fp->fp[i], cmsg_data + i, 
> o_flags);
> - if (err)
> + if (err < 0)
>   break;
>   }
>  
> diff --git a/net/core/scm.c b/net/core/scm.c
> index df190f1fdd28..b9a0442ebd26 100644
> --- a/net/core/scm.c
> +++ b/net/core/scm.c
> @@ -307,7 +307,7 @@ void scm_detach_fds(struct msghdr *msg, struct scm_cookie 
> *scm)
>  
>   for (i = 0; i < fdmax; i++) {
>   err = fd_install_received_user(scm->fp->fp[i], cmsg_data + i, 
> o_flags);
> - if (err)
> + if (err < 0)
>   break;
>   }
>  
> -- 
> 2.25.1
> 

Reviewed-by: Sargun Dhillon 


Re: [PATCH 4/5] dt-bindings: fpga: xilinx-slave-serial: add optional INIT_B GPIO

2020-06-17 Thread Luca Ceresoli
Hi Rob, Moritz,

On 18/06/20 00:39, Rob Herring wrote:
> On Thu, Jun 11, 2020 at 11:11:43PM +0200, Luca Ceresoli wrote:
>> The INIT_B is used by the 6 and 7 series to report the programming status,
>> providing more control and information about programming errors.
>>
>> Signed-off-by: Luca Ceresoli 
>> ---
>>  .../devicetree/bindings/fpga/xilinx-slave-serial.txt   | 7 ++-
>>  1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/fpga/xilinx-slave-serial.txt 
>> b/Documentation/devicetree/bindings/fpga/xilinx-slave-serial.txt
>> index 9f103f3872e8..a049082e1513 100644
>> --- a/Documentation/devicetree/bindings/fpga/xilinx-slave-serial.txt
>> +++ b/Documentation/devicetree/bindings/fpga/xilinx-slave-serial.txt
>> @@ -16,6 +16,10 @@ Required properties:
>>  - prog_b-gpios: config pin (referred to as PROGRAM_B in the manual)
>>  - done-gpios: config status pin (referred to as DONE in the manual)
>>  
>> +Optional properties:
>> +- init_b-gpios: initialization status and configuration error pin
>> +(referred to as INIT_B in the manual)
> 
> Don't use '_' in property names:
> 
> init-b-gpios

OK, will fix.

Moritz, please don't apply this version of patches 4 and 5 if you still
haven't done so.

Now what about the existing prog_b-gpios property? Should we just leave
it as is for backward compatibility, or is there a migration path to fix
it as well?

Thanks.
-- 
Luca


Re: [PATCH v3] seccomp: Add find_notification helper

2020-06-17 Thread Sargun Dhillon
On Wed, Jun 17, 2020 at 01:08:44PM -0700, Nathan Chancellor wrote:
> On Mon, Jun 01, 2020 at 04:25:32AM -0700, Sargun Dhillon wrote:
> > This adds a helper which can iterate through a seccomp_filter to
> > find a notification matching an ID. It removes several replicated
> > chunks of code.
> > 
> > Signed-off-by: Sargun Dhillon 
> > Acked-by: Christian Brauner 
> > Reviewed-by: Tycho Andersen 
> > Cc: Matt Denton 
> > Cc: Kees Cook ,
> > Cc: Jann Horn ,
> > Cc: Robert Sesek ,
> > Cc: Chris Palmer 
> > Cc: Christian Brauner 
> > Cc: Tycho Andersen 
> > ---
> >  kernel/seccomp.c | 55 
> >  1 file changed, 28 insertions(+), 27 deletions(-)
> > 
> > diff --git a/kernel/seccomp.c b/kernel/seccomp.c
> > index 55a6184f5990..cc6b47173a95 100644
> > --- a/kernel/seccomp.c
> > +++ b/kernel/seccomp.c
> > @@ -41,6 +41,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  enum notify_state {
> > SECCOMP_NOTIFY_INIT,
> > @@ -1021,10 +1022,27 @@ static int seccomp_notify_release(struct inode 
> > *inode, struct file *file)
> > return 0;
> >  }
> >  
> > +/* must be called with notif_lock held */
> > +static inline struct seccomp_knotif *
> > +find_notification(struct seccomp_filter *filter, u64 id)
> > +{
> > +   struct seccomp_knotif *cur;
> > +
> > +   lockdep_assert_held(&filter->notify_lock);
> > +
> > +   list_for_each_entry(cur, &filter->notif->notifications, list) {
> > +   if (cur->id == id)
> > +   return cur;
> > +   }
> > +
> > +   return NULL;
> > +}
> > +
> > +
> >  static long seccomp_notify_recv(struct seccomp_filter *filter,
> > void __user *buf)
> >  {
> > -   struct seccomp_knotif *knotif = NULL, *cur;
> > +   struct seccomp_knotif *knotif, *cur;
> > struct seccomp_notif unotif;
> > ssize_t ret;
> >  
> > @@ -1078,15 +1096,8 @@ static long seccomp_notify_recv(struct 
> > seccomp_filter *filter,
> >  * may have died when we released the lock, so we need to make
> >  * sure it's still around.
> >  */
> > -   knotif = NULL;
> > mutex_lock(&filter->notify_lock);
> > -   list_for_each_entry(cur, &filter->notif->notifications, list) {
> > -   if (cur->id == unotif.id) {
> > -   knotif = cur;
> > -   break;
> > -   }
> > -   }
> > -
> > +   knotif = find_notification(filter, unotif.id);
> > if (knotif) {
> > knotif->state = SECCOMP_NOTIFY_INIT;
> > up(&filter->notif->request);
> > @@ -1101,7 +1112,7 @@ static long seccomp_notify_send(struct seccomp_filter 
> > *filter,
> > void __user *buf)
> >  {
> > struct seccomp_notif_resp resp = {};
> > -   struct seccomp_knotif *knotif = NULL, *cur;
> > +   struct seccomp_knotif *knotif;
> > long ret;
> >  
> > if (copy_from_user(&resp, buf, sizeof(resp)))
> > @@ -1118,13 +1129,7 @@ static long seccomp_notify_send(struct 
> > seccomp_filter *filter,
> > if (ret < 0)
> > return ret;
> >  
> > -   list_for_each_entry(cur, &filter->notif->notifications, list) {
> > -   if (cur->id == resp.id) {
> > -   knotif = cur;
> > -   break;
> > -   }
> > -   }
> > -
> > +   knotif = find_notification(filter, resp.id);
> > if (!knotif) {
> > ret = -ENOENT;
> > goto out;
> > @@ -1150,7 +1155,7 @@ static long seccomp_notify_send(struct seccomp_filter 
> > *filter,
> >  static long seccomp_notify_id_valid(struct seccomp_filter *filter,
> > void __user *buf)
> >  {
> > -   struct seccomp_knotif *knotif = NULL;
> 
> I don't know that this should have been removed, clang now warns:
> 
> kernel/seccomp.c:1063:2: warning: variable 'knotif' is used uninitialized 
> whenever 'for' loop exits because its condition is false 
> [-Wsometimes-uninitialized]
> list_for_each_entry(cur, &filter->notif->notifications, list) {
> ^
> include/linux/list.h:602:7: note: expanded from macro 'list_for_each_entry'
>  &pos->member != (head);\
>  ^~
> kernel/seccomp.c:1075:7: note: uninitialized use occurs here
> if (!knotif) {
>  ^~
> kernel/seccomp.c:1063:2: note: remove the condition if it is always true
> list_for_each_entry(cur, &filter->notif->notifications, list) {
> ^
> include/linux/list.h:602:7: note: expanded from macro 'list_for_each_entry'
>  &pos->member != (head);\
>  ^
> kernel/seccomp.c:1045:31: note: initialize the variable 'knotif' to silence 
> this warning
> struct seccomp_knotif *knotif, *cur;
> 

Re: [PATCH v3] libata: Use per port sync for detach

2020-06-17 Thread Kai-Heng Feng
Hi Jens,

> On Jun 3, 2020, at 16:40, John Garry  wrote:
> 
> On 03/06/2020 08:48, Kai-Heng Feng wrote:
>> Commit 130f4caf145c ("libata: Ensure ata_port probe has completed before
>> detach") may cause system freeze during suspend.
>> Using async_synchronize_full() in PM callbacks is wrong, since async
>> callbacks that are already scheduled may wait for not-yet-scheduled
>> callbacks, causes a circular dependency.
>> Instead of using big hammer like async_synchronize_full(), use async
>> cookie to make sure port probe are synced, without affecting other
>> scheduled PM callbacks.
>> Fixes: 130f4caf145c ("libata: Ensure ata_port probe has completed before 
>> detach")
>> BugLink: https://bugs.launchpad.net/bugs/1867983
>> Suggested-by: John Garry 
>> Signed-off-by: Kai-Heng Feng 
> 
> thanks,
> Tested-by: John Garry 

Can you please review or merge this patch?

Kai-Heng

> 
>> ---
>> v3:
>>  - Move the comment to properly align with the code.
>> v2:
>>  - Sync up to cookie + 1.
>>  - Squash the synchronization into the same loop.
>>  drivers/ata/libata-core.c | 11 +--
>>  include/linux/libata.h|  3 +++
>>  2 files changed, 8 insertions(+), 6 deletions(-)
>> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
>> index 69361ec43db5..b1cd4d97bc2a 100644
>> --- a/drivers/ata/libata-core.c
>> +++ b/drivers/ata/libata-core.c
>> @@ -42,7 +42,6 @@
>>  #include 
>>  #include 
>>  #include 
>> -#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -5778,7 +5777,7 @@ int ata_host_register(struct ata_host *host, struct 
>> scsi_host_template *sht)
>>  /* perform each probe asynchronously */
>>  for (i = 0; i < host->n_ports; i++) {
>>  struct ata_port *ap = host->ports[i];
>> -async_schedule(async_port_probe, ap);
>> +ap->cookie = async_schedule(async_port_probe, ap);
>>  }
>>  return 0;
>> @@ -5920,11 +5919,11 @@ void ata_host_detach(struct ata_host *host)
>>  {
>>  int i;
>>  -   /* Ensure ata_port probe has completed */
>> -async_synchronize_full();
>> -
>> -for (i = 0; i < host->n_ports; i++)
>> +for (i = 0; i < host->n_ports; i++) {
>> +/* Ensure ata_port probe has completed */
>> +async_synchronize_cookie(host->ports[i]->cookie + 1);
>>  ata_port_detach(host->ports[i]);
>> +}
>>  /* the host is dead now, dissociate ACPI */
>>  ata_acpi_dissociate(host);
>> diff --git a/include/linux/libata.h b/include/linux/libata.h
>> index af832852e620..8a4843704d28 100644
>> --- a/include/linux/libata.h
>> +++ b/include/linux/libata.h
>> @@ -22,6 +22,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>/*
>>   * Define if arch has non-standard setup.  This is a _PCI_ standard
>> @@ -872,6 +873,8 @@ struct ata_port {
>>  struct timer_list   fastdrain_timer;
>>  unsigned long   fastdrain_cnt;
>>  +   async_cookie_t  cookie;
>> +
>>  int em_message_type;
>>  void*private_data;
>>  
> 



Re: [PATCH][next] bcache: Use struct_size() in kzalloc()

2020-06-17 Thread Joe Perches
On Thu, 2020-06-18 at 13:38 +0800, Coly Li wrote:
> On 2020/6/18 06:27, Gustavo A. R. Silva wrote:
> > Make use of the struct_size() helper instead of an open-coded version
> > in order to avoid any potential type mistakes.
[]
> > diff --git a/drivers/md/bcache/writeback.c b/drivers/md/bcache/writeback.c
[]
> > -   io = kzalloc(sizeof(struct dirty_io) +
> > -sizeof(struct bio_vec) *
> > -DIV_ROUND_UP(KEY_SIZE(&w->key),
> > - PAGE_SECTORS),
> > +   io = kzalloc(struct_size(io, bio.bi_inline_vecs,
>  ^^
>  I like this :-)
> 
> > +   DIV_ROUND_UP(KEY_SIZE(&w->key), 
> > PAGE_SECTORS)),
> 
> The above line seems too long for 80 characters limitation. Does
> checkpatch.pl complain for this ?

No.  checkpatch has changed:

>From bdc48fa11e46f867ea4d75fa59ee87a7f48be144 Mon Sep 17 00:00:00 2001
From: Joe Perches 
Date: Fri, 29 May 2020 16:12:21 -0700
Subject: [PATCH] checkpatch/coding-style: deprecate 80-column warning

Yes, staying withing 80 columns is certainly still _preferred_.  But
it's not the hard limit that the checkpatch warnings imply, and other
concerns can most certainly dominate.

Increase the default limit to 100 characters.  Not because 100
characters is some hard limit either, but that's certainly a "what are
you doing" kind of value and less likely to be about the occasional
slightly longer lines.

Miscellanea:

 - to avoid unnecessary whitespace changes in files, checkpatch will no
   longer emit a warning about line length when scanning files unless
   --strict is also used

 - Add a bit to coding-style about alignment to open parenthesis

Signed-off-by: Joe Perches 
Signed-off-by: Linus Torvalds 
> 



drivers/video/fbdev/tdfxfb.c:1120:27: sparse: sparse: incorrect type in argument 1 (different address spaces)

2020-06-17 Thread kernel test robot
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   1b5044021070efa3259f3e9548dc35d1eb6aa844
commit: 80591e61a0f7e88deaada69844e4a31280c4a38f kbuild: tell sparse about the 
$ARCH
date:   7 months ago
config: s390-randconfig-s032-20200618 (attached as .config)
compiler: s390-linux-gcc (GCC) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.2-rc1-10-gc17b1b06-dirty
git checkout 80591e61a0f7e88deaada69844e4a31280c4a38f
# save the attached .config to linux build tree
make W=1 C=1 ARCH=s390 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 


sparse warnings: (new ones prefixed by >>)

>> drivers/video/fbdev/tdfxfb.c:1120:27: sparse: sparse: incorrect type in 
>> argument 1 (different address spaces) @@ expected void *s @@ got 
>> unsigned char [noderef] [usertype]  *cursorbase @@
>> drivers/video/fbdev/tdfxfb.c:1120:27: sparse: expected void *s
   drivers/video/fbdev/tdfxfb.c:1120:27: sparse: got unsigned char 
[noderef] [usertype]  *cursorbase
   drivers/video/fbdev/tdfxfb.c:1131:33: sparse: sparse: cast removes address 
space '' of expression
   drivers/video/fbdev/tdfxfb.c:1134:33: sparse: sparse: cast removes address 
space '' of expression
   include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
   include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
   include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
   include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
   include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
   include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
   include/asm-generic/io.h:225:22: sparse: sparse: incorrect type in argument 
1 (different base types) @@ expected unsigned int [usertype] val @@ got 
restricted __le32 [usertype] @@
   include/asm-generic/io.h:225:22: sparse: expected unsigned int 
[usertype] val
   include/asm-generic/io.h:225:22: sparse: got restricted __le32 [usertype]
   include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
   include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
   include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
   include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
   include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
   include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
   include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
   include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
   include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
   include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
   include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
   include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
   include/asm-generic/io.h:225:22: sparse: sparse: incorrect type in argument 
1 (different base types) @@ expected unsigned int [usertype] val @@ got 
restricted __le32 [usertype] @@
   include/asm-generic/io.h:225:22: sparse: expected unsigned int 
[usertype] val
   include/asm-generic/io.h:225:22: sparse: got restricted __le32 [usertype]
   include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
   include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
   include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
   include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
   include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
   include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
   include/asm-generic/io.h:225:22: sparse: sparse: incorrect type in argument 
1 (different base types) @@ expected unsigned int [usertype] val @@ got 
restricted __le32 [usertype] @@
   include/asm-generic/io.h:225:22: sparse: expected unsigned int 
[usertype] val
   include/asm-generic/io.h:225:22: sparse: got restricted __le32 [usertype]
   include/asm-generic/io.h:225:22: sparse: sparse: incorrect type in argument 
1 (different base types) @@ expected unsigned int [usertype] val @@ got 
restricted __le32 [usertype] @@
   include/asm-generic/io.h:225:22: sparse: expected unsigned int 
[usertype] val
   include/asm-generic/io.h:225:22: sparse: got restricted __le32 [usertype]
   include/asm-generic/io.h:225:22: sparse: sparse: incorrect type in argument 
1 (different base types) @@ expected unsigned int [usertype] val @@ got 
restricted __le32 [usertype] @@
   include/asm-generic/io.h:225:22: sparse: expected unsigned int 
[usertype] val
   include/asm-generic/io.h:225:22: sparse: got

Re: [PATCH][next] bcache: Use struct_size() in kzalloc()

2020-06-17 Thread Coly Li
On 2020/6/18 06:27, Gustavo A. R. Silva wrote:
> Make use of the struct_size() helper instead of an open-coded version
> in order to avoid any potential type mistakes.
> 
> This code was detected with the help of Coccinelle and, audited and
> fixed manually.
> 
> Signed-off-by: Gustavo A. R. Silva  ---
>  drivers/md/bcache/writeback.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/md/bcache/writeback.c b/drivers/md/bcache/writeback.c
> index 1cf1e5016cb9..c0db3c860179 100644
> --- a/drivers/md/bcache/writeback.c
> +++ b/drivers/md/bcache/writeback.c
> @@ -459,10 +459,8 @@ static void read_dirty(struct cached_dev *dc)
>   for (i = 0; i < nk; i++) {
>   w = keys[i];
>  
> - io = kzalloc(sizeof(struct dirty_io) +
> -  sizeof(struct bio_vec) *
> -  DIV_ROUND_UP(KEY_SIZE(&w->key),
> -   PAGE_SECTORS),
> + io = kzalloc(struct_size(io, bio.bi_inline_vecs,
 ^^
 I like this :-)

> + DIV_ROUND_UP(KEY_SIZE(&w->key), 
> PAGE_SECTORS)),

The above line seems too long for 80 characters limitation. Does
checkpatch.pl complain for this ?


Thanks.

Coly Li


>GFP_KERNEL);
>   if (!io)
>   goto err;
> 



Re: linux-next: Tree for Jun 18 (fs/io_uring)

2020-06-17 Thread Randy Dunlap
On 6/17/20 9:15 PM, Stephen Rothwell wrote:
> Hi all,
> 
> News: there will be no linux-next release tomorrow.
> 
> Changes since 20200617:
> 

when CONFIG_BLOCK is not set/enabled:

../fs/io_uring.c: In function 'io_async_task_func':
../fs/io_uring.c:4559:7: error: implicit declaration of function 
'io_sq_thread_acquire_mm'; did you mean 'atomic_read_acquire'? 
[-Werror=implicit-function-declaration]
   if (io_sq_thread_acquire_mm(ctx, req)) {
   ^~~
   atomic_read_acquire
../fs/io_uring.c: In function 'io_sq_thread':
../fs/io_uring.c:6268:4: error: implicit declaration of function 
'io_sq_thread_drop_mm'; did you mean 'io_sq_thread'? 
[-Werror=implicit-function-declaration]
io_sq_thread_drop_mm(ctx);
^~~~
io_sq_thread



-- 
~Randy
Reported-by: Randy Dunlap 



Re: [PATCH v2 0/8] Introduce sv48 support

2020-06-17 Thread Alex Ghiti

Hi Palmer,

Le 6/3/20 à 4:10 AM, Alexandre Ghiti a écrit :

This patchset implements sv48 support at runtime. The kernel will try to
boot with 4-level page table and will fallback to 3-level if the HW does not
support it.
  
The biggest advantage is that we only have one kernel for 64bit, which

is way easier to maintain.
  
Folding the 4th level into a 3-level page table has almost no cost at

runtime. But as mentioned Palmer, the relocatable code generated is less
performant.
  
At the moment, there is no way to build a 3-level page table non-relocatable

64bit kernel. We agreed that distributions will use this runtime configuration
anyway, but Palmer proposed to introduce a new Kconfig, which I will do later
as sv48 support was asked for 5.8.
  
Finally, the user can now ask for sv39 explicitly by using the device-tree

which will reduce memory footprint and reduce the number of memory accesses
in case of TLB miss.

Changes in v2:
   * Move variable declarations to pgtable.h in patch 5/7 as suggested by Anup
   * Restore mmu-type properties in patch 6 as suggested by Anup
   * Fix unused variable in patch 5 that was used in patch 6
   * Fix SPARSEMEM build (patch 2 was modified so I dropped the Reviewed-by)
   * Applied various Reviewed-by

Alexandre Ghiti (8):
   riscv: Get rid of compile time logic with MAX_EARLY_MAPPING_SIZE
   riscv: Allow to dynamically define VA_BITS
   riscv: Simplify MAXPHYSMEM config
   riscv: Prepare ptdump for vm layout dynamic addresses
   riscv: Implement sv48 support
   riscv: Allow user to downgrade to sv39 when hw supports sv48
   riscv: Use pgtable_l4_enabled to output mmu type in cpuinfo
   riscv: Explicit comment about user virtual address space size

  arch/riscv/Kconfig  |  34 ++---
  arch/riscv/include/asm/csr.h|   3 +-
  arch/riscv/include/asm/fixmap.h |   1 +
  arch/riscv/include/asm/page.h   |  15 +++
  arch/riscv/include/asm/pgalloc.h|  36 ++
  arch/riscv/include/asm/pgtable-64.h |  97 +-
  arch/riscv/include/asm/pgtable.h|  31 -
  arch/riscv/include/asm/sparsemem.h  |   6 +-
  arch/riscv/kernel/cpu.c |  23 ++--
  arch/riscv/kernel/head.S|   3 +-
  arch/riscv/mm/context.c |   2 +-
  arch/riscv/mm/init.c| 194 
  arch/riscv/mm/ptdump.c  |  49 +--
  13 files changed, 412 insertions(+), 82 deletions(-)



Do you any remark regarding this patchset and the others ?

Thanks,

Alex



[PATCH v3 3/3] media: v4l: xilinx: Add Xilinx UHD-SDI Rx Subsystem driver

2020-06-17 Thread Vishal Sagar
The Xilinx UHD-SDI Rx subsystem soft IP is used to capture native SDI
streams from SDI sources like SDI broadcast equipment like cameras and
mixers. This block outputs either native SDI, native video or
AXI4-Stream compliant data stream for further processing. Please refer
to PG290 for details.

The driver is used to configure the IP to add framer, search for
specific modes, get the detected mode, stream parameters, errors, etc.
It also generates events for video lock/unlock, bridge over/under flow.

The driver supports 10/12 bpc YUV 422 media bus format currently. It
also decodes the stream parameters based on the ST352 packet embedded in the
stream. In case the ST352 packet isn't present in the stream, the core's
detected properties are used to set stream properties.

The driver currently supports only the AXI4-Stream IP configuration.

Signed-off-by: Vishal Sagar 
---
v3
- fixed KConfig with better description
- removed unnecessary header files
- converted uppercase to lowercase for all hex values
- merged core struct to state struct
- removed most one line functions and replaced with direct reg
  read/write or macros
- dt property bpp to bpc. default 10. not mandatory.
- fixed subscribe events, log_status, s_stream
- merged overflow/underflow to one event
- moved all controls to xilinx-sdirxss.h
- max events from 128 to 8
- used FIELD_GET() instead of custom macro
- updated the controls documentation
- added spinlock
- removed 3GB control and added mode to detect bitmask
- fixed format for (width, height, colorspace, xfer func, etc)
- added dv_timings_cap, s/g_dv_timings
- fixed set/get_format
- fix v4l control registrations
- fix order of registration / deregistration in probe() remove()
- fixed other comments from Hyun, Laurent and Hans
- things yet to close
  - adding source port for connector (Laurent's suggestion)
  - adding new FIELD type for Transport Stream V4L2_FIELD_ALTERNATE_PROG (Han's 
suggestion)
  - Update / remove EDH or CRC related controls

v2
- Added DV timing support based on Hans Verkuilś feedback
- More documentation to custom v4l controls and events
- Fixed Hyunś comments
- Added macro for masking and shifting as per Joe Perches comments
- Updated to latest as per Xilinx github repo driver like
  adding new DV timings not in mainline yet uptill 03/21/20

 drivers/media/platform/xilinx/Kconfig |   11 +
 drivers/media/platform/xilinx/Makefile|1 +
 .../media/platform/xilinx/xilinx-sdirxss.c| 2121 +
 include/uapi/linux/v4l2-controls.h|6 +
 include/uapi/linux/xilinx-sdirxss.h   |  283 +++
 5 files changed, 2422 insertions(+)
 create mode 100644 drivers/media/platform/xilinx/xilinx-sdirxss.c
 create mode 100644 include/uapi/linux/xilinx-sdirxss.h

diff --git a/drivers/media/platform/xilinx/Kconfig 
b/drivers/media/platform/xilinx/Kconfig
index 01c96fb66414..578cdcc1036e 100644
--- a/drivers/media/platform/xilinx/Kconfig
+++ b/drivers/media/platform/xilinx/Kconfig
@@ -12,6 +12,17 @@ config VIDEO_XILINX
 
 if VIDEO_XILINX
 
+config VIDEO_XILINX_SDIRXSS
+   tristate "Xilinx UHD SDI Rx Subsystem"
+   help
+ Driver for Xilinx UHD-SDI Rx Subsystem. This is a V4L sub-device
+ based driver that takes input from a SDI source like SDI camera and
+ converts it into an AXI4-Stream. The subsystem comprises a SMPTE
+ UHD-SDI Rx core, a SDI Rx to Native Video bridge and a Video In to
+ AXI4-Stream bridge. The driver is used to set different stream
+ detection modes and identify stream properties to properly configure
+ downstream.
+
 config VIDEO_XILINX_TPG
tristate "Xilinx Video Test Pattern Generator"
depends on VIDEO_XILINX
diff --git a/drivers/media/platform/xilinx/Makefile 
b/drivers/media/platform/xilinx/Makefile
index 4cdc0b1ec7a5..3beaf24d832c 100644
--- a/drivers/media/platform/xilinx/Makefile
+++ b/drivers/media/platform/xilinx/Makefile
@@ -3,5 +3,6 @@
 xilinx-video-objs += xilinx-dma.o xilinx-vip.o xilinx-vipp.o
 
 obj-$(CONFIG_VIDEO_XILINX) += xilinx-video.o
+obj-$(CONFIG_VIDEO_XILINX_SDIRXSS) += xilinx-sdirxss.o
 obj-$(CONFIG_VIDEO_XILINX_TPG) += xilinx-tpg.o
 obj-$(CONFIG_VIDEO_XILINX_VTC) += xilinx-vtc.o
diff --git a/drivers/media/platform/xilinx/xilinx-sdirxss.c 
b/drivers/media/platform/xilinx/xilinx-sdirxss.c
new file mode 100644
index ..e39aab7c656a
--- /dev/null
+++ b/drivers/media/platform/xilinx/xilinx-sdirxss.c
@@ -0,0 +1,2121 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Driver for Xilinx SDI Rx Subsystem
+ *
+ * Copyright (C) 2017 - 2020 Xilinx, Inc.
+ *
+ * Contacts: Vishal Sagar 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * SDI Rx register map, bitmask and offsets
+ */
+#define XSDIRX_RST_CTRL_REG0x00
+#define XSDIRX_MDL_CTRL_REG0x04
+#define XSDIRX_GLBL_IER_REG0x0c
+#define XSDIRX

[PATCH v3 0/3] Add support for Xilinx UHD-SDI Receiver subsystem

2020-06-17 Thread Vishal Sagar
Xilinx SMPTE UHD-SDI Receiver Subsystem


The SMPTE UHD-SDI Receiver (RX) Subsystem allows you to quickly create
systems based on SMPTE SDI protocols. It receives unaligned native SDI
streams from the SDI GT PHY and outputs an AXI4-Stream video stream,
native video, or native SDI using Xilinx transceivers as the physical
layer.

SMPTE UHD-SDI Rx Subsystem AXI4-Stream Architecture

  ++
  |   Native SDI   Native Video|
SDI   |   +=+   |   ++  |   +=+|AXI4
Stream|   |  SMPTE  |   V   |   SDI Rx   |  V   | Video In||Stream
->|-->| UHD-SDI |-->|to  |->|   to|--->|--->
  |   |   RX|   |  Native|  | AXI4-Stream ||
  |   +=+   |Video Bridge|  +=+|
  |  |  ^   ++ |
   <--|--+  |  |
sdi_rx_irq| |  |
  +=+===+==+
|^  ^
||  |
 s_axi_aclk   sdi_rx_clk   video_out_clk


The subsystem consists of the following subcores:
- SMPTE UHD-SDI (RX)
- SDI RX to Video Bridge
- Video In to AXI4-Stream

At design time, this subsystem can be configured in 3Gbps, 6Gbps or
12Gbps mode. It can also be configured to output
- SDI Native stream
- Native Video
- AXI4-Stream

This driver only supports the AXI4-Stream configuration as there is a
corresponding media bus format for YUV 422 10/12 bits per component.

Though the core also supports RBG/YUV444/YUV420 10/12 bits per component,
these are not supported in driver due to lack of corresponding media bus
format currently.

The SDI core has detection modes where in it can be configured to detect
one or more modes from SD (Standard Definition), HD (High Definition),
3GA, 3GB, 6G and 12G modes. When the core has detected the format, it
generates a video lock. In case the source is removed or there is data
corruption, the video may unlock. This is intimated to the application
via a V4L2 event. Other events which application can subscribe are for
overflow and underflow of the video bridges.

The driver gives out the stream properties like width, height, colorformat,
frame interval and progressive/interlaced based on the ST352 packet in SDI
stream. If the ST352 packet is absent, then the values detected by the
SMPTE UHD-SDI Rx core are used.

The SDI core detection modes and detected mode, errors, etc are all
accessible via v4l controls. This driver has been tested with Omnitek
Ultra4K HD, Phabrix Qx and Blackmagic SDI-HDMI convertors.

v2
1/2
- Converted to yaml format
- Removed references to xlnx,video*
- Fixed as per Sakari Ailus and Rob Herring's comments

2/2
- Added DV timing support based on Hans Verkuilś feedback
- More documentation to custom v4l controls and events
- Fixed Hyunś comments
- Added macro for masking and shifting as per Joe Perches comments
- Updated to latest as per Xilinx github repo driver like
  adding new DV timings not in mainline yet uptill 03/21/20

Vishal Sagar (3):
  v4l2-dv-timings: Add timings for 1920x1080P48 and 4KP48
  media: dt-bindings: media: xilinx: Add Xilinx UHD-SDI Receiver
Subsystem
  media: v4l: xilinx: Add Xilinx UHD-SDI Rx Subsystem driver

 .../bindings/media/xilinx/xlnx,sdirxss.yaml   |  132 +
 drivers/media/platform/xilinx/Kconfig |   11 +
 drivers/media/platform/xilinx/Makefile|1 +
 .../media/platform/xilinx/xilinx-sdirxss.c| 2121 +
 include/dt-bindings/media/xilinx-sdi.h|   20 +
 include/uapi/linux/v4l2-controls.h|6 +
 include/uapi/linux/v4l2-dv-timings.h  |   31 +-
 include/uapi/linux/xilinx-sdirxss.h   |  283 +++
 8 files changed, 2604 insertions(+), 1 deletion(-)
 create mode 100644 
Documentation/devicetree/bindings/media/xilinx/xlnx,sdirxss.yaml
 create mode 100644 drivers/media/platform/xilinx/xilinx-sdirxss.c
 create mode 100644 include/dt-bindings/media/xilinx-sdi.h
 create mode 100644 include/uapi/linux/xilinx-sdirxss.h

-- 
2.21.0



[PATCH v3 2/3] media: dt-bindings: media: xilinx: Add Xilinx UHD-SDI Receiver Subsystem

2020-06-17 Thread Vishal Sagar
Add bindings documentation for Xilinx UHD-SDI Receiver Subsystem.

The Xilinx UHD-SDI Receiver Subsystem consists of SMPTE UHD-SDI (RX) IP
core, an SDI RX to Video Bridge IP core to convert SDI video to native
video and a Video In to AXI4-Stream IP core to convert native video to
AXI4-Stream.

Signed-off-by: Vishal Sagar 
---
v3
- bpc instead of bpp
- removed bpc as required property (default to 10 bpc)
- add dt-bindings/media/xilinx-sdi.h
- made line-rate as u32 instead of string
- fixed reg
- fixed s/upto/up to/

v2
- Removed references to xlnx,video*
- Fixed as per Sakari Ailus and Rob Herring's comments
- Converted to yaml format

 .../bindings/media/xilinx/xlnx,sdirxss.yaml   | 132 ++
 include/dt-bindings/media/xilinx-sdi.h|  20 +++
 2 files changed, 152 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/media/xilinx/xlnx,sdirxss.yaml
 create mode 100644 include/dt-bindings/media/xilinx-sdi.h

diff --git a/Documentation/devicetree/bindings/media/xilinx/xlnx,sdirxss.yaml 
b/Documentation/devicetree/bindings/media/xilinx/xlnx,sdirxss.yaml
new file mode 100644
index ..6cfc18ca435f
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/xilinx/xlnx,sdirxss.yaml
@@ -0,0 +1,132 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/xilinx/xlnx,sdirxss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+
+title: Xilinx SMPTE UHD-SDI Receiver Subsystem
+
+maintainers:
+  - Vishal Sagar 
+
+description: |
+  The SMPTE UHD-SDI Receiver (RX) Subsystem allows you to quickly create 
systems
+  based on SMPTE SDI protocols. It receives unaligned native SDI streams from
+  the SDI GT PHY and outputs an AXI4-Stream video stream, native video, or
+  native SDI using Xilinx transceivers as the physical layer.
+
+  The subsystem consists of
+  1 - SMPTE UHD-SDI Rx
+  2 - SDI Rx to Native Video Bridge
+  3 - Video In to AXI4-Stream Bridge
+
+  The subsystem can capture SDI streams in up to 12G mode 8 data streams and 
output
+  a dual pixel per clock RGB/YUV444,422/420 10/12 bits per component 
AXI4-Stream.
+
+properties:
+  compatible:
+items:
+  - enum:
+- xlnx,v-smpte-uhdsdi-rx-ss-2.0
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  clocks:
+description: List of clock specifiers
+items:
+  - description: AXI4-Lite clock
+  - description: SMPTE UHD-SDI Rx core clock
+  - description: Video clock
+
+  clock-names:
+items:
+  - const: s_axi_aclk
+  - const: sdi_rx_clk
+  - const: video_out_clk
+
+  xlnx,bpc:
+description: Bits per component supported. Can be 10 or 12 bits per 
component only.
+allOf:
+  - $ref: "/schemas/types.yaml#/definitions/uint32"
+  - enum: [10, 12]
+
+  xlnx,line-rate:
+description: |
+  The maximum mode supported by the design. Possible values are as below
+  0 - XSDI_STD_3G  -  3G mode
+  1 - XSDI_STD_6G  -  6G mode
+  2 - XSDI_STD_12G_8DS - 12G mode with 8 data streams
+allOf:
+  - $ref: "/schemas/types.yaml#/definitions/uint32"
+  - enum: [0, 1, 2]
+
+  xlnx,include-edh:
+type: boolean
+description: |
+  This is present when the Error Detection and Handling processor is
+  enabled in design.
+
+  ports:
+type: object
+description: |
+  Generally the SDI port is connected to a device like SDI Broadcast camera
+  which is independently controlled. Hence port@0 is a source port which 
can be
+  connected to downstream IP which can work with AXI4 Stream data.
+properties:
+  port@0:
+type: object
+description: Source port
+properties:
+  reg:
+const: 0
+  endpoint:
+type: object
+properties:
+  remote-endpoint: true
+required:
+  - remote-endpoint
+additionalProperties: false
+additionalProperties: false
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+  - clock-names
+  - xlnx,line-rate
+  - ports
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+uhdsdirxss: v-smpte-uhdsdi-rxss@8000 {
+  compatible = "xlnx,v-smpte-uhdsdi-rx-ss-2.0";
+  interrupt-parent = <&gic>;
+  interrupts = <0 89 4>;
+  reg = <0x8000 0x1>;
+  xlnx,include-edh;
+  xlnx,line-rate = ;
+  clocks = <&clk_1>, <&si570_1>, <&clk_2>;
+  clock-names = "s_axi_aclk", "sdi_rx_clk", "video_out_clk";
+  xlnx,bpc = <10>;
+
+  ports {
+#address-cells = <1>;
+#size-cells = <0>;
+port@0 {
+  reg = <0>;
+  sdirx_out: endpoint {
+remote-endpoint = <&vcap_sdirx_in>;
+  };
+};
+  };
+};
+...
diff --git a/include/dt-bindings/media/xilinx-sdi.h 
b/include/dt-bindings/media/xilinx-sdi.h
new file mode 100644
index ..11938fade041
--- /dev/null
+++ b

[PATCH v3 1/3] v4l2-dv-timings: Add timings for 1920x1080P48 and 4KP48

2020-06-17 Thread Vishal Sagar
Add the timing entry for 1920x1080p48, 3840x2160p48 and 4096x2160p48
from CTA-861-G.
1920x1080p48 is VIC 111.
3840x2160P48 is VIC 114.
4096x2160P48 is VIC 115.

Signed-off-by: Vishal Sagar 
---
v3
- Added for first time

 include/uapi/linux/v4l2-dv-timings.h | 31 +++-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/include/uapi/linux/v4l2-dv-timings.h 
b/include/uapi/linux/v4l2-dv-timings.h
index b52b67c62562..6ceaa7841923 100644
--- a/include/uapi/linux/v4l2-dv-timings.h
+++ b/include/uapi/linux/v4l2-dv-timings.h
@@ -167,6 +167,16 @@
V4L2_DV_FL_HAS_CEA861_VIC, { 0, 0 }, 20) \
 }
 
+#define V4L2_DV_BT_CEA_1920X1080P48 { \
+   .type = V4L2_DV_BT_656_1120, \
+   V4L2_INIT_BT_TIMINGS(1920, 1080, 0, \
+   V4L2_DV_HSYNC_POS_POL | V4L2_DV_VSYNC_POS_POL, \
+   14850, 638, 44, 148, 4, 5, 36, 0, 0, 0, \
+   V4L2_DV_BT_STD_CEA861, \
+   V4L2_DV_FL_CAN_REDUCE_FPS | V4L2_DV_FL_IS_CE_VIDEO | \
+   V4L2_DV_FL_HAS_CEA861_VIC, { 0, 0 }, 111) \
+}
+
 #define V4L2_DV_BT_CEA_1920X1080P50 { \
.type = V4L2_DV_BT_656_1120, \
V4L2_INIT_BT_TIMINGS(1920, 1080, 0, \
@@ -229,6 +239,16 @@
{ 0, 0 }, 95, 1) \
 }
 
+#define V4L2_DV_BT_CEA_3840X2160P48 { \
+   .type = V4L2_DV_BT_656_1120, \
+   V4L2_INIT_BT_TIMINGS(3840, 2160, 0, \
+   V4L2_DV_HSYNC_POS_POL | V4L2_DV_VSYNC_POS_POL, \
+   59400, 1276, 88, 296, 8, 10, 72, 0, 0, 0, \
+   V4L2_DV_BT_STD_CEA861, \
+   V4L2_DV_FL_CAN_REDUCE_FPS | V4L2_DV_FL_IS_CE_VIDEO | \
+   V4L2_DV_FL_HAS_CEA861_VIC, { 0, 0 }, 114) \
+}
+
 #define V4L2_DV_BT_CEA_3840X2160P50 { \
.type = V4L2_DV_BT_656_1120, \
V4L2_INIT_BT_TIMINGS(3840, 2160, 0, \
@@ -278,6 +298,16 @@
V4L2_DV_FL_HAS_CEA861_VIC, { 0, 0 }, 100) \
 }
 
+#define V4L2_DV_BT_CEA_4096X2160P48 { \
+   .type = V4L2_DV_BT_656_1120, \
+   V4L2_INIT_BT_TIMINGS(4096, 2160, 0, \
+   V4L2_DV_HSYNC_POS_POL | V4L2_DV_VSYNC_POS_POL, \
+   59400, 1020, 88, 296, 8, 10, 72, 0, 0, 0, \
+   V4L2_DV_BT_STD_CEA861, \
+   V4L2_DV_FL_CAN_REDUCE_FPS | V4L2_DV_FL_IS_CE_VIDEO | \
+   V4L2_DV_FL_HAS_CEA861_VIC, { 0, 0 }, 115) \
+}
+
 #define V4L2_DV_BT_CEA_4096X2160P50 { \
.type = V4L2_DV_BT_656_1120, \
V4L2_INIT_BT_TIMINGS(4096, 2160, 0, \
@@ -297,7 +327,6 @@
V4L2_DV_FL_HAS_CEA861_VIC, { 0, 0 }, 102) \
 }
 
-
 /* VESA Discrete Monitor Timings as per version 1.0, revision 12 */
 
 #define V4L2_DV_BT_DMT_640X350P85 { \
-- 
2.21.0



[PATCH -next] lib: fix test_hmm.c reference after free

2020-06-17 Thread Randy Dunlap
From: Randy Dunlap 

Coccinelle scripts report the following errors:

lib/test_hmm.c:523:20-26: ERROR: reference preceded by free on line 521
lib/test_hmm.c:524:21-27: ERROR: reference preceded by free on line 521
lib/test_hmm.c:523:28-35: ERROR: devmem is NULL but dereferenced.
lib/test_hmm.c:524:29-36: ERROR: devmem is NULL but dereferenced.

Fix these by using the local variable 'res' instead of devmem.

Signed-off-by: Randy Dunlap 
Cc: Jérôme Glisse 
Cc: linux...@kvack.org
Cc: Ralph Campbell 
---
 lib/test_hmm.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- linux-next-20200617.orig/lib/test_hmm.c
+++ linux-next-20200617/lib/test_hmm.c
@@ -520,8 +520,7 @@ static bool dmirror_allocate_chunk(struc
 err_free:
kfree(devmem);
 err_release:
-   release_mem_region(devmem->pagemap.res.start,
-  resource_size(&devmem->pagemap.res));
+   release_mem_region(res->start, resource_size(res));
 err:
mutex_unlock(&mdevice->devmem_lock);
return false;



Re: [pipe] 566d136289: stress-ng.tee.ops_per_sec -84.7% regression

2020-06-17 Thread Tetsuo Handa
On 2020/06/18 9:51, kernel test robot wrote:
> FYI, we noticed a -84.7% regression of stress-ng.tee.ops_per_sec due to 
> commit:
> 
> 
> commit: 566d136289dc57816ac290de87a9a0f7d9bd3cbb ("pipe: Fix pipe_full() test 
> in opipe_prep().")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master

This would be because the test case shows higher performance if the pipe writer 
does busy wait.
This commit fixed an unkillable busy wait bug when the pipe reader does not try 
to read.

> If you fix the issue, kindly add following tag
> Reported-by: kernel test robot 

We can't fix the issue. ;-)



mmotm 2020-06-17-22-17 uploaded

2020-06-17 Thread akpm
The mm-of-the-moment snapshot 2020-06-17-22-17 has been uploaded to

   http://www.ozlabs.org/~akpm/mmotm/

mmotm-readme.txt says

README for mm-of-the-moment:

http://www.ozlabs.org/~akpm/mmotm/

This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
more than once a week.

You will need quilt to apply these patches to the latest Linus release (5.x
or 5.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
http://ozlabs.org/~akpm/mmotm/series

The file broken-out.tar.gz contains two datestamp files: .DATE and
.DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
followed by the base kernel version against which this patch series is to
be applied.

This tree is partially included in linux-next.  To see which patches are
included in linux-next, consult the `series' file.  Only the patches
within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
linux-next.


A full copy of the full kernel tree with the linux-next and mmotm patches
already applied is available through git within an hour of the mmotm
release.  Individual mmotm releases are tagged.  The master branch always
points to the latest release, so it's constantly rebasing.

https://github.com/hnaz/linux-mm

The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
contains daily snapshots of the -mm tree.  It is updated more frequently
than mmotm, and is untested.

A git copy of this tree is also available at

https://github.com/hnaz/linux-mm



This mmotm tree contains the following patches against 5.8-rc1:
(patches marked "*" will be included in linux-next)

  origin.patch
* openrisc-fix-boot-oops-when-debug_vm-is-enabled.patch
* mm-do_swap_page-fix-up-the-error-code-instantiation.patch
* mm-slab-use-memzero_explicit-in-kzfree.patch
* mm-workingset-age-nonresident-information-alongside-anonymous-pages.patch
* 
mm-swap-fix-for-mm-workingset-age-nonresident-information-alongside-anonymous-pages.patch
* mm-memory-fix-io-cost-for-anonymous-page.patch
* mm-fix-swap-cache-node-allocation-mask.patch
* mm-memcontrol-handle-div0-crash-race-condition-in-memorylow.patch
* mm-memcontrol-fix-do-not-put-the-css-reference.patch
* mm-memcg-prevent-missed-memorylow-load-tears.patch
* docs-mm-gup-minor-documentation-update.patch
* doc-thp-cow-fault-no-longer-allocate-thp.patch
* mm-compaction-make-capture-control-handling-safe-wrt-interrupts.patch
* 
kexec-do-not-verify-the-signature-without-the-lockdown-or-mandatory-signature.patch
* ocfs2-avoid-inode-removed-while-nfsd-access-it.patch
* ocfs2-load-global_inode_alloc.patch
* ocfs2-fix-panic-on-nfs-server-over-ocfs2.patch
* ocfs2-fix-value-of-ocfs2_invalid_slot.patch
* linux-bitsh-fix-unsigned-less-than-zero-warnings.patch
* proc-kpageflags-prevent-an-integer-overflow-in-stable_page_flags.patch
* proc-kpageflags-do-not-use-uninitialized-struct-pages.patch
* checkpatch-test-git_dir-changes.patch
* scripts-tagssh-collect-compiled-source-precisely.patch
* bloat-o-meter-support-comparing-library-archives.patch
* ocfs2-clear-links-count-in-ocfs2_mknod-if-an-error-occurs.patch
* ocfs2-fix-ocfs2-corrupt-when-iputting-an-inode.patch
* drivers-tty-serial-sh-scic-suppress-uninitialized-var-warning.patch
* ramfs-support-o_tmpfile.patch
* kernel-watchdog-flush-all-printk-nmi-buffers-when-hardlockup-detected.patch
  mm.patch
* mm-treewide-rename-kzfree-to-kfree_sensitive.patch
* mm-ksize-should-silently-accept-a-null-pointer.patch
* mm-slub-extend-slub_debug-syntax-for-multiple-blocks.patch
* mm-slub-make-some-slub_debug-related-attributes-read-only.patch
* mm-slub-remove-runtime-allocation-order-changes.patch
* mm-slub-make-remaining-slub_debug-related-attributes-read-only.patch
* mm-slub-make-reclaim_account-attribute-read-only.patch
* mm-slub-introduce-static-key-for-slub_debug.patch
* mm-slub-introduce-kmem_cache_debug_flags.patch
* mm-slub-extend-checks-guarded-by-slub_debug-static-key.patch
* mm-slab-slub-move-and-improve-cache_from_obj.patch
* mm-kcsan-instrument-slab-slub-free-with-assert_exclusive_access.patch
* 
mm-memcg-factor-out-memcg-and-lruvec-level-changes-out-of-__mod_lruvec_state.patch
* mm-memcg-prepare-for-byte-sized-vmstat-items.patch
* mm-memcg-convert-vmstat-slab-counters-to-bytes.patch
* mm-slub-implement-slub-version-of-obj_to_index.patch
* mm-memcontrol-decouple-reference-counting-from-page-accounting.patch
* mm-memcg-slab-obj_cgroup-api.patch
* mm-memcg-slab-allocate-obj_cgroups-for-non-root-slab-pages.patch
* mm-memcg-slab-save-obj_cgroup-for-non-root-slab-objects.patch
* mm-memcg-slab-charge-individual-slab-objects-instead-of-pages.patch
* mm-memcg-slab-deprecate-memorykmemslabinfo.patch
* mm-memcg-slab-move-memcg_kmem_bypass-to-memcontrolh.patch
* 
mm-memcg-slab-use-a-single-set-of-kmem_caches-for-all-accounted-allocations.patch
* mm-memcg-slab-simplify-memcg-cache-creation.patch
* mm-memcg-slab-remove-memcg_kmem_get_cache.patch
* mm-memcg-slab-deprecate-slab_root_caches.patch
* mm-memcg-slab-remove-redundan

Re: [PATCH v3 1/2] ALSA: hda/realtek: Add COEF controlled micmute LED support

2020-06-17 Thread Kai-Heng Feng



> On Jun 17, 2020, at 23:50, Takashi Iwai  wrote:
> 
> On Wed, 17 Jun 2020 17:24:30 +0200,
> Kai-Heng Feng wrote:
>> 
>> 
>> 
>>> On Jun 17, 2020, at 19:55, Takashi Iwai  wrote:
>>> 
>>> On Wed, 17 Jun 2020 12:29:01 +0200,
>>> Kai-Heng Feng wrote:
 
 Currently, HDA codec LED class can only be used by GPIO controlled LED.
 However, there are some new systems that control LED via COEF instead of
 GPIO.
 
 In order to support those systems, create a new helper that can be
 facilitated by both COEF controlled and GPIO controlled LED.
 
 In addition to that, add LED_CORE_SUSPENDRESUME flag since some systems
 don't restore the LED properly after suspend.
 
 Signed-off-by: Kai-Heng Feng 
>>> 
>>> Thanks for the quick follow up, the issues I pointed were fixed.
>>> 
>>> But, now looking at the code change again, I'm no longer sure whether
>>> it's the right move.
>>> 
>>> Basically, the led cdev should serve only for turning on/off the LED
>>> as given.  But your patch changes it to call the generic mixer
>>> updater, which is rather the one who would call the led cdev state
>>> update itself.  That is, it's other way round.
>>> 
>>> IMO, what we need is to make all places calling
>>> snd_hda_gen_add_micmute_led() to create led cdev, and change those
>>> calls with snd_hda_gen_fixup_micmute_led().
>> 
>> Ok, so it's the same as patch v1.
>> How should we handle vendors other than HP?
>> Only create led cdev if the ID matches to HP?
> 
> It's fine to create a LED classdev for other vendors, too.  But the
> problem is that it wasn't consistent.  With the LED classdev, we
> should use only cdev, instead of mixing up different ways.

Ok, now I get what you meant...

> 
> I wrote a few patches to convert those mic-mute LED stuff to classdev,
> including some cleanups.  The patches are found in
> topic/hda-micmute-led branch of sound git tree.  Could you check it?
> 
> Note that it's totally untested.  Also it doesn't contain yet
> LED_CORE_SUSPENDRESUME, which should be done in another patch in
> anyway.

Other than LED_CORE_SUSPENDRESUME, it works great!

Tested-by: Kai-Heng Feng 

> 
>>> It'll be a bit more changes and likely not fitting with 5.8, but the
>>> whole result will be more consistent.
>> 
>> A bit off topic, but do you think it's reasonable to also create led cdev 
>> for mute LED, in addition to micmute LED?
>> I just found that the LEDs are still on during system suspend, and led cdev 
>> has the ability to turn off the LEDs on system suspend.
> 
> Yes, it makes sense, too.  But the playback mute handling is a bit
> more complicated than the mic-mute LED because it's implemented with a
> vmaster hook.  I'll take a look later.

Thanks. I'll be happy to test it.

Kai-Heng

> 
> 
> thanks,
> 
> Takashi



Re: [Tee-dev] [PATCHv8 1/3] optee: use uuid for sysfs driver entry

2020-06-17 Thread Sumit Garg
On Thu, 18 Jun 2020 at 10:29, Sumit Garg  wrote:
>
> Hi Jerome,
>
> On Wed, 17 Jun 2020 at 20:46, Jerome Forissier  wrote:
> >
> >
> >
> > On 6/17/20 3:58 PM, Sumit Garg wrote:
> > > Hi Maxim,
> > >
> > > On Thu, 4 Jun 2020 at 23:28, Maxim Uvarov  wrote:
> > >>
> > >> With the evolving use-cases for TEE bus, now it's required to support
> > >> multi-stage enumeration process. But using a simple index doesn't
> > >> suffice this requirement and instead leads to duplicate sysfs entries.
> > >> So instead switch to use more informative device UUID for sysfs entry
> > >> like:
> > >> /sys/bus/tee/devices/optee-ta-
> > >>
> > >> Signed-off-by: Maxim Uvarov 
> > >> Reviewed-by: Sumit Garg 
> > >> ---
> > >>  Documentation/ABI/testing/sysfs-bus-optee-devices | 8 
> > >>  MAINTAINERS   | 1 +
> > >>  drivers/tee/optee/device.c| 9 ++---
> > >>  3 files changed, 15 insertions(+), 3 deletions(-)
> > >>  create mode 100644 Documentation/ABI/testing/sysfs-bus-optee-devices
> > >>
> > >> diff --git a/Documentation/ABI/testing/sysfs-bus-optee-devices 
> > >> b/Documentation/ABI/testing/sysfs-bus-optee-devices
> > >> new file mode 100644
> > >> index ..0ae04ae5374a
> > >> --- /dev/null
> > >> +++ b/Documentation/ABI/testing/sysfs-bus-optee-devices
> > >> @@ -0,0 +1,8 @@
> > >> +What:  /sys/bus/tee/devices/optee-ta-/
> > >> +Date:   May 2020
> > >> +KernelVersion   5.7
> > >> +Contact:tee-...@lists.linaro.org
> > >> +Description:
> > >> +   OP-TEE bus provides reference to registered drivers 
> > >> under this directory. The 
> > >> +   matches Trusted Application (TA) driver and 
> > >> corresponding TA in secure OS. Drivers
> > >> +   are free to create needed API under optee-ta- 
> > >> directory.
> > >> diff --git a/MAINTAINERS b/MAINTAINERS
> > >> index ecc0749810b0..6717afef2de3 100644
> > >> --- a/MAINTAINERS
> > >> +++ b/MAINTAINERS
> > >> @@ -12516,6 +12516,7 @@ OP-TEE DRIVER
> > >>  M: Jens Wiklander 
> > >>  L: tee-...@lists.linaro.org
> > >>  S: Maintained
> > >> +F: Documentation/ABI/testing/sysfs-bus-optee-devices
> > >>  F: drivers/tee/optee/
> > >>
> > >>  OP-TEE RANDOM NUMBER GENERATOR (RNG) DRIVER
> > >> diff --git a/drivers/tee/optee/device.c b/drivers/tee/optee/device.c
> > >> index e3a148521ec1..23d264c8146e 100644
> > >> --- a/drivers/tee/optee/device.c
> > >> +++ b/drivers/tee/optee/device.c
> > >> @@ -65,7 +65,7 @@ static int get_devices(struct tee_context *ctx, u32 
> > >> session,
> > >> return 0;
> > >>  }
> > >>
> > >> -static int optee_register_device(const uuid_t *device_uuid, u32 
> > >> device_id)
> > >> +static int optee_register_device(const uuid_t *device_uuid)
> > >>  {
> > >> struct tee_client_device *optee_device = NULL;
> > >> int rc;
> > >> @@ -75,7 +75,10 @@ static int optee_register_device(const uuid_t 
> > >> *device_uuid, u32 device_id)
> > >> return -ENOMEM;
> > >>
> > >> optee_device->dev.bus = &tee_bus_type;
> > >> -   dev_set_name(&optee_device->dev, "optee-clnt%u", device_id);
> > >> +   if (dev_set_name(&optee_device->dev, "optee-ta-%pUl", 
> > >> device_uuid)) {
> > >
> > > You should be using format specifier as: "%pUb" instead of "%pUl" as
> > > UUID representation for TAs is in big endian format. See below:
> >
> > Where does device_uuid come from? If it comes directly from OP-TEE, then
> > it should be a pointer to the following struct:
> >
> > typedef struct
> > {
> > uint32_t timeLow;
> > uint16_t timeMid;
> > uint16_t timeHiAndVersion;
> > uint8_t clockSeqAndNode[8];
> > } TEE_UUID;
> >
> > (GlobalPlatform TEE Internal Core API spec v1.2.1 section 3.2.4)
> >
> > - The spec does not mandate any particular endianness and simply warns
> > about possible issues if secure and non-secure worlds differ in endianness.
> > - OP-TEE uses %pUl assuming that host order is little endian (that is
> > true for the Arm platforms that run OP-TEE currently). By the same logic
> > %pUl should be fine in the kernel.

I think Linux adheres to this RFC [1] for UUID byte order. See below
snippet from section: "Layout and Byte Order":

   The fields are encoded as 16 octets, with the sizes and order of the
   fields defined above, and with each field encoded with the Most
   Significant Byte first (known as network byte order).  Note that the
   field names, particularly for multiplexed fields, follow historical
   practice.

-Sumit

[1] https://tools.ietf.org/html/rfc4122

> > - On the other hand, the UUID in a Trusted App header is always encoded
> > big endian by the Python script that signs and optionally encrypts the
> > TA. This should not have any visible impact on UUIDs exchanged between
> > the secure and non-secure world though.
> >
> > So I am wondering why you had to use %pUb. There must be some
> > inconsistency somewhere :-/
>
> 

Re: [PATCH] sparse: use identifiers to define address spaces

2020-06-17 Thread Luc Van Oostenryck
On Thu, Jun 18, 2020 at 03:22:15AM +0200, Miguel Ojeda wrote:
> Hi Luc,

Hi Miguel,

> On Thu, Jun 18, 2020 at 12:02 AM Luc Van Oostenryck
>  wrote:
> >
> > diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
> > index 21aed0981edf..e368384445b6 100644
> > --- a/include/linux/compiler_types.h
> > +++ b/include/linux/compiler_types.h
> > @@ -5,20 +5,20 @@
> >  #ifndef __ASSEMBLY__
> >
> >  #ifdef __CHECKER__
> > -# define __user__attribute__((noderef, address_space(1)))
> >  # define __kernel  __attribute__((address_space(0)))
> > +# define __user__attribute__((noderef, 
> > address_space(__user)))
> 
> I guess `__kernel` moves to the first place since it uses the first
> address space?

No, there is no really an order between address spaces. Even before
this patch, the number were only used as an ID to distinguish them
from each other.

I just moved __kernel above because it is quite different from
the others because it's the default one, and so:
* it's never displayed
* it's normally not needed, nor in type annotations, nor in cast
  between address spaces. The only time it's needed is when it's
  combined with a typeof to express "the same type as this one but
  without the address space"
* it can't be defined with a name, '0' must be used.

So, it seemed strange to me to have it in the middle of the other ones.
   
-- Luc


Re: [Tee-dev] [PATCHv8 1/3] optee: use uuid for sysfs driver entry

2020-06-17 Thread Sumit Garg
Hi Jerome,

On Wed, 17 Jun 2020 at 20:46, Jerome Forissier  wrote:
>
>
>
> On 6/17/20 3:58 PM, Sumit Garg wrote:
> > Hi Maxim,
> >
> > On Thu, 4 Jun 2020 at 23:28, Maxim Uvarov  wrote:
> >>
> >> With the evolving use-cases for TEE bus, now it's required to support
> >> multi-stage enumeration process. But using a simple index doesn't
> >> suffice this requirement and instead leads to duplicate sysfs entries.
> >> So instead switch to use more informative device UUID for sysfs entry
> >> like:
> >> /sys/bus/tee/devices/optee-ta-
> >>
> >> Signed-off-by: Maxim Uvarov 
> >> Reviewed-by: Sumit Garg 
> >> ---
> >>  Documentation/ABI/testing/sysfs-bus-optee-devices | 8 
> >>  MAINTAINERS   | 1 +
> >>  drivers/tee/optee/device.c| 9 ++---
> >>  3 files changed, 15 insertions(+), 3 deletions(-)
> >>  create mode 100644 Documentation/ABI/testing/sysfs-bus-optee-devices
> >>
> >> diff --git a/Documentation/ABI/testing/sysfs-bus-optee-devices 
> >> b/Documentation/ABI/testing/sysfs-bus-optee-devices
> >> new file mode 100644
> >> index ..0ae04ae5374a
> >> --- /dev/null
> >> +++ b/Documentation/ABI/testing/sysfs-bus-optee-devices
> >> @@ -0,0 +1,8 @@
> >> +What:  /sys/bus/tee/devices/optee-ta-/
> >> +Date:   May 2020
> >> +KernelVersion   5.7
> >> +Contact:tee-...@lists.linaro.org
> >> +Description:
> >> +   OP-TEE bus provides reference to registered drivers under 
> >> this directory. The 
> >> +   matches Trusted Application (TA) driver and corresponding 
> >> TA in secure OS. Drivers
> >> +   are free to create needed API under optee-ta- 
> >> directory.
> >> diff --git a/MAINTAINERS b/MAINTAINERS
> >> index ecc0749810b0..6717afef2de3 100644
> >> --- a/MAINTAINERS
> >> +++ b/MAINTAINERS
> >> @@ -12516,6 +12516,7 @@ OP-TEE DRIVER
> >>  M: Jens Wiklander 
> >>  L: tee-...@lists.linaro.org
> >>  S: Maintained
> >> +F: Documentation/ABI/testing/sysfs-bus-optee-devices
> >>  F: drivers/tee/optee/
> >>
> >>  OP-TEE RANDOM NUMBER GENERATOR (RNG) DRIVER
> >> diff --git a/drivers/tee/optee/device.c b/drivers/tee/optee/device.c
> >> index e3a148521ec1..23d264c8146e 100644
> >> --- a/drivers/tee/optee/device.c
> >> +++ b/drivers/tee/optee/device.c
> >> @@ -65,7 +65,7 @@ static int get_devices(struct tee_context *ctx, u32 
> >> session,
> >> return 0;
> >>  }
> >>
> >> -static int optee_register_device(const uuid_t *device_uuid, u32 device_id)
> >> +static int optee_register_device(const uuid_t *device_uuid)
> >>  {
> >> struct tee_client_device *optee_device = NULL;
> >> int rc;
> >> @@ -75,7 +75,10 @@ static int optee_register_device(const uuid_t 
> >> *device_uuid, u32 device_id)
> >> return -ENOMEM;
> >>
> >> optee_device->dev.bus = &tee_bus_type;
> >> -   dev_set_name(&optee_device->dev, "optee-clnt%u", device_id);
> >> +   if (dev_set_name(&optee_device->dev, "optee-ta-%pUl", 
> >> device_uuid)) {
> >
> > You should be using format specifier as: "%pUb" instead of "%pUl" as
> > UUID representation for TAs is in big endian format. See below:
>
> Where does device_uuid come from? If it comes directly from OP-TEE, then
> it should be a pointer to the following struct:
>
> typedef struct
> {
> uint32_t timeLow;
> uint16_t timeMid;
> uint16_t timeHiAndVersion;
> uint8_t clockSeqAndNode[8];
> } TEE_UUID;
>
> (GlobalPlatform TEE Internal Core API spec v1.2.1 section 3.2.4)
>
> - The spec does not mandate any particular endianness and simply warns
> about possible issues if secure and non-secure worlds differ in endianness.
> - OP-TEE uses %pUl assuming that host order is little endian (that is
> true for the Arm platforms that run OP-TEE currently). By the same logic
> %pUl should be fine in the kernel.
> - On the other hand, the UUID in a Trusted App header is always encoded
> big endian by the Python script that signs and optionally encrypts the
> TA. This should not have any visible impact on UUIDs exchanged between
> the secure and non-secure world though.
>
> So I am wondering why you had to use %pUb. There must be some
> inconsistency somewhere :-/

Yes there is. Linux stores UUID in big endian format (16 byte octets)
and OP-TEE stores UUID in little endian format (in form of struct you
referenced above).

And format conversion APIs [1] in OP-TEE OS are used while passing
UUID among Linux and OP-TEE.

So we need to use %pUb in case of Linux and %pUl in case of OP-TEE.

[1] https://github.com/OP-TEE/optee_os/blob/master/core/tee/uuid.c

-Sumit

>
> --
> Jerome
>
> >
> > # ls /sys/bus/tee/devices/
> > optee-ta-405b6ad9-e5c3-e321-8794-1002a5d5c61b
> > optee-ta-71d950bc-c9d4-c442-82cb-343fb7f37896
> > optee-ta-e70f4af0-5d1f-9b4b-abf7-619b85b4ce8c
> >
> > While UUID for fTPM TA is in big endian format:
> > bc50d971-d4c9-42c4-82cb-343fb7f37896
> >
> > Sorry that I missed it during 

Re: [PATCH v6 0/6] DVFS for IO devices on sdm845 and sc7180

2020-06-17 Thread Rajendra Nayak

Hey Matthias, thanks for summarizing this.

On 6/18/2020 3:45 AM, Matthias Kaehlcke wrote:

What is the plan for landing these, it seems not all must/should
go through the QCOM tree.

My guesses:

tty: serial: qcom_geni_serial: Use OPP API to set clk/perf state
spi: spi-geni-qcom: Use OPP API to set clk/perf state
   QCOM tree due to shared dependency on change in include/linux/qcom-geni-se.h


That's correct, Bjorn/Andy, can these be pulled in now for 5.9?
They have acks from Greg for serial and Mark for the spi patch.
 

drm/msm/dpu: Use OPP API to set clk/perf state
drm/msm: dsi: Use OPP API to set clk/perf state
   drm/msm tree


Correct, the dsi patch is still not reviewed by Rob, so once that's done,
I am guessing Rob would pull both of these.



media: venus: core: Add support for opp tables/perf voting
   venus tree


correct, this is pending review/ack from Stan.



spi: spi-qcom-qspi: Use OPP API to set clk/perf state
   SPI tree


Right, Mark has this acked, I am guessing he will pull this in at
some point.

thanks,
Rajendra




Does this make sense or are there any dependencies I'm missing?

Thanks

Matthias

On Mon, Jun 15, 2020 at 05:32:38PM +0530, Rajendra Nayak wrote:

Changes in v6:
1. rebased on 5.8-rc1, no functional change.

Changes in v5:
1. Opp cleanup path fixed up across drivers

Changes in v4:
1. Fixed all review feedback on v3
2. Dropped the dts patches, will post as a seperate series once
driver changes are reviewed and merged.
The driver changes without DT updates to include OPP tables will
have zero functional change.
3. Dropped the mmc/sdhc patch, which is a standalone patch. will
repost if needed seperately.

Changes in v3:
1. Added better error handling for dev_pm_opp_of_add_table()
2. Some minor changes and fixes in 'PATCH 12/17' as compared to v2
3. Dropped the mmc patch picked up by Ulf [2]

Changes in v2:
1. Added error handling for dev_pm_opp_set_clkname()
and dev_pm_opp_of_add_table()
2. Used dev_pm_opp_put_clkname() in the cleanup path
3. Dropped the OPP patch pulled in by Viresh [1]
4. Dropped the UFS patches since they had some major rework
needed because of changes that were merged in the merge window
and I don't have a UFS device currently to validate the changes.

We have had support added in the OPP core for a while now to support
DVFS for IO devices, and this series uses that infrastructure to
add DVFS support for various IO devices in sdm845 and sc7180 SoCs.

[1] https://lkml.org/lkml/2020/4/14/98
[2] https://lore.kernel.org/patchwork/patch/1226381/

Rajendra Nayak (6):
   tty: serial: qcom_geni_serial: Use OPP API to set clk/perf state
   spi: spi-geni-qcom: Use OPP API to set clk/perf state
   drm/msm/dpu: Use OPP API to set clk/perf state
   drm/msm: dsi: Use OPP API to set clk/perf state
   media: venus: core: Add support for opp tables/perf voting
   spi: spi-qcom-qspi: Use OPP API to set clk/perf state

  drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c  |  3 +-
  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 26 +++-
  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h|  4 ++
  drivers/gpu/drm/msm/dsi/dsi.h  |  2 +
  drivers/gpu/drm/msm/dsi/dsi_cfg.c  |  4 +-
  drivers/gpu/drm/msm/dsi/dsi_host.c | 58 ++
  drivers/media/platform/qcom/venus/core.c   | 43 ---
  drivers/media/platform/qcom/venus/core.h   |  5 +++
  drivers/media/platform/qcom/venus/pm_helpers.c | 54 ++--
  drivers/spi/spi-geni-qcom.c| 26 ++--
  drivers/spi/spi-qcom-qspi.c| 28 -
  drivers/tty/serial/qcom_geni_serial.c  | 34 ---
  include/linux/qcom-geni-se.h   |  4 ++
  13 files changed, 268 insertions(+), 23 deletions(-)

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



--
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 Jun 18

2020-06-17 Thread Stephen Rothwell
Hi all,

News: there will be no linux-next release tomorrow.

Changes since 20200617:

My fixes tree contains:

  4cb4bfffe2c1 ("device_cgroup: Fix RCU list debugging warning")

The ipsec tree gained conflicts against Linus' tree.

The amdgpu tree still had its build failure so I used the version from
next-20200616.

The pidfd tree gained a conflict against the powerpc-fixes tree.

Non-merge commits (relative to Linus' tree): 1549
 1605 files changed, 252975 insertions(+), 21474 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 htmldocs. 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 320 trees (counting Linus' and 82 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 (1b5044021070 Merge tag 'dma-mapping-5.8-3' of 
git://git.infradead.org/users/hch/dma-mapping)
Merging fixes/master (df8cb0ea9423 device_cgroup: Fix RCU list debugging 
warning)
Merging kbuild-current/fixes (0f50d21ade11 scripts: Fix typo in 
headers_install.sh)
Merging arc-current/for-curr (040ece2a3c15 ARC: build: remove deprecated toggle 
for arc700 builds)
Merging arm-current/fixes (3866f217aaa8 ARM: 8977/1: ptrace: Fix mask for thumb 
breakpoint hook)
Merging arm-soc-fixes/arm/fixes (99706d62fb50 Merge tag 
'omap-for-v5.7/cpsw-fixes-signed' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/fixes)
Merging uniphier-fixes/fixes (0e698dfa2822 Linux 5.7-rc4)
Merging arm64-fixes/for-next/fixes (b9249cba25a5 arm64: bti: Require clang >= 
10.0.1 for in-kernel BTI support)
Merging m68k-current/for-linus (3381df095419 m68k: tools: Replace zero-length 
array with flexible-array member)
Merging powerpc-fixes/fixes (b55129f97aee powerpc/8xx: Provide ptep_get() with 
16k pages)
Merging s390-fixes/fixes (b3583fca5fb6 s390: fix syscall_get_error for compat 
processes)
Merging sparc/master (b3a9e3b9622a Linux 5.8-rc1)
Merging fscrypt-current/for-stable (2b4eae95c736 fscrypt: don't evict dirty 
inodes after removing key)
Merging net/master (ef7232da6bcd ionic: export features for vlans to use)
Merging bpf/master (8030e250d882 bpf: Document optval > PAGE_SIZE behavior for 
sockopt hooks)
Merging ipsec/master (be01369859b8 esp, ah: modernize the crypto algorithm 
selections)
CONFLICT (content): Merge conflict in net/ipv6/Kconfig
CONFLICT (content): Merge conflict in net/ipv4/Kconfig
Merging netfilter/master (c92cbaea3cc0 net: dsa: sja1105: fix PTP timestamping 
with large tc-taprio cycles)
Merging ipvs/master (bdc48fa11e46 checkpatch/coding-style: deprecate 80-column 
warning)
Merging wireless-drivers/master (b3a9e3b9622a Linux 5.8-rc1)
Merging mac80211/master (59d4bfc1e2c0 net: fix wiki website url mac80211 and 
wireless files)
Merging rdma-fixes/for-rc (b3a9e3b9622a Linux 5.8-rc1)
Merging sound-current/for-linus (b2c22910fe5a ALSA: hda/realtek: Add mute LED 
and micmute LED support for HP systems)
Merging sound-asoc-fixes/for-linus (a884e26fea98 Merge remote-tracking branch 
'asoc/for-5.8' into asoc-linus)
Merging regmap-fixes/for-linus (82228364de4a Merge remote-tracking branch 
'regmap/for-5.8' into regmap-linus)
Merging regulator-fixes/for-linus (1b3bcca20858 regulator: mt6358: Remove 
BROKEN dependency)
Merging spi-fixes/for-linus (1c8794921564 Merge remote-tracking branch 
&#

Re: [PATCH 00/12] KVM: arm64: Support stage2 hardware DBM

2020-06-17 Thread zhukeqian
Hi,

On 2020/6/16 17:35, Keqian Zhu wrote:
> This patch series add support for stage2 hardware DBM, and it is only
> used for dirty log for now.
> 
> It works well under some migration test cases, including VM with 4K
> pages or 2M THP. I checked the SHA256 hash digest of all memory and
> they keep same for source VM and destination VM, which means no dirty
> pages is missed under hardware DBM.
> 
> Some key points:
> 
> 1. Only support hardware updates of dirty status for PTEs. PMDs and PUDs
>are not involved for now.
> 
> 2. About *performance*: In RFC patch, I have mentioned that for every 64GB
>memory, KVM consumes about 40ms to scan all PTEs to collect dirty log.
>
>Initially, I plan to solve this problem using parallel CPUs. However
>I faced two problems.
> 
>The first is bottleneck of memory bandwith. Single thread will occupy
>bandwidth about 500GB/s, we can support about 4 parallel threads at
>most, so the ideal speedup ratio is low.
Aha, I make it wrong here. I test it again, and find that speedup ratio can
be about 23x when I use 32 CPUs to scan PTs (takes about 5ms when scanning PTs
of 200GB RAM).

> 
>The second is huge impact on other CPUs. To scan PTs quickly, I use
>smp_call_function_many, which is based on IPI, to dispatch workload
>on other CPUs. Though it can complete work in time, the interrupt is
>disabled during scaning PTs, which has huge impact on other CPUs.
I think we can divide scanning workload into smaller ones, which can disable
and enable interrupts periodly.

> 
>Now, I make hardware dirty log can be dynamic enabled and disabled.
>Userspace can enable it before VM migration and disable it when
>remaining dirty pages is little. Thus VM downtime is not affected. 
BTW, we can reserve this interface for userspace if CPU computing resources
are not enough.

Thanks,
Keqian
> 
> 
> 3. About correctness: Only add DBM bit when PTE is already writable, so
>we still have readonly PTE and some mechanisms which rely on readonly
>PTs are not broken.
> 
> 4. About PTs modification races: There are two kinds of PTs modification.
>
>The first is adding or clearing specific bit, such as AF or RW. All
>these operations have been converted to be atomic, avoid covering
>dirty status set by hardware.
>
>The second is replacement, such as PTEs unmapping or changement. All
>these operations will invoke kvm_set_pte finally. kvm_set_pte have
>been converted to be atomic and we save the dirty status to underlying
>bitmap if dirty status is coverred.
> 
> 
> Keqian Zhu (12):
>   KVM: arm64: Add some basic functions to support hw DBM
>   KVM: arm64: Modify stage2 young mechanism to support hw DBM
>   KVM: arm64: Report hardware dirty status of stage2 PTE if coverred
>   KVM: arm64: Support clear DBM bit for PTEs
>   KVM: arm64: Add KVM_CAP_ARM_HW_DIRTY_LOG capability
>   KVM: arm64: Set DBM bit of PTEs during write protecting
>   KVM: arm64: Scan PTEs to sync dirty log
>   KVM: Omit dirty log sync in log clear if initially all set
>   KVM: arm64: Steply write protect page table by mask bit
>   KVM: arm64: Save stage2 PTE dirty status if it is coverred
>   KVM: arm64: Support disable hw dirty log after enable
>   KVM: arm64: Enable stage2 hardware DBM
> 
>  arch/arm64/include/asm/kvm_host.h |  11 +
>  arch/arm64/include/asm/kvm_mmu.h  |  56 +++-
>  arch/arm64/include/asm/sysreg.h   |   2 +
>  arch/arm64/kvm/arm.c  |  22 +-
>  arch/arm64/kvm/mmu.c  | 411 --
>  arch/arm64/kvm/reset.c|  14 +-
>  include/uapi/linux/kvm.h  |   1 +
>  tools/include/uapi/linux/kvm.h|   1 +
>  virt/kvm/kvm_main.c   |   7 +-
>  9 files changed, 499 insertions(+), 26 deletions(-)
> 


memory leak in macvlan_hash_add_source

2020-06-17 Thread syzbot
Hello,

syzbot found the following crash on:

HEAD commit:7ae77150 Merge tag 'powerpc-5.8-1' of git://git.kernel.org..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=11fbb45610
kernel config:  https://syzkaller.appspot.com/x/.config?x=9a1aa05456dfd557
dashboard link: https://syzkaller.appspot.com/bug?extid=62100d232f618b7da606
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=163092a910
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=12caed7a10

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+62100d232f618b7da...@syzkaller.appspotmail.com

BUG: memory leak
unreferenced object 0x888115ac4080 (size 64):
  comm "syz-executor882", pid 6646, jiffies 4294954688 (age 14.840s)
  hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 20 ee 41 15 81 88 ff ff   .A.
00 09 92 15 81 88 ff ff aa aa aa aa aa 23 00 00  .#..
  backtrace:
[] kmalloc include/linux/slab.h:555 [inline]
[] macvlan_hash_add_source+0x52/0xe0 
drivers/net/macvlan.c:161
[<5aee7a07>] macvlan_changelink_sources+0x8a/0x1f0 
drivers/net/macvlan.c:1355
[] macvlan_common_newlink+0x21a/0x570 
drivers/net/macvlan.c:1463
[] __rtnl_newlink+0x843/0xb10 net/core/rtnetlink.c:3340
[<9677515c>] rtnl_newlink+0x49/0x70 net/core/rtnetlink.c:3398
[] rtnetlink_rcv_msg+0x173/0x4b0 net/core/rtnetlink.c:5461
[] netlink_rcv_skb+0x5a/0x180 
net/netlink/af_netlink.c:2469
[] netlink_unicast_kernel net/netlink/af_netlink.c:1303 
[inline]
[] netlink_unicast+0x20a/0x2f0 
net/netlink/af_netlink.c:1329
[<6a00463c>] netlink_sendmsg+0x2b5/0x560 
net/netlink/af_netlink.c:1918
[] sock_sendmsg_nosec net/socket.c:652 [inline]
[] sock_sendmsg+0x4c/0x60 net/socket.c:672
[<0ca330a5>] sys_sendmsg+0x118/0x2f0 net/socket.c:2352
[<6a5fc310>] ___sys_sendmsg+0x8a/0xd0 net/socket.c:2406
[<4d3b2570>] __sys_sendmmsg+0xda/0x230 net/socket.c:2496
[] __do_sys_sendmmsg net/socket.c:2525 [inline]
[] __se_sys_sendmmsg net/socket.c:2522 [inline]
[] __x64_sys_sendmmsg+0x24/0x30 net/socket.c:2522
[<333adef2>] do_syscall_64+0x6e/0x220 arch/x86/entry/common.c:295
[] entry_SYSCALL_64_after_hwframe+0x44/0xa9



---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches


[PATCH] [net/sched]: Remove redundant condition in qdisc_graft

2020-06-17 Thread Gaurav Singh
parent cannot be NULL here since its in the else part
of the if (parent == NULL) condition. Remove the extra
check on parent pointer.

Signed-off-by: Gaurav Singh 
---
 net/sched/sch_api.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c
index 9a3449b56bd6..be93ebcdb18d 100644
--- a/net/sched/sch_api.c
+++ b/net/sched/sch_api.c
@@ -1094,7 +1094,7 @@ static int qdisc_graft(struct net_device *dev, struct 
Qdisc *parent,
 
/* Only support running class lockless if parent is lockless */
if (new && (new->flags & TCQ_F_NOLOCK) &&
-   parent && !(parent->flags & TCQ_F_NOLOCK))
+   !(parent->flags & TCQ_F_NOLOCK))
qdisc_clear_nolock(new);
 
if (!cops || !cops->graft)
-- 
2.17.1



RE: [PATCH V2 2/9] ARM: imx: Select MXC_CLK for ARCH_MXC

2020-06-17 Thread Aisheng Dong
> From: Anson Huang 
> Sent: Thursday, June 18, 2020 11:18 AM
> 
> > From: Aisheng Dong 
> > Sent: 2020年6月18日 11:09
> >
> > > From: Anson Huang 
> > > Sent: Wednesday, June 17, 2020 8:36 PM
> > >
> > > > Subject: RE: [PATCH V2 2/9] ARM: imx: Select MXC_CLK for ARCH_MXC
> > > >
> > > > > From: Anson Huang 
> > > > > Sent: Tuesday, June 9, 2020 3:32 PM
> > > > >
> > > > > i.MX common clock drivers may support module build, so it is NOT
> > > > > selected by default, for ARCH_MXC ARMv7 platforms, need to
> > > > > select it manually to make build pass.
> > > > >
> > > > > Signed-off-by: Anson Huang 
> > > >
> > > > Can't the original def_xxx work?
> > > >
> > > > config MXC_CLK
> > > > tristate
> > > > def_tristate ARCH_MXC
> > >
> > > Such change will make MXC_CLK=y even all i.MX8 SoCs clock drivers
> > > are selected as module, so it does NOT meet the requirement of
> > > module support. Below is from .config when all
> > > i.MX8 SoCs clock drivers are configured to module.
> > >
> > >  CONFIG_MXC_CLK=y
> > >  CONFIG_MXC_CLK_SCU=m
> > >  CONFIG_CLK_IMX8MM=m
> > >  CONFIG_CLK_IMX8MN=m
> > >  CONFIG_CLK_IMX8MP=m
> > >  CONFIG_CLK_IMX8MQ=m
> > >  CONFIG_CLK_IMX8QXP=m
> > >
> >
> > It works at my side.
> > Below is my changes based on your patchset:
> > $ git diff
> > diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> > index
> > 47b10d20f411..e7d7b90e2cf8 100644
> > --- a/arch/arm/mach-imx/Kconfig
> > +++ b/arch/arm/mach-imx/Kconfig
> > @@ -4,7 +4,6 @@ menuconfig ARCH_MXC
> > depends on ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7 ||
> > ARM_SINGLE_ARMV7M
> > select ARCH_SUPPORTS_BIG_ENDIAN
> > select CLKSRC_IMX_GPT
> > -   select MXC_CLK
> > select GENERIC_IRQ_CHIP
> > select GPIOLIB
> > select PINCTRL
> > diff --git a/drivers/clk/imx/Kconfig b/drivers/clk/imx/Kconfig index
> > 26cedbfe386c..f7b3e3a2cb9f 100644
> > --- a/drivers/clk/imx/Kconfig
> > +++ b/drivers/clk/imx/Kconfig
> > @@ -3,6 +3,7 @@
> >  config MXC_CLK
> > tristate "IMX clock"
> > depends on ARCH_MXC
> > +   def_tristate ARCH_MXC
> >
> >  config MXC_CLK_SCU
> > tristate "IMX SCU clock"
> >
> 
> I guess you tried imx_v6_v7_defconfig? It does NOT work for ARM64 defconfig
> when we try to make CONFIG_MXC_CLK=m, Below are my change, you can see
> in .config, even all i.MX8 SoCs clock drivers are configured to module, the
> CONFIG_MXC_CLK is still =y, but the expected result is =m.
> 

It works at my side because it can manually selected as m or add 
CONFIG_MXC_CLK=m
In defconfig.
But now I got your point you want CONFIG_MXC_CLK default to m once define
CONFIG_CLK_IMX8X=m in defconfig.

> BTW, all i.MX8 SoCs select MXC_CLK in their kconfig, this patch just does the
> same thing for i.MX6/7 in common place.
> 

I just noticed for MX6&7, actually CONFIG_MXC_CLK can't be m otherwise we will 
meet build break.
That means CONFIG_MXC_CLK cannot be configurable by users for non-ARM64 
platforms.
Thus can't use def_tristate and we still need select it under ARCH_MXC.
This lightly lose a bit meaning to make this core library as module.

IMHO I'd still prefer to builtin those core libraries rather than convert to 
module.

Regards
Aisheng

> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig index
> 47b10d2..e7d7b90 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -4,7 +4,6 @@ menuconfig ARCH_MXC
> depends on ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7 ||
> ARM_SINGLE_ARMV7M
> select ARCH_SUPPORTS_BIG_ENDIAN
> select CLKSRC_IMX_GPT
> -   select MXC_CLK
> select GENERIC_IRQ_CHIP
> select GPIOLIB
> select PINCTRL
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index
> 8222e4b..21e2dbb 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -799,11 +799,11 @@ CONFIG_COMMON_CLK_S2MPS11=y
> CONFIG_COMMON_CLK_PWM=y  CONFIG_COMMON_CLK_VC5=y
> CONFIG_CLK_RASPBERRYPI=m -CONFIG_CLK_IMX8MM=y
> -CONFIG_CLK_IMX8MN=y -CONFIG_CLK_IMX8MP=y -CONFIG_CLK_IMX8MQ=y
> -CONFIG_CLK_IMX8QXP=y
> +CONFIG_CLK_IMX8MM=m
> +CONFIG_CLK_IMX8MN=m
> +CONFIG_CLK_IMX8MP=m
> +CONFIG_CLK_IMX8MQ=m
> +CONFIG_CLK_IMX8QXP=m
>  CONFIG_TI_SCI_CLK=y
>  CONFIG_COMMON_CLK_QCOM=y
>  CONFIG_QCOM_A53PLL=y
> diff --git a/drivers/clk/imx/Kconfig b/drivers/clk/imx/Kconfig index
> 26cedbf..f7b3e3a 100644
> --- a/drivers/clk/imx/Kconfig
> +++ b/drivers/clk/imx/Kconfig
> @@ -3,6 +3,7 @@
>  config MXC_CLK
> tristate "IMX clock"
> depends on ARCH_MXC
> +   def_tristate ARCH_MXC
> 
>  config MXC_CLK_SCU
> tristate "IMX SCU clock"
> 
> .config:
>  CONFIG_MXC_CLK=y
>  CONFIG_MXC_CLK_SCU=m
>  CONFIG_CLK_IMX8MM=m
>  CONFIG_CLK_IMX8MN=m
>  CONFIG_CLK_IMX8MP=m
>  CONFIG_CLK_IMX8MQ=m
>  CONFIG_CLK_IMX8QXP=m
> 
> Anson


[PATCH] kunit: fix KconfigParseError by ignoring CC_VERSION_TEXT

2020-06-17 Thread Vitor Massaru Iha
Commit 8b59cd81dc5 ("kbuild: ensure full rebuild when the compiler
is updated") added the environment variable CC_VERSION_TEXT,
parse_from_string() doesn't expect a string and this causes the
failure below:

[iha@bbking linux]$ tools/testing/kunit/kunit.py run --timeout=60
[00:20:12] Configuring KUnit Kernel ...
Generating .config ...
Traceback (most recent call last):
  File "tools/testing/kunit/kunit.py", line 347, in 
main(sys.argv[1:])
  File "tools/testing/kunit/kunit.py", line 257, in main
result = run_tests(linux, request)
  File "tools/testing/kunit/kunit.py", line 134, in run_tests
config_result = config_tests(linux, config_request)
  File "tools/testing/kunit/kunit.py", line 64, in config_tests
success = linux.build_reconfig(request.build_dir, request.make_options)
  File "/home/iha/lkmp/linux/tools/testing/kunit/kunit_kernel.py", line 161, in 
build_reconfig
return self.build_config(build_dir, make_options)
  File "/home/iha/lkmp/linux/tools/testing/kunit/kunit_kernel.py", line 145, in 
build_config
return self.validate_config(build_dir)
  File "/home/iha/lkmp/linux/tools/testing/kunit/kunit_kernel.py", line 124, in 
validate_config
validated_kconfig.read_from_file(kconfig_path)
  File "/home/iha/lkmp/linux/tools/testing/kunit/kunit_config.py", line 89, in 
read_from_file
self.parse_from_string(f.read())
  File "/home/iha/lkmp/linux/tools/testing/kunit/kunit_config.py", line 85, in 
parse_from_string
raise KconfigParseError('Failed to parse: ' + line)
kunit_config.KconfigParseError: Failed to parse: CONFIG_CC_VERSION_TEXT="gcc 
(GCC) 10.1.1 20200507 (Red Hat 10.1.1-1)"

Signed-off-by: Vitor Massaru Iha 
---
 tools/testing/kunit/kunit_config.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/testing/kunit/kunit_config.py 
b/tools/testing/kunit/kunit_config.py
index e75063d603b5..3033520597b6 100644
--- a/tools/testing/kunit/kunit_config.py
+++ b/tools/testing/kunit/kunit_config.py
@@ -9,6 +9,7 @@
 import collections
 import re
 
+CONFIG_IGNORE_CC_VERSION_TEXT = 'CONFIG_CC_VERSION_TEXT'
 CONFIG_IS_NOT_SET_PATTERN = r'^# CONFIG_(\w+) is not set$'
 CONFIG_PATTERN = r'^CONFIG_(\w+)=(\S+)$'
 
@@ -79,7 +80,7 @@ class Kconfig(object):
self.add_entry(entry)
continue
 
-   if line[0] == '#':
+   if line[0] == '#' or CONFIG_IGNORE_CC_VERSION_TEXT in 
line:
continue
else:
raise KconfigParseError('Failed to parse: ' + 
line)

base-commit: 7bf200b3a4ac10b1b0376c70b8c66ed39eae7cdd
-- 
2.26.2



[tip:x86/cleanups] BUILD SUCCESS 2accfa69050c2a0d6fc6106f609208b3e9622b26

2020-06-17 Thread kernel test robot
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git  
x86/cleanups
branch HEAD: 2accfa69050c2a0d6fc6106f609208b3e9622b26  cpu/speculation: Add 
prototype for cpu_show_srbds()

elapsed time: 726m

configs tested: 109
configs skipped: 6

The following configs have been built successfully.
More configs may be tested in the coming days.

arm64allyesconfig
arm64   defconfig
arm64allmodconfig
arm64 allnoconfig
arm defconfig
arm  allyesconfig
arm  allmodconfig
arm   allnoconfig
mips   ip28_defconfig
xtensaxip_kc705_defconfig
m68kmvme16x_defconfig
armmmp2_defconfig
arm  ep93xx_defconfig
mips   xway_defconfig
sparcalldefconfig
arm mv78xx0_defconfig
powerpc mpc83xx_defconfig
c6x  alldefconfig
xtensa  defconfig
riscv  rv32_defconfig
i386  allnoconfig
i386 allyesconfig
i386defconfig
i386  debian-10.3
ia64 allmodconfig
ia64defconfig
ia64  allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k  allnoconfig
m68k   sun3_defconfig
m68kdefconfig
m68k allyesconfig
nios2   defconfig
nios2allyesconfig
openriscdefconfig
c6x  allyesconfig
c6x   allnoconfig
openrisc allyesconfig
nds32   defconfig
nds32 allnoconfig
csky allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
h8300allmodconfig
arc defconfig
arc  allyesconfig
sh   allmodconfig
shallnoconfig
microblazeallnoconfig
mips allyesconfig
mips  allnoconfig
mips allmodconfig
pariscallnoconfig
parisc  defconfig
parisc   allyesconfig
parisc   allmodconfig
powerpc defconfig
powerpc  allyesconfig
powerpc  rhel-kconfig
powerpc  allmodconfig
powerpc   allnoconfig
i386 randconfig-a006-20200617
i386 randconfig-a002-20200617
i386 randconfig-a001-20200617
i386 randconfig-a004-20200617
i386 randconfig-a005-20200617
i386 randconfig-a003-20200617
x86_64   randconfig-a015-20200617
x86_64   randconfig-a011-20200617
x86_64   randconfig-a016-20200617
x86_64   randconfig-a014-20200617
x86_64   randconfig-a012-20200617
x86_64   randconfig-a013-20200617
i386 randconfig-a015-20200617
i386 randconfig-a011-20200617
i386 randconfig-a014-20200617
i386 randconfig-a016-20200617
i386 randconfig-a013-20200617
i386 randconfig-a012-20200617
riscvallyesconfig
riscv allnoconfig
riscv   defconfig
riscvallmodconfig
s390 allyesconfig
s390  allnoconfig
s390 allmodconfig
s390defconfig
sparcallyesconfig
sparc   defconfig
sparc64 defconfig
sparc64   allnoconfig
sparc64  allyesconfig
sparc64  allmodconfig
umallnoconfig
um  defconfig
um   allmodconfig
um

Re: [PATCH] [net/sched] Fix null pointer deref skb in tc_ctl_action

2020-06-17 Thread Eric Dumazet



On 6/17/20 6:43 PM, Gaurav Singh wrote:
> Add null check for skb
> 

Bad choice really.

You have to really understand code intent before trying to fix it.

> Signed-off-by: Gaurav Singh 
> ---
>  net/sched/act_api.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/net/sched/act_api.c b/net/sched/act_api.c
> index 8ac7eb0a8309..fd584821d75a 100644
> --- a/net/sched/act_api.c
> +++ b/net/sched/act_api.c
> @@ -1473,9 +1473,12 @@ static const struct nla_policy 
> tcaa_policy[TCA_ROOT_MAX + 1] = {
>  static int tc_ctl_action(struct sk_buff *skb, struct nlmsghdr *n,
>struct netlink_ext_ack *extack)
>  {
> + if (!skb)
> + return 0;


We do not allow this

warning: ISO C90 forbids mixed declarations and code 
[-Wdeclaration-after-statement]

> +
>   struct net *net = sock_net(skb->sk);
>   struct nlattr *tca[TCA_ROOT_MAX + 1];
> - u32 portid = skb ? NETLINK_CB(skb).portid : 0;
> + u32 portid = NETLINK_CB(skb).portid;
>   int ret = 0, ovr = 0;
>  
>   if ((n->nlmsg_type != RTM_GETACTION) &&
> 

Please compile your patches, do not expect us from doing this.



[PATCH net] net: dsa: bcm_sf2: Fix node reference count

2020-06-17 Thread Florian Fainelli
of_find_node_by_name() will do an of_node_put() on the "from" argument.
With CONFIG_OF_DYNAMIC enabled which checks for device_node reference
counts, we would be getting a warning like this:

[6.347230] refcount_t: increment on 0; use-after-free.
[6.352498] WARNING: CPU: 3 PID: 77 at lib/refcount.c:156
refcount_inc_checked+0x38/0x44
[6.360601] Modules linked in:
[6.363661] CPU: 3 PID: 77 Comm: kworker/3:1 Tainted: GW
5.4.46-gb78b3e9956e6 #13
[6.372546] Hardware name: BCM97278SV (DT)
[6.376649] Workqueue: events deferred_probe_work_func
[6.381796] pstate: 6005 (nZCv daif -PAN -UAO)
[6.386595] pc : refcount_inc_checked+0x38/0x44
[6.391133] lr : refcount_inc_checked+0x38/0x44
...
[6.478791] Call trace:
[6.481243]  refcount_inc_checked+0x38/0x44
[6.485433]  kobject_get+0x3c/0x4c
[6.488840]  of_node_get+0x24/0x34
[6.492247]  of_irq_find_parent+0x3c/0xe0
[6.496263]  of_irq_parse_one+0xe4/0x1d0
[6.500191]  irq_of_parse_and_map+0x44/0x84
[6.504381]  bcm_sf2_sw_probe+0x22c/0x844
[6.508397]  platform_drv_probe+0x58/0xa8
[6.512413]  really_probe+0x238/0x3fc
[6.516081]  driver_probe_device+0x11c/0x12c
[6.520358]  __device_attach_driver+0xa8/0x100
[6.524808]  bus_for_each_drv+0xb4/0xd0
[6.528650]  __device_attach+0xd0/0x164
[6.532493]  device_initial_probe+0x24/0x30
[6.536682]  bus_probe_device+0x38/0x98
[6.540524]  deferred_probe_work_func+0xa8/0xd4
[6.545061]  process_one_work+0x178/0x288
[6.549078]  process_scheduled_works+0x44/0x48
[6.553529]  worker_thread+0x218/0x270
[6.557285]  kthread+0xdc/0xe4
[6.560344]  ret_from_fork+0x10/0x18
[6.563925] ---[ end trace 68f65caf69bb152a ]---

Fix this by adding a of_node_get() to increment the reference count
prior to the call.

Fixes: afa3b592953b ("net: dsa: bcm_sf2: Ensure correct sub-node is parsed")
Signed-off-by: Florian Fainelli 
---
 drivers/net/dsa/bcm_sf2.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index c1bd21e4b15c..9f62ba3e4345 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -1154,6 +1154,8 @@ static int bcm_sf2_sw_probe(struct platform_device *pdev)
set_bit(0, priv->cfp.used);
set_bit(0, priv->cfp.unique);
 
+   /* Balance of_node_put() done by of_find_node_by_name() */
+   of_node_get(dn);
ports = of_find_node_by_name(dn, "ports");
if (ports) {
bcm_sf2_identify_ports(priv, ports);
-- 
2.17.1



Re: [PATCH v8 11/14] media: dt-bindings: Add jpeg enc device tree node document

2020-06-17 Thread Xia Jiang
On Thu, 2020-05-21 at 16:00 +, Tomasz Figa wrote:
> Hi Xia,
> 
> On Fri, Apr 03, 2020 at 05:40:30PM +0800, Xia Jiang wrote:
> > Add jpeg enc device tree node document
> > 
> > Reviewed-by: Rob Herring 
> > Signed-off-by: Xia Jiang 
> > ---
> > v8: no changes
> > 
> > v7: no changes
> > 
> > v6: no changes
> > 
> > v5: no changes
> > 
> > v4: no changes
> > 
> > v3: change compatible to SoC specific compatible
> > 
> > v2: no changes
> > ---
> >  .../bindings/media/mediatek-jpeg-encoder.txt  | 37 +++
> >  1 file changed, 37 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt
> > 
> 
> Thank you for the patch. Please see my comments inline.
Dear Tomasz,

Sorry for missing this message. Replied below.
> 
> > diff --git 
> > a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt 
> > b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt
> > new file mode 100644
> > index ..fa8da699493b
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt
> > @@ -0,0 +1,37 @@
> > +* MediaTek JPEG Encoder
> > +
> > +MediaTek JPEG Encoder is the JPEG encode hardware present in MediaTek SoCs
> > +
> > +Required properties:
> > +- compatible : should be one of:
> > +   "mediatek,mt2701-jpgenc"
> > +   ...
> 
> What does this "..." mean?
"..." means that compatible name is not just "mediatek,mt2701-jpgenc",
different project has different compatible name(for example the MT8173's
compatible name may be "mediatek,mt8173-jpgenc").
> 
> > +   followed by "mediatek,mtk-jpgenc"
> > +- reg : physical base address of the JPEG encoder registers and length of
> > +  memory mapped region.
> > +- interrupts : interrupt number to the interrupt controller.
> > +- clocks: device clocks, see
> > +  Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
> > +- clock-names: must contain "jpgenc". It is the clock of JPEG encoder.
> 
> nit: In principle the clocks should be named after the function the clock
> performs on the consumer side, i.e. the JPEG block in this case, I guess
> here it's just a generic clock that does everything, but I guess it comes
> from somewhere. Is it the AHB clock or something? In that case it would
> normally be called "ahb".
I have confirmed with hardware designer that the jpeg clock is not AHB
clock,it follows subsys clock(because 2701 is the old IC,I didn't get
the source name).It has the same source with venc clock.We can see that
the clocks = , Should I name it "venc" or the
orignal "jpgenc"?
> 
> > +- power-domains: a phandle to the power domain, see
> > +  Documentation/devicetree/bindings/power/power_domain.txt for details.
> > +- mediatek,larb: must contain the local arbiters in the current SoCs, see
> > +  
> > Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
> > +  for details.
> 
> I believe this isn't necessary anymore, because larbs are added
> automatically by the MTK IOMMU driver using device links. +CC Yong who
> worked on that.
Yes,I have confirmed with Yong that he will help me to modify this.Is it
ok that I keep the orignal larb code?

Best Regards,
Xia Jiang
> 
> > +- iommus: should point to the respective IOMMU block with master port as
> > +  argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
> > +  for details.
> > +
> > +Example:
> > +   jpegenc: jpegenc@1500a000 {
> > +   compatible = "mediatek,mt2701-jpgenc",
> > +"mediatek,mtk-jpgenc";
> > +   reg = <0 0x1500a000 0 0x1000>;
> > +   interrupts = ;
> > +   clocks =  <&imgsys CLK_IMG_VENC>;
> > +   clock-names = "jpgenc";
> > +   power-domains = <&scpsys MT2701_POWER_DOMAIN_ISP>;
> > +   mediatek,larb = <&larb2>;
> 
> Ditto.
> 
> Best regards,
> Tomasz



Re: [PATCH] [net/sched]: Remove redundant condition in qdisc_graft

2020-06-17 Thread Eric Dumazet



On 6/17/20 6:23 PM, Gaurav Singh wrote:
> Signed-off-by: Gaurav Singh 

Two Signed-off-by ?

> 
> Fix build errors

Your patch does not fix a build error.

> 
> Signed-off-by: Gaurav Singh 
> ---
>  net/sched/sch_api.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c
> index 9a3449b56bd6..be93ebcdb18d 100644
> --- a/net/sched/sch_api.c
> +++ b/net/sched/sch_api.c
> @@ -1094,7 +1094,7 @@ static int qdisc_graft(struct net_device *dev, struct 
> Qdisc *parent,
>  
>   /* Only support running class lockless if parent is lockless */
>   if (new && (new->flags & TCQ_F_NOLOCK) &&
> - parent && !(parent->flags & TCQ_F_NOLOCK))
> + !(parent->flags & TCQ_F_NOLOCK))
>   qdisc_clear_nolock(new);
>  
>   if (!cops || !cops->graft)
> 


Re: [f2fs-dev] [PATCH] f2fs: avoid checkpatch error

2020-06-17 Thread Chao Yu
On 2020/6/17 3:02, Jaegeuk Kim wrote:
> ERROR:INITIALISED_STATIC: do not initialise statics to NULL
> 
> Signed-off-by: Jaegeuk Kim 

Reviewed-by: Chao Yu 

Thanks,


[PATCH V4 3/3] dt-bindings: clock: Correct example in i.MX8QXP LPCG binding

2020-06-17 Thread Anson Huang
In i.MX8QXP LPCG binding's example, "fsl,imx7d-usdhc" as fallback
compatible is incorrect, remove it to avoid below build error:

Documentation/devicetree/bindings/clock/imx8qxp-lpcg.example.dt.yaml:
mmc@5b01: compatible: Additional items are not allowed ('fsl,imx7d-usdhc' 
was unexpected)
Documentation/devicetree/bindings/clock/imx8qxp-lpcg.example.dt.yaml:
mmc@5b01: compatible: ['fsl,imx8qxp-usdhc', 'fsl,imx7d-usdhc'] is too long

Signed-off-by: Anson Huang 
---
New patch, to fix build error when patch #1 is added.
---
 Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml 
b/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml
index 33f3010..1d5e9bc 100644
--- a/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml
+++ b/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml
@@ -62,7 +62,7 @@ examples:
 };
 
 mmc@5b01 {
-compatible = "fsl,imx8qxp-usdhc", "fsl,imx7d-usdhc";
+compatible = "fsl,imx8qxp-usdhc";
 interrupts = ;
 reg = <0x5b01 0x1>;
 clocks = <&conn_lpcg IMX_CONN_LPCG_SDHC0_IPG_CLK>,
-- 
2.7.4



[PATCH V4 2/3] dt-bindings: clock: Correct mmc node name in i.MX35 binding

2020-06-17 Thread Anson Huang
Nodename should be "mmc" instead of "esdhc" in i.MX35 clock binding
to avoid below build error:

Documentation/devicetree/bindings/clock/imx35-clock.example.dt.yaml:
esdhc@53fb4000: $nodename:0: 'esdhc@53fb4000' does not match '^mmc(@.*)?$'

Signed-off-by: Anson Huang 
---
New patch, to fix build error when patch #1 is added.
---
 Documentation/devicetree/bindings/clock/imx35-clock.yaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/clock/imx35-clock.yaml 
b/Documentation/devicetree/bindings/clock/imx35-clock.yaml
index bd871da..3e20cca 100644
--- a/Documentation/devicetree/bindings/clock/imx35-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/imx35-clock.yaml
@@ -130,7 +130,7 @@ examples:
 #clock-cells = <1>;
 };
 
-esdhc@53fb4000 {
+mmc@53fb4000 {
 compatible = "fsl,imx35-esdhc";
 reg = <0x53fb4000 0x4000>;
 interrupts = <7>;
-- 
2.7.4



[PATCH V4 1/3] dt-bindings: mmc: Convert imx esdhc to json-schema

2020-06-17 Thread Anson Huang
Convert the i.MX ESDHC binding to DT schema format using json-schema

Signed-off-by: Anson Huang 
---
No change.
---
 .../devicetree/bindings/mmc/fsl-imx-esdhc.txt  |  67 ---
 .../devicetree/bindings/mmc/fsl-imx-esdhc.yaml | 124 +
 2 files changed, 124 insertions(+), 67 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt
 create mode 100644 Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml

diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt 
b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt
deleted file mode 100644
index de1b8bd..000
--- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt
+++ /dev/null
@@ -1,67 +0,0 @@
-* Freescale Enhanced Secure Digital Host Controller (eSDHC) for i.MX
-
-The Enhanced Secure Digital Host Controller on Freescale i.MX family
-provides an interface for MMC, SD, and SDIO types of memory cards.
-
-This file documents differences between the core properties described
-by mmc.txt and the properties used by the sdhci-esdhc-imx driver.
-
-Required properties:
-- compatible : Should be "fsl,-esdhc", the supported chips include
-  "fsl,imx25-esdhc"
-  "fsl,imx35-esdhc"
-  "fsl,imx51-esdhc"
-  "fsl,imx53-esdhc"
-  "fsl,imx6q-usdhc"
-  "fsl,imx6sl-usdhc"
-  "fsl,imx6sx-usdhc"
-  "fsl,imx6ull-usdhc"
-  "fsl,imx7d-usdhc"
-  "fsl,imx7ulp-usdhc"
-  "fsl,imx8mq-usdhc"
-  "fsl,imx8mm-usdhc"
-  "fsl,imx8mn-usdhc"
-  "fsl,imx8mp-usdhc"
-  "fsl,imx8qm-usdhc"
-  "fsl,imx8qxp-usdhc"
-
-Optional properties:
-- fsl,wp-controller : Indicate to use controller internal write protection
-- fsl,delay-line : Specify the number of delay cells for override mode.
-  This is used to set the clock delay for DLL(Delay Line) on override mode
-  to select a proper data sampling window in case the clock quality is not good
-  due to signal path is too long on the board. Please refer to eSDHC/uSDHC
-  chapter, DLL (Delay Line) section in RM for details.
-- voltage-ranges : Specify the voltage range in case there are software
-  transparent level shifters on the outputs of the controller. Two cells are
-  required, first cell specifies minimum slot voltage (mV), second cell
-  specifies maximum slot voltage (mV). Several ranges could be specified.
-- fsl,tuning-start-tap: Specify the start dealy cell point when send first 
CMD19
-  in tuning procedure.
-- fsl,tuning-step: Specify the increasing delay cell steps in tuning procedure.
-  The uSDHC use one delay cell as default increasing step to do tuning process.
-  This property allows user to change the tuning step to more than one delay
-  cells which is useful for some special boards or cards when the default
-  tuning step can't find the proper delay window within limited tuning retries.
-- fsl,strobe-dll-delay-target: Specify the strobe dll control slave delay 
target.
-  This delay target programming host controller loopback read clock, and this
-  property allows user to change the delay target for the strobe input read 
clock.
-  If not use this property, driver default set the delay target to value 7.
-  Only eMMC HS400 mode need to take care of this property.
-
-Examples:
-
-esdhc@70004000 {
-   compatible = "fsl,imx51-esdhc";
-   reg = <0x70004000 0x4000>;
-   interrupts = <1>;
-   fsl,wp-controller;
-};
-
-esdhc@70008000 {
-   compatible = "fsl,imx51-esdhc";
-   reg = <0x70008000 0x4000>;
-   interrupts = <2>;
-   cd-gpios = <&gpio1 6 0>; /* GPIO1_6 */
-   wp-gpios = <&gpio1 5 0>; /* GPIO1_5 */
-};
diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml 
b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
new file mode 100644
index 000..75dc116
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
@@ -0,0 +1,124 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/fsl-imx-esdhc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Enhanced Secure Digital Host Controller (eSDHC) for i.MX
+
+maintainers:
+  - Shawn Guo 
+
+allOf:
+  - $ref: "mmc-controller.yaml"
+
+description: |
+  The Enhanced Secure Digital Host Controller on Freescale i.MX family
+  provides an interface for MMC, SD, and SDIO types of memory cards.
+
+  This file documents differences between the core properties described
+  by mmc.txt and the properties used by the sdhci-esdhc-imx driver.
+
+properties:
+  compatible:
+enum:
+  - fsl,imx25-esdhc
+  - fsl,imx35-esdhc
+  - fsl,imx51-esdhc
+  - fsl,imx53-esdhc
+  - fsl,imx6q-usdhc
+  - fsl,imx6sl-usdhc
+  - fsl,imx6sx-usdhc
+  - fsl,imx6ull-usdhc
+  - fsl,imx7d-usdhc
+  - fsl,imx7ulp-usdhc
+  - fsl,imx8mq-usdhc
+

Re: [PATCH v3] f2fs: use kfree() instead of kvfree() to free superblock data

2020-06-17 Thread Chao Yu
On 2020/6/16 1:58, Jaegeuk Kim wrote:
> On 06/09, Eric Biggers wrote:
>> On Wed, Jun 10, 2020 at 01:14:46AM +0300, Denis Efremov wrote:
>>> Use kfree() instead of kvfree() to free super in read_raw_super_block()
>>> because the memory is allocated with kzalloc() in the function.
>>> Use kfree() instead of kvfree() to free sbi, raw_super in
>>> f2fs_fill_super() and f2fs_put_super() because the memory is allocated
>>> with kzalloc().
>>>
>>> Fixes: 5222595d093e ("f2fs: use kvmalloc, if kmalloc is failed")
>>> Signed-off-by: Denis Efremov 

Reviewed-by: Chao Yu 

Thanks,

>>
>> I don't think "Fixes" is appropriate here.
> 
> Agreed. I queued this Cl without it. :)
> Thanks,
> 
>>
>> kvfree() still works on kmalloc'ed memory; it's just not preferred.
>>
>> So this is more a cleanup than a fix.
>>
>> - Eric
> .
> 


回复: 回复: [PATCH] f2fs: fix a race condition between f2fs_write_end_io and f2fs_del_fsync_node_entry

2020-06-17 Thread Zac
> On 2020/6/18 10:39, Zac wrote:
> >
> >> On 2020/6/17 17:04, zhaowu...@wingtech.com wrote:
> >>> From: Wuyun Zhao 
> >>>
> >>> Under some condition, the __write_node_page will submit a page which
> is
> >> not
> >>> f2fs_in_warm_node_list and will not call f2fs_add_fsync_node_entry.
> >>> f2fs_gc continue to run to invoke f2fs_iget -> do_read_inode to read
the
> >> same node page
> >>> and set code node, which make f2fs_in_warm_node_list become true,
> >>> that will cause f2fs_bug_on in f2fs_del_fsync_node_entry when
> >> f2fs_write_end_io called.
> >> Could you please add below race condition description into commit
> >> message?
> >>
> >> - f2fs_write_end_io
> >>- f2fs_iget
> >> - do_read_inode
> >>  - set_cold_node
> >>  recover cold node flag
> >>  - f2fs_in_warm_node_list
> >>   - is_cold_node
> >>   if node is cold, assume we have added
> >>   node to fsync_node_list during writepages()
> >>  - f2fs_del_fsync_node_entry
> >>   - f2fs_bug_on() due to node page
> >>   is not in fsync_node_list
> >
> > Ok, will add the commit message.
> >
> >> BTW, I'm curious about why we can lose cold flag for non-dir inode?
> >> any clue to reproduce this bug (I mean losing cold flag)?
> >
> > it's a f2fs image with 25600MB
> > flash this image to device
> > the device will resize it according to the userdata partition size which
is
> > about 94GB
> > the device mount the f2fs partition
> > then hit this f2fs_bug_on
> >
> > seems that the cold flag is not been set when mkfs
> 
> Ah, I guess both mkfs/sload ignores setting cold node flag for non-dir
inode,
> could you please send another patch to fix this issue?

Patch v2 has been sent.

> >
> > I think the issue is that
> >
> > 1. the node page in the storage is without cold bit
> > 2. f2fs_disable_checkpoint -> f2fs_gc -> f2fs_get_node_page, this page
> won't
> > be set cold flag
> > 3. f2fs_move_node_page -> __write_node_page to write this page
> > 4. f2fs_gc -> f2fs_iget -> do_read_inode to read this page and set cold
flag
> 
> Clear enough, thanks for your explanation. :)
> 
> Thanks,
> 
> >
> >>>
> >>> [   34.966133] Call trace:
> >>> [   34.969902]  f2fs_del_fsync_node_entry+0x100/0x108
> >>> [   34.976071]  f2fs_write_end_io+0x1e0/0x288
> >>> [   34.981539]  bio_endio+0x248/0x270
> >>> [   34.986289]  blk_update_request+0x2b0/0x4d8
> >>> [   34.991841]  scsi_end_request+0x40/0x440
> >>> [   34.997126]  scsi_io_completion+0xa4/0x748
> >>> [   35.002593]  scsi_finish_command+0xdc/0x110
> >>> [   35.008143]  scsi_softirq_done+0x118/0x150
> >>> [   35.013610]  blk_done_softirq+0x8c/0xe8
> >>> [   35.018811]  __do_softirq+0x2e8/0x578
> >>> [   35.023828]  irq_exit+0xfc/0x120
> >>> [   35.028398]  handle_IPI+0x1d8/0x330
> >>> [   35.033233]  gic_handle_irq+0x110/0x1d4
> >>> [   35.038433]  el1_irq+0xb4/0x130
> >>> [   35.042917]  kmem_cache_alloc+0x3f0/0x418
> >>> [   35.048288]  radix_tree_node_alloc+0x50/0xf8
> >>> [   35.053933]  __radix_tree_create+0xf8/0x188
> >>> [   35.059484]  __radix_tree_insert+0x3c/0x128
> >>> [   35.065035]  add_gc_inode+0x90/0x118
> >>> [   35.069967]  f2fs_gc+0x1b80/0x2d70
> >>> [   35.074718]  f2fs_disable_checkpoint+0x94/0x1d0
> >>> [   35.080621]  f2fs_fill_super+0x10c4/0x1b88
> >>> [   35.086088]  mount_bdev+0x194/0x1e0
> >>> [   35.090923]  f2fs_mount+0x40/0x50
> >>> [   35.095589]  mount_fs+0xb4/0x190
> >>> [   35.100159]  vfs_kern_mount+0x80/0x1d8
> >>> [   35.105260]  do_mount+0x478/0xf18
> >>> [   35.109926]  ksys_mount+0x90/0xd0
> >>> [   35.114592]  __arm64_sys_mount+0x24/0x38
> >>>
> >>> Signed-off-by: Wuyun Zhao 
> >>
> >> Reviewed-by: Chao Yu 
> >>
> >> Thanks,
> >>
> >>> ---
> >>>  fs/f2fs/inode.c | 1 +
> >>>  1 file changed, 1 insertion(+)
> >>>
> >>> diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c
> >>> index be6ac33..0df5c8c 100644
> >>> --- a/fs/f2fs/inode.c
> >>> +++ b/fs/f2fs/inode.c
> >>> @@ -402,6 +402,7 @@ static int do_read_inode(struct inode *inode)
> >>>
> >>>   /* try to recover cold bit for non-dir inode */
> >>>   if (!S_ISDIR(inode->i_mode) && !is_cold_node(node_page)) {
> >>> + f2fs_wait_on_page_writeback(node_page, NODE, true, true);
> >>>   set_cold_node(node_page, false);
> >>>   set_page_dirty(node_page);
> >>>   }
> >>>
> >
> > .
> >



[PATCH 1/2] spi: spidev: fix a race between spidev_release and spidev_remove

2020-06-17 Thread Zhenzhong Duan
Imagine below scene, spidev is referenced after it's freed.

spidev_release()spidev_remove()
...
spin_lock_irq(&spidev->spi_lock);
spidev->spi = NULL;
spin_unlock_irq(&spidev->spi_lock);
mutex_lock(&device_list_lock);
dofree = (spidev->spi == NULL);
if (dofree)
kfree(spidev);
mutex_unlock(&device_list_lock);
mutex_lock(&device_list_lock);
list_del(&spidev->device_entry);
device_destroy(spidev_class, spidev->devt);
clear_bit(MINOR(spidev->devt), minors);
if (spidev->users == 0)
kfree(spidev);
mutex_unlock(&device_list_lock);

Fix it by resetting spidev->spi in device_list_lock's protection.

Signed-off-by: Zhenzhong Duan 
---
 drivers/spi/spidev.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spidev.c b/drivers/spi/spidev.c
index d753df7..f74ea26 100644
--- a/drivers/spi/spidev.c
+++ b/drivers/spi/spidev.c
@@ -787,13 +787,13 @@ static int spidev_remove(struct spi_device *spi)
 {
struct spidev_data  *spidev = spi_get_drvdata(spi);
 
+   /* prevent new opens */
+   mutex_lock(&device_list_lock);
/* make sure ops on existing fds can abort cleanly */
spin_lock_irq(&spidev->spi_lock);
spidev->spi = NULL;
spin_unlock_irq(&spidev->spi_lock);
 
-   /* prevent new opens */
-   mutex_lock(&device_list_lock);
list_del(&spidev->device_entry);
device_destroy(spidev_class, spidev->devt);
clear_bit(MINOR(spidev->devt), minors);
-- 
1.8.3.1



[PATCH 2/2] spi: spidev: fix a potential use-after-free in spidev_release()

2020-06-17 Thread Zhenzhong Duan
If an spi device is unbounded from the driver before the release
process, there will be an NULL pointer reference when it's
referenced in spi_slave_abort().

Fix it by checking it's already freed before reference.

Signed-off-by: Zhenzhong Duan 
---
 drivers/spi/spidev.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/spi/spidev.c b/drivers/spi/spidev.c
index f74ea26..59e0767 100644
--- a/drivers/spi/spidev.c
+++ b/drivers/spi/spidev.c
@@ -609,15 +609,20 @@ static int spidev_open(struct inode *inode, struct file 
*filp)
 static int spidev_release(struct inode *inode, struct file *filp)
 {
struct spidev_data  *spidev;
+   int dofree;
 
mutex_lock(&device_list_lock);
spidev = filp->private_data;
filp->private_data = NULL;
 
+   spin_lock_irq(&spidev->spi_lock);
+   /* ... after we unbound from the underlying device? */
+   dofree = (spidev->spi == NULL);
+   spin_unlock_irq(&spidev->spi_lock);
+
/* last close? */
spidev->users--;
if (!spidev->users) {
-   int dofree;
 
kfree(spidev->tx_buffer);
spidev->tx_buffer = NULL;
@@ -625,19 +630,14 @@ static int spidev_release(struct inode *inode, struct 
file *filp)
kfree(spidev->rx_buffer);
spidev->rx_buffer = NULL;
 
-   spin_lock_irq(&spidev->spi_lock);
-   if (spidev->spi)
-   spidev->speed_hz = spidev->spi->max_speed_hz;
-
-   /* ... after we unbound from the underlying device? */
-   dofree = (spidev->spi == NULL);
-   spin_unlock_irq(&spidev->spi_lock);
-
if (dofree)
kfree(spidev);
+   else
+   spidev->speed_hz = spidev->spi->max_speed_hz;
}
 #ifdef CONFIG_SPI_SLAVE
-   spi_slave_abort(spidev->spi);
+   if (!dofree)
+   spi_slave_abort(spidev->spi);
 #endif
mutex_unlock(&device_list_lock);
 
-- 
1.8.3.1



Re: [PATCH v2 09/16] rcu/tree: Maintain separate array for vmalloc ptrs

2020-06-17 Thread Paul E. McKenney
On Wed, Jun 17, 2020 at 05:52:14PM -0700, Matthew Wilcox wrote:
> On Wed, Jun 17, 2020 at 04:46:09PM -0700, Paul E. McKenney wrote:
> > > + // Handle two first channels.
> > > + for (i = 0; i < FREE_N_CHANNELS; i++) {
> > > + for (; bkvhead[i]; bkvhead[i] = bnext) {
> > > + bnext = bkvhead[i]->next;
> > > + debug_rcu_bhead_unqueue(bkvhead[i]);
> > > +
> > > + rcu_lock_acquire(&rcu_callback_map);
> > > + if (i == 0) { // kmalloc() / kfree().
> > > + trace_rcu_invoke_kfree_bulk_callback(
> > > + rcu_state.name, bkvhead[i]->nr_records,
> > > + bkvhead[i]->records);
> > > +
> > > + kfree_bulk(bkvhead[i]->nr_records,
> > > + bkvhead[i]->records);
> > > + } else { // vmalloc() / vfree().
> > > + for (j = 0; j < bkvhead[i]->nr_records; j++) {
> > > + trace_rcu_invoke_kfree_callback(
> > > + rcu_state.name,
> > > + bkvhead[i]->records[j], 0);
> > > +
> > > + vfree(bkvhead[i]->records[j]);
> > > + }
> > > + }
> > > + rcu_lock_release(&rcu_callback_map);
> > 
> > Not an emergency, but did you look into replacing this "if" statement
> > with an array of pointers to functions implementing the legs of the
> > "if" statement?  If nothing else, this would greatly reduced indentation.
> 
> I don't think that replacing direct function calls with indirect function
> calls is a great suggestion with the current state of play around branch
> prediction.
> 
> I'd suggest:
> 
>   rcu_lock_acquire(&rcu_callback_map);
>   trace_rcu_invoke_kfree_bulk_callback(rcu_state.name,
>   bkvhead[i]->nr_records, bkvhead[i]->records);
>   if (i == 0) {
>   kfree_bulk(bkvhead[i]->nr_records,
>   bkvhead[i]->records);
>   } else {
>   for (j = 0; j < bkvhead[i]->nr_records; j++) {
>   vfree(bkvhead[i]->records[j]);
>   }
>   }
>   rcu_lock_release(&rcu_callback_map);
> 
> But I'd also suggest a vfree_bulk be added.  There are a few things
> which would be better done in bulk as part of the vfree process
> (we batch them up already, but i'm sure we could do better).

I suspect that he would like to keep the tracing.

It might be worth trying the branches, given that they would be constant
and indexed by "i".  The compiler might well remove the indirection.

The compiler guys brag about doing so, which of course might or might
not have any correlation to a given compiler actually doing so.  :-/

Having a vfree_bulk() might well be useful, but I would feel more
confidence in that if there were other callers of kfree_bulk().

But again, either way, future work as far as this series is concerned.

Thanx, Paul


RE: [PATCH V2 2/9] ARM: imx: Select MXC_CLK for ARCH_MXC

2020-06-17 Thread Anson Huang


> -Original Message-
> From: Aisheng Dong 
> Sent: 2020年6月18日 11:09
> To: Anson Huang ; li...@armlinux.org.uk;
> shawn...@kernel.org; s.ha...@pengutronix.de; ker...@pengutronix.de;
> feste...@gmail.com; mturque...@baylibre.com; sb...@kernel.org;
> oleksandr.suvo...@toradex.com; Stefan Agner ;
> a...@arndb.de; Abel Vesa ; Peng Fan
> ; t...@linutronix.de; alli...@lohutok.net;
> gre...@linuxfoundation.org; i...@metux.net; Leonard Crestez
> ; Andy Duan ; Daniel
> Baluta ; yuehaib...@huawei.com;
> s...@canb.auug.org.au; linux-arm-ker...@lists.infradead.org;
> linux-kernel@vger.kernel.org; linux-...@vger.kernel.org
> Cc: dl-linux-imx 
> Subject: RE: [PATCH V2 2/9] ARM: imx: Select MXC_CLK for ARCH_MXC
> 
> > From: Anson Huang 
> > Sent: Wednesday, June 17, 2020 8:36 PM
> >
> > > Subject: RE: [PATCH V2 2/9] ARM: imx: Select MXC_CLK for ARCH_MXC
> > >
> > > > From: Anson Huang 
> > > > Sent: Tuesday, June 9, 2020 3:32 PM
> > > >
> > > > i.MX common clock drivers may support module build, so it is NOT
> > > > selected by default, for ARCH_MXC ARMv7 platforms, need to select
> > > > it manually to make build pass.
> > > >
> > > > Signed-off-by: Anson Huang 
> > >
> > > Can't the original def_xxx work?
> > >
> > > config MXC_CLK
> > > tristate
> > > def_tristate ARCH_MXC
> >
> > Such change will make MXC_CLK=y even all i.MX8 SoCs clock drivers are
> > selected as module, so it does NOT meet the requirement of module
> > support. Below is from .config when all
> > i.MX8 SoCs clock drivers are configured to module.
> >
> >  CONFIG_MXC_CLK=y
> >  CONFIG_MXC_CLK_SCU=m
> >  CONFIG_CLK_IMX8MM=m
> >  CONFIG_CLK_IMX8MN=m
> >  CONFIG_CLK_IMX8MP=m
> >  CONFIG_CLK_IMX8MQ=m
> >  CONFIG_CLK_IMX8QXP=m
> >
> 
> It works at my side.
> Below is my changes based on your patchset:
> $ git diff
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig index
> 47b10d20f411..e7d7b90e2cf8 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -4,7 +4,6 @@ menuconfig ARCH_MXC
> depends on ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7 ||
> ARM_SINGLE_ARMV7M
> select ARCH_SUPPORTS_BIG_ENDIAN
> select CLKSRC_IMX_GPT
> -   select MXC_CLK
> select GENERIC_IRQ_CHIP
> select GPIOLIB
> select PINCTRL
> diff --git a/drivers/clk/imx/Kconfig b/drivers/clk/imx/Kconfig index
> 26cedbfe386c..f7b3e3a2cb9f 100644
> --- a/drivers/clk/imx/Kconfig
> +++ b/drivers/clk/imx/Kconfig
> @@ -3,6 +3,7 @@
>  config MXC_CLK
> tristate "IMX clock"
> depends on ARCH_MXC
> +   def_tristate ARCH_MXC
> 
>  config MXC_CLK_SCU
> tristate "IMX SCU clock"
> 

I guess you tried imx_v6_v7_defconfig? It does NOT work for ARM64 defconfig 
when we try to make
CONFIG_MXC_CLK=m, Below are my change, you can see in .config, even all i.MX8 
SoCs clock drivers
are configured to module, the CONFIG_MXC_CLK is still =y, but the expected 
result is =m.

BTW, all i.MX8 SoCs select MXC_CLK in their kconfig, this patch just does the 
same thing for i.MX6/7
in common place.

diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 47b10d2..e7d7b90 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -4,7 +4,6 @@ menuconfig ARCH_MXC
depends on ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7 || ARM_SINGLE_ARMV7M
select ARCH_SUPPORTS_BIG_ENDIAN
select CLKSRC_IMX_GPT
-   select MXC_CLK
select GENERIC_IRQ_CHIP
select GPIOLIB
select PINCTRL
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 8222e4b..21e2dbb 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -799,11 +799,11 @@ CONFIG_COMMON_CLK_S2MPS11=y
 CONFIG_COMMON_CLK_PWM=y
 CONFIG_COMMON_CLK_VC5=y
 CONFIG_CLK_RASPBERRYPI=m
-CONFIG_CLK_IMX8MM=y
-CONFIG_CLK_IMX8MN=y
-CONFIG_CLK_IMX8MP=y
-CONFIG_CLK_IMX8MQ=y
-CONFIG_CLK_IMX8QXP=y
+CONFIG_CLK_IMX8MM=m
+CONFIG_CLK_IMX8MN=m
+CONFIG_CLK_IMX8MP=m
+CONFIG_CLK_IMX8MQ=m
+CONFIG_CLK_IMX8QXP=m
 CONFIG_TI_SCI_CLK=y
 CONFIG_COMMON_CLK_QCOM=y
 CONFIG_QCOM_A53PLL=y
diff --git a/drivers/clk/imx/Kconfig b/drivers/clk/imx/Kconfig
index 26cedbf..f7b3e3a 100644
--- a/drivers/clk/imx/Kconfig
+++ b/drivers/clk/imx/Kconfig
@@ -3,6 +3,7 @@
 config MXC_CLK
tristate "IMX clock"
depends on ARCH_MXC
+   def_tristate ARCH_MXC

 config MXC_CLK_SCU
tristate "IMX SCU clock"

.config:
 CONFIG_MXC_CLK=y
 CONFIG_MXC_CLK_SCU=m
 CONFIG_CLK_IMX8MM=m
 CONFIG_CLK_IMX8MN=m
 CONFIG_CLK_IMX8MP=m
 CONFIG_CLK_IMX8MQ=m
 CONFIG_CLK_IMX8QXP=m

Anson


Re: [PATCH v5 01/13] powerpc: Remove Xilinx PPC405/PPC440 support

2020-06-17 Thread Nathan Chancellor
On Thu, Jun 18, 2020 at 10:48:21AM +1000, Michael Ellerman wrote:
> Nick Desaulniers  writes:
> > On Wed, Jun 17, 2020 at 3:20 AM Michael Ellerman  
> > wrote:
> >> Michael Ellerman  writes:
> >> > Michal Simek  writes:
> >> 
> >>
> >> >> Or if bamboo requires uImage to be built by default you can do it via
> >> >> Kconfig.
> >> >>
> >> >> diff --git a/arch/powerpc/platforms/44x/Kconfig
> >> >> b/arch/powerpc/platforms/44x/Kconfig
> >> >> index 39e93d23fb38..300864d7b8c9 100644
> >> >> --- a/arch/powerpc/platforms/44x/Kconfig
> >> >> +++ b/arch/powerpc/platforms/44x/Kconfig
> >> >> @@ -13,6 +13,7 @@ config BAMBOO
> >> >> select PPC44x_SIMPLE
> >> >> select 440EP
> >> >> select FORCE_PCI
> >> >> +   select DEFAULT_UIMAGE
> >> >> help
> >> >>   This option enables support for the IBM PPC440EP evaluation 
> >> >> board.
> >> >
> >> > Who knows what the actual bamboo board used. But I'd be happy to take a
> >> > SOB'ed patch to do the above, because these days the qemu emulation is
> >> > much more likely to be used than the actual board.
> >>
> >> I just went to see why my CI boot of 44x didn't catch this, and it's
> >> because I don't use the uImage, I just boot the vmlinux directly:
> >>
> >>   $ qemu-system-ppc -M bamboo -m 128m -display none -kernel build~/vmlinux 
> >> -append "console=ttyS0" -display none -nodefaults -serial mon:stdio
> >>   Linux version 5.8.0-rc1-00118-g69119673bd50 (michael@alpine1-p1) (gcc 
> >> (Ubuntu 9.3.0-10ubuntu2) 9.3.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #4 
> >> Wed Jun 17 20:19:22 AEST 2020
> >>   Using PowerPC 44x Platform machine description
> >>   ioremap() called early from find_legacy_serial_ports+0x690/0x770. Use 
> >> early_ioremap() instead
> >>   printk: bootconsole [udbg0] enabled
> >>
> >>
> >> So that's probably the simplest solution?
> >
> > If the uImage or zImage self decompresses, I would prefer to test that as 
> > well.
> 
> The uImage is decompressed by qemu AIUI.
> 
> >> That means previously arch/powerpc/boot/zImage was just a hardlink to
> >> the uImage:
> >
> > It sounds like we can just boot the zImage, or is that no longer
> > created with the uImage?
> 
> The zImage won't boot on bamboo.
> 
> Because of the vagaries of the arch/powerpc/boot/Makefile the zImage
> ends up pointing to treeImage.ebony, which is for a different board.
> 
> The zImage link is made to the first item in $(image-y):
> 
> $(obj)/zImage:$(addprefix $(obj)/, $(image-y))
>   $(Q)rm -f $@; ln $< $@
>  ^
>  first preqrequisite
> 
> Which for this defconfig happens to be:
> 
> image-$(CONFIG_EBONY) += treeImage.ebony cuImage.ebony
> 
> If you turned off CONFIG_EBONY then the zImage will be a link to
> treeImage.bamboo, but qemu can't boot that either.
> 
> It's kind of nuts that the zImage points to some arbitrary image
> depending on what's configured and the order of things in the Makefile.
> But I'm not sure how we make it less nuts without risking breaking
> people's existing setups.
> 
> cheers

Hi Michael,

For what it's worth, this is squared this away in terms of our CI by
just building and booting the uImage directly, rather than implicitly
using the zImage:

https://github.com/ClangBuiltLinux/continuous-integration/pull/282
https://github.com/ClangBuiltLinux/boot-utils/pull/22

We were only using the zImage because that is what Joel Stanley intially
set us up with when PowerPC 32-bit was added to our CI:

https://github.com/ClangBuiltLinux/continuous-integration/pull/100

Admittedly, we really do not have many PowerPC experts in our
organization so we are supporting it on a "best effort" basis, which
often involves using whatever knowledge is floating around or can be
gained from interactions such as this :) so thank you for that!

Cheers,
Nathan


RE: [PATCH V2 2/9] ARM: imx: Select MXC_CLK for ARCH_MXC

2020-06-17 Thread Aisheng Dong
> From: Anson Huang 
> Sent: Wednesday, June 17, 2020 8:36 PM
> 
> > Subject: RE: [PATCH V2 2/9] ARM: imx: Select MXC_CLK for ARCH_MXC
> >
> > > From: Anson Huang 
> > > Sent: Tuesday, June 9, 2020 3:32 PM
> > >
> > > i.MX common clock drivers may support module build, so it is NOT
> > > selected by default, for ARCH_MXC ARMv7 platforms, need to select it
> > > manually to make build pass.
> > >
> > > Signed-off-by: Anson Huang 
> >
> > Can't the original def_xxx work?
> >
> > config MXC_CLK
> > tristate
> > def_tristate ARCH_MXC
> 
> Such change will make MXC_CLK=y even all i.MX8 SoCs clock drivers are selected
> as module, so it does NOT meet the requirement of module support. Below is
> from .config when all
> i.MX8 SoCs clock drivers are configured to module.
> 
>  CONFIG_MXC_CLK=y
>  CONFIG_MXC_CLK_SCU=m
>  CONFIG_CLK_IMX8MM=m
>  CONFIG_CLK_IMX8MN=m
>  CONFIG_CLK_IMX8MP=m
>  CONFIG_CLK_IMX8MQ=m
>  CONFIG_CLK_IMX8QXP=m
> 

It works at my side.
Below is my changes based on your patchset:
$ git diff
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 47b10d20f411..e7d7b90e2cf8 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -4,7 +4,6 @@ menuconfig ARCH_MXC
depends on ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7 || ARM_SINGLE_ARMV7M
select ARCH_SUPPORTS_BIG_ENDIAN
select CLKSRC_IMX_GPT
-   select MXC_CLK
select GENERIC_IRQ_CHIP
select GPIOLIB
select PINCTRL
diff --git a/drivers/clk/imx/Kconfig b/drivers/clk/imx/Kconfig
index 26cedbfe386c..f7b3e3a2cb9f 100644
--- a/drivers/clk/imx/Kconfig
+++ b/drivers/clk/imx/Kconfig
@@ -3,6 +3,7 @@
 config MXC_CLK
tristate "IMX clock"
depends on ARCH_MXC
+   def_tristate ARCH_MXC
 
 config MXC_CLK_SCU
tristate "IMX SCU clock"

Regards
Aisheng

> Anson


[tip:x86/misc] BUILD SUCCESS 5603119e48d0fee163a827c2342b372f1a0e913c

2020-06-17 Thread kernel test robot
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git  
x86/misc
branch HEAD: 5603119e48d0fee163a827c2342b372f1a0e913c  x86/msr: Filter MSR 
writes

elapsed time: 720m

configs tested: 100
configs skipped: 93

The following configs have been built successfully.
More configs may be tested in the coming days.

arm64allyesconfig
arm64   defconfig
arm64allmodconfig
arm64 allnoconfig
arm defconfig
arm  allyesconfig
arm  allmodconfig
arm   allnoconfig
c6x  alldefconfig
xtensa  defconfig
riscv  rv32_defconfig
i386  allnoconfig
i386 allyesconfig
i386defconfig
i386  debian-10.3
ia64 allmodconfig
ia64defconfig
ia64  allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k  allnoconfig
m68k   sun3_defconfig
m68kdefconfig
m68k allyesconfig
nios2   defconfig
nios2allyesconfig
openriscdefconfig
c6x  allyesconfig
c6x   allnoconfig
openrisc allyesconfig
nds32   defconfig
nds32 allnoconfig
csky allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
h8300allmodconfig
arc defconfig
arc  allyesconfig
sh   allmodconfig
shallnoconfig
microblazeallnoconfig
mips allyesconfig
mips  allnoconfig
mips allmodconfig
pariscallnoconfig
parisc  defconfig
parisc   allyesconfig
parisc   allmodconfig
powerpc defconfig
powerpc  allyesconfig
powerpc  rhel-kconfig
powerpc  allmodconfig
powerpc   allnoconfig
i386 randconfig-a006-20200617
i386 randconfig-a002-20200617
i386 randconfig-a001-20200617
i386 randconfig-a004-20200617
i386 randconfig-a005-20200617
i386 randconfig-a003-20200617
x86_64   randconfig-a015-20200617
x86_64   randconfig-a011-20200617
x86_64   randconfig-a016-20200617
x86_64   randconfig-a014-20200617
x86_64   randconfig-a012-20200617
x86_64   randconfig-a013-20200617
i386 randconfig-a015-20200617
i386 randconfig-a011-20200617
i386 randconfig-a014-20200617
i386 randconfig-a016-20200617
i386 randconfig-a013-20200617
i386 randconfig-a012-20200617
riscvallyesconfig
riscv allnoconfig
riscv   defconfig
riscvallmodconfig
s390 allyesconfig
s390  allnoconfig
s390 allmodconfig
s390defconfig
sparcallyesconfig
sparc   defconfig
sparc64 defconfig
sparc64   allnoconfig
sparc64  allyesconfig
sparc64  allmodconfig
um   allmodconfig
umallnoconfig
um   allyesconfig
um  defconfig
x86_64   rhel-7.6
x86_64rhel-7.6-kselftests
x86_64   rhel-8.3
x86_64  kexec
x86_64   rhel
x86_64 rhel-7.2-clear
x86_64lkp
x86_64  fedora-25

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01

Re: [PATCH v5 09/12] PCI: brcmstb: Set internal memory viewport sizes

2020-06-17 Thread Bjorn Helgaas
On Wed, Jun 17, 2020 at 01:28:12PM -0400, Jim Quinlan wrote:
> Hello Bjorn,
> 
> On Tue, Jun 16, 2020 at 6:05 PM Bjorn Helgaas  wrote:
> >
> > On Tue, Jun 16, 2020 at 04:55:16PM -0400, Jim Quinlan wrote:
> > > BrcmSTB PCIe controllers are intimately connected to the memory
> > > controller(s) on the SOC.  There is a "viewport" for each memory 
> > > controller
> > > that allows inbound accesses to CPU memory.  Each viewport's size must be
> > > set to a power of two, and that size must be equal to or larger than the
> > > amount of memory each controller supports.
> >
> > This describes some requirements, but doesn't actually say what this
> > patch *does*.
> >
> > I *think* it reads the viewport sizes from the "brcm,scb-sizes" DT
> > property instead of computing something from "dma-ranges".  Looks like
> > it also adds support for SCB1 and SCB2.
> >
> > Those seem interesting, but don't really come through in the subject
> > or even the commit log.
> >
> > If I understand correctly, this is all for DMA ("inbound accesses to
> > CPU memory").  I think it would be worth mentioning "DMA", since
> > that's the common term for this.
> 
> 
> I have changed the commit message to the text below.  Please let me
> know if it requires more work
> Thanks, Jim
> 
> PCI: brcmstb: Set internal memory DMA viewport sizes

Did you not set the viewport sizes before?

> BrcmSTB PCIe controllers are intimately connected to the memory
> controller(s) on the SOC.  There is a "viewport" for each memory controller
> that allows inbound DMA acceses to CPU memory.  Each viewport's size must
> be set to a power of two, and that size must be equal to or larger than the
> amount of memory each controller supports.  Unfortunately the viewport
> sizes cannot be ascertained from the "dma-ranges" property so they have
> their own property, "brcm,scb-sizes".

s/inbound DMA acceses to CPU memory/DMA/

"Accesses" is redundant since the "A" in "DMA" stands for "access".
I'm not sure "inbound" adds anything and might confuse since DMA may
be either a read or write of CPU memory.

I assume *all* drivers need to know the address and size of regions in
"dma-ranges".  Is there something special about this device that means
it needs something different?

I guess it's the base/extension split?  That couldn't be described as
two separate DMA ranges?

Could/should the new property have a name somehow related to
"dma-ranges"?

Should "dma-ranges" be documented in
Documentation/devicetree/bindings/pci/pci.txt instead of the
individual device bindings?

> There may be one to three memory controllers; they are indicated by the
> term SCBi.  Each controller has a base region and an optional extension
> region.  In physical memory, the base and extension regions are not
> adjacent, but in PCIe-space they are.  Further, the 1-3 viewports are also
> adjacent in PCIe-space.
> 
> The SCB settings work in conjunction with the "dma-ranges' offsets to
> enable non-identity mappings between system memory and PCIe space.

s/ranges'/ranges"/ (mismatched quotes)

This describes the hardware, but still doesn't actually say what this
patch *does*.

If I'm a user, why do I want this patch?  Does it fix something that
didn't work before?  Does it increase the amount of DMA-able memory?

What does this mean in terms of backwards compatibility with old DTs?
Does this work with old DTs that don't have "brcm,scb-sizes"?  Maybe
this is all related to specific devices that weren't supported before,
so there *are* no old DTs for them?  I can't tell from the binding
update or the patch that this is related to specific devices.

> > > Signed-off-by: Jim Quinlan 
> > > Acked-by: Florian Fainelli 
> > > ---
> > >  drivers/pci/controller/pcie-brcmstb.c | 68 ---
> > >  1 file changed, 50 insertions(+), 18 deletions(-)
> > >
> > > diff --git a/drivers/pci/controller/pcie-brcmstb.c 
> > > b/drivers/pci/controller/pcie-brcmstb.c
> > > index 9189406fd35c..39f77709c6a2 100644
> > > --- a/drivers/pci/controller/pcie-brcmstb.c
> > > +++ b/drivers/pci/controller/pcie-brcmstb.c
> > > @@ -57,6 +57,8 @@
> > >  #define  PCIE_MISC_MISC_CTRL_MAX_BURST_SIZE_MASK 0x30
> > >  #define  PCIE_MISC_MISC_CTRL_MAX_BURST_SIZE_128  0x0
> > >  #define  PCIE_MISC_MISC_CTRL_SCB0_SIZE_MASK  0xf800
> > > +#define  PCIE_MISC_MISC_CTRL_SCB1_SIZE_MASK  0x07c0
> > > +#define  PCIE_MISC_MISC_CTRL_SCB2_SIZE_MASK  0x001f
> > >
> > >  #define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LO 0x400c
> > >  #define PCIE_MEM_WIN0_LO(win)\
> > > @@ -154,6 +156,7 @@
> > >  #define SSC_STATUS_OFFSET0x1
> > >  #define SSC_STATUS_SSC_MASK  0x400
> > >  #define SSC_STATUS_PLL_LOCK_MASK 0x800
> > > +#define PCIE_BRCM_MAX_MEMC   3
> > >
> > >  #define IDX_ADDR(pcie)   
> > > (pcie->reg_offsets[EXT_CFG_INDEX])
> > >  #define DATA_ADDR(pcie)  
> > > (pcie->reg_offsets[EXT_CFG_DATA]

[PATCH] [v2] pinctrl: meson: fix drive strength register and bit calculation

2020-06-17 Thread Hyeonki Hong
If a GPIO bank has greater than 16 pins, PAD_DS_REG is split into two
or more registers. However, when register and bit were calculated, the
first register defined in the bank was used, and the bit was calculated
based on the first pin. This causes problems in setting the driving
strength.

The following method was used to solve this problem:
A bit is calculated first using predefined strides. Then, If the bit is
32 or more, the register is changed by the quotient of the bit divided
by 32. And the bit is set to the remainder.

Signed-off-by: Hyeonki Hong 
---
 drivers/pinctrl/meson/pinctrl-meson.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/pinctrl/meson/pinctrl-meson.c 
b/drivers/pinctrl/meson/pinctrl-meson.c
index bbc919bef2bf..bf116c2e45c0 100644
--- a/drivers/pinctrl/meson/pinctrl-meson.c
+++ b/drivers/pinctrl/meson/pinctrl-meson.c
@@ -56,6 +56,10 @@
 #include "../pinctrl-utils.h"
 #include "pinctrl-meson.h"
 
+static const unsigned int meson_bit_strides[] = {
+   1, 1, 1, 1, 1, 2, 1
+};
+
 /**
  * meson_get_bank() - find the bank containing a given pin
  *
@@ -96,8 +100,9 @@ static void meson_calc_reg_and_bit(struct meson_bank *bank, 
unsigned int pin,
 {
struct meson_reg_desc *desc = &bank->regs[reg_type];
 
-   *reg = desc->reg * 4;
-   *bit = desc->bit + pin - bank->first;
+   *bit = (desc->bit + pin - bank->first) * meson_bit_strides[reg_type];
+   *reg = (desc->reg + (*bit / 32)) * 4;
+   *bit &= 0x1f;
 }
 
 static int meson_get_groups_count(struct pinctrl_dev *pcdev)
@@ -314,7 +319,6 @@ static int meson_pinconf_set_drive_strength(struct 
meson_pinctrl *pc,
return ret;
 
meson_calc_reg_and_bit(bank, pin, REG_DS, ®, &bit);
-   bit = bit << 1;
 
if (drive_strength_ua <= 500) {
ds_val = MESON_PINCONF_DRV_500UA;
@@ -441,7 +445,6 @@ static int meson_pinconf_get_drive_strength(struct 
meson_pinctrl *pc,
return ret;
 
meson_calc_reg_and_bit(bank, pin, REG_DS, ®, &bit);
-   bit = bit << 1;
 
ret = regmap_read(pc->reg_ds, reg, &val);
if (ret)
-- 
2.17.1



[PATCH v2] f2fs: fix a race condition between f2fs_write_end_io and f2fs_del_fsync_node_entry

2020-06-17 Thread zhaowuyun
From: Wuyun Zhao 

Under some condition, the __write_node_page will submit a page which is not
f2fs_in_warm_node_list and will not call f2fs_add_fsync_node_entry.
f2fs_gc continue to run to invoke f2fs_iget -> do_read_inode to read the same 
node page
and set code node, which make f2fs_in_warm_node_list become true,
that will cause f2fs_bug_on in f2fs_del_fsync_node_entry when f2fs_write_end_io 
called.

- f2fs_write_end_io
- f2fs_iget
 - do_read_inode
  - set_cold_node
  recover cold node flag
 - f2fs_in_warm_node_list
  - is_cold_node
  if node is cold, assume we have added
  node to fsync_node_list during writepages()
 - f2fs_del_fsync_node_entry
  - f2fs_bug_on() due to node page
  is not in fsync_node_list

[   34.966133] Call trace:
[   34.969902]  f2fs_del_fsync_node_entry+0x100/0x108
[   34.976071]  f2fs_write_end_io+0x1e0/0x288
[   34.981539]  bio_endio+0x248/0x270
[   34.986289]  blk_update_request+0x2b0/0x4d8
[   34.991841]  scsi_end_request+0x40/0x440
[   34.997126]  scsi_io_completion+0xa4/0x748
[   35.002593]  scsi_finish_command+0xdc/0x110
[   35.008143]  scsi_softirq_done+0x118/0x150
[   35.013610]  blk_done_softirq+0x8c/0xe8
[   35.018811]  __do_softirq+0x2e8/0x578
[   35.023828]  irq_exit+0xfc/0x120
[   35.028398]  handle_IPI+0x1d8/0x330
[   35.033233]  gic_handle_irq+0x110/0x1d4
[   35.038433]  el1_irq+0xb4/0x130
[   35.042917]  kmem_cache_alloc+0x3f0/0x418
[   35.048288]  radix_tree_node_alloc+0x50/0xf8
[   35.053933]  __radix_tree_create+0xf8/0x188
[   35.059484]  __radix_tree_insert+0x3c/0x128
[   35.065035]  add_gc_inode+0x90/0x118
[   35.069967]  f2fs_gc+0x1b80/0x2d70
[   35.074718]  f2fs_disable_checkpoint+0x94/0x1d0
[   35.080621]  f2fs_fill_super+0x10c4/0x1b88
[   35.086088]  mount_bdev+0x194/0x1e0
[   35.090923]  f2fs_mount+0x40/0x50
[   35.095589]  mount_fs+0xb4/0x190
[   35.100159]  vfs_kern_mount+0x80/0x1d8
[   35.105260]  do_mount+0x478/0xf18
[   35.109926]  ksys_mount+0x90/0xd0
[   35.114592]  __arm64_sys_mount+0x24/0x38

Signed-off-by: Wuyun Zhao 
Reviewed-by: Chao Yu 
---
 fs/f2fs/inode.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c
index be6ac33..0df5c8c 100644
--- a/fs/f2fs/inode.c
+++ b/fs/f2fs/inode.c
@@ -402,6 +402,7 @@ static int do_read_inode(struct inode *inode)
 
/* try to recover cold bit for non-dir inode */
if (!S_ISDIR(inode->i_mode) && !is_cold_node(node_page)) {
+   f2fs_wait_on_page_writeback(node_page, NODE, true, true);
set_cold_node(node_page, false);
set_page_dirty(node_page);
}
-- 
2.7.4



Re: 回复: [PATCH] f2fs: fix a race condition between f2fs_write_end_io and f2fs_del_fsync_node_entry

2020-06-17 Thread Chao Yu
On 2020/6/18 10:39, Zac wrote:
> 
>> On 2020/6/17 17:04, zhaowu...@wingtech.com wrote:
>>> From: Wuyun Zhao 
>>>
>>> Under some condition, the __write_node_page will submit a page which is
>> not
>>> f2fs_in_warm_node_list and will not call f2fs_add_fsync_node_entry.
>>> f2fs_gc continue to run to invoke f2fs_iget -> do_read_inode to read the
>> same node page
>>> and set code node, which make f2fs_in_warm_node_list become true,
>>> that will cause f2fs_bug_on in f2fs_del_fsync_node_entry when
>> f2fs_write_end_io called.
>> Could you please add below race condition description into commit
>> message?
>>
>> - f2fs_write_end_io
>>  - f2fs_iget
>>   - do_read_inode
>>- set_cold_node
>>recover cold node flag
>>  - f2fs_in_warm_node_list
>>   - is_cold_node
>>   if node is cold, assume we have added
>>   node to fsync_node_list during writepages()
>>  - f2fs_del_fsync_node_entry
>>   - f2fs_bug_on() due to node page
>>   is not in fsync_node_list
> 
> Ok, will add the commit message.
> 
>> BTW, I'm curious about why we can lose cold flag for non-dir inode?
>> any clue to reproduce this bug (I mean losing cold flag)?
> 
> it's a f2fs image with 25600MB
> flash this image to device
> the device will resize it according to the userdata partition size which is
> about 94GB
> the device mount the f2fs partition
> then hit this f2fs_bug_on
> 
> seems that the cold flag is not been set when mkfs

Ah, I guess both mkfs/sload ignores setting cold node flag for non-dir inode,
could you please send another patch to fix this issue?

> 
> I think the issue is that
> 
> 1. the node page in the storage is without cold bit
> 2. f2fs_disable_checkpoint -> f2fs_gc -> f2fs_get_node_page, this page won't
> be set cold flag
> 3. f2fs_move_node_page -> __write_node_page to write this page
> 4. f2fs_gc -> f2fs_iget -> do_read_inode to read this page and set cold flag

Clear enough, thanks for your explanation. :)

Thanks,

> 
>>>
>>> [   34.966133] Call trace:
>>> [   34.969902]  f2fs_del_fsync_node_entry+0x100/0x108
>>> [   34.976071]  f2fs_write_end_io+0x1e0/0x288
>>> [   34.981539]  bio_endio+0x248/0x270
>>> [   34.986289]  blk_update_request+0x2b0/0x4d8
>>> [   34.991841]  scsi_end_request+0x40/0x440
>>> [   34.997126]  scsi_io_completion+0xa4/0x748
>>> [   35.002593]  scsi_finish_command+0xdc/0x110
>>> [   35.008143]  scsi_softirq_done+0x118/0x150
>>> [   35.013610]  blk_done_softirq+0x8c/0xe8
>>> [   35.018811]  __do_softirq+0x2e8/0x578
>>> [   35.023828]  irq_exit+0xfc/0x120
>>> [   35.028398]  handle_IPI+0x1d8/0x330
>>> [   35.033233]  gic_handle_irq+0x110/0x1d4
>>> [   35.038433]  el1_irq+0xb4/0x130
>>> [   35.042917]  kmem_cache_alloc+0x3f0/0x418
>>> [   35.048288]  radix_tree_node_alloc+0x50/0xf8
>>> [   35.053933]  __radix_tree_create+0xf8/0x188
>>> [   35.059484]  __radix_tree_insert+0x3c/0x128
>>> [   35.065035]  add_gc_inode+0x90/0x118
>>> [   35.069967]  f2fs_gc+0x1b80/0x2d70
>>> [   35.074718]  f2fs_disable_checkpoint+0x94/0x1d0
>>> [   35.080621]  f2fs_fill_super+0x10c4/0x1b88
>>> [   35.086088]  mount_bdev+0x194/0x1e0
>>> [   35.090923]  f2fs_mount+0x40/0x50
>>> [   35.095589]  mount_fs+0xb4/0x190
>>> [   35.100159]  vfs_kern_mount+0x80/0x1d8
>>> [   35.105260]  do_mount+0x478/0xf18
>>> [   35.109926]  ksys_mount+0x90/0xd0
>>> [   35.114592]  __arm64_sys_mount+0x24/0x38
>>>
>>> Signed-off-by: Wuyun Zhao 
>>
>> Reviewed-by: Chao Yu 
>>
>> Thanks,
>>
>>> ---
>>>  fs/f2fs/inode.c | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c
>>> index be6ac33..0df5c8c 100644
>>> --- a/fs/f2fs/inode.c
>>> +++ b/fs/f2fs/inode.c
>>> @@ -402,6 +402,7 @@ static int do_read_inode(struct inode *inode)
>>>
>>> /* try to recover cold bit for non-dir inode */
>>> if (!S_ISDIR(inode->i_mode) && !is_cold_node(node_page)) {
>>> +   f2fs_wait_on_page_writeback(node_page, NODE, true, true);
>>> set_cold_node(node_page, false);
>>> set_page_dirty(node_page);
>>> }
>>>
> 
> .
> 


[PATCH AUTOSEL 5.7 012/388] staging: wfx: check ssidlen and prevent an array overflow

2020-06-17 Thread Sasha Levin
From: Dan Carpenter 

[ Upstream commit 87f86cddda65cab8a7e3df8a00e16abeccaa0730 ]

We need to cap "ssidlen" to prevent a memcpy() overflow.

Fixes: 40115bbc40e2 ("staging: wfx: implement the rest of mac80211 API")
Signed-off-by: Dan Carpenter 
Reviewed-by: Jérôme Pouiller 
Link: https://lore.kernel.org/r/20200424104235.GA416402@mwanda
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
---
 drivers/staging/wfx/sta.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/wfx/sta.c b/drivers/staging/wfx/sta.c
index 9d430346a58b..969d7a4a7fbd 100644
--- a/drivers/staging/wfx/sta.c
+++ b/drivers/staging/wfx/sta.c
@@ -520,7 +520,9 @@ static void wfx_do_join(struct wfx_vif *wvif)
ssidie = ieee80211_bss_get_ie(bss, WLAN_EID_SSID);
if (ssidie) {
ssidlen = ssidie[1];
-   memcpy(ssid, &ssidie[2], ssidie[1]);
+   if (ssidlen > IEEE80211_MAX_SSID_LEN)
+   ssidlen = IEEE80211_MAX_SSID_LEN;
+   memcpy(ssid, &ssidie[2], ssidlen);
}
rcu_read_unlock();
 
-- 
2.25.1



[PATCH AUTOSEL 5.7 007/388] ASoC: SOF: imx8: Fix randbuild error

2020-06-17 Thread Sasha Levin
From: YueHaibing 

[ Upstream commit fe17e6cdc0fefca96ba9659be4b2b07487cbf0c5 ]

when do randconfig like this:
CONFIG_SND_SOC_SOF_IMX8_SUPPORT=y
CONFIG_SND_SOC_SOF_IMX8=y
CONFIG_SND_SOC_SOF_OF=y
CONFIG_IMX_DSP=m
CONFIG_IMX_SCU=y

there is a link error:

sound/soc/sof/imx/imx8.o: In function 'imx8_send_msg':
imx8.c:(.text+0x380): undefined reference to 'imx_dsp_ring_doorbell'

Select IMX_DSP in SND_SOC_SOF_IMX8_SUPPORT to fix this

Fixes: f9ad75468453 ("ASoC: SOF: imx: fix reverse CONFIG_SND_SOC_SOF_OF 
dependency")
Reported-by: Hulk Robot 
Signed-off-by: YueHaibing 
Signed-off-by: Daniel Baluta 
Link: https://lore.kernel.org/r/20200409071832.2039-2-daniel.bal...@oss.nxp.com
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
---
 sound/soc/sof/imx/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/sof/imx/Kconfig b/sound/soc/sof/imx/Kconfig
index bae4f7bf5f75..812749064ca8 100644
--- a/sound/soc/sof/imx/Kconfig
+++ b/sound/soc/sof/imx/Kconfig
@@ -14,7 +14,7 @@ if SND_SOC_SOF_IMX_TOPLEVEL
 config SND_SOC_SOF_IMX8_SUPPORT
bool "SOF support for i.MX8"
depends on IMX_SCU
-   depends on IMX_DSP
+   select IMX_DSP
help
  This adds support for Sound Open Firmware for NXP i.MX8 platforms
  Say Y if you have such a device.
-- 
2.25.1



Re: [PATCH] tools/thermal: tmon: include pthread and time headers in tmon.h

2020-06-17 Thread Florian Fainelli



On 6/17/2020 4:58 PM, Markus Mayer wrote:
> Include sys/time.h and pthread.h in tmon.h, so that types
> "pthread_mutex_t" and "struct timeval tv" are known when tmon.h
> references them.
> 
> Without these headers, compiling tmon against musl-libc will fail with
> these errors:
> 
> In file included from sysfs.c:31:0:
> tmon.h:47:8: error: unknown type name 'pthread_mutex_t'
>  extern pthread_mutex_t input_lock;
> ^~~
> make[3]: *** [: sysfs.o] Error 1
> make[3]: *** Waiting for unfinished jobs
> In file included from tui.c:31:0:
> tmon.h:54:17: error: field 'tv' has incomplete type
>   struct timeval tv;
>  ^~
> make[3]: *** [: tui.o] Error 1
> make[2]: *** [Makefile:83: tmon] Error 2
> 
> Signed-off-by: Markus Mayer 

Acked-by: Florian Fainelli 
-- 
Florian


[PATCH AUTOSEL 5.7 006/388] i2c: piix4: Detect secondary SMBus controller on AMD AM4 chipsets

2020-06-17 Thread Sasha Levin
From: Adam Honse 

[ Upstream commit f27237c174fd965300e4e532cd9d153ce824 ]

The AMD X370 and other AM4 chipsets (A/B/X 3/4/5 parts) and Threadripper
equivalents have a secondary SMBus controller at I/O port address
0x0B20.  This bus is used by several manufacturers to control
motherboard RGB lighting via embedded controllers.  I have been using
this bus in my OpenRGB project to control the Aura RGB on many
motherboards and ASRock also uses this bus for their Polychrome RGB
controller.

I am not aware of any CZ-compatible platforms which do not have the
second SMBus channel.  All of AMD's AM4- and Threadripper- series
chipsets that OpenRGB users have tested appear to have this secondary
bus.  I also noticed this secondary bus is present on older AMD
platforms including my FM1 home server.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202587
Signed-off-by: Adam Honse 
Reviewed-by: Jean Delvare 
Reviewed-by: Sebastian Reichel 
Tested-by: Sebastian Reichel 
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin 
---
 drivers/i2c/busses/i2c-piix4.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-piix4.c b/drivers/i2c/busses/i2c-piix4.c
index 30ded6422e7b..69740a4ff1db 100644
--- a/drivers/i2c/busses/i2c-piix4.c
+++ b/drivers/i2c/busses/i2c-piix4.c
@@ -977,7 +977,8 @@ static int piix4_probe(struct pci_dev *dev, const struct 
pci_device_id *id)
}
 
if (dev->vendor == PCI_VENDOR_ID_AMD &&
-   dev->device == PCI_DEVICE_ID_AMD_HUDSON2_SMBUS) {
+   (dev->device == PCI_DEVICE_ID_AMD_HUDSON2_SMBUS ||
+dev->device == PCI_DEVICE_ID_AMD_KERNCZ_SMBUS)) {
retval = piix4_setup_sb800(dev, id, 1);
}
 
-- 
2.25.1



[PATCH AUTOSEL 5.7 011/388] clk: qcom: msm8916: Fix the address location of pll->config_reg

2020-06-17 Thread Sasha Levin
From: Bryan O'Donoghue 

[ Upstream commit f47ab3c2f5338828a67e89d5f688d2cef9605245 ]

During the process of debugging a processor derived from the msm8916 which
we found the new processor was not starting one of its PLLs.

After tracing the addresses and writes that downstream was doing and
comparing to upstream it became obvious that we were writing to a different
register location than downstream when trying to configure the PLL.

This error is also present in upstream msm8916.

As an example clk-pll.c::clk_pll_recalc_rate wants to write to
pll->config_reg updating the bit-field POST_DIV_RATIO. That bit-field is
defined in PLL_USER_CTL not in PLL_CONFIG_CTL. Taking the BIMC PLL as an
example

lm80-p0436-13_c_qc_snapdragon_410_processor_hrd.pdf

0x01823010 GCC_BIMC_PLL_USER_CTL
0x01823014 GCC_BIMC_PLL_CONFIG_CTL

This pattern is repeated for gpll0, gpll1, gpll2 and bimc_pll.

This error is likely not apparent since the bootloader will already have
initialized these PLLs.

This patch corrects the location of config_reg from PLL_CONFIG_CTL to
PLL_USER_CTL for all relevant PLLs on msm8916.

Fixes commit 3966fab8b6ab ("clk: qcom: Add MSM8916 Global Clock Controller 
support")

Cc: Georgi Djakov 
Cc: Andy Gross 
Cc: Bjorn Andersson 
Cc: Michael Turquette 
Cc: Stephen Boyd 
Signed-off-by: Bryan O'Donoghue 
Link: 
https://lkml.kernel.org/r/20200329124116.4185447-1-bryan.odonog...@linaro.org
Signed-off-by: Stephen Boyd 
Signed-off-by: Sasha Levin 
---
 drivers/clk/qcom/gcc-msm8916.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/qcom/gcc-msm8916.c b/drivers/clk/qcom/gcc-msm8916.c
index 4e329a7baf2b..17e4a5a2a9fd 100644
--- a/drivers/clk/qcom/gcc-msm8916.c
+++ b/drivers/clk/qcom/gcc-msm8916.c
@@ -260,7 +260,7 @@ static struct clk_pll gpll0 = {
.l_reg = 0x21004,
.m_reg = 0x21008,
.n_reg = 0x2100c,
-   .config_reg = 0x21014,
+   .config_reg = 0x21010,
.mode_reg = 0x21000,
.status_reg = 0x2101c,
.status_bit = 17,
@@ -287,7 +287,7 @@ static struct clk_pll gpll1 = {
.l_reg = 0x20004,
.m_reg = 0x20008,
.n_reg = 0x2000c,
-   .config_reg = 0x20014,
+   .config_reg = 0x20010,
.mode_reg = 0x2,
.status_reg = 0x2001c,
.status_bit = 17,
@@ -314,7 +314,7 @@ static struct clk_pll gpll2 = {
.l_reg = 0x4a004,
.m_reg = 0x4a008,
.n_reg = 0x4a00c,
-   .config_reg = 0x4a014,
+   .config_reg = 0x4a010,
.mode_reg = 0x4a000,
.status_reg = 0x4a01c,
.status_bit = 17,
@@ -341,7 +341,7 @@ static struct clk_pll bimc_pll = {
.l_reg = 0x23004,
.m_reg = 0x23008,
.n_reg = 0x2300c,
-   .config_reg = 0x23014,
+   .config_reg = 0x23010,
.mode_reg = 0x23000,
.status_reg = 0x2301c,
.status_bit = 17,
-- 
2.25.1



[Linux] [PATCH] Kernel selftests: tpm2: upgrade tpm2 tests from python2 to python3

2020-06-17 Thread Pengfei Xu
Some Linux OS will never support python2 anymore, so upgrade tpm2 selftests
to python3.

Signed-off-by: Pengfei Xu 
---
 tools/testing/selftests/tpm2/test_smoke.sh |  4 +-
 tools/testing/selftests/tpm2/test_space.sh |  2 +-
 tools/testing/selftests/tpm2/tpm2.py   | 68 ++
 tools/testing/selftests/tpm2/tpm2_tests.py | 24 +---
 4 files changed, 61 insertions(+), 37 deletions(-)

diff --git a/tools/testing/selftests/tpm2/test_smoke.sh 
b/tools/testing/selftests/tpm2/test_smoke.sh
index 663062701d5a..d05467f6d258 100755
--- a/tools/testing/selftests/tpm2/test_smoke.sh
+++ b/tools/testing/selftests/tpm2/test_smoke.sh
@@ -6,8 +6,8 @@ ksft_skip=4
 
 [ -f /dev/tpm0 ] || exit $ksft_skip
 
-python -m unittest -v tpm2_tests.SmokeTest
-python -m unittest -v tpm2_tests.AsyncTest
+python3 -m unittest -v tpm2_tests.SmokeTest
+python3 -m unittest -v tpm2_tests.AsyncTest
 
 CLEAR_CMD=$(which tpm2_clear)
 if [ -n $CLEAR_CMD ]; then
diff --git a/tools/testing/selftests/tpm2/test_space.sh 
b/tools/testing/selftests/tpm2/test_space.sh
index 36c9d030a1c6..151c64e8ee9f 100755
--- a/tools/testing/selftests/tpm2/test_space.sh
+++ b/tools/testing/selftests/tpm2/test_space.sh
@@ -6,4 +6,4 @@ ksft_skip=4
 
 [ -f /dev/tpmrm0 ] || exit $ksft_skip
 
-python -m unittest -v tpm2_tests.SpaceTest
+python3 -m unittest -v tpm2_tests.SpaceTest
diff --git a/tools/testing/selftests/tpm2/tpm2.py 
b/tools/testing/selftests/tpm2/tpm2.py
index d0fcb66a88a6..b0ccc1499c53 100644
--- a/tools/testing/selftests/tpm2/tpm2.py
+++ b/tools/testing/selftests/tpm2/tpm2.py
@@ -247,14 +247,18 @@ class ProtocolError(Exception):
 class AuthCommand(object):
 """TPMS_AUTH_COMMAND"""
 
-def __init__(self, session_handle=TPM2_RS_PW, nonce='', 
session_attributes=0,
- hmac=''):
+def __init__(self, session_handle=TPM2_RS_PW, nonce=''.encode(),
+ session_attributes=0, hmac=''.encode()):
+if not isinstance(nonce, bytes):
+nonce = nonce.encode()
+if not isinstance(hmac, bytes):
+hmac = hmac.encode()
 self.session_handle = session_handle
 self.nonce = nonce
 self.session_attributes = session_attributes
 self.hmac = hmac
 
-def __str__(self):
+def __bytes__(self):
 fmt = '>I H%us B H%us' % (len(self.nonce), len(self.hmac))
 return struct.pack(fmt, self.session_handle, len(self.nonce),
self.nonce, self.session_attributes, len(self.hmac),
@@ -268,11 +272,15 @@ class AuthCommand(object):
 class SensitiveCreate(object):
 """TPMS_SENSITIVE_CREATE"""
 
-def __init__(self, user_auth='', data=''):
+def __init__(self, user_auth=''.encode(), data=''.encode()):
+if not isinstance(user_auth, bytes):
+user_auth = user_auth.encode()
+if not isinstance(data, bytes):
+data = data.encode()
 self.user_auth = user_auth
 self.data = data
 
-def __str__(self):
+def __bytes__(self):
 fmt = '>H%us H%us' % (len(self.user_auth), len(self.data))
 return struct.pack(fmt, len(self.user_auth), self.user_auth,
len(self.data), self.data)
@@ -296,8 +304,15 @@ class Public(object):
 return '>HHIH%us%usH%us' % \
 (len(self.auth_policy), len(self.parameters), len(self.unique))
 
-def __init__(self, object_type, name_alg, object_attributes, 
auth_policy='',
- parameters='', unique=''):
+def __init__(self, object_type, name_alg, object_attributes,
+ auth_policy=''.encode(), parameters=''.encode(),
+ unique=''.encode()):
+if not isinstance(auth_policy, bytes):
+auth_policy = auth_policy.encode()
+if not isinstance(parameters, bytes):
+parameters = parameters.encode()
+if not isinstance(unique, bytes):
+unique = unique.encode()
 self.object_type = object_type
 self.name_alg = name_alg
 self.object_attributes = object_attributes
@@ -305,7 +320,7 @@ class Public(object):
 self.parameters = parameters
 self.unique = unique
 
-def __str__(self):
+def __bytes__(self):
 return struct.pack(self.__fmt(),
self.object_type,
self.name_alg,
@@ -343,7 +358,7 @@ def get_algorithm(name):
 
 def hex_dump(d):
 d = [format(ord(x), '02x') for x in d]
-d = [d[i: i + 16] for i in xrange(0, len(d), 16)]
+d = [d[i: i + 16] for i in range(0, len(d), 16)]
 d = [' '.join(x) for x in d]
 d = os.linesep.join(d)
 
@@ -401,7 +416,7 @@ class Client:
 pcrsel_len = max((i >> 3) + 1, 3)
 pcrsel = [0] * pcrsel_len
 pcrsel[i >> 3] = 1 << (i & 7)
-pcrsel = ''.join(map(chr, pcrsel))
+pcrsel = ''.join(map(chr, pcrsel)).encode()
 
 fmt = '>HII IHB%us' % (pcrsel_len)
 cmd = struct.pack(fmt,
@@ -430,6 +445,8 @@ class Client:
  

[PATCH AUTOSEL 5.7 008/388] iio: pressure: bmp280: Tolerate IRQ before registering

2020-06-17 Thread Sasha Levin
From: Andy Shevchenko 

[ Upstream commit 97b31a6f5fb95b1ec6575b78a7240baddba34384 ]

With DEBUG_SHIRQ enabled we have a kernel crash

[  116.482696] BUG: kernel NULL pointer dereference, address: 

...

[  116.606571] Call Trace:
[  116.609023]  
[  116.611047]  complete+0x34/0x50
[  116.614206]  bmp085_eoc_irq+0x9/0x10 [bmp280]

because DEBUG_SHIRQ mechanism fires an IRQ before registration and drivers
ought to be able to handle an interrupt happening before request_irq() returns.

Fixes: aae953949651 ("iio: pressure: bmp280: add support for BMP085 EOC 
interrupt")
Signed-off-by: Andy Shevchenko 
Acked-by: Linus Walleij 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Sasha Levin 
---
 drivers/iio/pressure/bmp280-core.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/iio/pressure/bmp280-core.c 
b/drivers/iio/pressure/bmp280-core.c
index 29c209cc1108..2540e7c2358c 100644
--- a/drivers/iio/pressure/bmp280-core.c
+++ b/drivers/iio/pressure/bmp280-core.c
@@ -713,7 +713,7 @@ static int bmp180_measure(struct bmp280_data *data, u8 
ctrl_meas)
unsigned int ctrl;
 
if (data->use_eoc)
-   init_completion(&data->done);
+   reinit_completion(&data->done);
 
ret = regmap_write(data->regmap, BMP280_REG_CTRL_MEAS, ctrl_meas);
if (ret)
@@ -969,6 +969,9 @@ static int bmp085_fetch_eoc_irq(struct device *dev,
"trying to enforce it\n");
irq_trig = IRQF_TRIGGER_RISING;
}
+
+   init_completion(&data->done);
+
ret = devm_request_threaded_irq(dev,
irq,
bmp085_eoc_irq,
-- 
2.25.1



[PATCH AUTOSEL 5.7 003/388] clk: sunxi: Fix incorrect usage of round_down()

2020-06-17 Thread Sasha Levin
From: Rikard Falkeborn 

[ Upstream commit ee25d9742dabed3fd18158b518f846abeb70f319 ]

round_down() can only round to powers of 2. If round_down() is asked
to round to something that is not a power of 2, incorrect results are
produced. The incorrect results can be both too large and too small.

Instead, use rounddown() which can round to any number.

Fixes: 6a721db180a2 ("clk: sunxi: Add A31 clocks support")
Signed-off-by: Rikard Falkeborn 
Signed-off-by: Maxime Ripard 
Signed-off-by: Sasha Levin 
---
 drivers/clk/sunxi/clk-sunxi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 27201fd26e44..e1aa1fbac48a 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -90,7 +90,7 @@ static void sun6i_a31_get_pll1_factors(struct factors_request 
*req)
 * Round down the frequency to the closest multiple of either
 * 6 or 16
 */
-   u32 round_freq_6 = round_down(freq_mhz, 6);
+   u32 round_freq_6 = rounddown(freq_mhz, 6);
u32 round_freq_16 = round_down(freq_mhz, 16);
 
if (round_freq_6 > round_freq_16)
-- 
2.25.1



[PATCH AUTOSEL 5.7 019/388] arm64: dts: renesas: Fix IOMMU device node names

2020-06-17 Thread Sasha Levin
From: Yoshihiro Shimoda 

[ Upstream commit cf8ae446bbcbf5c48214eb7ddaa6ac6e12f4633d ]

Fix IOMMU device node names as "iommu@".

Fixes: 8f507babc617 ("arm64: dts: renesas: r8a774a1: Add IPMMU device nodes")
Fixes: 63093a8e58be ("arm64: dts: renesas: r8a774b1: Add IPMMU device nodes")
Fixes: 6c7e02178e8f ("arm64: dts: renesas: r8a774c0: Add IPMMU device nodes")
Fixes: 3b7e7848f0e8 ("arm64: dts: renesas: r8a7795: Add IPMMU device nodes")
Fixes: e4b9a493df45 ("arm64: dts: renesas: r8a7795-es1: Add IPMMU device nodes")
Fixes: 389baa409617 ("arm64: dts: renesas: r8a7796: Add IPMMU device nodes")
Fixes: 55697cbb44e4 ("arm64: dts: renesas: r8a779{65,80,90}: Add IPMMU devices 
nodes")
Fixes: ce3b52a1595b ("arm64: dts: renesas: r8a77970: Add IPMMU device nodes")
Fixes: a3901e7398e1 ("arm64: dts: renesas: r8a77995: Add IPMMU device nodes")
Signed-off-by: Yoshihiro Shimoda 
Reviewed-by: Niklas Söderlund 
Link: 
https://lore.kernel.org/r/1587461775-13369-1-git-send-email-yoshihiro.shimoda...@renesas.com
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Sasha Levin 
---
 arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 18 ++--
 arch/arm64/boot/dts/renesas/r8a774b1.dtsi | 18 ++--
 arch/arm64/boot/dts/renesas/r8a774c0.dtsi | 18 ++--
 arch/arm64/boot/dts/renesas/r8a77950.dtsi | 14 +-
 arch/arm64/boot/dts/renesas/r8a77951.dtsi | 34 +++
 arch/arm64/boot/dts/renesas/r8a77960.dtsi | 22 +++
 arch/arm64/boot/dts/renesas/r8a77965.dtsi | 20 ++---
 arch/arm64/boot/dts/renesas/r8a77970.dtsi | 10 +++
 arch/arm64/boot/dts/renesas/r8a77980.dtsi | 16 +--
 arch/arm64/boot/dts/renesas/r8a77990.dtsi | 20 ++---
 arch/arm64/boot/dts/renesas/r8a77995.dtsi | 20 ++---
 11 files changed, 105 insertions(+), 105 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi 
b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
index 79023433a740..a603d947970e 100644
--- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
@@ -1000,7 +1000,7 @@ dmac2: dma-controller@e731 {
   <&ipmmu_ds1 30>, <&ipmmu_ds1 31>;
};
 
-   ipmmu_ds0: mmu@e674 {
+   ipmmu_ds0: iommu@e674 {
compatible = "renesas,ipmmu-r8a774a1";
reg = <0 0xe674 0 0x1000>;
renesas,ipmmu-main = <&ipmmu_mm 0>;
@@ -1008,7 +1008,7 @@ ipmmu_ds0: mmu@e674 {
#iommu-cells = <1>;
};
 
-   ipmmu_ds1: mmu@e774 {
+   ipmmu_ds1: iommu@e774 {
compatible = "renesas,ipmmu-r8a774a1";
reg = <0 0xe774 0 0x1000>;
renesas,ipmmu-main = <&ipmmu_mm 1>;
@@ -1016,7 +1016,7 @@ ipmmu_ds1: mmu@e774 {
#iommu-cells = <1>;
};
 
-   ipmmu_hc: mmu@e657 {
+   ipmmu_hc: iommu@e657 {
compatible = "renesas,ipmmu-r8a774a1";
reg = <0 0xe657 0 0x1000>;
renesas,ipmmu-main = <&ipmmu_mm 2>;
@@ -1024,7 +1024,7 @@ ipmmu_hc: mmu@e657 {
#iommu-cells = <1>;
};
 
-   ipmmu_mm: mmu@e67b {
+   ipmmu_mm: iommu@e67b {
compatible = "renesas,ipmmu-r8a774a1";
reg = <0 0xe67b 0 0x1000>;
interrupts = ,
@@ -1033,7 +1033,7 @@ ipmmu_mm: mmu@e67b {
#iommu-cells = <1>;
};
 
-   ipmmu_mp: mmu@ec67 {
+   ipmmu_mp: iommu@ec67 {
compatible = "renesas,ipmmu-r8a774a1";
reg = <0 0xec67 0 0x1000>;
renesas,ipmmu-main = <&ipmmu_mm 4>;
@@ -1041,7 +1041,7 @@ ipmmu_mp: mmu@ec67 {
#iommu-cells = <1>;
};
 
-   ipmmu_pv0: mmu@fd80 {
+   ipmmu_pv0: iommu@fd80 {
compatible = "renesas,ipmmu-r8a774a1";
reg = <0 0xfd80 0 0x1000>;
renesas,ipmmu-main = <&ipmmu_mm 5>;
@@ -1049,7 +1049,7 @@ ipmmu_pv0: mmu@fd80 {
#iommu-cells = <1>;
};
 
-   ipmmu_pv1: mmu@fd95 {
+   ipmmu_pv1: iommu@fd95 {
compatible = "renesas,ipmmu-r8a774a1";
reg = <0 0xfd95 0 0x1000>;
renesas,ipmmu-main = <&ipmmu_mm 6>;
@@ -1057,7 +1057,7 @@ ipmmu_pv1: mmu@fd95 {
#iommu-cells = <1>;
};
 
-   ipmmu_vc0: mmu@fe6b {
+   ipmmu_vc0: iommu@fe6b {
compatible = "renesas,ipmmu-r8a774a1";
reg = <0 0xfe6b 0 0x1000>

[PATCH AUTOSEL 5.7 017/388] ARM: integrator: Add some Kconfig selections

2020-06-17 Thread Sasha Levin
From: Linus Walleij 

[ Upstream commit d2854bbe5f5c4b4bec8061caf4f2e603d8819446 ]

The CMA and DMA_CMA Kconfig options need to be selected
by the Integrator in order to produce boot console on some
Integrator systems.

The REGULATOR and REGULATOR_FIXED_VOLTAGE need to be
selected in order to boot the system from an external
MMC card when using MMCI/PL181 from the device tree
probe path.

Select these things directly from the Kconfig so we are
sure to be able to bring the systems up with console
from any device tree.

Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin 
---
 arch/arm/mach-integrator/Kconfig | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-integrator/Kconfig b/arch/arm/mach-integrator/Kconfig
index 982eabc36163..2406cab73835 100644
--- a/arch/arm/mach-integrator/Kconfig
+++ b/arch/arm/mach-integrator/Kconfig
@@ -4,6 +4,8 @@ menuconfig ARCH_INTEGRATOR
depends on ARCH_MULTI_V4T || ARCH_MULTI_V5 || ARCH_MULTI_V6
select ARM_AMBA
select COMMON_CLK_VERSATILE
+   select CMA
+   select DMA_CMA
select HAVE_TCM
select ICST
select MFD_SYSCON
@@ -35,14 +37,13 @@ config INTEGRATOR_IMPD1
select ARM_VIC
select GPIO_PL061
select GPIOLIB
+   select REGULATOR
+   select REGULATOR_FIXED_VOLTAGE
help
  The IM-PD1 is an add-on logic module for the Integrator which
  allows ARM(R) Ltd PrimeCells to be developed and evaluated.
  The IM-PD1 can be found on the Integrator/PP2 platform.
 
- To compile this driver as a module, choose M here: the
- module will be called impd1.
-
 config INTEGRATOR_CM7TDMI
bool "Integrator/CM7TDMI core module"
depends on ARCH_INTEGRATOR_AP
-- 
2.25.1



  1   2   3   4   5   6   7   8   9   10   >