Re: [PATCH v6 9/9] remoteproc: Properly handle firmware name when attaching

[Bjorn Andersson]

On Tue 14 Jul 12:50 PDT 2020, Mathieu Poirier wrote:

> This patch prevents the firmware image name from being displayed when
> the remoteproc core is attaching to a remote processor. This is needed
> needed since there is no guarantee about the nature of the firmware
> image that is loaded by the external entity.
> 
> Signed-off-by: Mathieu Poirier 
> Reviewed-by: Arnaud Pouliquen 
> Tested-by: Arnaud Pouliquen 

Reviewed-by: Bjorn Andersson 

> ---
>  drivers/remoteproc/remoteproc_core.c  | 18 ++
>  drivers/remoteproc/remoteproc_sysfs.c | 16 ++--
>  include/linux/remoteproc.h|  2 ++
>  3 files changed, 34 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/remoteproc/remoteproc_core.c 
> b/drivers/remoteproc/remoteproc_core.c
> index 6b6e4ec8cf3a..099c76ab198f 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -1624,6 +1624,14 @@ static int rproc_stop(struct rproc *rproc, bool 
> crashed)
>  
>   rproc->state = RPROC_OFFLINE;
>  
> + /*
> +  * The remote processor has been stopped and is now offline, which means
> +  * that the next time it is brought back online the remoteproc core will
> +  * be responsible to load its firmware.  As such it is no longer
> +  * autonomous.
> +  */
> + rproc->autonomous = false;
> +
>   dev_info(dev, "stopped remote processor %s\n", rproc->name);
>  
>   return 0;
> @@ -2142,6 +2150,16 @@ int rproc_add(struct rproc *rproc)
>   /* create debugfs entries */
>   rproc_create_debug_dir(rproc);
>  
> + /*
> +  * Remind ourselves the remote processor has been attached to rather
> +  * than booted by the remoteproc core.  This is important because the
> +  * RPROC_DETACHED state will be lost as soon as the remote processor
> +  * has been attached to.  Used in firmware_show() and reset in
> +  * rproc_stop().
> +  */
> + if (rproc->state == RPROC_DETACHED)
> + rproc->autonomous = true;
> +
>   /* if rproc is marked always-on, request it to boot */
>   if (rproc->auto_boot) {
>   ret = rproc_trigger_auto_boot(rproc);
> diff --git a/drivers/remoteproc/remoteproc_sysfs.c 
> b/drivers/remoteproc/remoteproc_sysfs.c
> index 264759713934..eea514cec50e 100644
> --- a/drivers/remoteproc/remoteproc_sysfs.c
> +++ b/drivers/remoteproc/remoteproc_sysfs.c
> @@ -15,8 +15,20 @@ static ssize_t firmware_show(struct device *dev, struct 
> device_attribute *attr,
> char *buf)
>  {
>   struct rproc *rproc = to_rproc(dev);
> -
> - return sprintf(buf, "%s\n", rproc->firmware);
> + const char *firmware = rproc->firmware;
> +
> + /*
> +  * If the remote processor has been started by an external
> +  * entity we have no idea of what image it is running.  As such
> +  * simply display a generic string rather then rproc->firmware.
> +  *
> +  * Here we rely on the autonomous flag because a remote processor
> +  * may have been attached to and currently in a running state.
> +  */
> + if (rproc->autonomous)
> + firmware = "unknown";
> +
> + return sprintf(buf, "%s\n", firmware);
>  }
>  
>  /* Change firmware name via sysfs */
> diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
> index bf6a310ba870..cf5e31556780 100644
> --- a/include/linux/remoteproc.h
> +++ b/include/linux/remoteproc.h
> @@ -491,6 +491,7 @@ struct rproc_dump_segment {
>   * @table_sz: size of @cached_table
>   * @has_iommu: flag to indicate if remote processor is behind an MMU
>   * @auto_boot: flag to indicate if remote processor should be auto-started
> + * @autonomous: true if an external entity has booted the remote processor
>   * @dump_segments: list of segments in the firmware
>   * @nb_vdev: number of vdev currently handled by rproc
>   */
> @@ -524,6 +525,7 @@ struct rproc {
>   size_t table_sz;
>   bool has_iommu;
>   bool auto_boot;
> + bool autonomous;
>   struct list_head dump_segments;
>   int nb_vdev;
>   u8 elf_class;
> -- 
> 2.25.1
> 

Re: [PATCH v3] powerpc/pseries: detect secure and trusted boot state of the system.

[Daniel Axtens]

Michal Suchánek  writes:

> On Wed, Jul 15, 2020 at 07:52:01AM -0400, Nayna Jain wrote:
>> The device-tree property to check secure and trusted boot state is
>> different for guests(pseries) compared to baremetal(powernv).
>> 
>> This patch updates the existing is_ppc_secureboot_enabled() and
>> is_ppc_trustedboot_enabled() functions to add support for pseries.
>> 
>> The secureboot and trustedboot state are exposed via device-tree property:
>> /proc/device-tree/ibm,secure-boot and /proc/device-tree/ibm,trusted-boot
>> 
>> The values of ibm,secure-boot under pseries are interpreted as:
>   ^^^
>> 
>> 0 - Disabled
>> 1 - Enabled in Log-only mode. This patch interprets this value as
>> disabled, since audit mode is currently not supported for Linux.
>> 2 - Enabled and enforced.
>> 3-9 - Enabled and enforcing; requirements are at the discretion of the
>> operating system.
>> 
>> The values of ibm,trusted-boot under pseries are interpreted as:
>^^^
> These two should be different I suppose?

I'm not quite sure what you mean? They'll be documented in a future
revision of the PAPR, once I get my act together and submit the
relevant internal paperwork.

Daniel
>
> Thanks
>
> Michal
>> 0 - Disabled
>> 1 - Enabled
>> 
>> Signed-off-by: Nayna Jain 
>> Reviewed-by: Daniel Axtens 
>> ---
>> v3:
>> * fixed double check. Thanks Daniel for noticing it.
>> * updated patch description.
>> 
>> v2:
>> * included Michael Ellerman's feedback.
>> * added Daniel Axtens's Reviewed-by.
>> 
>>  arch/powerpc/kernel/secure_boot.c | 19 +--
>>  1 file changed, 17 insertions(+), 2 deletions(-)
>> 
>> diff --git a/arch/powerpc/kernel/secure_boot.c 
>> b/arch/powerpc/kernel/secure_boot.c
>> index 4b982324d368..118bcb5f79c4 100644
>> --- a/arch/powerpc/kernel/secure_boot.c
>> +++ b/arch/powerpc/kernel/secure_boot.c
>> @@ -6,6 +6,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  
>>  static struct device_node *get_ppc_fw_sb_node(void)
>>  {
>> @@ -23,12 +24,19 @@ bool is_ppc_secureboot_enabled(void)
>>  {
>>  struct device_node *node;
>>  bool enabled = false;
>> +u32 secureboot;
>>  
>>  node = get_ppc_fw_sb_node();
>>  enabled = of_property_read_bool(node, "os-secureboot-enforcing");
>> -
>>  of_node_put(node);
>>  
>> +if (enabled)
>> +goto out;
>> +
>> +if (!of_property_read_u32(of_root, "ibm,secure-boot", ))
>> +enabled = (secureboot > 1);
>> +
>> +out:
>>  pr_info("Secure boot mode %s\n", enabled ? "enabled" : "disabled");
>>  
>>  return enabled;
>> @@ -38,12 +46,19 @@ bool is_ppc_trustedboot_enabled(void)
>>  {
>>  struct device_node *node;
>>  bool enabled = false;
>> +u32 trustedboot;
>>  
>>  node = get_ppc_fw_sb_node();
>>  enabled = of_property_read_bool(node, "trusted-enabled");
>> -
>>  of_node_put(node);
>>  
>> +if (enabled)
>> +goto out;
>> +
>> +if (!of_property_read_u32(of_root, "ibm,trusted-boot", ))
>> +enabled = (trustedboot > 0);
>> +
>> +out:
>>  pr_info("Trusted boot mode %s\n", enabled ? "enabled" : "disabled");
>>  
>>  return enabled;
>> -- 
>> 2.26.2
>> 

linux-next: build failure after merge of the kvm tree

[Stephen Rothwell]

Hi all,

After merging the kvm tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

arch/x86/kernel/kvm.c: In function '__sysvec_kvm_asyncpf_interrupt':
arch/x86/kernel/kvm.c:275:13: error: implicit declaration of function 
'idtentry_enter_cond_rcu'; did you mean 'idtentry_enter_nmi'? 
[-Werror=implicit-function-declaration]
  275 |  rcu_exit = idtentry_enter_cond_rcu(regs);
  | ^~~
  | idtentry_enter_nmi
arch/x86/kernel/kvm.c:286:2: error: implicit declaration of function 
'idtentry_exit_cond_rcu'; did you mean 'idtentry_exit_nmi'? 
[-Werror=implicit-function-declaration]
  286 |  idtentry_exit_cond_rcu(regs, rcu_exit);
  |  ^~
  |  idtentry_exit_nmi

Caused by commit

  b037b09b9058 ("x86/entry: Rename idtentry_enter/exit_cond_rcu() to 
idtentry_enter/exit()")

from the tip tree interacting with commit

  26d05b368a5c ("Merge branch 'kvm-async-pf-int' into HEAD")

from the kvm tree.

I have applied the following merge fix patch.

From: Stephen Rothwell 
Date: Fri, 17 Jul 2020 15:51:27 +1000
Subject: [PATCH] fix up for idtentry_{enter,exit}_cond_rcu() renaming

Signed-off-by: Stephen Rothwell 
---
 arch/x86/kernel/kvm.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index cebd96687194..91dd322f768d 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -270,9 +270,9 @@ DEFINE_IDTENTRY_SYSVEC(sysvec_kvm_asyncpf_interrupt)
 {
struct pt_regs *old_regs = set_irq_regs(regs);
u32 token;
-   bool rcu_exit;
+   idtentry_state_t state;
 
-   rcu_exit = idtentry_enter_cond_rcu(regs);
+   state = idtentry_enter(regs);
 
inc_irq_stat(irq_hv_callback_count);
 
@@ -283,7 +283,7 @@ DEFINE_IDTENTRY_SYSVEC(sysvec_kvm_asyncpf_interrupt)
wrmsrl(MSR_KVM_ASYNC_PF_ACK, 1);
}
 
-   idtentry_exit_cond_rcu(regs, rcu_exit);
+   idtentry_exit(regs, state);
set_irq_regs(old_regs);
 }
 
-- 
2.27.0

-- 
Cheers,
Stephen Rothwell


pgpLG6b2SJQwd.pgp
Description: OpenPGP digital signature

Re: [PATCH v3 2/4] clocksource/drivers: Add CLINT timer driver

[Anup Patel]

On Fri, Jul 17, 2020 at 10:58 AM Daniel Lezcano
 wrote:
>
> On 17/07/2020 07:21, Anup Patel wrote:
> > On Fri, Jul 17, 2020 at 2:57 AM Daniel Lezcano
> >  wrote:
> >>
> >>
> >> Hi Anup,
> >>
> >>
> >> On 15/07/2020 09:15, Anup Patel wrote:
> >>> The TIME CSR and SBI calls are not available in RISC-V M-mode so we
> >>> separate add CLINT driver for Linux RISC-V M-mode (i.e. RISC-V NoMMU
> >>> kernel).
> >>
> >> The description is confusing, please reword it and give a bit more
> >> information about the timer itself, especially, the IPI thing.
> >
> > Okay, will update.
> >
> >>
> >>> Signed-off-by: Anup Patel 
> >>> ---
> >>>  drivers/clocksource/Kconfig   |  10 ++
> >>>  drivers/clocksource/Makefile  |   1 +
> >>>  drivers/clocksource/timer-clint.c | 229 ++
> >>>  include/linux/cpuhotplug.h|   1 +
> >>>  4 files changed, 241 insertions(+)
> >>>  create mode 100644 drivers/clocksource/timer-clint.c
> >>>
> >>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> >>> index 91418381fcd4..eabcf1cfb0c0 100644
> >>> --- a/drivers/clocksource/Kconfig
> >>> +++ b/drivers/clocksource/Kconfig
> >>> @@ -658,6 +658,16 @@ config RISCV_TIMER
> >>> is accessed via both the SBI and the rdcycle instruction.  This is
> >>> required for all RISC-V systems.
> >>>
> >>> +config CLINT_TIMER
> >>> + bool "Timer for the RISC-V platform"
> >>> + depends on GENERIC_SCHED_CLOCK && RISCV_M_MODE
> >>> + default y
> >>> + select TIMER_PROBE
> >>> + select TIMER_OF
> >>> + help
> >>> +   This option enables the CLINT timer for RISC-V systems. The CLINT
> >>> +   driver is usually used for NoMMU RISC-V systems.
> >>
> >> For the timer, we do silent option and let the platform config select
> >> it. Please refer to other timer option below as reference.
> >
> > Okay, I will use "default RISCV" instead of "default y" (just like other
> > timer Kconfig options).
>
> Preferably, select it from the platform's Kconfig.

Okay, I will update.

>
> >>
> >>>  config CSKY_MP_TIMER
> >>>   bool "SMP Timer for the C-SKY platform" if COMPILE_TEST
> >>>   depends on CSKY
> >>> diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
> >>> index bdda1a2e4097..18e700e703a0 100644
> >>> --- a/drivers/clocksource/Makefile
> >>> +++ b/drivers/clocksource/Makefile
> >>> @@ -87,6 +87,7 @@ obj-$(CONFIG_CLKSRC_ST_LPC) += clksrc_st_lpc.o
> >>>  obj-$(CONFIG_X86_NUMACHIP)   += numachip.o
> >>>  obj-$(CONFIG_ATCPIT100_TIMER)+= timer-atcpit100.o
> >>>  obj-$(CONFIG_RISCV_TIMER)+= timer-riscv.o
> >>> +obj-$(CONFIG_CLINT_TIMER)+= timer-clint.o
> >>>  obj-$(CONFIG_CSKY_MP_TIMER)  += timer-mp-csky.o
> >>>  obj-$(CONFIG_GX6605S_TIMER)  += timer-gx6605s.o
> >>>  obj-$(CONFIG_HYPERV_TIMER)   += hyperv_timer.o
> >>> diff --git a/drivers/clocksource/timer-clint.c 
> >>> b/drivers/clocksource/timer-clint.c
> >>> new file mode 100644
> >>> index ..bfc38bb5a589
> >>> --- /dev/null
> >>> +++ b/drivers/clocksource/timer-clint.c
> >>> @@ -0,0 +1,229 @@
> >>> +// SPDX-License-Identifier: GPL-2.0
> >>> +/*
> >>> + * Copyright (C) 2020 Western Digital Corporation or its affiliates.
> >>> + *
> >>> + * Most of the M-mode (i.e. NoMMU) RISC-V systems usually have a
> >>> + * CLINT MMIO timer device.
> >>> + */
> >>> +
> >>> +#define pr_fmt(fmt) "clint: " fmt
> >>> +#include 
> >>> +#include 
> >>> +#include 
> >>> +#include 
> >>> +#include 
> >>> +#include 
> >>> +#include 
> >>> +#include 
> >>> +#include 
> >>> +#include 
> >>> +#include 
> >>> +#include 
> >>> +
> >>> +#define CLINT_IPI_OFF0
> >>> +#define CLINT_TIMER_CMP_OFF  0x4000
> >>> +#define CLINT_TIMER_VAL_OFF  0xbff8
> >>> +
> >>> +/* CLINT manages IPI and Timer for RISC-V M-mode  */
> >>> +static u32 __iomem *clint_ipi_base;
> >>> +static u64 __iomem *clint_timer_cmp;
> >>> +static u64 __iomem *clint_timer_val;
> >>> +static unsigned long clint_timer_freq;
> >>> +static unsigned int clint_timer_irq;
> >>> +
> >>> +static void clint_send_ipi(const struct cpumask *target)
> >>> +{
> >>> + unsigned int cpu;
> >>> +
> >>> + for_each_cpu(cpu, target)
> >>> + writel(1, clint_ipi_base + cpuid_to_hartid_map(cpu));
> >>> +}
> >>> +
> >>> +static void clint_clear_ipi(void)
> >>> +{
> >>> + writel(0, clint_ipi_base + cpuid_to_hartid_map(smp_processor_id()));
> >>> +}
> >>> +
> >>> +static struct riscv_ipi_ops clint_ipi_ops = {
> >>> + .ipi_inject = clint_send_ipi,
> >>> + .ipi_clear = clint_clear_ipi,
> >>> +};
> >>> +
> >>> +#ifdef CONFIG_64BIT
> >>> +#define clint_get_cycles()   readq_relaxed(clint_timer_val)
> >>> +#else
> >>> +#define clint_get_cycles()   readl_relaxed(clint_timer_val)
> >>> +#define clint_get_cycles_hi()readl_relaxed(((u32 
> >>> *)clint_timer_val) + 1)
> >>> +#endif
> >>> +
> >>> +#ifdef CONFIG_64BIT
> >>> +static u64 

Re: [PATCH 2/3] remoteproc: qcom_q6v5_mss: Add MBA log extraction support

[Bjorn Andersson]

On Thu 16 Jul 22:22 PDT 2020, Sibi Sankar wrote:

> On 2020-07-17 10:27, Bjorn Andersson wrote:
> > On Thu 16 Jul 05:36 PDT 2020, Sibi Sankar wrote:
> > 
> > > On SC7180 the MBA firmware stores the bootup text logs in a 4K segment
> > > at the beginning of the MBA region. Add support to extract the logs
> > > which will be useful to debug mba boot/authentication issues.
> > > 
> > > Signed-off-by: Sibi Sankar 
> > > ---
> > >  drivers/remoteproc/qcom_q6v5_mss.c | 41
> > > ++
> > >  1 file changed, 36 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/drivers/remoteproc/qcom_q6v5_mss.c
> > > b/drivers/remoteproc/qcom_q6v5_mss.c
> > > index 95e21ed607cb9..4ddf084b2c6fc 100644
> > > --- a/drivers/remoteproc/qcom_q6v5_mss.c
> > > +++ b/drivers/remoteproc/qcom_q6v5_mss.c
> > > @@ -9,6 +9,7 @@
> > > 
> > >  #include 
> > >  #include 
> > > +#include 
> > >  #include 
> > >  #include 
> > >  #include 
> > > @@ -37,6 +38,8 @@
> > > 
> > >  #define MPSS_CRASH_REASON_SMEM   421
> > > 
> > > +#define MBA_LOG_SIZE SZ_4K
> > > +
> > >  /* RMB Status Register Values */
> > >  #define RMB_PBL_SUCCESS  0x1
> > > 
> > > @@ -139,6 +142,7 @@ struct rproc_hexagon_res {
> > >   int version;
> > >   bool need_mem_protection;
> > >   bool has_alt_reset;
> > > + bool has_mba_logs;
> > >   bool has_spare_reg;
> > >  };
> > > 
> > > @@ -200,6 +204,7 @@ struct q6v5 {
> > >   struct qcom_sysmon *sysmon;
> > >   bool need_mem_protection;
> > >   bool has_alt_reset;
> > > + bool has_mba_logs;
> > >   bool has_spare_reg;
> > >   int mpss_perm;
> > >   int mba_perm;
> > > @@ -518,6 +523,19 @@ static int q6v5_rmb_mba_wait(struct q6v5
> > > *qproc, u32 status, int ms)
> > >   return val;
> > >  }
> > > 
> > > +static void q6v5_dump_mba_logs(struct q6v5 *qproc)
> > > +{
> > > + struct rproc *rproc = qproc->rproc;
> > > + void *data;
> > > +
> > > + data = vmalloc(MBA_LOG_SIZE);
> > > + if (!data)
> > > + return;
> > > +
> > > + memcpy(data, qproc->mba_region, MBA_LOG_SIZE);
> > > + dev_coredumpv(>dev, data, MBA_LOG_SIZE, GFP_KERNEL);
> > > +}
> > > +
> > >  static int q6v5proc_reset(struct q6v5 *qproc)
> > >  {
> > >   u32 val;
> > > @@ -838,6 +856,7 @@ static int q6v5_mba_load(struct q6v5 *qproc)
> > >  {
> > >   int ret;
> > >   int xfermemop_ret;
> > > + bool mba_load_err = false;
> > > 
> > >   qcom_q6v5_prepare(>q6v5);
> > > 
> > > @@ -931,7 +950,7 @@ static int q6v5_mba_load(struct q6v5 *qproc)
> > >   q6v5proc_halt_axi_port(qproc, qproc->halt_map, qproc->halt_q6);
> > >   q6v5proc_halt_axi_port(qproc, qproc->halt_map, qproc->halt_modem);
> > >   q6v5proc_halt_axi_port(qproc, qproc->halt_map, qproc->halt_nc);
> > > -
> > > + mba_load_err = true;
> > >  reclaim_mba:
> > >   xfermemop_ret = q6v5_xfer_mem_ownership(qproc, >mba_perm,
> > > true,
> > >   false, qproc->mba_phys,
> > > @@ -939,6 +958,8 @@ static int q6v5_mba_load(struct q6v5 *qproc)
> > >   if (xfermemop_ret) {
> > >   dev_err(qproc->dev,
> > >   "Failed to reclaim mba buffer, system may become 
> > > unstable\n");
> > > + } else if (qproc->has_mba_logs & mba_load_err) {
> > > + q6v5_dump_mba_logs(qproc);
> > >   }
> > > 
> > >  disable_active_clks:
> > > @@ -968,7 +989,7 @@ static int q6v5_mba_load(struct q6v5 *qproc)
> > >   return ret;
> > >  }
> > > 
> > > -static void q6v5_mba_reclaim(struct q6v5 *qproc)
> > > +static void q6v5_mba_reclaim(struct q6v5 *qproc, bool err_path)
> > >  {
> > >   int ret;
> > >   u32 val;
> > > @@ -1006,6 +1027,9 @@ static void q6v5_mba_reclaim(struct q6v5 *qproc)
> > > qproc->mba_size);
> > >   WARN_ON(ret);
> > > 
> > > + if (qproc->has_mba_logs && err_path && !ret)
> > 
> > Wouldn't it be possible to just call q6v5_dump_mba_logs() directly after
> > the return from q6v5_mba_reclaim()? That way we can avoid passing the
> > bool to indicate if the reclaim should also dump some stuff.
> > 
> > Sure we don't have a way to tell if the assign_mem failed, but we're
> > going to crash shortly anyways (which is something we should change).
> 
> We wont crash as long as we dont touch
> the mba region though. Trying a mba
> logs dump in such a case will ensure
> that we crash lol.
> 

Right, but that means that if we ever try to start the remoteproc again
it will crash on us.

So what I meant at the end there is that we should either have a
mechanism to ensure that no further accesses are attempted (e.g.
prohibit a subsequent "start") or this might actually be a valid case
for a BUG_ON().

Regards,
Bjorn

> > 
> > 
> > 
> > I think you should move the has_mba_logs into q6v5_dump_mba_logs(),
> > making it cause an early return.
> 
> cool sure I'll do that.
> 
> > 
> > Regards,
> > Bjorn
> > 
> > > + q6v5_dump_mba_logs(qproc);
> > > +
> > >   ret = qcom_q6v5_unprepare(>q6v5);
> > >   if (ret) {
> > >   q6v5_pds_disable(qproc, qproc->proxy_pds,
> > > 

Re: [PATCH v2 1/4] dt-bindings: media: venus: Add an optional power domain for perf voting

[Rajendra Nayak]

On 7/17/2020 1:29 AM, Rob Herring wrote:

On Thu, Jul 16, 2020 at 11:12:16AM +0530, Rajendra Nayak wrote:

Add an optional power domain which when specified can be used for
setting the performance state of Venus.


The h/w suddenly grew a new power island/domain? Seems like an abuse of
power-domains...


The power-domain always existed, we have just managed to survive without
having venus support DVFS and have the domain always be at a high performance
level (set statically by boot code)
Now, if we care to do DVFS and support better PM on the SoC, its important
for the devices to manage this additional power domain (and dynamically
scale it)

That said, if the name 'opp-pd' makes it look like a software construct,
like Bjorn mentioned, I am fine to give it a real name like 'cx-pd'
Does that sound good?

PS: Like I mentioned earlier [1], cx is a shared power island,
not a power island specific to this block, and definitely not a software
pm-domain construct.

[1] https://lore.kernel.org/patchwork/patch/1241077/





Signed-off-by: Rajendra Nayak 
---
This is a resend of https://lore.kernel.org/patchwork/patch/1241077/

  Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml| 6 +-
  Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml | 6 +-
  2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml 
b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
index 55f2d67..1e8675b 100644
--- a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
@@ -25,12 +25,16 @@ properties:
  maxItems: 1
  
power-domains:

-maxItems: 2
+minItems: 2
+maxItems: 3
  
power-domain-names:

+minItems: 2
+maxItems: 3
  items:
- const: venus
- const: vcodec0
+  - const: opp-pd
  
clocks:

  maxItems: 5
diff --git a/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml 
b/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml
index 157dff8..437286d 100644
--- a/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml
@@ -25,13 +25,17 @@ properties:
  maxItems: 1
  
power-domains:

-maxItems: 3
+minItems: 3
+maxItems: 4
  
power-domain-names:

+minItems: 3
+maxItems: 4
  items:
- const: venus
- const: vcodec0
- const: vcodec1
+  - const: opp-pd
  
clocks:

  maxItems: 7
--
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

mmotm 2020-07-16-22-52 uploaded

[Andrew Morton]

The mm-of-the-moment snapshot 2020-07-16-22-52 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-rc5:
(patches marked "*" will be included in linux-next)

  origin.patch
* mm-shuffle-dont-move-pages-between-zones-and-dont-read-garbage-memmaps.patch
* mm-avoid-access-flag-update-tlb-flush-for-retried-page-fault.patch
* mm-avoid-access-flag-update-tlb-flush-for-retried-page-fault-v2.patch
* mm-close-race-between-munmap-and-expand_upwards-downwards.patch
* mm-close-race-between-munmap-and-expand_upwards-downwards-fix.patch
* vfs-xattr-mm-shmem-kernfs-release-simple-xattr-entry-in-a-right-way.patch
* mm-initialize-return-of-vm_insert_pages.patch
* mm-memcontrol-fix-oops-inside-mem_cgroup_get_nr_swap_pages.patch
* proc-kpageflags-prevent-an-integer-overflow-in-stable_page_flags.patch
* proc-kpageflags-do-not-use-uninitialized-struct-pages.patch
* mm-memcg-fix-refcount-error-while-moving-and-swapping.patch
* mm-memcg-slab-fix-memory-leak-at-non-root-kmem_cache-destroy.patch
* mm-hugetlb-avoid-hardcoding-while-checking-if-cma-is-enabled.patch
* mailmap-add-entry-for-mike-rapoport.patch
* revert-squashfs-migrate-from-ll_rw_block-usage-to-bio.patch
* revert-squashfs-migrate-from-ll_rw_block-usage-to-bio-fix.patch
* checkpatch-test-git_dir-changes.patch
* kthread-remove-incorrect-comment-in-kthread_create_on_cpu.patch
* scripts-tagssh-collect-compiled-source-precisely.patch
* scripts-tagssh-collect-compiled-source-precisely-v2.patch
* bloat-o-meter-support-comparing-library-archives.patch
* scripts-decode_stacktrace-skip-missing-symbols.patch
* scripts-decode_stacktrace-guess-basepath-if-not-specified.patch
* scripts-decode_stacktrace-guess-path-to-modules.patch
* scripts-decode_stacktrace-guess-path-to-vmlinux-by-release-name.patch
* const_structscheckpatch-add-regulator_ops.patch
* scripts-spellingtxt-add-more-spellings-to-spellingtxt.patch
* ocfs2-clear-links-count-in-ocfs2_mknod-if-an-error-occurs.patch
* ocfs2-fix-ocfs2-corrupt-when-iputting-an-inode.patch
* ocfs2-change-slot-number-type-s16-to-u16.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-expand-config_slab_freelist_hardened-to-include-slab.patch
* slab-add-naive-detection-of-double-free.patch
* slab-add-naive-detection-of-double-free-fix.patch
* mm-slab-check-gfp_slab_bug_mask-before-alloc_pages-in-kmalloc_order.patch
* mm-slub-extend-slub_debug-syntax-for-multiple-blocks.patch
* mm-slub-extend-slub_debug-syntax-for-multiple-blocks-fix.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-introduce-kmem_cache_debug_flags-fix.patch
* mm-slub-extend-checks-guarded-by-slub_debug-static-key.patch
* mm-slab-slub-move-and-improve-cache_from_obj.patch
* mm-slab-slub-improve-error-reporting-and-overhead-of-cache_from_obj.patch
* mm-slab-slub-improve-error-reporting-and-overhead-of-cache_from_obj-fix.patch
* slub-drop-lockdep_assert_held-from-put_map.patch
* mm-kcsan-instrument-slab-slub-free-with-assert_exclusive_access.patch
* 
mm-debug_vm_pgtable-add-tests-validating-arch-helpers-for-core-mm-features.patch
* 

Re: [PATCH v4 2/2] remoteproc: core: Register the character device interface

[Bjorn Andersson]

On Tue 07 Jul 12:07 PDT 2020, Siddharth Gupta wrote:

> Add the character device during rproc_add. This would create
> a character device node at /dev/remoteproc. Userspace
> applications can interact with the remote processor using this
> interface.
> 
> Signed-off-by: Rishabh Bhatnagar 
> Signed-off-by: Siddharth Gupta 
> ---
>  drivers/remoteproc/remoteproc_core.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/remoteproc/remoteproc_core.c 
> b/drivers/remoteproc/remoteproc_core.c
> index 0f95e02..ec7fb49 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -1966,6 +1966,13 @@ int rproc_add(struct rproc *rproc)
>   struct device *dev = >dev;
>   int ret;
>  
> + /* add char device for this remoteproc */
> + ret = rproc_char_device_add(rproc);
> + if (ret) {
> + dev_err(dev, "Failed to add char dev for %s\n", rproc->name);

Please move this error message into rproc_char_device_add(), to make it
consistent with the other error handling in this function not printing.

Apart from that it looks good.

Regards,
Bjorn

> + return ret;
> + }
> +
>   ret = device_add(dev);
>   if (ret < 0)
>   return ret;
> @@ -2241,6 +2248,7 @@ int rproc_del(struct rproc *rproc)
>   mutex_unlock(>lock);
>  
>   rproc_delete_debug_dir(rproc);
> + rproc_char_device_remove(rproc);
>  
>   /* the rproc is downref'ed as soon as it's removed from the klist */
>   mutex_lock(_list_mutex);
> @@ -2409,6 +2417,7 @@ static int __init remoteproc_init(void)
>  {
>   rproc_init_sysfs();
>   rproc_init_debugfs();
> + rproc_init_cdev();
>   rproc_init_panic();
>  
>   return 0;
> @@ -2420,6 +2429,7 @@ static void __exit remoteproc_exit(void)
>   ida_destroy(_dev_index);
>  
>   rproc_exit_panic();
> + rproc_exit_cdev();
>   rproc_exit_debugfs();
>   rproc_exit_sysfs();
>  }
> -- 
> Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 

Re: [PATCH] tools/memory-model: document the "one-time init" pattern

[Sedat Dilek]

On Fri, Jul 17, 2020 at 6:48 AM Eric Biggers  wrote:
>
> From: Eric Biggers 
...
> This is motivated by the discussion at
> https://lkml.kernel.org/linux-fsdevel/2020071300.205104-1-ebigg...@kernel.org/T/#u
...
> +In where cases where taking the mutex in the "already initialized" case

"In cases where..." (drop first "where")

> +presents scalability concerns, the implementation can be optimized to
> +check the 'inited' flag outside the mutex.  Unfortunately, this
> +optimization is often implemented incorrectly by using a plain load.
> +That violates the memory model and may result in unpredictable behavior.

- Sedat -

Re: [PATCH v4 1/2] remoteproc: Add remoteproc character device interface

[Bjorn Andersson]

On Wed 15 Jul 13:18 PDT 2020, Mathieu Poirier wrote:

> On Tue, Jul 07, 2020 at 12:07:49PM -0700, Siddharth Gupta wrote:
> > Add the character device interface into remoteproc framework.
> > This interface can be used in order to boot/shutdown remote
> > subsystems and provides a basic ioctl based interface to implement
> > supplementary functionality. An ioctl call is implemented to enable
> > the shutdown on release feature which will allow remote processors to
> > be shutdown when the controlling userpsace application crashes or hangs.
> > 
> > Signed-off-by: Rishabh Bhatnagar 
> > Signed-off-by: Siddharth Gupta 
> > ---
> >  Documentation/userspace-api/ioctl/ioctl-number.rst |   1 +
> >  drivers/remoteproc/Kconfig |   9 ++
> >  drivers/remoteproc/Makefile|   1 +
> >  drivers/remoteproc/remoteproc_cdev.c   | 146 
> > +
> >  drivers/remoteproc/remoteproc_internal.h   |  28 
> >  include/linux/remoteproc.h |   5 +
> >  include/uapi/linux/remoteproc_cdev.h   |  37 ++
> >  7 files changed, 227 insertions(+)
> >  create mode 100644 drivers/remoteproc/remoteproc_cdev.c
> >  create mode 100644 include/uapi/linux/remoteproc_cdev.h
> > 
> > diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst 
> > b/Documentation/userspace-api/ioctl/ioctl-number.rst
> > index 59472cd..2a19883 100644
> > --- a/Documentation/userspace-api/ioctl/ioctl-number.rst
> > +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
> > @@ -339,6 +339,7 @@ Code  Seq#Include File  
> >  Comments
> >  0xB4  00-0F  linux/gpio.h
> > 
> >  0xB5  00-0F  uapi/linux/rpmsg.h  
> > 
> >  0xB6  alllinux/fpga-dfl.h
> > +0xB7  alluapi/linux/remoteproc_cdev.h
> > 
> >  0xC0  00-0F  linux/usb/iowarrior.h
> >  0xCA  00-0F  uapi/misc/cxl.h
> >  0xCA  10-2F  uapi/misc/ocxl.h
> > diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> > index c4d1731..652060f 100644
> > --- a/drivers/remoteproc/Kconfig
> > +++ b/drivers/remoteproc/Kconfig
> > @@ -14,6 +14,15 @@ config REMOTEPROC
> >  
> >  if REMOTEPROC
> >  
> > +config REMOTEPROC_CDEV
> > +   bool "Remoteproc character device interface"
> > +   help
> > + Say y here to have a character device interface for the remoteproc
> > + framework. Userspace can boot/shutdown remote processors through
> > + this interface.
> > +
> > + It's safe to say N if you don't want to use this interface.
> > +
> >  config IMX_REMOTEPROC
> > tristate "IMX6/7 remoteproc support"
> > depends on ARCH_MXC
> > diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> > index e8b886e..311ae3f 100644
> > --- a/drivers/remoteproc/Makefile
> > +++ b/drivers/remoteproc/Makefile
> > @@ -9,6 +9,7 @@ remoteproc-y+= 
> > remoteproc_debugfs.o
> >  remoteproc-y   += remoteproc_sysfs.o
> >  remoteproc-y   += remoteproc_virtio.o
> >  remoteproc-y   += remoteproc_elf_loader.o
> > +obj-$(CONFIG_REMOTEPROC_CDEV)  += remoteproc_cdev.o
> >  obj-$(CONFIG_IMX_REMOTEPROC)   += imx_rproc.o
> >  obj-$(CONFIG_INGENIC_VPU_RPROC)+= ingenic_rproc.o
> >  obj-$(CONFIG_MTK_SCP)  += mtk_scp.o mtk_scp_ipi.o
> > diff --git a/drivers/remoteproc/remoteproc_cdev.c 
> > b/drivers/remoteproc/remoteproc_cdev.c
> > new file mode 100644
> > index 000..8a0eb47
> > --- /dev/null
> > +++ b/drivers/remoteproc/remoteproc_cdev.c
> > @@ -0,0 +1,146 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Character device interface driver for Remoteproc framework.
> > + *
> > + * Copyright (c) 2020, The Linux Foundation. All rights reserved.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> 
> Alphabetical order please.
> 
> > +
> > +#include "remoteproc_internal.h"
> > +
> > +#define NUM_RPROC_DEVICES  64
> > +static dev_t rproc_major;
> > +
> > +static ssize_t rproc_cdev_write(struct file *filp, const char __user *buf, 
> > size_t len, loff_t *pos)
> > +{
> > +   struct rproc *rproc = container_of(filp->f_inode->i_cdev, struct rproc, 
> > char_dev);
> > +   int ret = 0;
> > +   char cmd[10];
> > +
> > +   if (!len || len > sizeof(cmd))
> > +   return -EINVAL;
> > +
> > +   ret = copy_from_user(cmd, buf, sizeof(cmd));
> > +   if (ret)
> > +   return -EFAULT;
> > +
> > +   if (sysfs_streq(cmd, "start")) {
> > +   if (rproc->state == RPROC_RUNNING)
> > +   return -EBUSY;
> > +
> > +   ret = 

Re: [PATCH v4 05/10] powerpc/dt_cpu_ftrs: Add feature for 2nd DAWR

[Jordan Niethe]

On Fri, Jul 17, 2020 at 2:10 PM Ravi Bangoria
 wrote:
>
> Add new device-tree feature for 2nd DAWR. If this feature is present,
> 2nd DAWR is supported, otherwise not.
>
> Signed-off-by: Ravi Bangoria 
> ---
>  arch/powerpc/include/asm/cputable.h | 7 +--
>  arch/powerpc/kernel/dt_cpu_ftrs.c   | 7 +++
>  2 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/cputable.h 
> b/arch/powerpc/include/asm/cputable.h
> index e506d429b1af..3445c86e1f6f 100644
> --- a/arch/powerpc/include/asm/cputable.h
> +++ b/arch/powerpc/include/asm/cputable.h
> @@ -214,6 +214,7 @@ static inline void cpu_feature_keys_init(void) { }
>  #define CPU_FTR_P9_TLBIE_ERAT_BUG  LONG_ASM_CONST(0x0001)
>  #define CPU_FTR_P9_RADIX_PREFETCH_BUG  LONG_ASM_CONST(0x0002)
>  #define CPU_FTR_ARCH_31
> LONG_ASM_CONST(0x0004)
> +#define CPU_FTR_DAWR1  LONG_ASM_CONST(0x0008)
>
>  #ifndef __ASSEMBLY__
>
> @@ -497,14 +498,16 @@ static inline void cpu_feature_keys_init(void) { }
>  #define CPU_FTRS_POSSIBLE  \
> (CPU_FTRS_POWER7 | CPU_FTRS_POWER8E | CPU_FTRS_POWER8 | \
>  CPU_FTR_ALTIVEC_COMP | CPU_FTR_VSX_COMP | CPU_FTRS_POWER9 | \
> -CPU_FTRS_POWER9_DD2_1 | CPU_FTRS_POWER9_DD2_2 | CPU_FTRS_POWER10)
> +CPU_FTRS_POWER9_DD2_1 | CPU_FTRS_POWER9_DD2_2 | CPU_FTRS_POWER10 
> | \
> +CPU_FTR_DAWR1)
>  #else
>  #define CPU_FTRS_POSSIBLE  \
> (CPU_FTRS_PPC970 | CPU_FTRS_POWER5 | \
>  CPU_FTRS_POWER6 | CPU_FTRS_POWER7 | CPU_FTRS_POWER8E | \
>  CPU_FTRS_POWER8 | CPU_FTRS_CELL | CPU_FTRS_PA6T | \
>  CPU_FTR_VSX_COMP | CPU_FTR_ALTIVEC_COMP | CPU_FTRS_POWER9 | \
> -CPU_FTRS_POWER9_DD2_1 | CPU_FTRS_POWER9_DD2_2 | CPU_FTRS_POWER10)
> +CPU_FTRS_POWER9_DD2_1 | CPU_FTRS_POWER9_DD2_2 | CPU_FTRS_POWER10 
> | \
> +CPU_FTR_DAWR1)
Instead of putting CPU_FTR_DAWR1 into CPU_FTRS_POSSIBLE should it go
into CPU_FTRS_POWER10?
Then it will be picked up by CPU_FTRS_POSSIBLE.
>  #endif /* CONFIG_CPU_LITTLE_ENDIAN */
>  #endif
>  #else
> diff --git a/arch/powerpc/kernel/dt_cpu_ftrs.c 
> b/arch/powerpc/kernel/dt_cpu_ftrs.c
> index ac650c233cd9..c78cd3596ec4 100644
> --- a/arch/powerpc/kernel/dt_cpu_ftrs.c
> +++ b/arch/powerpc/kernel/dt_cpu_ftrs.c
> @@ -574,6 +574,12 @@ static int __init feat_enable_mma(struct dt_cpu_feature 
> *f)
> return 1;
>  }
>
> +static int __init feat_enable_debug_facilities_v31(struct dt_cpu_feature *f)
> +{
> +   cur_cpu_spec->cpu_features |= CPU_FTR_DAWR1;
> +   return 1;
> +}
> +
>  struct dt_cpu_feature_match {
> const char *name;
> int (*enable)(struct dt_cpu_feature *f);
> @@ -649,6 +655,7 @@ static struct dt_cpu_feature_match __initdata
> {"wait-v3", feat_enable, 0},
> {"prefix-instructions", feat_enable, 0},
> {"matrix-multiply-assist", feat_enable_mma, 0},
> +   {"debug-facilities-v31", feat_enable_debug_facilities_v31, 0},
Since all feat_enable_debug_facilities_v31() does is set
CPU_FTR_DAWR1, if you just have:
{"debug-facilities-v31", feat_enable, CPU_FTR_DAWR1},
I think cpufeatures_process_feature() should set it in for you at this point:
if (m->enable(f)) {
cur_cpu_spec->cpu_features |= m->cpu_ftr_bit_mask;
break;
}

>  };
>
>  static bool __initdata using_dt_cpu_ftrs;
> --
> 2.26.2
>

[PATCH] power: supply: sc27xx: prevent adc * 1000 from overflow

[Chunyan Zhang]

From: Chunyan Zhang 

The input parameter is int type, cause adc * 1000 could overflow.
Change to use s64 to avoid this issue.

Fixes: 195ca1703784 ("power: supply: Add Spreadtrum SC27XX fuel gauge unit 
driver")
Signed-off-by: Chen Yongzhi 
Signed-off-by: Chunyan Zhang 
---
 drivers/power/supply/sc27xx_fuel_gauge.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/power/supply/sc27xx_fuel_gauge.c 
b/drivers/power/supply/sc27xx_fuel_gauge.c
index be42e814ea34..a9838a2a673d 100644
--- a/drivers/power/supply/sc27xx_fuel_gauge.c
+++ b/drivers/power/supply/sc27xx_fuel_gauge.c
@@ -133,12 +133,12 @@ static const char * const sc27xx_charger_supply_name[] = {
"sc2723_charger",
 };
 
-static int sc27xx_fgu_adc_to_current(struct sc27xx_fgu_data *data, int adc)
+static int sc27xx_fgu_adc_to_current(struct sc27xx_fgu_data *data, s64 adc)
 {
return DIV_ROUND_CLOSEST(adc * 1000, data->cur_1000ma_adc);
 }
 
-static int sc27xx_fgu_adc_to_voltage(struct sc27xx_fgu_data *data, int adc)
+static int sc27xx_fgu_adc_to_voltage(struct sc27xx_fgu_data *data, s64 adc)
 {
return DIV_ROUND_CLOSEST(adc * 1000, data->vol_1000mv_adc);
 }
-- 
2.20.1

Re: [PATCH v7 08/19] mm: memcg/slab: save obj_cgroup for non-root slab objects

[Naresh Kamboju]

On Fri, 17 Jul 2020 at 01:38, Roman Gushchin  wrote:
>
> On Thu, Jul 16, 2020 at 10:25:01PM +0530, Naresh Kamboju wrote:
> > On Tue, 23 Jun 2020 at 23:11, Roman Gushchin  wrote:
> > >
> > > Store the obj_cgroup pointer in the corresponding place of
> > > page->obj_cgroups for each allocated non-root slab object.  Make sure that
> > > each allocated object holds a reference to obj_cgroup.
> > >
> > > Objcg pointer is obtained from the memcg->objcg dereferencing in
> > > memcg_kmem_get_cache() and passed from pre_alloc_hook to post_alloc_hook.
> > > Then in case of successful allocation(s) it's getting stored in the
> > > page->obj_cgroups vector.
> > >
> > > The objcg obtaining part look a bit bulky now, but it will be simplified
> > > by next commits in the series.
> > >
> > > Signed-off-by: Roman Gushchin 
> > > Reviewed-by: Vlastimil Babka 
> > > Reviewed-by: Shakeel Butt 
> > > ---
> > >  include/linux/memcontrol.h |  3 +-
> > >  mm/memcontrol.c| 14 +++--
> > >  mm/slab.c  | 18 +++-
> > >  mm/slab.h  | 60 ++
> > >  mm/slub.c  | 14 +
> > >  5 files changed, 88 insertions(+), 21 deletions(-)


> > >
> >
> > I am not sure if this is the related patch or not that is causing
> > mips architecture build failure on linux -next.
>
> Hello, Naresh!
>
> Thank you for the report, interesting...
> There is nothing arch-specific in the code, so there must be something
> compiler-dependent. My wild guess is that the problem is caused by a memory
> allocation from the memcg_slab_post_alloc_hook(), but it's added by a later
> patch in the series. So if it really fails at this patch, there must be 
> something
> different. I'll try to reproduce it, but I have to install the MIPS toolchain 
> first,
> so it might take some time. If it creates some troubles, can you, please, 
> check
> if s/__always_inline/inline helps?

sed -i -e 's#__always_inline#inline#g' mm/slub.c ->> then builds fine.

-  Naresh

Re: [PATCH v4 1/2] remoteproc: Add remoteproc character device interface

[Bjorn Andersson]

On Tue 07 Jul 12:07 PDT 2020, Siddharth Gupta wrote:

> Add the character device interface into remoteproc framework.
> This interface can be used in order to boot/shutdown remote
> subsystems and provides a basic ioctl based interface to implement
> supplementary functionality. An ioctl call is implemented to enable
> the shutdown on release feature which will allow remote processors to
> be shutdown when the controlling userpsace application crashes or hangs.
> 
> Signed-off-by: Rishabh Bhatnagar 
> Signed-off-by: Siddharth Gupta 
> ---
>  Documentation/userspace-api/ioctl/ioctl-number.rst |   1 +
>  drivers/remoteproc/Kconfig |   9 ++
>  drivers/remoteproc/Makefile|   1 +
>  drivers/remoteproc/remoteproc_cdev.c   | 146 
> +
>  drivers/remoteproc/remoteproc_internal.h   |  28 
>  include/linux/remoteproc.h |   5 +
>  include/uapi/linux/remoteproc_cdev.h   |  37 ++
>  7 files changed, 227 insertions(+)
>  create mode 100644 drivers/remoteproc/remoteproc_cdev.c
>  create mode 100644 include/uapi/linux/remoteproc_cdev.h
> 
> diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst 
> b/Documentation/userspace-api/ioctl/ioctl-number.rst
> index 59472cd..2a19883 100644
> --- a/Documentation/userspace-api/ioctl/ioctl-number.rst
> +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
> @@ -339,6 +339,7 @@ Code  Seq#Include File
>Comments
>  0xB4  00-0F  linux/gpio.h
> 
>  0xB5  00-0F  uapi/linux/rpmsg.h  
> 
>  0xB6  alllinux/fpga-dfl.h
> +0xB7  alluapi/linux/remoteproc_cdev.h
> 
>  0xC0  00-0F  linux/usb/iowarrior.h
>  0xCA  00-0F  uapi/misc/cxl.h
>  0xCA  10-2F  uapi/misc/ocxl.h
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index c4d1731..652060f 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -14,6 +14,15 @@ config REMOTEPROC
>  
>  if REMOTEPROC
>  
> +config REMOTEPROC_CDEV
> + bool "Remoteproc character device interface"
> + help
> +   Say y here to have a character device interface for the remoteproc
> +   framework. Userspace can boot/shutdown remote processors through
> +   this interface.
> +
> +   It's safe to say N if you don't want to use this interface.
> +
>  config IMX_REMOTEPROC
>   tristate "IMX6/7 remoteproc support"
>   depends on ARCH_MXC
> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> index e8b886e..311ae3f 100644
> --- a/drivers/remoteproc/Makefile
> +++ b/drivers/remoteproc/Makefile
> @@ -9,6 +9,7 @@ remoteproc-y  += remoteproc_debugfs.o
>  remoteproc-y += remoteproc_sysfs.o
>  remoteproc-y += remoteproc_virtio.o
>  remoteproc-y += remoteproc_elf_loader.o
> +obj-$(CONFIG_REMOTEPROC_CDEV)+= remoteproc_cdev.o
>  obj-$(CONFIG_IMX_REMOTEPROC) += imx_rproc.o
>  obj-$(CONFIG_INGENIC_VPU_RPROC)  += ingenic_rproc.o
>  obj-$(CONFIG_MTK_SCP)+= mtk_scp.o mtk_scp_ipi.o
> diff --git a/drivers/remoteproc/remoteproc_cdev.c 
> b/drivers/remoteproc/remoteproc_cdev.c
> new file mode 100644
> index 000..8a0eb47
> --- /dev/null
> +++ b/drivers/remoteproc/remoteproc_cdev.c
> @@ -0,0 +1,146 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Character device interface driver for Remoteproc framework.
> + *
> + * Copyright (c) 2020, The Linux Foundation. All rights reserved.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "remoteproc_internal.h"
> +
> +#define NUM_RPROC_DEVICES64
> +static dev_t rproc_major;
> +
> +static ssize_t rproc_cdev_write(struct file *filp, const char __user *buf, 
> size_t len, loff_t *pos)
> +{
> + struct rproc *rproc = container_of(filp->f_inode->i_cdev, struct rproc, 
> char_dev);
> + int ret = 0;
> + char cmd[10];
> +
> + if (!len || len > sizeof(cmd))
> + return -EINVAL;
> +
> + ret = copy_from_user(cmd, buf, sizeof(cmd));

I believe you should copy "len" bytes here, instead of 10.

> + if (ret)
> + return -EFAULT;
> +
> + if (sysfs_streq(cmd, "start")) {
> + if (rproc->state == RPROC_RUNNING)
> + return -EBUSY;
> +
> + ret = rproc_boot(rproc);
> + if (ret)
> + dev_err(>dev, "Boot failed:%d\n", ret);

rproc_boot() of a child thereof has already told us why the boot failed,
so please omit this print.

> + } else if (sysfs_streq(cmd, "stop")) {
> + if 

Re: [PATCH v4 3/7] vmalloc: Add text_alloc() and text_free()

[kernel test robot]

Hi Jarkko,

I love your patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v5.8-rc5 next-20200716]
[cannot apply to tip/x86/core tip/perf/core]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Jarkko-Sakkinen/arch-x86-kprobes-Remove-MODULES-dependency/20200717-110947
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
07a56bb875afbe39dabbf6ba7b83783d166863db
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 9.3.0
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
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=ia64 

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

All errors (new ones prefixed by >>):

   WARNING: unmet direct dependencies detected for FRAME_POINTER
   Depends on DEBUG_KERNEL && (M68K || UML || SUPERH) || 
ARCH_WANT_FRAME_POINTERS
   Selected by
   - FAULT_INJECTION_STACKTRACE_FILTER && FAULT_INJECTION_DEBUG_FS && 
STACKTRACE_SUPPORT && !X86_64 && !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM 
&& !ARC && !X86
   scripts/Makefile.build:65: 'arch/ia64/kernel/palinfo.ko' 
'arch/ia64/kernel/mca_recovery.ko' 'arch/ia64/kernel/err_inject.ko' will not be 
built even though obj-m is specified.
   scripts/Makefile.build:66: You cannot use subdir-y/m to visit a module 
Makefile. Use obj-y/m instead.
   In file included from include/asm-generic/percpu.h:7,
   from arch/ia64/include/asm/percpu.h:46,
   from arch/ia64/include/asm/processor.h:76,
   from arch/ia64/include/asm/thread_info.h:12,
   from include/linux/thread_info.h:38,
   from include/asm-generic/preempt.h:5,
   from ./arch/ia64/include/generated/asm/preempt.h:1,
   from include/linux/preempt.h:78,
   from include/linux/rcupdate.h:27,
   from include/linux/rculist.h:11,
   from include/linux/sched/signal.h:5,
   from arch/ia64/kernel/asm-offsets.c:10:
   include/linux/topology.h: In function 'cpu_smt_mask':
>> arch/ia64/include/asm/topology.h:45:50: error: 'cpu_sibling_map' undeclared 
>> (first use in this function)
   45 | #define topology_sibling_cpumask(cpu) (_cpu(cpu_sibling_map, cpu))
   | ^~~
   include/linux/percpu-defs.h:219:47: note: in definition of macro 
'__verify_pcpu_ptr'
   219 | const void __percpu = (typeof((ptr) + 0))NULL; | ^~~
   include/linux/percpu-defs.h:269:29: note: in expansion of macro 'per_cpu_ptr'
   269 | #define per_cpu(var, cpu) cpu))
   | ^~~
   arch/ia64/include/asm/topology.h:45:42: note: in expansion of macro 'per_cpu'
   45 | #define topology_sibling_cpumask(cpu) (_cpu(cpu_sibling_map, cpu))
   | ^~~
   include/linux/topology.h:204:9: note: in expansion of macro 
'topology_sibling_cpumask'
   204 | return topology_sibling_cpumask(cpu);
   | ^~~~
   arch/ia64/include/asm/topology.h:45:50: note: each undeclared identifier is 
reported only once for each function it appears in
   45 | #define topology_sibling_cpumask(cpu) (_cpu(cpu_sibling_map, cpu))
   | ^~~
   include/linux/percpu-defs.h:219:47: note: in definition of macro 
'__verify_pcpu_ptr'
   219 | const void __percpu = (typeof((ptr) + 0))NULL; | ^~~
   include/linux/percpu-defs.h:269:29: note: in expansion of macro 'per_cpu_ptr'
   269 | #define per_cpu(var, cpu) cpu))
   | ^~~
   arch/ia64/include/asm/topology.h:45:42: note: in expansion of macro 'per_cpu'
   45 | #define topology_sibling_cpumask(cpu) (_cpu(cpu_sibling_map, cpu))
   | ^~~
   include/linux/topology.h:204:9: note: in expansion of macro 
'topology_sibling_cpumask'
   204 | return topology_sibling_cpumask(cpu);
   | ^~~~
   arch/ia64/kernel/asm-offsets.c: At top level:
   arch/ia64/kernel/asm-offsets.c:23:6: warning: no previous prototype for 'foo'
   23 | void foo(void)
   | ^~~
   Makefile arch block certs crypto drivers fs include init ipc kernel lib mm 
net scripts security sound source usr virt [scripts/Makefile.build:114: 
arch/ia64/kernel/asm-offsets.s] Error 1
   Target '__build' not remade because of errors.
   Makefile arch block certs crypto drivers fs include init ipc kernel lib mm 
net scripts security sound source usr virt [Makefile:1175: prepare0] Error 2
   Target 'prepare' not remade because of errors.
   make: Makefile arch block certs crypto drivers fs include init ipc kernel 
lib mm net scripts security sound source usr virt [Makefile:185: __sub-make] 
Error 2
   make: Target 'prepare' not remade because of errors.

vim +/cpu_siblin

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

[Christoph Hellwig]

On Fri, Jul 17, 2020 at 01:01:12PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the sound tree, today's linux-next build (x86_64
> allmodconfig) failed like this:

No, the sound commit needs to be reverted.  Drivers has absolutely not
business poking into DMA layer internals.

Re: [PATCH v4 3/7] vmalloc: Add text_alloc() and text_free()

[kernel test robot]

Hi Jarkko,

I love your patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on jeyu/modules-next v5.8-rc5 next-20200716]
[cannot apply to tip/x86/core tip/perf/core]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Jarkko-Sakkinen/arch-x86-kprobes-Remove-MODULES-dependency/20200717-110947
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
07a56bb875afbe39dabbf6ba7b83783d166863db
config: sparc-randconfig-s031-20200717 (attached as .config)
compiler: sparc64-linux-gcc (GCC) 9.3.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.2-49-g707c5017-dirty
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=sparc 

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

All errors (new ones prefixed by >>):

   In file included from arch/sparc/include/asm/page.h:10,
from arch/sparc/include/asm/string_32.h:13,
from arch/sparc/include/asm/string.h:7,
from include/linux/string.h:20,
from include/linux/bitmap.h:9,
from include/linux/cpumask.h:12,
from arch/sparc/include/asm/smp_32.h:15,
from arch/sparc/include/asm/smp.h:7,
from arch/sparc/include/asm/switch_to_32.h:5,
from arch/sparc/include/asm/switch_to.h:7,
from arch/sparc/include/asm/ptrace.h:120,
from arch/sparc/include/asm/thread_info_32.h:19,
from arch/sparc/include/asm/thread_info.h:7,
from include/linux/thread_info.h:38,
from include/asm-generic/preempt.h:5,
from ./arch/sparc/include/generated/asm/preempt.h:1,
from include/linux/preempt.h:78,
from include/linux/spinlock.h:51,
from include/linux/seqlock.h:36,
from include/linux/time.h:6,
from arch/sparc/vdso/vdso32/../vclock_gettime.c:16,
from arch/sparc/vdso/vdso32/vclock_gettime.c:22:
>> include/linux/mmzone.h:1317:29: error: expected identifier or '(' before 
>> 'unsigned'
1317 | static inline int pfn_valid(unsigned long pfn)
 | ^~~~
   arch/sparc/include/asm/page_32.h:133:28: note: in definition of macro 
'pfn_valid'
 133 | #define pfn_valid(pfn)  (((pfn) >= (pfn_base)) && 
(((pfn)-(pfn_base)) < max_mapnr))
 |^~~
>> arch/sparc/include/asm/page_32.h:133:33: error: expected ')' before '>=' 
>> token
 133 | #define pfn_valid(pfn)  (((pfn) >= (pfn_base)) && 
(((pfn)-(pfn_base)) < max_mapnr))
 | ^~
   include/linux/mmzone.h:1317:19: note: in expansion of macro 'pfn_valid'
1317 | static inline int pfn_valid(unsigned long pfn)
 |   ^
   arch/sparc/include/asm/page_32.h:133:48: error: expected ')' before '&&' 
token
 133 | #define pfn_valid(pfn)  (((pfn) >= (pfn_base)) && 
(((pfn)-(pfn_base)) < max_mapnr))
 |^~
   include/linux/mmzone.h:1317:19: note: in expansion of macro 'pfn_valid'
1317 | static inline int pfn_valid(unsigned long pfn)
 |   ^
   In file included from include/linux/page-flags-layout.h:28,
from include/linux/mmzone.h:19,
from include/linux/gfp.h:6,
from include/linux/umh.h:4,
from include/linux/kmod.h:9,
from include/linux/module.h:16,
from include/linux/moduleloader.h:6,
from include/linux/vmalloc.h:12,
from include/asm-generic/io.h:911,
from arch/sparc/include/asm/io_32.h:14,
from arch/sparc/include/asm/io.h:7,
from arch/sparc/vdso/vdso32/../vclock_gettime.c:18,
from arch/sparc/vdso/vdso32/vclock_gettime.c:22:
   include/linux/mmzone.h: In function 'pfn_in_present_section':
>> arch/sparc/include/asm/sparsemem.h:11:33: error: 'MAX_PHYS_ADDRESS_BITS' 
>> undeclared (first use in this function); did you mean 'MAX_PHYSADDR_BITS'?
  11 | #define MAX_PHYSMEM_BITSMAX_PHYS_ADDRESS_BITS
 |

Re: [PATCH 3/3] remoteproc: qcom_q6v5_mss: Update MBA log info

[Sibi Sankar]

On 2020-07-17 10:29, Bjorn Andersson wrote:

On Thu 16 Jul 05:36 PDT 2020, Sibi Sankar wrote:


Update MBA text logs location/size in IMEM to aid tools extract
them after ramdump collection.

Signed-off-by: Sibi Sankar 
---
 drivers/remoteproc/qcom_q6v5_mss.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/remoteproc/qcom_q6v5_mss.c 
b/drivers/remoteproc/qcom_q6v5_mss.c

index 4ddf084b2c6fc..539594ab955f1 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -932,6 +932,9 @@ static int q6v5_mba_load(struct q6v5 *qproc)
if (ret)
goto reclaim_mba;

+   if (qproc->has_mba_logs)
+   qcom_pil_info_store("mba", qproc->mba_phys, MBA_LOG_SIZE);


Is there a reason why we don't unconditionally write this to the PIL
info? And why it shouldn't be mba_size?


MBA text logs of size specified are the
only things extracted from MBA region by
the postmortem tools (the tool assumes
that the entire region is text). The MBA
log feature was only added to SC7180 MSS
firmware.



Regards,
Bjorn


+
ret = q6v5_rmb_mba_wait(qproc, 0, 5000);
if (ret == -ETIMEDOUT) {
dev_err(qproc->dev, "MBA boot timed out\n");
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum,

a Linux Foundation Collaborative Project



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

Re: [PATCH v3 2/4] clocksource/drivers: Add CLINT timer driver

[Daniel Lezcano]

On 17/07/2020 07:21, Anup Patel wrote:
> On Fri, Jul 17, 2020 at 2:57 AM Daniel Lezcano
>  wrote:
>>
>>
>> Hi Anup,
>>
>>
>> On 15/07/2020 09:15, Anup Patel wrote:
>>> The TIME CSR and SBI calls are not available in RISC-V M-mode so we
>>> separate add CLINT driver for Linux RISC-V M-mode (i.e. RISC-V NoMMU
>>> kernel).
>>
>> The description is confusing, please reword it and give a bit more
>> information about the timer itself, especially, the IPI thing.
> 
> Okay, will update.
> 
>>
>>> Signed-off-by: Anup Patel 
>>> ---
>>>  drivers/clocksource/Kconfig   |  10 ++
>>>  drivers/clocksource/Makefile  |   1 +
>>>  drivers/clocksource/timer-clint.c | 229 ++
>>>  include/linux/cpuhotplug.h|   1 +
>>>  4 files changed, 241 insertions(+)
>>>  create mode 100644 drivers/clocksource/timer-clint.c
>>>
>>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>>> index 91418381fcd4..eabcf1cfb0c0 100644
>>> --- a/drivers/clocksource/Kconfig
>>> +++ b/drivers/clocksource/Kconfig
>>> @@ -658,6 +658,16 @@ config RISCV_TIMER
>>> is accessed via both the SBI and the rdcycle instruction.  This is
>>> required for all RISC-V systems.
>>>
>>> +config CLINT_TIMER
>>> + bool "Timer for the RISC-V platform"
>>> + depends on GENERIC_SCHED_CLOCK && RISCV_M_MODE
>>> + default y
>>> + select TIMER_PROBE
>>> + select TIMER_OF
>>> + help
>>> +   This option enables the CLINT timer for RISC-V systems. The CLINT
>>> +   driver is usually used for NoMMU RISC-V systems.
>>
>> For the timer, we do silent option and let the platform config select
>> it. Please refer to other timer option below as reference.
> 
> Okay, I will use "default RISCV" instead of "default y" (just like other
> timer Kconfig options).

Preferably, select it from the platform's Kconfig.

>>
>>>  config CSKY_MP_TIMER
>>>   bool "SMP Timer for the C-SKY platform" if COMPILE_TEST
>>>   depends on CSKY
>>> diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
>>> index bdda1a2e4097..18e700e703a0 100644
>>> --- a/drivers/clocksource/Makefile
>>> +++ b/drivers/clocksource/Makefile
>>> @@ -87,6 +87,7 @@ obj-$(CONFIG_CLKSRC_ST_LPC) += clksrc_st_lpc.o
>>>  obj-$(CONFIG_X86_NUMACHIP)   += numachip.o
>>>  obj-$(CONFIG_ATCPIT100_TIMER)+= timer-atcpit100.o
>>>  obj-$(CONFIG_RISCV_TIMER)+= timer-riscv.o
>>> +obj-$(CONFIG_CLINT_TIMER)+= timer-clint.o
>>>  obj-$(CONFIG_CSKY_MP_TIMER)  += timer-mp-csky.o
>>>  obj-$(CONFIG_GX6605S_TIMER)  += timer-gx6605s.o
>>>  obj-$(CONFIG_HYPERV_TIMER)   += hyperv_timer.o
>>> diff --git a/drivers/clocksource/timer-clint.c 
>>> b/drivers/clocksource/timer-clint.c
>>> new file mode 100644
>>> index ..bfc38bb5a589
>>> --- /dev/null
>>> +++ b/drivers/clocksource/timer-clint.c
>>> @@ -0,0 +1,229 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/*
>>> + * Copyright (C) 2020 Western Digital Corporation or its affiliates.
>>> + *
>>> + * Most of the M-mode (i.e. NoMMU) RISC-V systems usually have a
>>> + * CLINT MMIO timer device.
>>> + */
>>> +
>>> +#define pr_fmt(fmt) "clint: " fmt
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#define CLINT_IPI_OFF0
>>> +#define CLINT_TIMER_CMP_OFF  0x4000
>>> +#define CLINT_TIMER_VAL_OFF  0xbff8
>>> +
>>> +/* CLINT manages IPI and Timer for RISC-V M-mode  */
>>> +static u32 __iomem *clint_ipi_base;
>>> +static u64 __iomem *clint_timer_cmp;
>>> +static u64 __iomem *clint_timer_val;
>>> +static unsigned long clint_timer_freq;
>>> +static unsigned int clint_timer_irq;
>>> +
>>> +static void clint_send_ipi(const struct cpumask *target)
>>> +{
>>> + unsigned int cpu;
>>> +
>>> + for_each_cpu(cpu, target)
>>> + writel(1, clint_ipi_base + cpuid_to_hartid_map(cpu));
>>> +}
>>> +
>>> +static void clint_clear_ipi(void)
>>> +{
>>> + writel(0, clint_ipi_base + cpuid_to_hartid_map(smp_processor_id()));
>>> +}
>>> +
>>> +static struct riscv_ipi_ops clint_ipi_ops = {
>>> + .ipi_inject = clint_send_ipi,
>>> + .ipi_clear = clint_clear_ipi,
>>> +};
>>> +
>>> +#ifdef CONFIG_64BIT
>>> +#define clint_get_cycles()   readq_relaxed(clint_timer_val)
>>> +#else
>>> +#define clint_get_cycles()   readl_relaxed(clint_timer_val)
>>> +#define clint_get_cycles_hi()readl_relaxed(((u32 
>>> *)clint_timer_val) + 1)
>>> +#endif
>>> +
>>> +#ifdef CONFIG_64BIT
>>> +static u64 clint_get_cycles64(void)
>>> +{
>>> + return clint_get_cycles();
>>> +}
>>> +#else /* CONFIG_64BIT */
>>> +static u64 clint_get_cycles64(void)
>>> +{
>>> + u32 hi, lo;
>>> +
>>> + do {
>>> + hi = clint_get_cycles_hi();
>>> + lo = clint_get_cycles();
>>> + } while (hi != clint_get_cycles_hi());
>>> +
>>> + return 

Re: [PATCH v16 00/22] per memcg lru_lock

[Alex Shi]

在 2020/7/16 下午10:11, Alexander Duyck 写道:
>> Thanks for Testing support from Intel 0day and Rong Chen, Fengguang Wu,
>> and Yun Wang. Hugh Dickins also shared his kbuild-swap case. Thanks!
> Hi Alex,
> 
> I think I am seeing a regression with this patch set when I run the
> will-it-scale/page_fault3 test. Specifically the processes result is
> dropping from 56371083 to 43127382 when I apply these patches.
> 
> I haven't had a chance to bisect and figure out what is causing it,
> and wanted to let you know in case you are aware of anything specific
> that may be causing this.


Thanks a lot for the info!

Actually, the patch 17th, and patch 13th may changed performance a little,
like the 17th, intel LKP found vm-scalability.throughput 68.0% improvement,
and stress-ng.remap.ops_per_sec -76.3% regression, or 
stress-ng.memfd.ops_per_sec
 +23.2%. etc.

This kind performance interference is known and acceptable.
Thanks
Alex
 

linux-next: manual merge of the kvm tree with the tip tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  arch/x86/kernel/kvm.c

between commit:

  b037b09b9058 ("x86/entry: Rename idtentry_enter/exit_cond_rcu() to 
idtentry_enter/exit()")

from the tip tree and commit:

  b1d405751cd5 ("KVM: x86: Switch KVM guest to using interrupts for page ready 
APF delivery")

from the kvm tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/kernel/kvm.c
index 3f78482d9496,d9995931ea18..
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@@ -232,18 -235,13 +235,13 @@@ EXPORT_SYMBOL_GPL(kvm_read_and_reset_ap
  
  noinstr bool __kvm_handle_async_pf(struct pt_regs *regs, u32 token)
  {
-   u32 reason = kvm_read_and_reset_apf_flags();
+   u32 flags = kvm_read_and_reset_apf_flags();
 -  bool rcu_exit;
 +  idtentry_state_t state;
  
-   switch (reason) {
-   case KVM_PV_REASON_PAGE_NOT_PRESENT:
-   case KVM_PV_REASON_PAGE_READY:
-   break;
-   default:
+   if (!flags)
return false;
-   }
  
 -  rcu_exit = idtentry_enter_cond_rcu(regs);
 +  state = idtentry_enter(regs);
instrumentation_begin();
  
/*


pgpY7vcPsr6AH.pgp
Description: OpenPGP digital signature

RE: [PATCH v6 0/5] scsi: ufs: Add Host Performance Booster Support

[Avri Altman]

> > v5 -> v6
> > Change base commit to b53293fa662e28ae0cdd40828dc641c09f133405
> >
> If no further comments, can this series have your Reviewed-by or Acked-by
> tag, so that this can be taken for 5.9?
> Thanks!
Hey, yes.  So sorry for this delay, I was away for few days.
Yes - This series looks good to me.

Thanks,
Avri

> 
> > v4 -> v5
> > Delete unused macro define.
> 

Re: [PATCH 2/3] remoteproc: qcom_q6v5_mss: Add MBA log extraction support

[Sibi Sankar]

On 2020-07-17 10:27, Bjorn Andersson wrote:

On Thu 16 Jul 05:36 PDT 2020, Sibi Sankar wrote:


On SC7180 the MBA firmware stores the bootup text logs in a 4K segment
at the beginning of the MBA region. Add support to extract the logs
which will be useful to debug mba boot/authentication issues.

Signed-off-by: Sibi Sankar 
---
 drivers/remoteproc/qcom_q6v5_mss.c | 41 
++

 1 file changed, 36 insertions(+), 5 deletions(-)

diff --git a/drivers/remoteproc/qcom_q6v5_mss.c 
b/drivers/remoteproc/qcom_q6v5_mss.c

index 95e21ed607cb9..4ddf084b2c6fc 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -9,6 +9,7 @@

 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -37,6 +38,8 @@

 #define MPSS_CRASH_REASON_SMEM 421

+#define MBA_LOG_SIZE   SZ_4K
+
 /* RMB Status Register Values */
 #define RMB_PBL_SUCCESS0x1

@@ -139,6 +142,7 @@ struct rproc_hexagon_res {
int version;
bool need_mem_protection;
bool has_alt_reset;
+   bool has_mba_logs;
bool has_spare_reg;
 };

@@ -200,6 +204,7 @@ struct q6v5 {
struct qcom_sysmon *sysmon;
bool need_mem_protection;
bool has_alt_reset;
+   bool has_mba_logs;
bool has_spare_reg;
int mpss_perm;
int mba_perm;
@@ -518,6 +523,19 @@ static int q6v5_rmb_mba_wait(struct q6v5 *qproc, 
u32 status, int ms)

return val;
 }

+static void q6v5_dump_mba_logs(struct q6v5 *qproc)
+{
+   struct rproc *rproc = qproc->rproc;
+   void *data;
+
+   data = vmalloc(MBA_LOG_SIZE);
+   if (!data)
+   return;
+
+   memcpy(data, qproc->mba_region, MBA_LOG_SIZE);
+   dev_coredumpv(>dev, data, MBA_LOG_SIZE, GFP_KERNEL);
+}
+
 static int q6v5proc_reset(struct q6v5 *qproc)
 {
u32 val;
@@ -838,6 +856,7 @@ static int q6v5_mba_load(struct q6v5 *qproc)
 {
int ret;
int xfermemop_ret;
+   bool mba_load_err = false;

qcom_q6v5_prepare(>q6v5);

@@ -931,7 +950,7 @@ static int q6v5_mba_load(struct q6v5 *qproc)
q6v5proc_halt_axi_port(qproc, qproc->halt_map, qproc->halt_q6);
q6v5proc_halt_axi_port(qproc, qproc->halt_map, qproc->halt_modem);
q6v5proc_halt_axi_port(qproc, qproc->halt_map, qproc->halt_nc);
-
+   mba_load_err = true;
 reclaim_mba:
 	xfermemop_ret = q6v5_xfer_mem_ownership(qproc, >mba_perm, 
true,

false, qproc->mba_phys,
@@ -939,6 +958,8 @@ static int q6v5_mba_load(struct q6v5 *qproc)
if (xfermemop_ret) {
dev_err(qproc->dev,
"Failed to reclaim mba buffer, system may become 
unstable\n");
+   } else if (qproc->has_mba_logs & mba_load_err) {
+   q6v5_dump_mba_logs(qproc);
}

 disable_active_clks:
@@ -968,7 +989,7 @@ static int q6v5_mba_load(struct q6v5 *qproc)
return ret;
 }

-static void q6v5_mba_reclaim(struct q6v5 *qproc)
+static void q6v5_mba_reclaim(struct q6v5 *qproc, bool err_path)
 {
int ret;
u32 val;
@@ -1006,6 +1027,9 @@ static void q6v5_mba_reclaim(struct q6v5 *qproc)
  qproc->mba_size);
WARN_ON(ret);

+   if (qproc->has_mba_logs && err_path && !ret)


Wouldn't it be possible to just call q6v5_dump_mba_logs() directly 
after

the return from q6v5_mba_reclaim()? That way we can avoid passing the
bool to indicate if the reclaim should also dump some stuff.

Sure we don't have a way to tell if the assign_mem failed, but we're
going to crash shortly anyways (which is something we should change).


We wont crash as long as we dont touch
the mba region though. Trying a mba
logs dump in such a case will ensure
that we crash lol.





I think you should move the has_mba_logs into q6v5_dump_mba_logs(),
making it cause an early return.


cool sure I'll do that.



Regards,
Bjorn


+   q6v5_dump_mba_logs(qproc);
+
ret = qcom_q6v5_unprepare(>q6v5);
if (ret) {
q6v5_pds_disable(qproc, qproc->proxy_pds,
@@ -1255,7 +1279,7 @@ static void qcom_q6v5_dump_segment(struct rproc 
*rproc,

false, true,
qproc->mpss_phys,
qproc->mpss_size);
-   q6v5_mba_reclaim(qproc);
+   q6v5_mba_reclaim(qproc, false);
}
}
 }
@@ -1297,7 +1321,7 @@ static int q6v5_start(struct rproc *rproc)
return 0;

 reclaim_mpss:
-   q6v5_mba_reclaim(qproc);
+   q6v5_mba_reclaim(qproc, true);

return ret;
 }
@@ -1313,7 +1337,7 @@ static int q6v5_stop(struct rproc *rproc)
if (ret == -ETIMEDOUT)
dev_err(qproc->dev, "timed out on wait\n");

-   q6v5_mba_reclaim(qproc);
+   q6v5_mba_reclaim(qproc, false);

return 0;
 }
@@ -1717,6 +1741,7 

Re: [PATCH] crypto: xts: use memmove to avoid overlapped memory copy

[Herbert Xu]

On Thu, Jul 16, 2020 at 06:56:30PM +0300, Ard Biesheuvel wrote:
> On Thu, 16 Jul 2020 at 18:29, Colin King  wrote:
> >
> > From: Colin Ian King 
> >
> > There is a memcpy that performs a potential overlapped memory copy
> > from source b to destination b + 1.  Fix this by using the safer
> > memmove instead.
> >
> > Addresses-Coverity: ("Overlapping buffer in memory copy")
> > Fixes: 8083b1bf8163 ("crypto: xts - add support for ciphertext stealing")
> > Signed-off-by: Colin Ian King 
> > ---
> >  crypto/xts.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/crypto/xts.c b/crypto/xts.c
> > index 3565f3b863a6..fa3e6e7b7043 100644
> > --- a/crypto/xts.c
> > +++ b/crypto/xts.c
> > @@ -169,7 +169,7 @@ static int cts_final(struct skcipher_request *req,
> >   offset - XTS_BLOCK_SIZE);
> >
> > scatterwalk_map_and_copy(b, rctx->tail, 0, XTS_BLOCK_SIZE, 0);
> > -   memcpy(b + 1, b, tail);
> > +   memmove(b + 1, b, tail);
> 
> This is a false positive: tail is guaranteed to be smaller than
> sizeof(*b), so memmove() is unnecessary here.
> 
> If changing to memcpy([1], [0], tail) makes the warning go away, i
> am fine with it, but otherwise we should just leave it as is.

How about a comment perhaps?

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

Re: [PATCH v3 2/4] clocksource/drivers: Add CLINT timer driver

[Anup Patel]

On Fri, Jul 17, 2020 at 2:57 AM Daniel Lezcano
 wrote:
>
>
> Hi Anup,
>
>
> On 15/07/2020 09:15, Anup Patel wrote:
> > The TIME CSR and SBI calls are not available in RISC-V M-mode so we
> > separate add CLINT driver for Linux RISC-V M-mode (i.e. RISC-V NoMMU
> > kernel).
>
> The description is confusing, please reword it and give a bit more
> information about the timer itself, especially, the IPI thing.

Okay, will update.

>
> > Signed-off-by: Anup Patel 
> > ---
> >  drivers/clocksource/Kconfig   |  10 ++
> >  drivers/clocksource/Makefile  |   1 +
> >  drivers/clocksource/timer-clint.c | 229 ++
> >  include/linux/cpuhotplug.h|   1 +
> >  4 files changed, 241 insertions(+)
> >  create mode 100644 drivers/clocksource/timer-clint.c
> >
> > diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> > index 91418381fcd4..eabcf1cfb0c0 100644
> > --- a/drivers/clocksource/Kconfig
> > +++ b/drivers/clocksource/Kconfig
> > @@ -658,6 +658,16 @@ config RISCV_TIMER
> > is accessed via both the SBI and the rdcycle instruction.  This is
> > required for all RISC-V systems.
> >
> > +config CLINT_TIMER
> > + bool "Timer for the RISC-V platform"
> > + depends on GENERIC_SCHED_CLOCK && RISCV_M_MODE
> > + default y
> > + select TIMER_PROBE
> > + select TIMER_OF
> > + help
> > +   This option enables the CLINT timer for RISC-V systems. The CLINT
> > +   driver is usually used for NoMMU RISC-V systems.
>
> For the timer, we do silent option and let the platform config select
> it. Please refer to other timer option below as reference.

Okay, I will use "default RISCV" instead of "default y" (just like other
timer Kconfig options).

>
> >  config CSKY_MP_TIMER
> >   bool "SMP Timer for the C-SKY platform" if COMPILE_TEST
> >   depends on CSKY
> > diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
> > index bdda1a2e4097..18e700e703a0 100644
> > --- a/drivers/clocksource/Makefile
> > +++ b/drivers/clocksource/Makefile
> > @@ -87,6 +87,7 @@ obj-$(CONFIG_CLKSRC_ST_LPC) += clksrc_st_lpc.o
> >  obj-$(CONFIG_X86_NUMACHIP)   += numachip.o
> >  obj-$(CONFIG_ATCPIT100_TIMER)+= timer-atcpit100.o
> >  obj-$(CONFIG_RISCV_TIMER)+= timer-riscv.o
> > +obj-$(CONFIG_CLINT_TIMER)+= timer-clint.o
> >  obj-$(CONFIG_CSKY_MP_TIMER)  += timer-mp-csky.o
> >  obj-$(CONFIG_GX6605S_TIMER)  += timer-gx6605s.o
> >  obj-$(CONFIG_HYPERV_TIMER)   += hyperv_timer.o
> > diff --git a/drivers/clocksource/timer-clint.c 
> > b/drivers/clocksource/timer-clint.c
> > new file mode 100644
> > index ..bfc38bb5a589
> > --- /dev/null
> > +++ b/drivers/clocksource/timer-clint.c
> > @@ -0,0 +1,229 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2020 Western Digital Corporation or its affiliates.
> > + *
> > + * Most of the M-mode (i.e. NoMMU) RISC-V systems usually have a
> > + * CLINT MMIO timer device.
> > + */
> > +
> > +#define pr_fmt(fmt) "clint: " fmt
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define CLINT_IPI_OFF0
> > +#define CLINT_TIMER_CMP_OFF  0x4000
> > +#define CLINT_TIMER_VAL_OFF  0xbff8
> > +
> > +/* CLINT manages IPI and Timer for RISC-V M-mode  */
> > +static u32 __iomem *clint_ipi_base;
> > +static u64 __iomem *clint_timer_cmp;
> > +static u64 __iomem *clint_timer_val;
> > +static unsigned long clint_timer_freq;
> > +static unsigned int clint_timer_irq;
> > +
> > +static void clint_send_ipi(const struct cpumask *target)
> > +{
> > + unsigned int cpu;
> > +
> > + for_each_cpu(cpu, target)
> > + writel(1, clint_ipi_base + cpuid_to_hartid_map(cpu));
> > +}
> > +
> > +static void clint_clear_ipi(void)
> > +{
> > + writel(0, clint_ipi_base + cpuid_to_hartid_map(smp_processor_id()));
> > +}
> > +
> > +static struct riscv_ipi_ops clint_ipi_ops = {
> > + .ipi_inject = clint_send_ipi,
> > + .ipi_clear = clint_clear_ipi,
> > +};
> > +
> > +#ifdef CONFIG_64BIT
> > +#define clint_get_cycles()   readq_relaxed(clint_timer_val)
> > +#else
> > +#define clint_get_cycles()   readl_relaxed(clint_timer_val)
> > +#define clint_get_cycles_hi()readl_relaxed(((u32 
> > *)clint_timer_val) + 1)
> > +#endif
> > +
> > +#ifdef CONFIG_64BIT
> > +static u64 clint_get_cycles64(void)
> > +{
> > + return clint_get_cycles();
> > +}
> > +#else /* CONFIG_64BIT */
> > +static u64 clint_get_cycles64(void)
> > +{
> > + u32 hi, lo;
> > +
> > + do {
> > + hi = clint_get_cycles_hi();
> > + lo = clint_get_cycles();
> > + } while (hi != clint_get_cycles_hi());
> > +
> > + return ((u64)hi << 32) | lo;
> > +}
> > +#endif /* CONFIG_64BIT */
> > +static int clint_clock_next_event(unsigned long delta,
> > +  

Re: [PATCH v8 4/5] remoteproc: Add inline coredump functionality

[Bjorn Andersson]

On Thu 16 Jul 15:20 PDT 2020, Rishabh Bhatnagar wrote:

> The current coredump implementation uses vmalloc area to copy
> all the segments. But this might put strain on low memory targets
> as the firmware size sometimes is in tens of MBs. The situation
> becomes worse if there are multiple remote processors undergoing
> recovery at the same time. This patch adds inline coredump
> functionality that avoids extra memory usage. This requires
> recovery to be halted until data is read by userspace and free
> function is called.
> 
> Signed-off-by: Rishabh Bhatnagar 
> Tested-by: Sibi Sankar 

Reviewed-by: Bjorn Andersson 

> ---
>  drivers/remoteproc/remoteproc_coredump.c | 156 
> +++
>  include/linux/remoteproc.h   |  16 
>  2 files changed, 154 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/remoteproc/remoteproc_coredump.c 
> b/drivers/remoteproc/remoteproc_coredump.c
> index 390f563..bb15a29 100644
> --- a/drivers/remoteproc/remoteproc_coredump.c
> +++ b/drivers/remoteproc/remoteproc_coredump.c
> @@ -5,6 +5,7 @@
>   * Copyright (c) 2020, The Linux Foundation. All rights reserved.
>   */
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -12,6 +13,12 @@
>  #include "remoteproc_internal.h"
>  #include "remoteproc_elf_helpers.h"
>  
> +struct rproc_coredump_state {
> + struct rproc *rproc;
> + void *header;
> + struct completion dump_done;
> +};
> +
>  /**
>   * rproc_coredump_cleanup() - clean up dump_segments list
>   * @rproc: the remote processor handle
> @@ -115,12 +122,110 @@ int rproc_coredump_set_elf_info(struct rproc *rproc, 
> u8 class, u16 machine)
>  }
>  EXPORT_SYMBOL(rproc_coredump_set_elf_info);
>  
> +static void rproc_coredump_free(void *data)
> +{
> + struct rproc_coredump_state *dump_state = data;
> +
> + vfree(dump_state->header);
> + complete(_state->dump_done);
> +}
> +
> +static void *rproc_coredump_find_segment(loff_t user_offset,
> +  struct list_head *segments,
> +  size_t *data_left)
> +{
> + struct rproc_dump_segment *segment;
> +
> + list_for_each_entry(segment, segments, node) {
> + if (user_offset < segment->size) {
> + *data_left = segment->size - user_offset;
> + return segment;
> + }
> + user_offset -= segment->size;
> + }
> +
> + *data_left = 0;
> + return NULL;
> +}
> +
> +static void rproc_copy_segment(struct rproc *rproc, void *dest,
> +struct rproc_dump_segment *segment,
> +size_t offset, size_t size)
> +{
> + void *ptr;
> +
> + if (segment->dump) {
> + segment->dump(rproc, segment, dest, offset, size);
> + } else {
> + ptr = rproc_da_to_va(rproc, segment->da + offset, size);
> + if (!ptr) {
> + dev_err(>dev,
> + "invalid copy request for segment %pad with 
> offset %zu and size %zu)\n",
> + >da, offset, size);
> + memset(dest, 0xff, size);
> + } else {
> + memcpy(dest, ptr, size);
> + }
> + }
> +}
> +
> +static ssize_t rproc_coredump_read(char *buffer, loff_t offset, size_t count,
> +void *data, size_t header_sz)
> +{
> + size_t seg_data, bytes_left = count;
> + ssize_t copy_sz;
> + struct rproc_dump_segment *seg;
> + struct rproc_coredump_state *dump_state = data;
> + struct rproc *rproc = dump_state->rproc;
> + void *elfcore = dump_state->header;
> +
> + /* Copy the vmalloc'ed header first. */
> + if (offset < header_sz) {
> + copy_sz = memory_read_from_buffer(buffer, count, ,
> +   elfcore, header_sz);
> +
> + return copy_sz;
> + }
> +
> + /*
> +  * Find out the segment memory chunk to be copied based on offset.
> +  * Keep copying data until count bytes are read.
> +  */
> + while (bytes_left) {
> + seg = rproc_coredump_find_segment(offset - header_sz,
> +   >dump_segments,
> +   _data);
> + /* EOF check */
> + if (!seg) {
> + dev_info(>dev, "Ramdump done, %lld bytes read",
> +  offset);
> + break;
> + }
> +
> + copy_sz = min_t(size_t, bytes_left, seg_data);
> +
> + rproc_copy_segment(rproc, buffer, seg, seg->size - seg_data,
> +copy_sz);
> +
> + offset += copy_sz;
> + buffer += copy_sz;
> + bytes_left -= copy_sz;
> + }
> +
> + return count - bytes_left;
> +}
> +
>  /**
>   * rproc_coredump() - perform coredump
>   * 

Re: [PATCH v16 05/22] mm/thp: move lru_add_page_tail func to huge_memory.c

[Alex Shi]

在 2020/7/16 下午9:17, Kirill A. Shutemov 写道:
> On Thu, Jul 16, 2020 at 04:59:48PM +0800, Alex Shi wrote:
>> Hi Kirill & Matthew,
>>
>> Is there any concern from for the THP involved patches?
> 
> It is mechanical move. I don't see a problem.
> 

Many thanks! Kirill,

Do you mind to give a reviewed-by?

And rre they ok for patch 6th,7th and 14th?

Thanks a lot!
Alex

Re: [PATCH v2 1/4] dt-bindings: media: venus: Add an optional power domain for perf voting

[Rajendra Nayak]

On 7/17/2020 5:13 AM, Bjorn Andersson wrote:

On Wed 15 Jul 22:42 PDT 2020, Rajendra Nayak wrote:


Add an optional power domain which when specified can be used for
setting the performance state of Venus.

Signed-off-by: Rajendra Nayak 
---
This is a resend of https://lore.kernel.org/patchwork/patch/1241077/

  Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml| 6 +-
  Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml | 6 +-
  2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml 
b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
index 55f2d67..1e8675b 100644
--- a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
@@ -25,12 +25,16 @@ properties:
  maxItems: 1
  
power-domains:

-maxItems: 2
+minItems: 2
+maxItems: 3
  
power-domain-names:

+minItems: 2
+maxItems: 3
  items:
- const: venus
- const: vcodec0
+  - const: opp-pd


In line with Rob's question, the "opp power-domain" seems like a
software construct, wouldn't this be better named e.g. "cx"?


The reason I chose to call it 'opp-pd' was to signify its the domain
that supports scaling (performance state) and not something that's just
turned on/off. I am fine calling it cx if that makes it look more 'real'



Regards,
Bjorn

  
clocks:

  maxItems: 5
diff --git a/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml 
b/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml
index 157dff8..437286d 100644
--- a/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml
@@ -25,13 +25,17 @@ properties:
  maxItems: 1
  
power-domains:

-maxItems: 3
+minItems: 3
+maxItems: 4
  
power-domain-names:

+minItems: 3
+maxItems: 4
  items:
- const: venus
- const: vcodec0
- const: vcodec1
+  - const: opp-pd
  
clocks:

  maxItems: 7
--
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

Re: [PATCH v16 15/22] mm/compaction: do page isolation first in compaction

[Alex Shi]

>> @@ -950,6 +951,21 @@ static bool too_many_isolated(pg_data_t *pgdat)
>> if (!(cc->gfp_mask & __GFP_FS) && page_mapping(page))
>> goto isolate_fail;
>>
>> +   /*
>> +* Be careful not to clear PageLRU until after we're
>> +* sure the page is not being freed elsewhere -- the
>> +* page release code relies on it.
>> +*/
>> +   if (unlikely(!get_page_unless_zero(page)))
>> +   goto isolate_fail;
>> +
>> +   if (__isolate_lru_page_prepare(page, isolate_mode) != 0)
>> +   goto isolate_fail_put;
>> +
>> +   /* Try isolate the page */
>> +   if (!TestClearPageLRU(page))
>> +   goto isolate_fail_put;
>> +
>> /* If we already hold the lock, we can skip some rechecking 
>> */
>> if (!locked) {
>> locked = compact_lock_irqsave(>lru_lock,
> 
> Why not do the __isolate_lru_page_prepare before getting the page?
> That way you can avoid performing an extra atomic operation on non-LRU
> pages.
>

This change come from Hugh Dickins as mentioned from commit log:
>> trylock_page() is not safe to use at this time: its setting PG_locked
>> can race with the page being freed or allocated ("Bad page"), and can
>> also erase flags being set by one of those "sole owners" of a freshly
>> allocated page who use non-atomic __SetPageFlag().

Hi Hugh,

would you like to show more details of the bug?

...

>> +* sure the page is not being freed elsewhere -- the
>> +* page release code relies on it.
>> +*/
>> +   if (unlikely(!get_page_unless_zero(page)))
>> +   goto busy;
>> +
>> +   if (!TestClearPageLRU(page)) {
>> +   /*
>> +* This page may in other isolation path,
>> +* but we still hold lru_lock.
>> +*/
>> +   put_page(page);
>> +   goto busy;
>> +   }
>> +
> 
> I wonder if it wouldn't make sense to combine these two atomic ops
> with tests and the put_page into a single inline function? Then it
> could be possible to just do one check and if succeeds you do the
> block of code below, otherwise you just fall-through into the -EBUSY
> case.
> 

Uh, since get_page changes page->_refcount, TestClearPageLRU changes 
page->flags,
So I don't know how to combine them, could you make it more clear with code?

Thanks
Alex

Re: [PATCH 1/3] remoteproc: qcom_q6v5_mss: Add modem debug policy support

[Sibi Sankar]

Hey Bjorn,
Thanks for taking time to review
the series.

On 2020-07-17 10:11, Bjorn Andersson wrote:

On Thu 16 Jul 05:36 PDT 2020, Sibi Sankar wrote:


Add modem debug policy support which will enable coredumps and live
debug support when the msadp firmware is present on secure devices.

Signed-off-by: Sibi Sankar 
---
 drivers/remoteproc/qcom_q6v5_mss.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/remoteproc/qcom_q6v5_mss.c 
b/drivers/remoteproc/qcom_q6v5_mss.c

index 13c6d5a72a831..95e21ed607cb9 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -187,6 +187,7 @@ struct q6v5 {
phys_addr_t mba_phys;
void *mba_region;
size_t mba_size;
+   size_t dp_size;

phys_addr_t mpss_phys;
phys_addr_t mpss_reloc;
@@ -406,6 +407,13 @@ static int q6v5_xfer_mem_ownership(struct q6v5 
*qproc, int *current_perm,

 static int q6v5_load(struct rproc *rproc, const struct firmware *fw)
 {
struct q6v5 *qproc = rproc->priv;
+   const struct firmware *dp_fw;
+
+	if (!request_firmware(_fw, "msadp", qproc->dev) && fw->size <= 
SZ_1M) {


Can we change this to a request_firmware_direct() to avoid the fact 
that
as written here devices lacking this file will pause here for 60 
seconds
waiting for userspace to assist in loading it (which at least none of 
my

systems do).

I also think that while it's nice to check that fw->size <= SZ_1M, to
avoid overwriting the tail of it, you should check that SZ_1M +
dp_fw->size < mba_size. To ensure that the memcpy doesn't go out of
bounds.


Sure I'll get ^^ done in the
next re-spin.




+   memcpy(qproc->mba_region + SZ_1M, dp_fw->data, dp_fw->size);
+   qproc->dp_size = dp_fw->size;
+   release_firmware(dp_fw);
+   }

memcpy(qproc->mba_region, fw->data, fw->size);

@@ -896,6 +904,10 @@ static int q6v5_mba_load(struct q6v5 *qproc)
}

writel(qproc->mba_phys, qproc->rmb_base + RMB_MBA_IMAGE_REG);
+   if (qproc->dp_size) {
+		writel(qproc->mba_phys + SZ_1M, qproc->rmb_base + 
RMB_PMI_CODE_START_REG);

+   writel(qproc->dp_size, qproc->rmb_base + 
RMB_PMI_CODE_LENGTH_REG);
+   }

ret = q6v5proc_reset(qproc);
if (ret)
@@ -1258,7 +1270,8 @@ static int q6v5_start(struct rproc *rproc)
if (ret)
return ret;

-   dev_info(qproc->dev, "MBA booted, loading mpss\n");
+   dev_info(qproc->dev, "MBA booted, debug policy %s, loading mpss\n",
+qproc->dp_size ? "enabled" : "disabled");


"MBA booted with%s debug policy, loading mpss\n", qproc->dp_size ? "" : 
"out"


Please.


Sure I'll use your template instead.



Regards,
Bjorn



ret = q6v5_mpss_load(qproc);
if (ret)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum,

a Linux Foundation Collaborative Project



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

Re: [PATCH v8 3/5] remoteproc: Pass size and offset as arguments to segment dump function

[Bjorn Andersson]

On Thu 16 Jul 15:20 PDT 2020, Rishabh Bhatnagar wrote:

> Change the segment dump API signature to include size and offset
> arguments. Refactor the qcom_q6v5_mss driver to use these
> arguments while copying the segment. Doing this lays the ground
> work for "inline" coredump functionality being added in the next
> patch.
> 

Reviewed-by: Bjorn Andersson 

> Signed-off-by: Rishabh Bhatnagar 
> ---
>  drivers/remoteproc/qcom_q6v5_mss.c   | 10 +-
>  drivers/remoteproc/remoteproc_coredump.c |  5 +++--
>  include/linux/remoteproc.h   |  5 +++--
>  3 files changed, 11 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/remoteproc/qcom_q6v5_mss.c 
> b/drivers/remoteproc/qcom_q6v5_mss.c
> index 037cd45..6baa3ae 100644
> --- a/drivers/remoteproc/qcom_q6v5_mss.c
> +++ b/drivers/remoteproc/qcom_q6v5_mss.c
> @@ -1199,7 +1199,7 @@ static int q6v5_mpss_load(struct q6v5 *qproc)
>  
>  static void qcom_q6v5_dump_segment(struct rproc *rproc,
>  struct rproc_dump_segment *segment,
> -void *dest)
> +void *dest, size_t cp_offset, size_t size)
>  {
>   int ret = 0;
>   struct q6v5 *qproc = rproc->priv;
> @@ -1219,16 +1219,16 @@ static void qcom_q6v5_dump_segment(struct rproc 
> *rproc,
>   }
>  
>   if (!ret)
> - ptr = ioremap_wc(qproc->mpss_phys + offset, segment->size);
> + ptr = ioremap_wc(qproc->mpss_phys + offset + cp_offset, size);
>  
>   if (ptr) {
> - memcpy(dest, ptr, segment->size);
> + memcpy(dest, ptr, size);
>   iounmap(ptr);
>   } else {
> - memset(dest, 0xff, segment->size);
> + memset(dest, 0xff, size);
>   }
>  
> - qproc->current_dump_size += segment->size;
> + qproc->current_dump_size += size;
>  
>   /* Reclaim mba after copying segments */
>   if (qproc->current_dump_size == qproc->total_dump_size) {
> diff --git a/drivers/remoteproc/remoteproc_coredump.c 
> b/drivers/remoteproc/remoteproc_coredump.c
> index ded0244..390f563 100644
> --- a/drivers/remoteproc/remoteproc_coredump.c
> +++ b/drivers/remoteproc/remoteproc_coredump.c
> @@ -72,7 +72,8 @@ int rproc_coredump_add_custom_segment(struct rproc *rproc,
> dma_addr_t da, size_t size,
> void (*dumpfn)(struct rproc *rproc,
>struct rproc_dump_segment 
> *segment,
> -  void *dest),
> +  void *dest, size_t offset,
> +  size_t size),
> void *priv)
>  {
>   struct rproc_dump_segment *segment;
> @@ -183,7 +184,7 @@ void rproc_coredump(struct rproc *rproc)
>   elf_phdr_set_p_align(class, phdr, 0);
>  
>   if (segment->dump) {
> - segment->dump(rproc, segment, data + offset);
> + segment->dump(rproc, segment, data + offset, 0, 
> segment->size);
>   } else {
>   ptr = rproc_da_to_va(rproc, segment->da, segment->size);
>   if (!ptr) {
> diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
> index e7b7bab..eb08139 100644
> --- a/include/linux/remoteproc.h
> +++ b/include/linux/remoteproc.h
> @@ -451,7 +451,7 @@ struct rproc_dump_segment {
>  
>   void *priv;
>   void (*dump)(struct rproc *rproc, struct rproc_dump_segment *segment,
> -  void *dest);
> +  void *dest, size_t offset, size_t size);
>   loff_t offset;
>  };
>  
> @@ -630,7 +630,8 @@ int rproc_coredump_add_custom_segment(struct rproc *rproc,
> dma_addr_t da, size_t size,
> void (*dumpfn)(struct rproc *rproc,
>struct rproc_dump_segment 
> *segment,
> -  void *dest),
> +  void *dest, size_t offset,
> +  size_t size),
> void *priv);
>  int rproc_coredump_set_elf_info(struct rproc *rproc, u8 class, u16 machine);
>  
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 

Re: [PATCH v3] mm/hugetlb: split hugetlb_cma in nodes with memory

[Anshuman Khandual]

On 07/16/2020 11:55 PM, Mike Kravetz wrote:
>>From 17c8f37afbf42fe7412e6eebb3619c6e0b7e1c3c Mon Sep 17 00:00:00 2001
> From: Mike Kravetz 
> Date: Tue, 14 Jul 2020 15:54:46 -0700
> Subject: [PATCH] hugetlb: move cma reservation to code setting up gigantic
>  hstate
> 
> Instead of calling hugetlb_cma_reserve() directly from arch specific
> code, call from hugetlb_add_hstate when adding a gigantic hstate.
> hugetlb_add_hstate is either called from arch specific huge page setup,
> or as the result of hugetlb command line processing.  In either case,
> this is late enough in the init process that all numa memory information
> should be initialized.  And, it is early enough to still use early
> memory allocator.

This assumes that hugetlb_add_hstate() is called from the arch code at
the right point in time for the generic HugeTLB to do the required CMA
reservation which is not ideal. I guess it must have been a reason why
CMA reservation should always called by the platform code which knows
the boot sequence timing better.

Re: [PATCH v8 2/5] remoteproc: qcom_q6v5_mss: Replace mask based tracking with size

[Bjorn Andersson]

On Thu 16 Jul 15:20 PDT 2020, Rishabh Bhatnagar wrote:

> From: Sibi Sankar 
> 
> In order to land inline coredump support for mss, the dump_segment
> function would need to support granularities less than the segment
> size. This is achieved by replacing mask based tracking with size.
> 
> Signed-off-by: Sibi Sankar 
> Signed-off-by: Rishabh Bhatnagar 

Reviewed-by: Bjorn Andersson 

> ---
>  drivers/remoteproc/qcom_q6v5_mss.c | 17 -
>  1 file changed, 8 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/remoteproc/qcom_q6v5_mss.c 
> b/drivers/remoteproc/qcom_q6v5_mss.c
> index feb70283b..037cd45 100644
> --- a/drivers/remoteproc/qcom_q6v5_mss.c
> +++ b/drivers/remoteproc/qcom_q6v5_mss.c
> @@ -181,8 +181,8 @@ struct q6v5 {
>   bool running;
>  
>   bool dump_mba_loaded;
> - unsigned long dump_segment_mask;
> - unsigned long dump_complete_mask;
> + size_t current_dump_size;
> + size_t total_dump_size;
>  
>   phys_addr_t mba_phys;
>   void *mba_region;
> @@ -1203,7 +1203,6 @@ static void qcom_q6v5_dump_segment(struct rproc *rproc,
>  {
>   int ret = 0;
>   struct q6v5 *qproc = rproc->priv;
> - unsigned long mask = BIT((unsigned long)segment->priv);
>   int offset = segment->da - qproc->mpss_reloc;
>   void *ptr = NULL;
>  
> @@ -1229,10 +1228,10 @@ static void qcom_q6v5_dump_segment(struct rproc 
> *rproc,
>   memset(dest, 0xff, segment->size);
>   }
>  
> - qproc->dump_segment_mask |= mask;
> + qproc->current_dump_size += segment->size;
>  
>   /* Reclaim mba after copying segments */
> - if (qproc->dump_segment_mask == qproc->dump_complete_mask) {
> + if (qproc->current_dump_size == qproc->total_dump_size) {
>   if (qproc->dump_mba_loaded) {
>   /* Try to reset ownership back to Q6 */
>   q6v5_xfer_mem_ownership(qproc, >mpss_perm,
> @@ -1274,7 +1273,7 @@ static int q6v5_start(struct rproc *rproc)
>   "Failed to reclaim mba buffer system may become 
> unstable\n");
>  
>   /* Reset Dump Segment Mask */
> - qproc->dump_segment_mask = 0;
> + qproc->current_dump_size = 0;
>   qproc->running = true;
>  
>   return 0;
> @@ -1323,7 +1322,7 @@ static int qcom_q6v5_register_dump_segments(struct 
> rproc *rproc,
>  
>   ehdr = (struct elf32_hdr *)fw->data;
>   phdrs = (struct elf32_phdr *)(ehdr + 1);
> - qproc->dump_complete_mask = 0;
> + qproc->total_dump_size = 0;
>  
>   for (i = 0; i < ehdr->e_phnum; i++) {
>   phdr = [i];
> @@ -1334,11 +1333,11 @@ static int qcom_q6v5_register_dump_segments(struct 
> rproc *rproc,
>   ret = rproc_coredump_add_custom_segment(rproc, phdr->p_paddr,
>   phdr->p_memsz,
>   qcom_q6v5_dump_segment,
> - (void *)i);
> + NULL);
>   if (ret)
>   break;
>  
> - qproc->dump_complete_mask |= BIT(i);
> + qproc->total_dump_size += phdr->p_memsz;
>   }
>  
>   release_firmware(fw);
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 

Re: [PATCH 3/3] remoteproc: qcom_q6v5_mss: Update MBA log info

[Bjorn Andersson]

On Thu 16 Jul 05:36 PDT 2020, Sibi Sankar wrote:

> Update MBA text logs location/size in IMEM to aid tools extract
> them after ramdump collection.
> 
> Signed-off-by: Sibi Sankar 
> ---
>  drivers/remoteproc/qcom_q6v5_mss.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/remoteproc/qcom_q6v5_mss.c 
> b/drivers/remoteproc/qcom_q6v5_mss.c
> index 4ddf084b2c6fc..539594ab955f1 100644
> --- a/drivers/remoteproc/qcom_q6v5_mss.c
> +++ b/drivers/remoteproc/qcom_q6v5_mss.c
> @@ -932,6 +932,9 @@ static int q6v5_mba_load(struct q6v5 *qproc)
>   if (ret)
>   goto reclaim_mba;
>  
> + if (qproc->has_mba_logs)
> + qcom_pil_info_store("mba", qproc->mba_phys, MBA_LOG_SIZE);

Is there a reason why we don't unconditionally write this to the PIL
info? And why it shouldn't be mba_size?

Regards,
Bjorn

> +
>   ret = q6v5_rmb_mba_wait(qproc, 0, 5000);
>   if (ret == -ETIMEDOUT) {
>   dev_err(qproc->dev, "MBA boot timed out\n");
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 

[tip:x86/urgent] BUILD SUCCESS 81e96851ea32deb2c921c870eecabf335f598aeb

[kernel test robot]

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git  
x86/urgent
branch HEAD: 81e96851ea32deb2c921c870eecabf335f598aeb  x86: math-emu: Fix up 
'cmp' insn for clang ias

elapsed time: 723m

configs tested: 60
configs skipped: 70

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

arm defconfig
arm  allyesconfig
arm  allmodconfig
arm   allnoconfig
arm64allyesconfig
arm64   defconfig
arm64allmodconfig
arm64 allnoconfig
i386 allyesconfig
i386defconfig
i386  debian-10.3
i386  allnoconfig
ia64 allmodconfig
ia64defconfig
ia64  allnoconfig
ia64 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
xtensa  defconfig
arc defconfig
arc  allyesconfig
sh   allmodconfig
shallnoconfig
microblazeallnoconfig
mips allyesconfig
mips  allnoconfig
mips allmodconfig
pariscallnoconfig
parisc  defconfig
parisc   allyesconfig
parisc   allmodconfig
riscvallyesconfig
riscv allnoconfig
riscv   defconfig
riscvallmodconfig
sparcallyesconfig
sparc   defconfig
sparc64 defconfig
sparc64   allnoconfig
sparc64  allyesconfig
sparc64  allmodconfig
x86_64   rhel
x86_64lkp
x86_64  fedora-25
x86_64rhel-7.6-kselftests
x86_64   rhel-8.3
x86_64  kexec

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org

Re: [PATCH 2/3] remoteproc: qcom_q6v5_mss: Add MBA log extraction support

[Bjorn Andersson]

On Thu 16 Jul 05:36 PDT 2020, Sibi Sankar wrote:

> On SC7180 the MBA firmware stores the bootup text logs in a 4K segment
> at the beginning of the MBA region. Add support to extract the logs
> which will be useful to debug mba boot/authentication issues.
> 
> Signed-off-by: Sibi Sankar 
> ---
>  drivers/remoteproc/qcom_q6v5_mss.c | 41 ++
>  1 file changed, 36 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/remoteproc/qcom_q6v5_mss.c 
> b/drivers/remoteproc/qcom_q6v5_mss.c
> index 95e21ed607cb9..4ddf084b2c6fc 100644
> --- a/drivers/remoteproc/qcom_q6v5_mss.c
> +++ b/drivers/remoteproc/qcom_q6v5_mss.c
> @@ -9,6 +9,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -37,6 +38,8 @@
>  
>  #define MPSS_CRASH_REASON_SMEM   421
>  
> +#define MBA_LOG_SIZE SZ_4K
> +
>  /* RMB Status Register Values */
>  #define RMB_PBL_SUCCESS  0x1
>  
> @@ -139,6 +142,7 @@ struct rproc_hexagon_res {
>   int version;
>   bool need_mem_protection;
>   bool has_alt_reset;
> + bool has_mba_logs;
>   bool has_spare_reg;
>  };
>  
> @@ -200,6 +204,7 @@ struct q6v5 {
>   struct qcom_sysmon *sysmon;
>   bool need_mem_protection;
>   bool has_alt_reset;
> + bool has_mba_logs;
>   bool has_spare_reg;
>   int mpss_perm;
>   int mba_perm;
> @@ -518,6 +523,19 @@ static int q6v5_rmb_mba_wait(struct q6v5 *qproc, u32 
> status, int ms)
>   return val;
>  }
>  
> +static void q6v5_dump_mba_logs(struct q6v5 *qproc)
> +{
> + struct rproc *rproc = qproc->rproc;
> + void *data;
> +
> + data = vmalloc(MBA_LOG_SIZE);
> + if (!data)
> + return;
> +
> + memcpy(data, qproc->mba_region, MBA_LOG_SIZE);
> + dev_coredumpv(>dev, data, MBA_LOG_SIZE, GFP_KERNEL);
> +}
> +
>  static int q6v5proc_reset(struct q6v5 *qproc)
>  {
>   u32 val;
> @@ -838,6 +856,7 @@ static int q6v5_mba_load(struct q6v5 *qproc)
>  {
>   int ret;
>   int xfermemop_ret;
> + bool mba_load_err = false;
>  
>   qcom_q6v5_prepare(>q6v5);
>  
> @@ -931,7 +950,7 @@ static int q6v5_mba_load(struct q6v5 *qproc)
>   q6v5proc_halt_axi_port(qproc, qproc->halt_map, qproc->halt_q6);
>   q6v5proc_halt_axi_port(qproc, qproc->halt_map, qproc->halt_modem);
>   q6v5proc_halt_axi_port(qproc, qproc->halt_map, qproc->halt_nc);
> -
> + mba_load_err = true;
>  reclaim_mba:
>   xfermemop_ret = q6v5_xfer_mem_ownership(qproc, >mba_perm, true,
>   false, qproc->mba_phys,
> @@ -939,6 +958,8 @@ static int q6v5_mba_load(struct q6v5 *qproc)
>   if (xfermemop_ret) {
>   dev_err(qproc->dev,
>   "Failed to reclaim mba buffer, system may become 
> unstable\n");
> + } else if (qproc->has_mba_logs & mba_load_err) {
> + q6v5_dump_mba_logs(qproc);
>   }
>  
>  disable_active_clks:
> @@ -968,7 +989,7 @@ static int q6v5_mba_load(struct q6v5 *qproc)
>   return ret;
>  }
>  
> -static void q6v5_mba_reclaim(struct q6v5 *qproc)
> +static void q6v5_mba_reclaim(struct q6v5 *qproc, bool err_path)
>  {
>   int ret;
>   u32 val;
> @@ -1006,6 +1027,9 @@ static void q6v5_mba_reclaim(struct q6v5 *qproc)
> qproc->mba_size);
>   WARN_ON(ret);
>  
> + if (qproc->has_mba_logs && err_path && !ret)

Wouldn't it be possible to just call q6v5_dump_mba_logs() directly after
the return from q6v5_mba_reclaim()? That way we can avoid passing the
bool to indicate if the reclaim should also dump some stuff.

Sure we don't have a way to tell if the assign_mem failed, but we're
going to crash shortly anyways (which is something we should change).



I think you should move the has_mba_logs into q6v5_dump_mba_logs(),
making it cause an early return.

Regards,
Bjorn

> + q6v5_dump_mba_logs(qproc);
> +
>   ret = qcom_q6v5_unprepare(>q6v5);
>   if (ret) {
>   q6v5_pds_disable(qproc, qproc->proxy_pds,
> @@ -1255,7 +1279,7 @@ static void qcom_q6v5_dump_segment(struct rproc *rproc,
>   false, true,
>   qproc->mpss_phys,
>   qproc->mpss_size);
> - q6v5_mba_reclaim(qproc);
> + q6v5_mba_reclaim(qproc, false);
>   }
>   }
>  }
> @@ -1297,7 +1321,7 @@ static int q6v5_start(struct rproc *rproc)
>   return 0;
>  
>  reclaim_mpss:
> - q6v5_mba_reclaim(qproc);
> + q6v5_mba_reclaim(qproc, true);
>  
>   return ret;
>  }
> @@ -1313,7 +1337,7 @@ static int q6v5_stop(struct rproc *rproc)
>   if (ret == -ETIMEDOUT)
>   dev_err(qproc->dev, "timed out on wait\n");
>  
> - q6v5_mba_reclaim(qproc);
> + q6v5_mba_reclaim(qproc, false);
>  
>   return 0;
>  }
> @@ -1717,6 +1741,7 @@ static int q6v5_probe(struct 

Re: [PATCH v2 0/6] [media] pci: use generic power management

[Vaibhav Gupta]

On Fri, Jul 17, 2020 at 09:26:02AM +0530, Vaibhav Gupta wrote:
> Linux Kernel Mentee: Remove Legacy Power Management.
> 
> The purpose of this patch series is to upgrade power management in media
> drivers. This has been done by upgrading .suspend() and .resume() callbacks.
> 
> The upgrade makes sure that the involvement of PCI Core does not change the
> order of operations executed in a driver. Thus, does not change its behavior.
> 
> In general, drivers with legacy PM, .suspend() and .resume() make use of PCI
> helper functions like pci_enable/disable_device_mem(), pci_set_power_state(),
> pci_save/restore_state(), pci_enable/disable_device(), etc. to complete
> their job.
> 
> The conversion requires the removal of those function calls, change the
> callbacks' definition accordingly and make use of dev_pm_ops structure.
> 
> v2: v1 possibly broke cx23885 and cx25821.
v1 didn't break anything in real as patch was not applied. But it could have.
> 
> All patches are compile-tested only.
> 
> Test tools:
> - Compiler: gcc (GCC) 10.1.0
> - allmodconfig build: make -j$(nproc) W=1 all
> 
> Vaibhav Gupta (6):
>   sta2x11: use generic power management
>   cx23885: use generic power management
>   cx25821: use generic power management
>   cx88: use generic power management
>   meye: use generic power management
>   tw68: use generic power management
> 
>  drivers/media/pci/cx23885/cx23885-core.c |  3 --
>  drivers/media/pci/cx25821/cx25821-core.c |  3 --
>  drivers/media/pci/cx88/cx88-video.c  | 52 +--
>  drivers/media/pci/meye/meye.c| 15 ++
>  drivers/media/pci/sta2x11/sta2x11_vip.c  | 63 ++--
>  drivers/media/pci/tw68/tw68-core.c   | 30 +--
>  6 files changed, 44 insertions(+), 122 deletions(-)
> 
> -- 
> 2.27.0
> 

Re: [PATCH] dt-bindings: uniphier-thermal: add minItems to socionext,tmod-calibration

[Masahiro Yamada]

On Fri, Jul 17, 2020 at 8:09 AM Rob Herring  wrote:
>
> On Tue, Jul 07, 2020 at 07:23:38PM +0900, Masahiro Yamada wrote:
> > As the description says, this property contains a pair of calibration
> > values. The number of items must be exactly 2.
> >
> > Add minItems to check a too short property.
> >
> > While I was here, I also added this property to the example because
> > this is the case in the real DT file,
> > arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
> >
> > Also, fix the interrupt type (edge -> level) to align with the
> > real DT.
> >
> > Signed-off-by: Masahiro Yamada 
> > ---
> >
> >  .../bindings/thermal/socionext,uniphier-thermal.yaml  | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git 
> > a/Documentation/devicetree/bindings/thermal/socionext,uniphier-thermal.yaml 
> > b/Documentation/devicetree/bindings/thermal/socionext,uniphier-thermal.yaml
> > index 553c9dcdaeeb..57ffd0c4c474 100644
> > --- 
> > a/Documentation/devicetree/bindings/thermal/socionext,uniphier-thermal.yaml
> > +++ 
> > b/Documentation/devicetree/bindings/thermal/socionext,uniphier-thermal.yaml
> > @@ -29,6 +29,7 @@ properties:
> >
> >socionext,tmod-calibration:
> >  $ref: /schemas/types.yaml#/definitions/uint32-array
> > +minItems: 2
>
> The intent was if minItems is not defined, then the default is the same
> as maxItems. This is not the default for json-schema, so the tooling is
> supposed to add it.


This implication is unclear.

maxItems should literally only define the max, and
we should stick to json-schema as much as possible, IMHO.




It would be nice if json-schema had something like:

numItems: 2

as a shorthand for

minItems: 2
maxItems: 2


Masahiro Yamada




> But looking at processed-schema.yaml, it doesn't
> seem to be happening for one case here. I'm working on a fix in the
> tools.
>
> Rob



--
Best Regards
Masahiro Yamada

Re: [git pull] drm fixes for 5.8-rc6

[pr-tracker-bot]

The pull request you sent on Fri, 17 Jul 2020 13:42:02 +1000:

> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-07-17-1

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8882572675c1bb1cc544f4e229a11661f1fc52e4

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [PATCH v4 1/2] kernel: Implement selective syscall userspace redirection

[Andy Lutomirski]

On Thu, Jul 16, 2020 at 7:15 PM Gabriel Krisman Bertazi
 wrote:
>
> Andy Lutomirski  writes:
>
> > On Thu, Jul 16, 2020 at 12:31 PM Gabriel Krisman Bertazi
> >  wrote:
> >>
> >
> > This is quite nice.  I have a few comments, though:
> >
> > You mentioned rt_sigreturn().  Should this automatically exempt the
> > kernel-provided signal restorer on architectures (e.g. x86_32) that
> > provide one?
>
> That seems reasonable.  Not sure how easy it is to do it, though.

For better or for worse, it's currently straightforward because the code is:

__kernel_sigreturn:
.LSTART_sigreturn:
popl %eax   /* XXX does this mean it needs unwind info? */
movl $__NR_sigreturn, %eax
SYSCALL_ENTER_KERNEL

and SYSCALL_ENTER_KERNEL is hardwired as int $0x80.  (The latter is
probably my fault, for better or for worse.)  So this would change to:

__vdso32_sigreturn_syscall:
  SYSCALL_ENTER_KERNEL

and vdso2c would wire up __vdso32_sigreturn_syscall.  Then there would
be something like:

bool arch_syscall_is_vdso_sigreturn(struct pt_regs *regs);

and that would be that.  Does anyone have an opinion as to whether
this is a good idea?  Modern glibc shouldn't be using this mechanism,
I think, but I won't swear to it.

>
> > The amount of syscall entry wiring that arches need to do is IMO
> > already a bit out of hand.  Should we instead rename TIF_SECCOMP to
> > TIF_SYSCALL_INTERCEPTION and have one generic callback that handles
> > seccomp and this new thing?
>
> Considering the previous suggestion from Kees to hide it inside the
> tracehook and Thomas rework of this path, I'm not sure what is the best
> solution here, but some rework of these flags is due.  Thomas suggested
> expanding these flags to 64 bits and having some arch specific and
> arch-agnostic flags.  With the storage expansion and arch-agnostic flags,
> would this still be desirable?

I think it would be desirable to consolidate this to avoid having
multiple arches need to separately wire up all of these mechanisms.
I'm not sure that the initial upstream implementation needs this, but
it might be nice to support this out of the box on all arches with
seccomp support.

>
> >> +int do_syscall_user_dispatch(struct pt_regs *regs)
> >> +{
> >> +   struct syscall_user_dispatch *sd = >syscall_dispatch;
> >> +   unsigned long ip = instruction_pointer(regs);
> >> +   char state;
> >> +
> >> +   if (likely(ip >= sd->dispatcher_start && ip <= sd->dispatcher_end))
> >> +   return 0;
> >> +
> >> +   if (likely(sd->selector)) {
> >> +   if (unlikely(__get_user(state, sd->selector)))
> >> +   do_exit(SIGSEGV);
> >> +
> >> +   if (likely(state == 0))
> >> +   return 0;
> >> +
> >> +   if (state != 1)
> >> +   do_exit(SIGSEGV);
> >
> > This seems a bit extreme and hard to debug if it ever happens.
>
> Makes sense, but I don't see a better way to return the error here.
> Maybe a SIGSYS with a different si_errno?  Alternatively, we could
> revert to the previous behavior of allowing syscalls on state != 0, that
> existed in v1.  What do you think?
>

I don't have a strong opinion.  SIGSYS with different si_errno is
probably reasonable.

--Andy

Re: [PATCH v3 02/12] powerpc/kexec_file: mark PPC64 specific code

[Hari Bathini]

On 16/07/20 7:19 am, Thiago Jung Bauermann wrote:
> 
> I didn't forget about this patch. I just wanted to see more of the
> changes before comenting on it.
> 
> Hari Bathini  writes:
> 
>> Some of the kexec_file_load code isn't PPC64 specific. Move PPC64
>> specific code from kexec/file_load.c to kexec/file_load_64.c. Also,
>> rename purgatory/trampoline.S to purgatory/trampoline_64.S in the
>> same spirit.
> 
> There's only a 64 bit implementation of kexec_file_load() so this is a
> somewhat theoretical exercise, but there's no harm in getting the code
> organized, so:
> 
> Reviewed-by: Thiago Jung Bauermann 
> 
> I have just one question below.



>> +/**
>> + * setup_new_fdt_ppc64 - Update the flattend device-tree of the kernel
>> + *   being loaded.
>> + * @image:   kexec image being loaded.
>> + * @fdt: Flattened device tree for the next kernel.
>> + * @initrd_load_addr:Address where the next initrd will be loaded.
>> + * @initrd_len:  Size of the next initrd, or 0 if there will be 
>> none.
>> + * @cmdline: Command line for the next kernel, or NULL if there 
>> will
>> + *   be none.
>> + *
>> + * Returns 0 on success, negative errno on error.
>> + */
>> +int setup_new_fdt_ppc64(const struct kimage *image, void *fdt,
>> +unsigned long initrd_load_addr,
>> +unsigned long initrd_len, const char *cmdline)
>> +{
>> +int chosen_node, ret;
>> +
>> +/* Remove memory reservation for the current device tree. */
>> +ret = delete_fdt_mem_rsv(fdt, __pa(initial_boot_params),
>> + fdt_totalsize(initial_boot_params));
>> +if (ret == 0)
>> +pr_debug("Removed old device tree reservation.\n");
>> +else if (ret != -ENOENT) {
>> +pr_err("Failed to remove old device-tree reservation.\n");
>> +return ret;
>> +}
>> +
>> +ret = setup_new_fdt(image, fdt, initrd_load_addr, initrd_len,
>> +cmdline, _node);
>> +if (ret)
>> +return ret;
>> +
>> +ret = fdt_setprop(fdt, chosen_node, "linux,booted-from-kexec", NULL, 0);
>> +if (ret)
>> +pr_err("Failed to update device-tree with 
>> linux,booted-from-kexec\n");
>> +
>> +return ret;
>> +}
> 
> For setup_purgatory_ppc64() you start with an empty function and build
> from there, but for setup_new_fdt_ppc64() you moved some code here. Is
> the code above 64 bit specific?

Actually, I was not quiet sure if fdt updates like in patch 6 & patch 9 can be
done after setup_ima_buffer() call. If you can confirm, I will move them back
to setup_purgatory()

Thanks
Hari

linux-next: manual merge of the tip tree with the crypto tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  arch/x86/include/asm/inst.h

between commit:

  d7866e503bdc ("crypto: x86 - Remove include/asm/inst.h")

from the crypto tree and commit:

  eaad981291ee ("x86/entry/64: Introduce the FIND_PERCPU_BASE macro")

from the tip tree.

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

I think if the crypto tree brought back this file as well (even without
the RDPID macro, it would make this conflict much more manageable.

/* SPDX-License-Identifier: GPL-2.0 */
/*
 * Generate .byte code for some instructions not supported by old
 * binutils.
 */
#ifndef X86_ASM_INST_H
#define X86_ASM_INST_H

#ifdef __ASSEMBLY__

#define REG_NUM_INVALID 100

#define REG_TYPE_R320
#define REG_TYPE_R641
#define REG_TYPE_XMM2
#define REG_TYPE_INVALID100

.macro R32_NUM opd r32
\opd = REG_NUM_INVALID
.ifc \r32,%eax
\opd = 0
.endif
.ifc \r32,%ecx
\opd = 1
.endif
.ifc \r32,%edx
\opd = 2
.endif
.ifc \r32,%ebx
\opd = 3
.endif
.ifc \r32,%esp
\opd = 4
.endif
.ifc \r32,%ebp
\opd = 5
.endif
.ifc \r32,%esi
\opd = 6
.endif
.ifc \r32,%edi
\opd = 7
.endif
#ifdef CONFIG_X86_64
.ifc \r32,%r8d
\opd = 8
.endif
.ifc \r32,%r9d
\opd = 9
.endif
.ifc \r32,%r10d
\opd = 10
.endif
.ifc \r32,%r11d
\opd = 11
.endif
.ifc \r32,%r12d
\opd = 12
.endif
.ifc \r32,%r13d
\opd = 13
.endif
.ifc \r32,%r14d
\opd = 14
.endif
.ifc \r32,%r15d
\opd = 15
.endif
#endif
.endm

.macro R64_NUM opd r64
\opd = REG_NUM_INVALID
#ifdef CONFIG_X86_64
.ifc \r64,%rax
\opd = 0
.endif
.ifc \r64,%rcx
\opd = 1
.endif
.ifc \r64,%rdx
\opd = 2
.endif
.ifc \r64,%rbx
\opd = 3
.endif
.ifc \r64,%rsp
\opd = 4
.endif
.ifc \r64,%rbp
\opd = 5
.endif
.ifc \r64,%rsi
\opd = 6
.endif
.ifc \r64,%rdi
\opd = 7
.endif
.ifc \r64,%r8
\opd = 8
.endif
.ifc \r64,%r9
\opd = 9
.endif
.ifc \r64,%r10
\opd = 10
.endif
.ifc \r64,%r11
\opd = 11
.endif
.ifc \r64,%r12
\opd = 12
.endif
.ifc \r64,%r13
\opd = 13
.endif
.ifc \r64,%r14
\opd = 14
.endif
.ifc \r64,%r15
\opd = 15
.endif
#endif
.endm

.macro XMM_NUM opd xmm
\opd = REG_NUM_INVALID
.ifc \xmm,%xmm0
\opd = 0
.endif
.ifc \xmm,%xmm1
\opd = 1
.endif
.ifc \xmm,%xmm2
\opd = 2
.endif
.ifc \xmm,%xmm3
\opd = 3
.endif
.ifc \xmm,%xmm4
\opd = 4
.endif
.ifc \xmm,%xmm5
\opd = 5
.endif
.ifc \xmm,%xmm6
\opd = 6
.endif
.ifc \xmm,%xmm7
\opd = 7
.endif
.ifc \xmm,%xmm8
\opd = 8
.endif
.ifc \xmm,%xmm9
\opd = 9
.endif
.ifc \xmm,%xmm10
\opd = 10
.endif
.ifc \xmm,%xmm11
\opd = 11
.endif
.ifc \xmm,%xmm12
\opd = 12
.endif
.ifc \xmm,%xmm13
\opd = 13
.endif
.ifc \xmm,%xmm14
\opd = 14
.endif
.ifc \xmm,%xmm15
\opd = 15
.endif
.endm

.macro REG_TYPE type reg
R32_NUM reg_type_r32 \reg
R64_NUM reg_type_r64 \reg
XMM_NUM reg_type_xmm \reg
.if reg_type_r64 <> REG_NUM_INVALID
\type = REG_TYPE_R64
.elseif reg_type_r32 <> REG_NUM_INVALID
\type = REG_TYPE_R32
.elseif reg_type_xmm <> REG_NUM_INVALID
\type = REG_TYPE_XMM
.else
\type = REG_TYPE_INVALID
.endif
.endm

.macro PFX_OPD_SIZE
.byte 0x66
.endm

.macro PFX_REX opd1 opd2 W=0
.if ((\opd1 | \opd2) & 8) || \W
.byte 0x40 | ((\opd1 & 8) >> 3) | ((\opd2 & 8) >> 1) | (\W << 3)
.endif
.endm

.macro MODRM mod opd1 opd2
.byte \mod | (\opd1 & 7) | ((\opd2 & 7) << 3)

[PATCH] tools/memory-model: document the "one-time init" pattern

[Eric Biggers]

From: Eric Biggers 

The "one-time init" pattern is implemented incorrectly in various places
in the kernel.  And when people do try to implement it correctly, it is
unclear what to use.  Try to give some proper guidance.

This is motivated by the discussion at
https://lkml.kernel.org/linux-fsdevel/2020071300.205104-1-ebigg...@kernel.org/T/#u
regarding fixing the initialization of super_block::s_dio_done_wq.

Cc: Akira Yokosawa 
Cc: Alan Stern 
Cc: Andrea Parri 
Cc: Boqun Feng 
Cc: Daniel Lustig 
Cc: Darrick J. Wong 
Cc: Dave Chinner 
Cc: David Howells 
Cc: Jade Alglave 
Cc: Luc Maranget 
Cc: Nicholas Piggin 
Cc: Paul E. McKenney 
Cc: Peter Zijlstra 
Cc: Will Deacon 
Signed-off-by: Eric Biggers 
---
 tools/memory-model/Documentation/recipes.txt | 151 +++
 1 file changed, 151 insertions(+)

diff --git a/tools/memory-model/Documentation/recipes.txt 
b/tools/memory-model/Documentation/recipes.txt
index 7fe8d7aa3029..04beb06dbfc7 100644
--- a/tools/memory-model/Documentation/recipes.txt
+++ b/tools/memory-model/Documentation/recipes.txt
@@ -519,6 +519,157 @@ CPU1 puts the waiting task to sleep and CPU0 fails to 
wake it up.
 
 Note that use of locking can greatly simplify this pattern.
 
+One-time init
+-
+
+The "one-time init" pattern is when multiple tasks can race to
+initialize the same data structure(s) on first use.
+
+In many cases, it's best to just avoid the need for this by simply
+initializing the data ahead of time.
+
+But in cases where the data would often go unused, one-time init can be
+appropriate to avoid wasting kernel resources.  It can also be
+appropriate if the initialization has other prerequisites which preclude
+it being done ahead of time.
+
+First, consider if your data has (a) global or static scope, (b) can be
+initialized from atomic context, and (c) cannot fail to be initialized.
+If all of those apply, just use DO_ONCE() from :
+
+   DO_ONCE(func);
+
+If that doesn't apply, you'll have to implement one-time init yourself.
+
+The simplest implementation just uses a mutex and an 'inited' flag.
+This implementation should be used where feasible:
+
+   static bool foo_inited;
+   static DEFINE_MUTEX(foo_init_mutex);
+
+   int init_foo_if_needed(void)
+   {
+   int err = 0;
+
+   mutex_lock(_init_mutex);
+   if (!foo_inited) {
+   err = init_foo();
+   if (err == 0)
+   foo_inited = true;
+   }
+   mutex_unlock(_init_mutex);
+   return err;
+   }
+
+The above example uses static variables, but this solution also works
+for initializing something that is part of another data structure.  The
+mutex may still be static.
+
+In where cases where taking the mutex in the "already initialized" case
+presents scalability concerns, the implementation can be optimized to
+check the 'inited' flag outside the mutex.  Unfortunately, this
+optimization is often implemented incorrectly by using a plain load.
+That violates the memory model and may result in unpredictable behavior.
+
+A correct implementation is:
+
+   static bool foo_inited;
+   static DEFINE_MUTEX(foo_init_mutex);
+
+   int init_foo_if_needed(void)
+   {
+   int err = 0;
+
+   /* pairs with smp_store_release() below */
+   if (smp_load_acquire(_inited))
+   return 0;
+
+   mutex_lock(_init_mutex);
+   if (!foo_inited) {
+   err = init_foo();
+   if (err == 0) /* pairs with smp_load_acquire() above */
+   smp_store_release(_inited, true);
+   }
+   mutex_unlock(_init_mutex);
+   return err;
+   }
+
+If only a single data structure is being initialized, then the pointer
+itself can take the place of the 'inited' flag:
+
+   static struct foo *foo;
+   static DEFINE_MUTEX(foo_init_mutex);
+
+   int init_foo_if_needed(void)
+   {
+   int err = 0;
+
+   /* pairs with smp_store_release() below */
+   if (smp_load_acquire())
+   return 0;
+
+   mutex_lock(_init_mutex);
+   if (!foo) {
+   struct foo *p = alloc_foo();
+
+   if (p) /* pairs with smp_load_acquire() above */
+   smp_store_release(, p);
+   else
+   err = -ENOMEM;
+   }
+   mutex_unlock(_init_mutex);
+   return err;
+   }
+
+There are also cases in which the smp_load_acquire() can be replaced by
+the more lightweight READ_ONCE().  (smp_store_release() is still
+required.)  Specifically, if all initialized memory is transitively
+reachable from the pointer itself, then there is no control dependency
+so the data dependency barrier 

Re: [PATCH 03/20] thermal: rcar_gen3_thermal: Add r8a774e1 support

[Daniel Lezcano]

On 15/07/2020 13:08, Lad Prabhakar wrote:
> From: Marian-Cristian Rotariu 
> 
> Add r8a774e1 specific compatible string.
> 
> Signed-off-by: Marian-Cristian Rotariu 
> 
> Signed-off-by: Lad Prabhakar  ---

Applied, thanks



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

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH 1/3] remoteproc: qcom_q6v5_mss: Add modem debug policy support

[Bjorn Andersson]

On Thu 16 Jul 05:36 PDT 2020, Sibi Sankar wrote:

> Add modem debug policy support which will enable coredumps and live
> debug support when the msadp firmware is present on secure devices.
> 
> Signed-off-by: Sibi Sankar 
> ---
>  drivers/remoteproc/qcom_q6v5_mss.c | 15 ++-
>  1 file changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/remoteproc/qcom_q6v5_mss.c 
> b/drivers/remoteproc/qcom_q6v5_mss.c
> index 13c6d5a72a831..95e21ed607cb9 100644
> --- a/drivers/remoteproc/qcom_q6v5_mss.c
> +++ b/drivers/remoteproc/qcom_q6v5_mss.c
> @@ -187,6 +187,7 @@ struct q6v5 {
>   phys_addr_t mba_phys;
>   void *mba_region;
>   size_t mba_size;
> + size_t dp_size;
>  
>   phys_addr_t mpss_phys;
>   phys_addr_t mpss_reloc;
> @@ -406,6 +407,13 @@ static int q6v5_xfer_mem_ownership(struct q6v5 *qproc, 
> int *current_perm,
>  static int q6v5_load(struct rproc *rproc, const struct firmware *fw)
>  {
>   struct q6v5 *qproc = rproc->priv;
> + const struct firmware *dp_fw;
> +
> + if (!request_firmware(_fw, "msadp", qproc->dev) && fw->size <= 
> SZ_1M) {

Can we change this to a request_firmware_direct() to avoid the fact that
as written here devices lacking this file will pause here for 60 seconds
waiting for userspace to assist in loading it (which at least none of my
systems do).

I also think that while it's nice to check that fw->size <= SZ_1M, to
avoid overwriting the tail of it, you should check that SZ_1M +
dp_fw->size < mba_size. To ensure that the memcpy doesn't go out of
bounds.

> + memcpy(qproc->mba_region + SZ_1M, dp_fw->data, dp_fw->size);
> + qproc->dp_size = dp_fw->size;
> + release_firmware(dp_fw);
> + }
>  
>   memcpy(qproc->mba_region, fw->data, fw->size);
>  
> @@ -896,6 +904,10 @@ static int q6v5_mba_load(struct q6v5 *qproc)
>   }
>  
>   writel(qproc->mba_phys, qproc->rmb_base + RMB_MBA_IMAGE_REG);
> + if (qproc->dp_size) {
> + writel(qproc->mba_phys + SZ_1M, qproc->rmb_base + 
> RMB_PMI_CODE_START_REG);
> + writel(qproc->dp_size, qproc->rmb_base + 
> RMB_PMI_CODE_LENGTH_REG);
> + }
>  
>   ret = q6v5proc_reset(qproc);
>   if (ret)
> @@ -1258,7 +1270,8 @@ static int q6v5_start(struct rproc *rproc)
>   if (ret)
>   return ret;
>  
> - dev_info(qproc->dev, "MBA booted, loading mpss\n");
> + dev_info(qproc->dev, "MBA booted, debug policy %s, loading mpss\n",
> +  qproc->dp_size ? "enabled" : "disabled");

"MBA booted with%s debug policy, loading mpss\n", qproc->dp_size ? "" : "out"

Please.

Regards,
Bjorn

>  
>   ret = q6v5_mpss_load(qproc);
>   if (ret)
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 

Re: [RFC PATCH v3 16/18] gpu: host1x: mipi: Split tegra_mipi_calibrate and tegra_mipi_wait

[Sowjanya Komatineni]

On 7/16/20 5:16 PM, Sowjanya Komatineni wrote:


On 7/16/20 4:47 PM, Dmitry Osipenko wrote:

17.07.2020 02:09, Sowjanya Komatineni пишет:

On 7/16/20 4:06 PM, Sowjanya Komatineni wrote:

On 7/16/20 4:01 PM, Dmitry Osipenko wrote:

17.07.2020 01:49, Sowjanya Komatineni пишет:

What keeps MIPI clock enabled after completion of the
tegra_mipi_calibrate() invocation?
MIPI clock is disabled at end of tegra_mipi_calibrate and is 
re-enabled

during tegra_mipi_wait.

I think I should fix this to keep the clock enabled till calibration
results are latched.

All consumers of tegra_mipi_calibrate() will call tegra_mipi_wait().

So will remove clk_disable mipi clk at end of tegra_mipi_calibrate()
and
clk_enable mipi_clk at beginning of tegra_mipi_wait()

Isn't it possible to perform the calibration after enabling CSI and
before of starting the sensor streaming?

Currently this is what I am doing. Triggering calibration start during
CSI receiver being ready and then sensor streaming will happen where
internal MIPI CAL detects for LP -> HS transition and applies results
to pads. So checking for calibration results after sensor stream is
enabled

1. Calling tegra_mipi_calibrate() during CSI streaming where CSI pads
are enabled and receiver is kept ready

2. Start Sensor stream

3. Calling tegra_mipi_wait() to check for MIPI Cal status.

So as mipi cal clk need to be kept enabled till 3rd step, we can enable
clock during tegra_mipi_calibrate() and leave it enabled and disable it
in tegra_mipi_wait after status check.

 From TRM:

The following sequence is recommended for capturing a single frame:

1. Set up CSI registers for use case such as number of lanes, virtual
channel, etc.
2. Initialize and power up CSI interface
3. Wait for initialization time or done signal from calibration logic
4. Power up camera through the I2C interface
5. All CSI data and clock lanes are in stop state, LP11
6. Initiate frame capture through the I2C
7. Frame done, CSI goes back to stop state, LP11

Hence, is it really necessary to perform the manual calibration?


done signal from calibration logic will happen only when it sees LP to 
HS transition as thats when calibration results are applied to pads 
and then done signal is set.


Also MIPI Pads calibration need to be done on every power off/on. So 
need to do calibration and trigger it along with CSI receiver 
programming to keep it ready and then need to check/wait for status 
only after sensor stream happens as thats where LP->HS transition happen.


Looks like sequence posted in TRM need to be updated clearly for proper 
MIPI CAL start and wait.


Correct steps should be like below

1. Set up CSI registers for use case such as number of lanes, virtual  
channel, etc.

2. Initialize and power up CSI CIL interface
3. Program MIPI CAL bias pads, cal configs, cal control registers and 
enable calibration start
4. Power up camera through the I2C interface and start sensor streaming 
through the I2C


Note: All sensors might not leave pads in LP-11 state as sensor may be 
power down when not in use.


So start streaming prior to checking for calibration done status as 
LP-11 -> HS transition happens during sensor stream and calibration 
logic can apply results to pads and update done status,


5. Wait for done signal from calibration logic

6. perform frame capture thru VI
7. Frame done, CSI goes back to stop state, LP11

Will work internally to correct sequence in TRM ...


In mipi driver will update as below to have mipi clk enabled till 
calibration status check is done.


Always tegra_mipi_wait() followes tegra_mipi_calibrate() in both DSI and 
CSI. So below sequence should work good.


tegra_mipi_calibrate()

- clk_enable mipi cal
- program mipi cal registers (bias pads cfgs, mipi cal ctrl and trigger 
calibration start)


tegra_mipi_wait()
- read mipi cal status and wait for active and done bits
- clk_disable mipi cal

Thanks

Sowjanya

Re: [PATCH][next] i2c: digicolor: Use fallthrough pseudo-keyword

[Baruch Siach]

Hi Gustavo,

On Thu, Jul 16, 2020 at 05:00:55PM -0500, Gustavo A. R. Silva wrote:
> Replace the existing /* fall through */ comments and its variants with
> the new pseudo-keyword macro fallthrough[1].
> 
> [1] 
> https://www.kernel.org/doc/html/latest/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through

This URL is likely to break at some point as documentation contest changes. 
Just refer to in kernel Documentation/process/deprecated.rst file.

Other than that:

Acked-by: Baruch Siach 

Thanks,
baruch

> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/i2c/busses/i2c-digicolor.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/i2c/busses/i2c-digicolor.c 
> b/drivers/i2c/busses/i2c-digicolor.c
> index 332f00437479..f67639dc74b7 100644
> --- a/drivers/i2c/busses/i2c-digicolor.c
> +++ b/drivers/i2c/busses/i2c-digicolor.c
> @@ -187,7 +187,7 @@ static irqreturn_t dc_i2c_irq(int irq, void *dev_id)
>   break;
>   }
>   i2c->state = STATE_WRITE;
> - /* fall through */
> + fallthrough;
>   case STATE_WRITE:
>   if (i2c->msgbuf_ptr < i2c->msg->len)
>   dc_i2c_write_buf(i2c);

-- 
 ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

Re: [PATCH v3 00/12] ima: Fix rule parsing bugs and extend KEXEC_CMDLINE rule support

[Tyler Hicks]

On 2020-07-17 00:31:33, Mimi Zohar wrote:
> On Thu, 2020-07-09 at 01:18 -0500, Tyler Hicks wrote:
> > This series ultimately extends the supported IMA rule conditionals for
> > the KEXEC_CMDLINE hook function. As of today, there's an imbalance in
> > IMA language conditional support for KEXEC_CMDLINE rules in comparison
> > to KEXEC_KERNEL_CHECK and KEXEC_INITRAMFS_CHECK rules. The KEXEC_CMDLINE
> > rules do not support *any* conditionals so you cannot have a sequence of
> > rules like this:
> > 
> >  dont_measure func=KEXEC_KERNEL_CHECK obj_type=foo_t
> >  dont_measure func=KEXEC_INITRAMFS_CHECK obj_type=foo_t
> >  dont_measure func=KEXEC_CMDLINE obj_type=foo_t
> >  measure func=KEXEC_KERNEL_CHECK
> >  measure func=KEXEC_INITRAMFS_CHECK
> >  measure func=KEXEC_CMDLINE
> > 
> > Instead, KEXEC_CMDLINE rules can only be measured or not measured and
> > there's no additional flexibility in today's implementation of the
> > KEXEC_CMDLINE hook function.
> > 
> > With this series, the above sequence of rules becomes valid and any
> > calls to kexec_file_load() with a kernel and initramfs inode type of
> > foo_t will not be measured (that includes the kernel cmdline buffer)
> > while all other objects given to a kexec_file_load() syscall will be
> > measured. There's obviously not an inode directly associated with the
> > kernel cmdline buffer but this patch series ties the inode based
> > decision making for KEXEC_CMDLINE to the kernel's inode. I think this
> > will be intuitive to policy authors.
> > 
> > While reading IMA code and preparing to make this change, I realized
> > that the buffer based hook functions (KEXEC_CMDLINE and KEY_CHECK) are
> > quite special in comparison to longer standing hook functions. These
> > buffer based hook functions can only support measure actions and there
> > are some restrictions on the conditionals that they support. However,
> > the rule parser isn't enforcing any of those restrictions and IMA policy
> > authors wouldn't have any immediate way of knowing that the policy that
> > they wrote is invalid. For example, the sequence of rules above parses
> > successfully in today's kernel but the
> > "dont_measure func=KEXEC_CMDLINE ..." rule is incorrectly handled in
> > ima_match_rules(). The dont_measure rule is *always* considered to be a
> > match so, surprisingly, no KEXEC_CMDLINE measurements are made.
> > 
> > While making the rule parser more strict, I realized that the parser
> > does not correctly free all of the allocated memory associated with an
> > ima_rule_entry when going down some error paths. Invalid policy loaded
> > by the policy administrator could result in small memory leaks.
> > 
> > I envision patches 1-7 going to stable. The series is ordered in a way
> > that has all the fixes up front, followed by cleanups, followed by the
> > feature patch. The breakdown of patches looks like so:
> > 
> >  Memory leak fixes: 1-3
> >  Parser strictness fixes: 4-7
> >  Code cleanups made possible by the fixes: 8-11
> >  Extend KEXEC_CMDLINE rule support: 12
> 
> Thanks, Tyler.  This is a really nice patch set.  The patches are now
> in the "next-integrity-testing" branch.

Thank you for all the helpful review comments. You know where to find me
if any bugs pop up during testing. :)

Tyler

> 
> Mimi

Re: [PATCH v3 03/12] powerpc/kexec_file: add helper functions for getting memory ranges

[Hari Bathini]

On 15/07/20 5:19 am, Thiago Jung Bauermann wrote:
> 
> Hello Hari,
> 
> Hari Bathini  writes:
> 
>> In kexec case, the kernel to be loaded uses the same memory layout as
>> the running kernel. So, passing on the DT of the running kernel would
>> be good enough.
>>
>> But in case of kdump, different memory ranges are needed to manage
>> loading the kdump kernel, booting into it and exporting the elfcore
>> of the crashing kernel. The ranges are exlude memory ranges, usable
> 
> s/exlude/exclude/
> 
>> memory ranges, reserved memory ranges and crash memory ranges.
>>
>> Exclude memory ranges specify the list of memory ranges to avoid while
>> loading kdump segments. Usable memory ranges list the memory ranges
>> that could be used for booting kdump kernel. Reserved memory ranges
>> list the memory regions for the loading kernel's reserve map. Crash
>> memory ranges list the memory ranges to be exported as the crashing
>> kernel's elfcore.
>>
>> Add helper functions for setting up the above mentioned memory ranges.
>> This helpers facilitate in understanding the subsequent changes better
>> and make it easy to setup the different memory ranges listed above, as
>> and when appropriate.
>>
>> Signed-off-by: Hari Bathini 
>> Tested-by: Pingfan Liu 
> 



>> +/**
>> + * add_reserved_ranges - Adds "/reserved-ranges" regions exported by f/w
>> + *   to the given memory ranges list.
>> + * @mem_ranges:  Range list to add the memory ranges to.
>> + *
>> + * Returns 0 on success, negative errno on error.
>> + */
>> +int add_reserved_ranges(struct crash_mem **mem_ranges)
>> +{
>> +int i, len, ret = 0;
>> +const __be32 *prop;
>> +
>> +prop = of_get_property(of_root, "reserved-ranges", );
>> +if (!prop)
>> +return 0;
>> +
>> +/*
>> + * Each reserved range is an (address,size) pair, 2 cells each,
>> + * totalling 4 cells per range.
> 
> Can you assume that, or do you need to check the #address-cells and
> #size-cells properties of the root node?

Taken from early_reserve_mem_dt() which did not seem to care.
Should we be doing any different here?

Thanks
Hari

Re: [PATCH v3 00/12] ima: Fix rule parsing bugs and extend KEXEC_CMDLINE rule support

[Mimi Zohar]

On Thu, 2020-07-09 at 01:18 -0500, Tyler Hicks wrote:
> This series ultimately extends the supported IMA rule conditionals for
> the KEXEC_CMDLINE hook function. As of today, there's an imbalance in
> IMA language conditional support for KEXEC_CMDLINE rules in comparison
> to KEXEC_KERNEL_CHECK and KEXEC_INITRAMFS_CHECK rules. The KEXEC_CMDLINE
> rules do not support *any* conditionals so you cannot have a sequence of
> rules like this:
> 
>  dont_measure func=KEXEC_KERNEL_CHECK obj_type=foo_t
>  dont_measure func=KEXEC_INITRAMFS_CHECK obj_type=foo_t
>  dont_measure func=KEXEC_CMDLINE obj_type=foo_t
>  measure func=KEXEC_KERNEL_CHECK
>  measure func=KEXEC_INITRAMFS_CHECK
>  measure func=KEXEC_CMDLINE
> 
> Instead, KEXEC_CMDLINE rules can only be measured or not measured and
> there's no additional flexibility in today's implementation of the
> KEXEC_CMDLINE hook function.
> 
> With this series, the above sequence of rules becomes valid and any
> calls to kexec_file_load() with a kernel and initramfs inode type of
> foo_t will not be measured (that includes the kernel cmdline buffer)
> while all other objects given to a kexec_file_load() syscall will be
> measured. There's obviously not an inode directly associated with the
> kernel cmdline buffer but this patch series ties the inode based
> decision making for KEXEC_CMDLINE to the kernel's inode. I think this
> will be intuitive to policy authors.
> 
> While reading IMA code and preparing to make this change, I realized
> that the buffer based hook functions (KEXEC_CMDLINE and KEY_CHECK) are
> quite special in comparison to longer standing hook functions. These
> buffer based hook functions can only support measure actions and there
> are some restrictions on the conditionals that they support. However,
> the rule parser isn't enforcing any of those restrictions and IMA policy
> authors wouldn't have any immediate way of knowing that the policy that
> they wrote is invalid. For example, the sequence of rules above parses
> successfully in today's kernel but the
> "dont_measure func=KEXEC_CMDLINE ..." rule is incorrectly handled in
> ima_match_rules(). The dont_measure rule is *always* considered to be a
> match so, surprisingly, no KEXEC_CMDLINE measurements are made.
> 
> While making the rule parser more strict, I realized that the parser
> does not correctly free all of the allocated memory associated with an
> ima_rule_entry when going down some error paths. Invalid policy loaded
> by the policy administrator could result in small memory leaks.
> 
> I envision patches 1-7 going to stable. The series is ordered in a way
> that has all the fixes up front, followed by cleanups, followed by the
> feature patch. The breakdown of patches looks like so:
> 
>  Memory leak fixes: 1-3
>  Parser strictness fixes: 4-7
>  Code cleanups made possible by the fixes: 8-11
>  Extend KEXEC_CMDLINE rule support: 12

Thanks, Tyler.  This is a really nice patch set.  The patches are now
in the "next-integrity-testing" branch.

Mimi

Re: [PATCH v5 6/6] MAINTAINERS: Add maintainers for MIPS core drivers

[Daniel Lezcano]

On 14/07/2020 14:57, Serge Semin wrote:
> Add Thomas and myself as maintainers of the MIPS CPU and GIC IRQchip, MIPS
> GIC timer and MIPS CPS CPUidle drivers.
> 
> Signed-off-by: Serge Semin 
> Acked-by: Marc Zyngier 

Acked-by: Daniel Lezcano 

> ---
> 
> Changelog v3:
> - Keep the files list alphabetically ordered.
> - Add Thomas as the co-maintainer of the designated drivers.
> ---
>  MAINTAINERS | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2926327e4976..20532e0287d7 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11278,6 +11278,17 @@ F:   arch/mips/configs/generic/board-boston.config
>  F:   drivers/clk/imgtec/clk-boston.c
>  F:   include/dt-bindings/clock/boston-clock.h
>  
> +MIPS CORE DRIVERS
> +M:   Thomas Bogendoerfer 
> +M:   Serge Semin 
> +L:   linux-m...@vger.kernel.org
> +S:   Supported
> +F:   drivers/bus/mips_cdmm.c
> +F:   drivers/clocksource/mips-gic-timer.c
> +F:   drivers/cpuidle/cpuidle-cps.c
> +F:   drivers/irqchip/irq-mips-cpu.c
> +F:   drivers/irqchip/irq-mips-gic.c
> +
>  MIPS GENERIC PLATFORM
>  M:   Paul Burton 
>  L:   linux-m...@vger.kernel.org
> 


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

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH v3 0/3] Off-load TLB invalidations to host for !GTSE

[Bharata B Rao]

On Fri, Jul 17, 2020 at 12:44:00PM +1000, Nicholas Piggin wrote:
> Excerpts from Nicholas Piggin's message of July 17, 2020 12:08 pm:
> > Excerpts from Qian Cai's message of July 17, 2020 3:27 am:
> >> On Fri, Jul 03, 2020 at 11:06:05AM +0530, Bharata B Rao wrote:
> >>> Hypervisor may choose not to enable Guest Translation Shootdown Enable
> >>> (GTSE) option for the guest. When GTSE isn't ON, the guest OS isn't
> >>> permitted to use instructions like tblie and tlbsync directly, but is
> >>> expected to make hypervisor calls to get the TLB flushed.
> >>> 
> >>> This series enables the TLB flush routines in the radix code to
> >>> off-load TLB flushing to hypervisor via the newly proposed hcall
> >>> H_RPT_INVALIDATE. 
> >>> 
> >>> To easily check the availability of GTSE, it is made an MMU feature.
> >>> The OV5 handling and H_REGISTER_PROC_TBL hcall are changed to
> >>> handle GTSE as an optionally available feature and to not assume GTSE
> >>> when radix support is available.
> >>> 
> >>> The actual hcall implementation for KVM isn't included in this
> >>> patchset and will be posted separately.
> >>> 
> >>> Changes in v3
> >>> =
> >>> - Fixed a bug in the hcall wrapper code where we were missing setting
> >>>   H_RPTI_TYPE_NESTED while retrying the failed flush request with
> >>>   a full flush for the nested case.
> >>> - s/psize_to_h_rpti/psize_to_rpti_pgsize
> >>> 
> >>> v2: 
> >>> https://lore.kernel.org/linuxppc-dev/20200626131000.5207-1-bhar...@linux.ibm.com/T/#t
> >>> 
> >>> Bharata B Rao (2):
> >>>   powerpc/mm: Enable radix GTSE only if supported.
> >>>   powerpc/pseries: H_REGISTER_PROC_TBL should ask for GTSE only if
> >>> enabled
> >>> 
> >>> Nicholas Piggin (1):
> >>>   powerpc/mm/book3s64/radix: Off-load TLB invalidations to host when
> >>> !GTSE
> >> 
> >> Reverting the whole series fixed random memory corruptions during boot on
> >> POWER9 PowerNV systems below.
> > 
> > If I s/mmu_has_feature(MMU_FTR_GTSE)/(1)/g in radix_tlb.c, then the .o
> > disasm is the same as reverting my patch.
> > 
> > Feature bits not being set right? PowerNV should be pretty simple, seems
> > to do the same as FTR_TYPE_RADIX.
> 
> Might need this fix
> 
> ---
> 
> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
> index 9cc49f265c86..54c9bcea9d4e 100644
> --- a/arch/powerpc/kernel/prom.c
> +++ b/arch/powerpc/kernel/prom.c
> @@ -163,7 +163,7 @@ static struct ibm_pa_feature {
>   { .pabyte = 0,  .pabit = 6, .cpu_features  = CPU_FTR_NOEXECUTE },
>   { .pabyte = 1,  .pabit = 2, .mmu_features  = MMU_FTR_CI_LARGE_PAGE },
>  #ifdef CONFIG_PPC_RADIX_MMU
> - { .pabyte = 40, .pabit = 0, .mmu_features  = MMU_FTR_TYPE_RADIX },
> + { .pabyte = 40, .pabit = 0, .mmu_features  = (MMU_FTR_TYPE_RADIX | 
> MMU_FTR_GTSE) },
>  #endif
>   { .pabyte = 1,  .pabit = 1, .invert = 1, .cpu_features = 
> CPU_FTR_NODSISRALIGN },
>   { .pabyte = 5,  .pabit = 0, .cpu_features  = CPU_FTR_REAL_LE,

Michael - Let me know if this should be folded into 1/3 and the complete
series resent.

Regards,
Bharata.

Re: [PATCH v4 00/16] Allwinner A100 Initial support

[Daniel Lezcano]

On 14/07/2020 08:55, Frank Lee wrote:
> From: Yangtao Li 

Do you expect me to pick patches 7,8,9 or ack them ?

> v4:
> -drop "dt-bindings: pinctrl: sunxi: make gpio banks supplies required"
> -fix dcdc1 regulator name
> -get rid of underscore in dts node name
> -Some trivial things in yaml files
> 
> v3:
> -Add pmu and nmi support
> -Add read data mask for calibration
> -Code style
> -Some trivial things in yaml files
> 
> v2:
> -Some naming consistency
> -Repair email address
> -Fix mmc clock
> -Don't export system clock
> -Fix checkpatch warning
> -Drop unneeded pin function, convert to jtag_gpu and i2s_x
> 
> Yangtao Li (16):
>   dt-bindings: clk: sunxi-ccu: add compatible string for A100 CCU and
> R-CCU
>   clk: sunxi-ng: add support for the Allwinner A100 CCU
>   dt-bindings: pinctrl: sunxi: Get rid of continual nesting
>   dt-bindings: pinctrl: sunxi: Add A100 pinctrl bindings
>   pinctrl: sunxi: add support for the Allwinner A100 pin controller
>   dt-bindings: nvmem: SID: add binding for A100's SID controller
>   dt-bindings: thermal: sun8i: Add binding for A100's THS controller
>   thermal: sun8i: add TEMP_CALIB_MASK for calibration data in
> sun50i_h6_ths_calibrate
>   thermal: sun8i: Add A100's THS controller support
>   mfd: axp20x: Allow the AXP803 to be probed by I2C
>   dt-bindings: irq: sun7i-nmi: fix dt-binding for a80 nmi
>   dt-bindings: irq: sun7i-nmi: Add binding for A100's NMI controller
>   dt-bindings: i2c: mv64xxx: Add compatible for the A100 i2c node.
>   arm64: allwinner: A100: add the basical Allwinner A100 DTSI file
>   dt-bindings: arm: sunxi: Add Allwinner A100 Perf1 Board bindings
>   arm64: allwinner: A100: add support for Allwinner Perf1 board
> 
>  .../devicetree/bindings/arm/sunxi.yaml|5 +
>  .../clock/allwinner,sun4i-a10-ccu.yaml|7 +-
>  .../bindings/i2c/marvell,mv64xxx-i2c.yaml |3 +
>  .../allwinner,sun7i-a20-sc-nmi.yaml   |5 +-
>  .../nvmem/allwinner,sun4i-a10-sid.yaml|   19 +-
>  .../pinctrl/allwinner,sun4i-a10-pinctrl.yaml  |  139 +-
>  .../thermal/allwinner,sun8i-a83t-ths.yaml |6 +-
>  arch/arm64/boot/dts/allwinner/Makefile|1 +
>  .../allwinner/sun50i-a100-allwinner-perf1.dts |  180 +++
>  .../arm64/boot/dts/allwinner/sun50i-a100.dtsi |  364 +
>  drivers/clk/sunxi-ng/Kconfig  |   10 +
>  drivers/clk/sunxi-ng/Makefile |2 +
>  drivers/clk/sunxi-ng/ccu-sun50i-a100-r.c  |  214 +++
>  drivers/clk/sunxi-ng/ccu-sun50i-a100-r.h  |   21 +
>  drivers/clk/sunxi-ng/ccu-sun50i-a100.c| 1276 +
>  drivers/clk/sunxi-ng/ccu-sun50i-a100.h|   56 +
>  drivers/mfd/axp20x-i2c.c  |2 +
>  drivers/pinctrl/sunxi/Kconfig |   10 +
>  drivers/pinctrl/sunxi/Makefile|2 +
>  drivers/pinctrl/sunxi/pinctrl-sun50i-a100-r.c |  105 ++
>  drivers/pinctrl/sunxi/pinctrl-sun50i-a100.c   |  708 +
>  drivers/thermal/sun8i_thermal.c   |   16 +-
>  include/dt-bindings/clock/sun50i-a100-ccu.h   |  116 ++
>  include/dt-bindings/clock/sun50i-a100-r-ccu.h |   23 +
>  include/dt-bindings/reset/sun50i-a100-ccu.h   |   68 +
>  include/dt-bindings/reset/sun50i-a100-r-ccu.h |   18 +
>  26 files changed, 3308 insertions(+), 68 deletions(-)
>  create mode 100644 
> arch/arm64/boot/dts/allwinner/sun50i-a100-allwinner-perf1.dts
>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
>  create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-a100-r.c
>  create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-a100-r.h
>  create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-a100.c
>  create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-a100.h
>  create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-a100-r.c
>  create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-a100.c
>  create mode 100644 include/dt-bindings/clock/sun50i-a100-ccu.h
>  create mode 100644 include/dt-bindings/clock/sun50i-a100-r-ccu.h
>  create mode 100644 include/dt-bindings/reset/sun50i-a100-ccu.h
>  create mode 100644 include/dt-bindings/reset/sun50i-a100-r-ccu.h
> 


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

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH v4 08/16] thermal: sun8i: add TEMP_CALIB_MASK for calibration data in sun50i_h6_ths_calibrate

[Daniel Lezcano]

On 14/07/2020 09:13, Frank Lee wrote:
> From: Yangtao Li 
> 
> For sun50i_h6_ths_calibrate(), the data read from nvmem needs a round of
> calculation. On the other hand, the newer SOC may store other data in
> the space other than 12bit sensor data. Add mask operation to read data
> to avoid conversion error.
> 
> Signed-off-by: Yangtao Li 
> Reviewed-by: Yangtao Li 

Can you clarify these SoB ?

Frank Lee==Yangtao Li==fr...@allwinnertech.com==tiny.win...@gmail.com ?



> ---
>  drivers/thermal/sun8i_thermal.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/thermal/sun8i_thermal.c b/drivers/thermal/sun8i_thermal.c
> index 74d73be16496..f423d44b9290 100644
> --- a/drivers/thermal/sun8i_thermal.c
> +++ b/drivers/thermal/sun8i_thermal.c
> @@ -244,7 +244,7 @@ static int sun50i_h6_ths_calibrate(struct ths_device 
> *tmdev,
>   ft_temp = (caldata[0] & FT_TEMP_MASK) * 100;
>  
>   for (i = 0; i < tmdev->chip->sensor_num; i++) {
> - int sensor_reg = caldata[i + 1];
> + int sensor_reg = caldata[i + 1] & TEMP_CALIB_MASK;
>   int cdata, offset;
>   int sensor_temp = tmdev->chip->calc_temp(tmdev, i, sensor_reg);
>  
> 


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

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH v4 04/10] powerpc/watchpoint: Enable watchpoint functionality on power10 guest

[Jordan Niethe]

On Fri, Jul 17, 2020 at 2:10 PM Ravi Bangoria
 wrote:
>
> CPU_FTR_DAWR is by default enabled for host via CPU_FTRS_DT_CPU_BASE
> (controlled by CONFIG_PPC_DT_CPU_FTRS). But cpu-features device-tree
> node is not PAPR compatible and thus not yet used by kvm or pHyp
> guests. Enable watchpoint functionality on power10 guest (both kvm
> and powervm) by adding CPU_FTR_DAWR to CPU_FTRS_POWER10. Note that
> this change does not enable 2nd DAWR support.
>
> Signed-off-by: Ravi Bangoria 
I ran the ptrace-hwbreak selftest successfully within a power10 kvm guest.
Tested-by: Jordan Niethe 
> ---
>  arch/powerpc/include/asm/cputable.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/include/asm/cputable.h 
> b/arch/powerpc/include/asm/cputable.h
> index bac2252c839e..e506d429b1af 100644
> --- a/arch/powerpc/include/asm/cputable.h
> +++ b/arch/powerpc/include/asm/cputable.h
> @@ -478,7 +478,7 @@ static inline void cpu_feature_keys_init(void) { }
> CPU_FTR_CFAR | CPU_FTR_HVMODE | CPU_FTR_VMX_COPY | \
> CPU_FTR_DBELL | CPU_FTR_HAS_PPR | CPU_FTR_ARCH_207S | \
> CPU_FTR_TM_COMP | CPU_FTR_ARCH_300 | CPU_FTR_PKEY | \
> -   CPU_FTR_ARCH_31)
> +   CPU_FTR_ARCH_31 | CPU_FTR_DAWR)
>  #define CPU_FTRS_CELL  (CPU_FTR_LWSYNC | \
> CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
> CPU_FTR_ALTIVEC_COMP | CPU_FTR_MMCRA | CPU_FTR_SMT | \
> --
> 2.26.2
>

Re: [PATCH v6 2/2] clocksource: Ingenic: Add support for the Ingenic X1000 OST.

[Daniel Lezcano]

On 10/07/2020 19:02, 周琰杰 (Zhou Yanjie) wrote:
> X1000 and SoCs after X1000 (such as X1500 and X1830) had a separate
> OST, it no longer belongs to TCU. This driver will register both a
> clocksource and a sched_clock to the system.
> 
> Tested-by: 周正 (Zhou Zheng) 
> Co-developed-by: 漆鹏振 (Qi Pengzhen) 
> Signed-off-by: 漆鹏振 (Qi Pengzhen) 
> Signed-off-by: 周琰杰 (Zhou Yanjie) 
> Reviewed-by: Paul Cercueil 
> ---
> 
> Notes:
> v1->v2:
> Fix compile warnings.
> Reported-by: kernel test robot 
> 
> v2->v3:
> No change.
> 
> v3->v4:
> 1.Rename "ost" to "sysost"
> 1.Remove unrelated changes.
> 2.Remove ost_clock_parent enum.
> 3.Remove ost->percpu_timer_channel/ost->global_timer_channel.
> 4.Set up independent .recalc_rate/.set_rate for percpu/global timer.
> 5.No longer call functions in variable declarations.
> 
> v4->v5:
> Use "of_io_request_and_map()" instead "of_iomap()".
> Suggested-by: Paul Cercueil 
> 
> v5->v6:
> No change.
> 
>  drivers/clocksource/Kconfig  |  11 +
>  drivers/clocksource/Makefile |   1 +
>  drivers/clocksource/ingenic-sysost.c | 539 
> +++
>  3 files changed, 551 insertions(+)
>  create mode 100644 drivers/clocksource/ingenic-sysost.c
> 
> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> index 91418381fcd4..1bca8b8fb30f 100644
> --- a/drivers/clocksource/Kconfig
> +++ b/drivers/clocksource/Kconfig
> @@ -696,6 +696,17 @@ config INGENIC_TIMER
>   help
> Support for the timer/counter unit of the Ingenic JZ SoCs.
>  
> +config INGENIC_SYSOST
> + bool "Clocksource/timer using the SYSOST in Ingenic X SoCs"

We usually use silent options and let the platform's Kconfig enable it.
We show up the option only when COMPILE_TEST is enabled.

Is there a reason to do it differently?

> + default MACH_INGENIC
> + depends on MIPS || COMPILE_TEST
> + depends on COMMON_CLK
> + select MFD_SYSCON
> + select TIMER_OF
> + select IRQ_DOMAIN
> + help
> +   Support for the SYSOST of the Ingenic X Series SoCs.
> +

[ ... ]


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

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: INFO: rcu detected stall in tipc_release

[syzbot]

syzbot has bisected this issue to:

commit 5e9eeccc58f3e6bcc99b929670665d2ce047e9c9
Author: Tuong Lien 
Date:   Wed Jun 3 05:06:01 2020 +

tipc: fix NULL pointer dereference in streaming

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=1464162090
start commit:   7cc2a8ea Merge tag 'block-5.8-2020-07-01' of git://git.ker..
git tree:   upstream
final oops: https://syzkaller.appspot.com/x/report.txt?x=1664162090
console output: https://syzkaller.appspot.com/x/log.txt?x=1264162090
kernel config:  https://syzkaller.appspot.com/x/.config?x=7be693511b29b338
dashboard link: https://syzkaller.appspot.com/bug?extid=3654c027d861c6df4b06
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=1294823310
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=11344c0510

Reported-by: syzbot+3654c027d861c6df4...@syzkaller.appspotmail.com
Fixes: 5e9eeccc58f3 ("tipc: fix NULL pointer dereference in streaming")

For information about bisection process see: https://goo.gl/tpsmEJ#bisection

Re: [PATCH v3 06/12] ppc64/kexec_file: restrict memory usage of kdump kernel

[Hari Bathini]

On 17/07/20 3:33 am, Thiago Jung Bauermann wrote:
> 
> Hari Bathini  writes:
> 
>> On 16/07/20 4:22 am, Thiago Jung Bauermann wrote:
>>>
>>> Hari Bathini  writes:
>>>


 
 +   * each representing a memory range.
 +   */
 +  ranges = (len >> 2) / (n_mem_addr_cells + n_mem_size_cells);
 +
 +  for (i = 0; i < ranges; i++) {
 +  base = of_read_number(prop, n_mem_addr_cells);
 +  prop += n_mem_addr_cells;
 +  end = base + of_read_number(prop, n_mem_size_cells) - 1;
>>
>> prop is not used after the above.
>>
>>> You need to `prop += n_mem_size_cells` here.
>>
>> But yeah, adding it would make it look complete in some sense..
> 
> Isn't it used in the next iteration of the loop?

Memory@XXX/reg typically has only one range. I was looking at it
from that perspective which is not right. Will update.

Thanks
Hari

Re: [PATCH] net: ethernet: ave: Fix error returns in ave_init

[Kunihiko Hayashi]

Hi Wang,

On 2020/07/17 11:50, Wang Hai wrote:

When regmap_update_bits failed in ave_init(), calls of the functions
reset_control_assert() and clk_disable_unprepare() were missed.
Add goto out_reset_assert to do this.

Fixes: 57878f2f4697 ("net: ethernet: ave: add support for phy-mode setting of system 
controller")
Reported-by: Hulk Robot 
Signed-off-by: Wang Hai 
---
  drivers/net/ethernet/socionext/sni_ave.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/socionext/sni_ave.c 
b/drivers/net/ethernet/socionext/sni_ave.c
index f2638446b62e..81b554dd7221 100644
--- a/drivers/net/ethernet/socionext/sni_ave.c
+++ b/drivers/net/ethernet/socionext/sni_ave.c
@@ -1191,7 +1191,7 @@ static int ave_init(struct net_device *ndev)
ret = regmap_update_bits(priv->regmap, SG_ETPINMODE,
 priv->pinmode_mask, priv->pinmode_val);
if (ret)
-   return ret;
+   goto out_reset_assert;
  
  	ave_global_reset(ndev);
  



Thank you for pointing out.

Reviewed-by: Kunihiko Hayashi 

---
Best Regards
Kunihiko Hayashi

Re: [PATCH] usb: gadget: configfs: Fix use-after-free issue with udc_name

[Peter Chen]

On 20-07-16 14:41:06, Macpaul Lin wrote:
> There is a use-after-free issue, if access udc_name
> in function gadget_dev_desc_UDC_store after another context
> free udc_name in function unregister_gadget.
> 
> Contex 1:

%s/contex/context

> gadget_dev_desc_UDC_store()->unregister_gadget()->
> free udc_name->set udc_name to NULL
> 
> Contex 2:

The same, otherwise:

Reviewed-by: Peter Chen 

Peter

> gadget_dev_desc_UDC_show()-> access udc_name
> 
> Call trace:
> dump_backtrace+0x0/0x340
> show_stack+0x14/0x1c
> dump_stack+0xe4/0x134
> print_address_description+0x78/0x478
> __kasan_report+0x270/0x2ec
> kasan_report+0x10/0x18
> __asan_report_load1_noabort+0x18/0x20
> string+0xf4/0x138
> vsnprintf+0x428/0x14d0
> sprintf+0xe4/0x12c
> gadget_dev_desc_UDC_show+0x54/0x64
> configfs_read_file+0x210/0x3a0
> __vfs_read+0xf0/0x49c
> vfs_read+0x130/0x2b4
> SyS_read+0x114/0x208
> el0_svc_naked+0x34/0x38
> 
> Add mutex_lock to protect this kind of scenario.

> 
> Signed-off-by: Eddie Hung 
> Signed-off-by: Macpaul Lin 
> Cc: sta...@vger.kernel.org
> ---
>  drivers/usb/gadget/configfs.c | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
> index 9dc06a4e1b30..21110b2865b9 100644
> --- a/drivers/usb/gadget/configfs.c
> +++ b/drivers/usb/gadget/configfs.c
> @@ -221,9 +221,16 @@ static ssize_t gadget_dev_desc_bcdUSB_store(struct 
> config_item *item,
>  
>  static ssize_t gadget_dev_desc_UDC_show(struct config_item *item, char *page)
>  {
> - char *udc_name = to_gadget_info(item)->composite.gadget_driver.udc_name;
> + struct gadget_info *gi = to_gadget_info(item);
> + char *udc_name;
> + int ret;
> +
> + mutex_lock(>lock);
> + udc_name = gi->composite.gadget_driver.udc_name;
> + ret = sprintf(page, "%s\n", udc_name ?: "");
> + mutex_unlock(>lock);
>  
> - return sprintf(page, "%s\n", udc_name ?: "");
> + return ret;
>  }
>  
>  static int unregister_gadget(struct gadget_info *gi)
> -- 
> 2.18.0

-- 

Thanks,
Peter Chen

Re: [PATCH v6 0/9] clocksource/drivers/timer-atmel-tcb: add sama5d2 support

[Daniel Lezcano]

On 11/07/2020 01:08, Alexandre Belloni wrote:
> Hello,
> 
> This series mainly adds sama5d2 support where we need to avoid using
> clock index 0 because that clock is never enabled by the driver.
> 
> There is also a rework of the 32khz clock handling so it is not used for
> clockevents on 32 bit counter because the increased rate improves the
> resolution and doesn't have any drawback with that counter width. This
> replaces a patch that has been carried in the linux-rt tree for a while.
> 
> Changes in v6:
>  - Added final Rob's Reviewed by, based on:
>https://lore.kernel.org/linux-arm-kernel/20200709210543.GA884561@bogus/
>  - fixed the clockevent periodic rate

Applied, thanks

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

Follow Linaro:   Facebook |
 Twitter |
 Blog

[PATCH v4 08/10] powerpc/watchpoint: Guest support for 2nd DAWR hcall

[Ravi Bangoria]

2nd DAWR can be set/unset using H_SET_MODE hcall with resource value 5.
Enable powervm guest support with that. This has no effect on kvm guest
because kvm will return error if guest does hcall with resource value 5.

Signed-off-by: Ravi Bangoria 
---
 arch/powerpc/include/asm/hvcall.h | 1 +
 arch/powerpc/include/asm/machdep.h| 2 +-
 arch/powerpc/include/asm/plpar_wrappers.h | 5 +
 arch/powerpc/kernel/dawr.c| 2 +-
 arch/powerpc/platforms/pseries/setup.c| 7 +--
 5 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/include/asm/hvcall.h 
b/arch/powerpc/include/asm/hvcall.h
index b785e9f0071c..33793444144c 100644
--- a/arch/powerpc/include/asm/hvcall.h
+++ b/arch/powerpc/include/asm/hvcall.h
@@ -358,6 +358,7 @@
 #define H_SET_MODE_RESOURCE_SET_DAWR0  2
 #define H_SET_MODE_RESOURCE_ADDR_TRANS_MODE3
 #define H_SET_MODE_RESOURCE_LE 4
+#define H_SET_MODE_RESOURCE_SET_DAWR1  5
 
 /* Values for argument to H_SIGNAL_SYS_RESET */
 #define H_SIGNAL_SYS_RESET_ALL -1
diff --git a/arch/powerpc/include/asm/machdep.h 
b/arch/powerpc/include/asm/machdep.h
index 7bcb6a39..a90b892f0bfe 100644
--- a/arch/powerpc/include/asm/machdep.h
+++ b/arch/powerpc/include/asm/machdep.h
@@ -131,7 +131,7 @@ struct machdep_calls {
unsigned long dabrx);
 
/* Set DAWR for this platform, leave empty for default implementation */
-   int (*set_dawr)(unsigned long dawr,
+   int (*set_dawr)(int nr, unsigned long dawr,
unsigned long dawrx);
 
 #ifdef CONFIG_PPC32/* XXX for now */
diff --git a/arch/powerpc/include/asm/plpar_wrappers.h 
b/arch/powerpc/include/asm/plpar_wrappers.h
index d12c3680d946..ece84a430701 100644
--- a/arch/powerpc/include/asm/plpar_wrappers.h
+++ b/arch/powerpc/include/asm/plpar_wrappers.h
@@ -315,6 +315,11 @@ static inline long plpar_set_watchpoint0(unsigned long 
dawr0, unsigned long dawr
return plpar_set_mode(0, H_SET_MODE_RESOURCE_SET_DAWR0, dawr0, dawrx0);
 }
 
+static inline long plpar_set_watchpoint1(unsigned long dawr1, unsigned long 
dawrx1)
+{
+   return plpar_set_mode(0, H_SET_MODE_RESOURCE_SET_DAWR1, dawr1, dawrx1);
+}
+
 static inline long plpar_signal_sys_reset(long cpu)
 {
return plpar_hcall_norets(H_SIGNAL_SYS_RESET, cpu);
diff --git a/arch/powerpc/kernel/dawr.c b/arch/powerpc/kernel/dawr.c
index 500f52fa4711..cdc2dccb987d 100644
--- a/arch/powerpc/kernel/dawr.c
+++ b/arch/powerpc/kernel/dawr.c
@@ -37,7 +37,7 @@ int set_dawr(int nr, struct arch_hw_breakpoint *brk)
dawrx |= (mrd & 0x3f) << (63 - 53);
 
if (ppc_md.set_dawr)
-   return ppc_md.set_dawr(dawr, dawrx);
+   return ppc_md.set_dawr(nr, dawr, dawrx);
 
if (nr == 0) {
mtspr(SPRN_DAWR0, dawr);
diff --git a/arch/powerpc/platforms/pseries/setup.c 
b/arch/powerpc/platforms/pseries/setup.c
index 2db8469e475f..d516ee8eb7fc 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -831,12 +831,15 @@ static int pseries_set_xdabr(unsigned long dabr, unsigned 
long dabrx)
return plpar_hcall_norets(H_SET_XDABR, dabr, dabrx);
 }
 
-static int pseries_set_dawr(unsigned long dawr, unsigned long dawrx)
+static int pseries_set_dawr(int nr, unsigned long dawr, unsigned long dawrx)
 {
/* PAPR says we can't set HYP */
dawrx &= ~DAWRX_HYP;
 
-   return  plpar_set_watchpoint0(dawr, dawrx);
+   if (nr == 0)
+   return plpar_set_watchpoint0(dawr, dawrx);
+   else
+   return plpar_set_watchpoint1(dawr, dawrx);
 }
 
 #define CMO_CHARACTERISTICS_TOKEN 44
-- 
2.26.2

[PATCH v4 10/10] powerpc/watchpoint: Remove 512 byte boundary

[Ravi Bangoria]

Power10 has removed 512 bytes boundary from match criteria. i.e. The watch
range can cross 512 bytes boundary.

Signed-off-by: Ravi Bangoria 
---
 arch/powerpc/kernel/hw_breakpoint.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/kernel/hw_breakpoint.c 
b/arch/powerpc/kernel/hw_breakpoint.c
index c55e67bab271..1f4a1efa0074 100644
--- a/arch/powerpc/kernel/hw_breakpoint.c
+++ b/arch/powerpc/kernel/hw_breakpoint.c
@@ -418,8 +418,9 @@ static int hw_breakpoint_validate_len(struct 
arch_hw_breakpoint *hw)
 
if (dawr_enabled()) {
max_len = DAWR_MAX_LEN;
-   /* DAWR region can't cross 512 bytes boundary */
-   if (ALIGN_DOWN(start_addr, SZ_512) != ALIGN_DOWN(end_addr - 1, 
SZ_512))
+   /* DAWR region can't cross 512 bytes boundary on p10 
predecessors */
+   if (!cpu_has_feature(CPU_FTR_ARCH_31) &&
+   (ALIGN_DOWN(start_addr, SZ_512) != ALIGN_DOWN(end_addr - 1, 
SZ_512)))
return -EINVAL;
} else if (IS_ENABLED(CONFIG_PPC_8xx)) {
/* 8xx can setup a range without limitation */
-- 
2.26.2

[PATCH v4 09/10] powerpc/watchpoint: Return available watchpoints dynamically

[Ravi Bangoria]

So far Book3S Powerpc supported only one watchpoint. Power10 is
introducing 2nd DAWR. Enable 2nd DAWR support for Power10.
Availability of 2nd DAWR will depend on CPU_FTR_DAWR1.

Signed-off-by: Ravi Bangoria 
---
 arch/powerpc/include/asm/cputable.h  | 4 +++-
 arch/powerpc/include/asm/hw_breakpoint.h | 5 +++--
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/include/asm/cputable.h 
b/arch/powerpc/include/asm/cputable.h
index 3445c86e1f6f..36a0851a7a9b 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -633,7 +633,9 @@ enum {
  * Maximum number of hw breakpoint supported on powerpc. Number of
  * breakpoints supported by actual hw might be less than this.
  */
-#define HBP_NUM_MAX1
+#define HBP_NUM_MAX2
+#define HBP_NUM_ONE1
+#define HBP_NUM_TWO2
 
 #endif /* !__ASSEMBLY__ */
 
diff --git a/arch/powerpc/include/asm/hw_breakpoint.h 
b/arch/powerpc/include/asm/hw_breakpoint.h
index cb424799da0d..d4eab1694bcd 100644
--- a/arch/powerpc/include/asm/hw_breakpoint.h
+++ b/arch/powerpc/include/asm/hw_breakpoint.h
@@ -5,10 +5,11 @@
  * Copyright 2010, IBM Corporation.
  * Author: K.Prasad 
  */
-
 #ifndef _PPC_BOOK3S_64_HW_BREAKPOINT_H
 #define _PPC_BOOK3S_64_HW_BREAKPOINT_H
 
+#include 
+
 #ifdef __KERNEL__
 struct arch_hw_breakpoint {
unsigned long   address;
@@ -46,7 +47,7 @@ struct arch_hw_breakpoint {
 
 static inline int nr_wp_slots(void)
 {
-   return HBP_NUM_MAX;
+   return cpu_has_feature(CPU_FTR_DAWR1) ? HBP_NUM_TWO : HBP_NUM_ONE;
 }
 
 #ifdef CONFIG_HAVE_HW_BREAKPOINT
-- 
2.26.2

[PATCH v4 06/10] powerpc/watchpoint: Set CPU_FTR_DAWR1 based on pa-features bit

[Ravi Bangoria]

As per the PAPR, bit 0 of byte 64 in pa-features property indicates
availability of 2nd DAWR registers. i.e. If this bit is set, 2nd
DAWR is present, otherwise not. Host generally uses "cpu-features",
which masks "pa-features". But "cpu-features" are still not used for
guests and thus this change is mostly applicable for guests only.

Signed-off-by: Ravi Bangoria 
---
 arch/powerpc/kernel/prom.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 9cc49f265c86..c76c09b97bc8 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -175,6 +175,8 @@ static struct ibm_pa_feature {
 */
{ .pabyte = 22, .pabit = 0, .cpu_features = CPU_FTR_TM_COMP,
  .cpu_user_ftrs2 = PPC_FEATURE2_HTM_COMP | PPC_FEATURE2_HTM_NOSC_COMP 
},
+
+   { .pabyte = 64, .pabit = 0, .cpu_features = CPU_FTR_DAWR1 },
 };
 
 static void __init scan_features(unsigned long node, const unsigned char *ftrs,
-- 
2.26.2

[PATCH v4 05/10] powerpc/dt_cpu_ftrs: Add feature for 2nd DAWR

[Ravi Bangoria]

Add new device-tree feature for 2nd DAWR. If this feature is present,
2nd DAWR is supported, otherwise not.

Signed-off-by: Ravi Bangoria 
---
 arch/powerpc/include/asm/cputable.h | 7 +--
 arch/powerpc/kernel/dt_cpu_ftrs.c   | 7 +++
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/cputable.h 
b/arch/powerpc/include/asm/cputable.h
index e506d429b1af..3445c86e1f6f 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -214,6 +214,7 @@ static inline void cpu_feature_keys_init(void) { }
 #define CPU_FTR_P9_TLBIE_ERAT_BUG  LONG_ASM_CONST(0x0001)
 #define CPU_FTR_P9_RADIX_PREFETCH_BUG  LONG_ASM_CONST(0x0002)
 #define CPU_FTR_ARCH_31
LONG_ASM_CONST(0x0004)
+#define CPU_FTR_DAWR1  LONG_ASM_CONST(0x0008)
 
 #ifndef __ASSEMBLY__
 
@@ -497,14 +498,16 @@ static inline void cpu_feature_keys_init(void) { }
 #define CPU_FTRS_POSSIBLE  \
(CPU_FTRS_POWER7 | CPU_FTRS_POWER8E | CPU_FTRS_POWER8 | \
 CPU_FTR_ALTIVEC_COMP | CPU_FTR_VSX_COMP | CPU_FTRS_POWER9 | \
-CPU_FTRS_POWER9_DD2_1 | CPU_FTRS_POWER9_DD2_2 | CPU_FTRS_POWER10)
+CPU_FTRS_POWER9_DD2_1 | CPU_FTRS_POWER9_DD2_2 | CPU_FTRS_POWER10 | 
\
+CPU_FTR_DAWR1)
 #else
 #define CPU_FTRS_POSSIBLE  \
(CPU_FTRS_PPC970 | CPU_FTRS_POWER5 | \
 CPU_FTRS_POWER6 | CPU_FTRS_POWER7 | CPU_FTRS_POWER8E | \
 CPU_FTRS_POWER8 | CPU_FTRS_CELL | CPU_FTRS_PA6T | \
 CPU_FTR_VSX_COMP | CPU_FTR_ALTIVEC_COMP | CPU_FTRS_POWER9 | \
-CPU_FTRS_POWER9_DD2_1 | CPU_FTRS_POWER9_DD2_2 | CPU_FTRS_POWER10)
+CPU_FTRS_POWER9_DD2_1 | CPU_FTRS_POWER9_DD2_2 | CPU_FTRS_POWER10 | 
\
+CPU_FTR_DAWR1)
 #endif /* CONFIG_CPU_LITTLE_ENDIAN */
 #endif
 #else
diff --git a/arch/powerpc/kernel/dt_cpu_ftrs.c 
b/arch/powerpc/kernel/dt_cpu_ftrs.c
index ac650c233cd9..c78cd3596ec4 100644
--- a/arch/powerpc/kernel/dt_cpu_ftrs.c
+++ b/arch/powerpc/kernel/dt_cpu_ftrs.c
@@ -574,6 +574,12 @@ static int __init feat_enable_mma(struct dt_cpu_feature *f)
return 1;
 }
 
+static int __init feat_enable_debug_facilities_v31(struct dt_cpu_feature *f)
+{
+   cur_cpu_spec->cpu_features |= CPU_FTR_DAWR1;
+   return 1;
+}
+
 struct dt_cpu_feature_match {
const char *name;
int (*enable)(struct dt_cpu_feature *f);
@@ -649,6 +655,7 @@ static struct dt_cpu_feature_match __initdata
{"wait-v3", feat_enable, 0},
{"prefix-instructions", feat_enable, 0},
{"matrix-multiply-assist", feat_enable_mma, 0},
+   {"debug-facilities-v31", feat_enable_debug_facilities_v31, 0},
 };
 
 static bool __initdata using_dt_cpu_ftrs;
-- 
2.26.2

[PATCH v4 04/10] powerpc/watchpoint: Enable watchpoint functionality on power10 guest

[Ravi Bangoria]

CPU_FTR_DAWR is by default enabled for host via CPU_FTRS_DT_CPU_BASE
(controlled by CONFIG_PPC_DT_CPU_FTRS). But cpu-features device-tree
node is not PAPR compatible and thus not yet used by kvm or pHyp
guests. Enable watchpoint functionality on power10 guest (both kvm
and powervm) by adding CPU_FTR_DAWR to CPU_FTRS_POWER10. Note that
this change does not enable 2nd DAWR support.

Signed-off-by: Ravi Bangoria 
---
 arch/powerpc/include/asm/cputable.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/cputable.h 
b/arch/powerpc/include/asm/cputable.h
index bac2252c839e..e506d429b1af 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -478,7 +478,7 @@ static inline void cpu_feature_keys_init(void) { }
CPU_FTR_CFAR | CPU_FTR_HVMODE | CPU_FTR_VMX_COPY | \
CPU_FTR_DBELL | CPU_FTR_HAS_PPR | CPU_FTR_ARCH_207S | \
CPU_FTR_TM_COMP | CPU_FTR_ARCH_300 | CPU_FTR_PKEY | \
-   CPU_FTR_ARCH_31)
+   CPU_FTR_ARCH_31 | CPU_FTR_DAWR)
 #define CPU_FTRS_CELL  (CPU_FTR_LWSYNC | \
CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
CPU_FTR_ALTIVEC_COMP | CPU_FTR_MMCRA | CPU_FTR_SMT | \
-- 
2.26.2

[PATCH v4 03/10] powerpc/watchpoint: Fix DAWR exception for CACHEOP

[Ravi Bangoria]

'ea' returned by analyse_instr() needs to be aligned down to cache
block size for CACHEOP instructions. analyse_instr() does not set
size for CACHEOP, thus size also needs to be calculated manually.

Fixes: 27985b2a640e ("powerpc/watchpoint: Don't ignore extraneous exceptions 
blindly")
Fixes: 74c6881019b7 ("powerpc/watchpoint: Prepare handler to handle more than 
one watchpoint")
Signed-off-by: Ravi Bangoria 
---
 arch/powerpc/kernel/hw_breakpoint.c | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/hw_breakpoint.c 
b/arch/powerpc/kernel/hw_breakpoint.c
index a971e22aea81..c55e67bab271 100644
--- a/arch/powerpc/kernel/hw_breakpoint.c
+++ b/arch/powerpc/kernel/hw_breakpoint.c
@@ -538,7 +538,12 @@ static bool check_dawrx_constraints(struct pt_regs *regs, 
int type,
if (OP_IS_LOAD(type) && !(info->type & HW_BRK_TYPE_READ))
return false;
 
-   if (OP_IS_STORE(type) && !(info->type & HW_BRK_TYPE_WRITE))
+   /*
+* The Cache Management instructions other than dcbz never
+* cause a match. i.e. if type is CACHEOP, the instruction
+* is dcbz, and dcbz is treated as Store.
+*/
+   if ((OP_IS_STORE(type) || type == CACHEOP) && !(info->type & 
HW_BRK_TYPE_WRITE))
return false;
 
if (is_kernel_addr(regs->nip) && !(info->type & HW_BRK_TYPE_KERNEL))
@@ -601,6 +606,15 @@ static bool check_constraints(struct pt_regs *regs, struct 
ppc_inst instr,
return false;
 }
 
+static int cache_op_size(void)
+{
+#ifdef __powerpc64__
+   return ppc64_caches.l1d.block_size;
+#else
+   return L1_CACHE_BYTES;
+#endif
+}
+
 static void get_instr_detail(struct pt_regs *regs, struct ppc_inst *instr,
 int *type, int *size, unsigned long *ea)
 {
@@ -616,7 +630,12 @@ static void get_instr_detail(struct pt_regs *regs, struct 
ppc_inst *instr,
if (!(regs->msr & MSR_64BIT))
*ea &= 0xUL;
 #endif
+
*size = GETSIZE(op.type);
+   if (*type == CACHEOP) {
+   *size = cache_op_size();
+   *ea &= ~(*size - 1);
+   }
 }
 
 static bool is_larx_stcx_instr(int type)
-- 
2.26.2

[PATCH v4 07/10] powerpc/watchpoint: Rename current H_SET_MODE DAWR macro

[Ravi Bangoria]

Current H_SET_MODE hcall macro name for setting/resetting DAWR0 is
H_SET_MODE_RESOURCE_SET_DAWR. Add suffix 0 to macro name as well.

Signed-off-by: Ravi Bangoria 
---
 arch/powerpc/include/asm/hvcall.h | 2 +-
 arch/powerpc/include/asm/plpar_wrappers.h | 2 +-
 arch/powerpc/kvm/book3s_hv.c  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/include/asm/hvcall.h 
b/arch/powerpc/include/asm/hvcall.h
index 43486e773bd6..b785e9f0071c 100644
--- a/arch/powerpc/include/asm/hvcall.h
+++ b/arch/powerpc/include/asm/hvcall.h
@@ -355,7 +355,7 @@
 
 /* Values for 2nd argument to H_SET_MODE */
 #define H_SET_MODE_RESOURCE_SET_CIABR  1
-#define H_SET_MODE_RESOURCE_SET_DAWR   2
+#define H_SET_MODE_RESOURCE_SET_DAWR0  2
 #define H_SET_MODE_RESOURCE_ADDR_TRANS_MODE3
 #define H_SET_MODE_RESOURCE_LE 4
 
diff --git a/arch/powerpc/include/asm/plpar_wrappers.h 
b/arch/powerpc/include/asm/plpar_wrappers.h
index 4293c5d2ddf4..d12c3680d946 100644
--- a/arch/powerpc/include/asm/plpar_wrappers.h
+++ b/arch/powerpc/include/asm/plpar_wrappers.h
@@ -312,7 +312,7 @@ static inline long plpar_set_ciabr(unsigned long ciabr)
 
 static inline long plpar_set_watchpoint0(unsigned long dawr0, unsigned long 
dawrx0)
 {
-   return plpar_set_mode(0, H_SET_MODE_RESOURCE_SET_DAWR, dawr0, dawrx0);
+   return plpar_set_mode(0, H_SET_MODE_RESOURCE_SET_DAWR0, dawr0, dawrx0);
 }
 
 static inline long plpar_signal_sys_reset(long cpu)
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 6bf66649ab92..7ad692c2d7c7 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -764,7 +764,7 @@ static int kvmppc_h_set_mode(struct kvm_vcpu *vcpu, 
unsigned long mflags,
return H_P3;
vcpu->arch.ciabr  = value1;
return H_SUCCESS;
-   case H_SET_MODE_RESOURCE_SET_DAWR:
+   case H_SET_MODE_RESOURCE_SET_DAWR0:
if (!kvmppc_power8_compatible(vcpu))
return H_P2;
if (!ppc_breakpoint_available())
-- 
2.26.2

[PATCH v4 01/10] powerpc/watchpoint: Fix 512 byte boundary limit

[Ravi Bangoria]

Milton Miller reported that we are aligning start and end address to
wrong size SZ_512M. It should be SZ_512. Fix that.

While doing this change I also found a case where ALIGN() comparison
fails. Within a given aligned range, ALIGN() of two addresses does not
match when start address is pointing to the first byte and end address
is pointing to any other byte except the first one. But that's not true
for ALIGN_DOWN(). ALIGN_DOWN() of any two addresses within that range
will always point to the first byte. So use ALIGN_DOWN() instead of
ALIGN().

Fixes: e68ef121c1f4 ("powerpc/watchpoint: Use builtin ALIGN*() macros")
Reported-by: Milton Miller 
Signed-off-by: Ravi Bangoria 
Tested-by: Jordan Niethe 
---
 arch/powerpc/kernel/hw_breakpoint.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/hw_breakpoint.c 
b/arch/powerpc/kernel/hw_breakpoint.c
index daf0e1da..031e6defc08e 100644
--- a/arch/powerpc/kernel/hw_breakpoint.c
+++ b/arch/powerpc/kernel/hw_breakpoint.c
@@ -419,7 +419,7 @@ static int hw_breakpoint_validate_len(struct 
arch_hw_breakpoint *hw)
if (dawr_enabled()) {
max_len = DAWR_MAX_LEN;
/* DAWR region can't cross 512 bytes boundary */
-   if (ALIGN(start_addr, SZ_512M) != ALIGN(end_addr - 1, SZ_512M))
+   if (ALIGN_DOWN(start_addr, SZ_512) != ALIGN_DOWN(end_addr - 1, 
SZ_512))
return -EINVAL;
} else if (IS_ENABLED(CONFIG_PPC_8xx)) {
/* 8xx can setup a range without limitation */
-- 
2.26.2

[PATCH v4 00/10] powerpc/watchpoint: Enable 2nd DAWR on baremetal and powervm

[Ravi Bangoria]

Last series[1] was to add basic infrastructure support for more than
one watchpoint on Book3S powerpc. This series actually enables the 2nd 
DAWR for baremetal and powervm. Kvm guest is still not supported.

v3: 
https://lore.kernel.org/lkml/20200708045046.135702-1-ravi.bango...@linux.ibm.com

v3->v4:
 - v3 patch #2 is split into two v4 patches: #2 and #3
 - Few other minor neats suggested by Jordan Niethe
 - Rebased to powerpc/next

[1]: 
https://lore.kernel.org/linuxppc-dev/20200514111741.97993-1-ravi.bango...@linux.ibm.com/

Ravi Bangoria (10):
  powerpc/watchpoint: Fix 512 byte boundary limit
  powerpc/watchpoint: Fix DAWR exception constraint
  powerpc/watchpoint: Fix DAWR exception for CACHEOP
  powerpc/watchpoint: Enable watchpoint functionality on power10 guest
  powerpc/dt_cpu_ftrs: Add feature for 2nd DAWR
  powerpc/watchpoint: Set CPU_FTR_DAWR1 based on pa-features bit
  powerpc/watchpoint: Rename current H_SET_MODE DAWR macro
  powerpc/watchpoint: Guest support for 2nd DAWR hcall
  powerpc/watchpoint: Return available watchpoints dynamically
  powerpc/watchpoint: Remove 512 byte boundary

 arch/powerpc/include/asm/cputable.h   | 13 ++-
 arch/powerpc/include/asm/hvcall.h |  3 +-
 arch/powerpc/include/asm/hw_breakpoint.h  |  5 +-
 arch/powerpc/include/asm/machdep.h|  2 +-
 arch/powerpc/include/asm/plpar_wrappers.h |  7 +-
 arch/powerpc/kernel/dawr.c|  2 +-
 arch/powerpc/kernel/dt_cpu_ftrs.c |  7 ++
 arch/powerpc/kernel/hw_breakpoint.c   | 98 +++
 arch/powerpc/kernel/prom.c|  2 +
 arch/powerpc/kvm/book3s_hv.c  |  2 +-
 arch/powerpc/platforms/pseries/setup.c|  7 +-
 11 files changed, 101 insertions(+), 47 deletions(-)

-- 
2.26.2

[PATCH v4 02/10] powerpc/watchpoint: Fix DAWR exception constraint

[Ravi Bangoria]

Pedro Miraglia Franco de Carvalho noticed that on p8/p9, DAR value is
inconsistent with different type of load/store. Like for byte,word
etc. load/stores, DAR is set to the address of the first byte of
overlap between watch range and real access. But for quadword load/
store it's sometime set to the address of the first byte of real
access whereas sometime set to the address of the first byte of
overlap. This issue has been fixed in p10. In p10(ISA 3.1), DAR is
always set to the address of the first byte of overlap. Commit 27985b2a640e
("powerpc/watchpoint: Don't ignore extraneous exceptions blindly")
wrongly assumes that DAR is set to the address of the first byte of
overlap for all load/stores on p8/p9 as well. Fix that. With the fix,
we now rely on 'ea' provided by analyse_instr(). If analyse_instr()
fails, generate event unconditionally on p8/p9, and on p10 generate
event only if DAR is within a DAWR range.

Note: 8xx is not affected.

Fixes: 27985b2a640e ("powerpc/watchpoint: Don't ignore extraneous exceptions 
blindly")
Fixes: 74c6881019b7 ("powerpc/watchpoint: Prepare handler to handle more than 
one watchpoint")
Reported-by: Pedro Miraglia Franco de Carvalho 
Signed-off-by: Ravi Bangoria 
---
 arch/powerpc/kernel/hw_breakpoint.c | 72 -
 1 file changed, 41 insertions(+), 31 deletions(-)

diff --git a/arch/powerpc/kernel/hw_breakpoint.c 
b/arch/powerpc/kernel/hw_breakpoint.c
index 031e6defc08e..a971e22aea81 100644
--- a/arch/powerpc/kernel/hw_breakpoint.c
+++ b/arch/powerpc/kernel/hw_breakpoint.c
@@ -498,11 +498,11 @@ static bool dar_in_user_range(unsigned long dar, struct 
arch_hw_breakpoint *info
return ((info->address <= dar) && (dar - info->address < info->len));
 }
 
-static bool dar_user_range_overlaps(unsigned long dar, int size,
-   struct arch_hw_breakpoint *info)
+static bool ea_user_range_overlaps(unsigned long ea, int size,
+  struct arch_hw_breakpoint *info)
 {
-   return ((dar < info->address + info->len) &&
-   (dar + size > info->address));
+   return ((ea < info->address + info->len) &&
+   (ea + size > info->address));
 }
 
 static bool dar_in_hw_range(unsigned long dar, struct arch_hw_breakpoint *info)
@@ -515,20 +515,22 @@ static bool dar_in_hw_range(unsigned long dar, struct 
arch_hw_breakpoint *info)
return ((hw_start_addr <= dar) && (hw_end_addr > dar));
 }
 
-static bool dar_hw_range_overlaps(unsigned long dar, int size,
- struct arch_hw_breakpoint *info)
+static bool ea_hw_range_overlaps(unsigned long ea, int size,
+struct arch_hw_breakpoint *info)
 {
unsigned long hw_start_addr, hw_end_addr;
 
hw_start_addr = ALIGN_DOWN(info->address, HW_BREAKPOINT_SIZE);
hw_end_addr = ALIGN(info->address + info->len, HW_BREAKPOINT_SIZE);
 
-   return ((dar < hw_end_addr) && (dar + size > hw_start_addr));
+   return ((ea < hw_end_addr) && (ea + size > hw_start_addr));
 }
 
 /*
  * If hw has multiple DAWR registers, we also need to check all
  * dawrx constraint bits to confirm this is _really_ a valid event.
+ * If type is UNKNOWN, but privilege level matches, consider it as
+ * a positive match.
  */
 static bool check_dawrx_constraints(struct pt_regs *regs, int type,
struct arch_hw_breakpoint *info)
@@ -553,7 +555,8 @@ static bool check_dawrx_constraints(struct pt_regs *regs, 
int type,
  * including extraneous exception. Otherwise return false.
  */
 static bool check_constraints(struct pt_regs *regs, struct ppc_inst instr,
- int type, int size, struct arch_hw_breakpoint 
*info)
+ unsigned long ea, int type, int size,
+ struct arch_hw_breakpoint *info)
 {
bool in_user_range = dar_in_user_range(regs->dar, info);
bool dawrx_constraints;
@@ -569,22 +572,27 @@ static bool check_constraints(struct pt_regs *regs, 
struct ppc_inst instr,
}
 
if (unlikely(ppc_inst_equal(instr, ppc_inst(0 {
-   if (in_user_range)
-   return true;
+   if (cpu_has_feature(CPU_FTR_ARCH_31) &&
+   !dar_in_hw_range(regs->dar, info))
+   return false;
 
-   if (dar_in_hw_range(regs->dar, info)) {
-   info->type |= HW_BRK_TYPE_EXTRANEOUS_IRQ;
-   return true;
-   }
-   return false;
+   return true;
}
 
dawrx_constraints = check_dawrx_constraints(regs, type, info);
 
-   if (dar_user_range_overlaps(regs->dar, size, info))
+   if (type == UNKNOWN) {
+   if (cpu_has_feature(CPU_FTR_ARCH_31) &&
+   !dar_in_hw_range(regs->dar, info))
+   return false;
+
return dawrx_constraints;
+   }

drivers/tty/serial/ucc_uart.c:286:6: warning: no previous prototype for 'qe_uart_set_mctrl'

[kernel test robot]

Hi Rasmus,

First bad commit (maybe != root cause):

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   07a56bb875afbe39dabbf6ba7b83783d166863db
commit: 5a35435ef4e6e4bd2aabd6706b146b298a9cffe5 soc: fsl: qe: remove PPC32 
dependency from CONFIG_QUICC_ENGINE
date:   7 months ago
config: c6x-randconfig-r011-20200717 (attached as .config)
compiler: c6x-elf-gcc (GCC) 9.3.0
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
git checkout 5a35435ef4e6e4bd2aabd6706b146b298a9cffe5
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=c6x 

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

All warnings (new ones prefixed by >>):

>> drivers/tty/serial/ucc_uart.c:286:6: warning: no previous prototype for 
>> 'qe_uart_set_mctrl' [-Wmissing-prototypes]
 286 | void qe_uart_set_mctrl(struct uart_port *port, unsigned int mctrl)
 |  ^

vim +/qe_uart_set_mctrl +286 drivers/tty/serial/ucc_uart.c

d7584ed2b994a5 drivers/serial/ucc_uart.c Timur Tabi 2008-01-15  278  
d7584ed2b994a5 drivers/serial/ucc_uart.c Timur Tabi 2008-01-15  279  /*
d7584ed2b994a5 drivers/serial/ucc_uart.c Timur Tabi 2008-01-15  280   * Set the 
modem control lines
d7584ed2b994a5 drivers/serial/ucc_uart.c Timur Tabi 2008-01-15  281   *
d7584ed2b994a5 drivers/serial/ucc_uart.c Timur Tabi 2008-01-15  282   * 
Although the QE can control the modem control lines (e.g. CTS), we
d7584ed2b994a5 drivers/serial/ucc_uart.c Timur Tabi 2008-01-15  283   * don't 
need that support. This function must exist, however, otherwise
d7584ed2b994a5 drivers/serial/ucc_uart.c Timur Tabi 2008-01-15  284   * the 
kernel will panic.
d7584ed2b994a5 drivers/serial/ucc_uart.c Timur Tabi 2008-01-15  285   */
d7584ed2b994a5 drivers/serial/ucc_uart.c Timur Tabi 2008-01-15 @286  void 
qe_uart_set_mctrl(struct uart_port *port, unsigned int mctrl)
d7584ed2b994a5 drivers/serial/ucc_uart.c Timur Tabi 2008-01-15  287  {
d7584ed2b994a5 drivers/serial/ucc_uart.c Timur Tabi 2008-01-15  288  }
d7584ed2b994a5 drivers/serial/ucc_uart.c Timur Tabi 2008-01-15  289  

:: The code at line 286 was first introduced by commit
:: d7584ed2b994a572326650b0c4d2c25961e6f49d [POWERPC] qe-uart: add support 
for Freescale QUICCEngine UART

:: TO: Timur Tabi 
:: CC: Kumar Gala 

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip

Re: Regression: squashfs issues since change "squashfs: migrate from ll_rw_block usage to BIO"

[Bernd Amend]

On Fri, Jul 17, 2020 at 3:22 AM Phillip Lougher
 wrote:
>
> On Fri, Jul 17, 2020 at 12:07 AM Andrew Morton
>  wrote:
> >
> > On Tue, 14 Jul 2020 21:41:07 +0200 Bernd Amend  
> > wrote:
> >
> > > Hi,
> > >
> > > With the Linux Kernel version 5.8-rc5/master I am unable to mount some
> > > squashfs filesystems compressed with "-comp lz4".
> > > If I try to mount them I get the following error:
> > > [1.084246] SQUASHFS error: lz4 decompression failed, data probably 
> > > corrupt
> > > [1.084545] SQUASHFS error: Failed to read block 0x873e1001: -5
> > > [1.084761] SQUASHFS error: Unable to read metadata cache entry 
> > > [873e0fff]
> > > [1.084983] SQUASHFS error: Unable to read directory block 
> > > [873e0fff:1586]
> > > [1.122564] SQUASHFS error: Unable to read metadata cache entry 
> > > [873e0fff]
> > > [1.122708] SQUASHFS error: Unable to read directory block 
> > > [873e0fff:1586]
> > > [1.122862] Starting init: /sbin/init exists but couldn't execute
> > > it (error -5)
> > > [1.123027] SQUASHFS error: Unable to read metadata cache entry 
> > > [873e0fff]
> > > [1.123152] SQUASHFS error: Unable to read directory block 
> > > [873e0fff:1586]
> > > [1.123279] Starting init: /etc/init exists but couldn't execute it
> > > (error -5)
> > > [1.123444] SQUASHFS error: Unable to read metadata cache entry 
> > > [873e0fff]
> > > [1.123573] SQUASHFS error: Unable to read directory block 
> > > [873e0fff:1586]
> > > [1.123713] Starting init: /bin/init exists but couldn't execute it
> > > (error -5)
> > > [1.123900] SQUASHFS error: Unable to read metadata cache entry 
> > > [873e0fff]
> > >
> > > or
> > >
> > > [ 4960.910693] attempt to access beyond end of device
> > > [ 4960.910695] loop0: rw=2048, want=46, limit=40
> > > [ 4960.910696] SQUASHFS error: Failed to read block 0x4001: -5
> > > [ 4960.910697] SQUASHFS error: Unable to read metadata cache entry [3fff]
> > > [ 4960.910698] SQUASHFS error: Unable to read inode 0x20c5000c
> > >
> > > I bisected the issue to the commit "squashfs: migrate from ll_rw_block
> > > usage to BIO"
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/squashfs?id=93e72b3c612adcaca13d874fcc86c53e6c8da541
> > >
> > > The issue can be reproduced by downloading
> > > https://theworldsend.eu/demo.squashfs (20K) and the following command
> > > line.
> > > # mount demo.squashfs mnt && ls mnt && umount mnt
> > >
> > > The same squashfs can be mounted using Linux <=5.7.8.
> > > The kernel config is identical to the Arch Linux Kernel configuration,
> > > build using gcc 9 and 10 on x86_64.
> >
> > Thanks.  I queued a reversion patch.  I'll go ahead with this if we are
> > unable to get this fixed in the next week or so.
> >
>
> Yes, there is a bug in the patch.  I have tracked it down today, and I
> will send out a fix patch tomorrow.
>
> The bug is here:
>
> +   /* Extract the length of the metadata block */
> +   data = page_address(bvec->bv_page) + bvec->bv_offset;
> +   length = data[offset];
> +   if (offset <= bvec->bv_len - 1) {
>
> This check is wrong, it should be
>
> +   if (offset < bvec->bv_len - 1) {
>
>
> Phillip

Thanks, this change resolves the issue for me.

Bernd

>
> > Are you able to check that the below fixes things up?
> >
> > Thanks.
> >
> >
> > From: Andrew Morton 
> > Subject: revert "squashfs: migrate from ll_rw_block usage to BIO"
> >
> > Revert 93e72b3c612adc ("squashfs: migrate from ll_rw_block usage to BIO")
> > due to a regression reported by Bernd Amend.
> >
> > Link: 
> > http://lkml.kernel.org/r/caf31+h5zb7zn73obrc5svlzgfstnyye5tkvr7-6atuoqrry...@mail.gmail.com
> > Reported-by: Bernd Amend 
> > Cc: Philippe Liard 
> > Cc: Christoph Hellwig 
> > Cc: Adrien Schildknecht 
> > Cc: Phillip Lougher 
> > Cc: Guenter Roeck 
> > Cc: Daniel Rosenberg 
> > Signed-off-by: Andrew Morton 
> > ---
> >
> >  fs/squashfs/block.c |  273 ++
> >  fs/squashfs/decompressor.h  |5
> >  fs/squashfs/decompressor_multi.c|9
> >  fs/squashfs/decompressor_multi_percpu.c |6
> >  fs/squashfs/decompressor_single.c   |9
> >  fs/squashfs/lz4_wrapper.c   |   17 -
> >  fs/squashfs/lzo_wrapper.c   |   17 -
> >  fs/squashfs/squashfs.h  |4
> >  fs/squashfs/xz_wrapper.c|   51 +---
> >  fs/squashfs/zlib_wrapper.c  |   63 ++---
> >  fs/squashfs/zstd_wrapper.c  |   62 ++--
> >  11 files changed, 237 insertions(+), 279 deletions(-)
> >
> > --- 
> > a/fs/squashfs/block.c~revert-squashfs-migrate-from-ll_rw_block-usage-to-bio
> > +++ a/fs/squashfs/block.c
> > @@ -13,7 +13,6 @@
> >   * datablocks and metadata blocks.
> >   */
> >
> > -#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -28,104 +27,45 @@
> >  #include "page_actor.h"
> >
> >  /*
> > - * Returns the amount of bytes copied to 

Re: [PATCH] usb: gadget: udc: Flush pending work also in error path

[Peter Chen]

On 20-07-16 13:55:25, Marek Szyprowski wrote:
> When binding an UDC driver to the pending gadget fails in
> check_pending_gadget_drivers(), the usb_add_gadget_udc_release() function
> ends without waiting for the usb_gadget_state_work to finish, what in
> turn might cause the whole struct usb_gadget being freed by the caller
> before the usb_gadget_state_work being executed.
> 
> This can be observed on some boards with USB Mass Storage gadget
> compiled-in and kernel booted without the needed module parameters:
> 
> dwc2 1248.hsotg: dwc2_check_params: Invalid parameter besl=1
> dwc2 1248.hsotg: dwc2_check_params: Invalid parameter 
> g_np_tx_fifo_size=1024
> dwc2 1248.hsotg: EPs: 16, dedicated fifos, 7808 entries in SPRAM
> Mass Storage Function, version: 2009/09/11
> LUN: removable file: (no medium)
> no file given for LUN0
> g_mass_storage 1248.hsotg: failed to start g_mass_storage: -22
> dwc2: probe of 1248.hsotg failed with error -22
> 8<--- cut here ---
> Unable to handle kernel NULL pointer dereference at virtual address 0004
> pgd = (ptrval)
> [0004] *pgd=
> Internal error: Oops: 5 [#1] PREEMPT SMP ARM
> Modules linked in:
> CPU: 1 PID: 88 Comm: kworker/1:2 Not tainted 
> 5.8.0-rc5-next-20200715-00062-gc5bb489ae825-dirty #8792
> Hardware name: Samsung Exynos (Flattened Device Tree)
> Workqueue:  0x0 (rcu_gp)
> PC is at process_one_work+0x44/0x7dc
> ...
> Process kworker/1:2 (pid: 88, stack limit = 0x(ptrval))
> Stack: (0xed9f1f00 to 0xed9f2000)
> ...
> [] (process_one_work) from [] (worker_thread+0x44/0x51c)
> [] (worker_thread) from [] (kthread+0x158/0x1a0)
> [] (kthread) from [] (ret_from_fork+0x14/0x20)
> Exception stack(0xed9f1fb0 to 0xed9f1ff8)
> ...
> ---[ end trace 5033c1326a62e5f3 ]---
> note: kworker/1:2[88] exited with preempt_count 1
> 
> Fix this by flushing pending work in error path.
> 
> Signed-off-by: Marek Szyprowski 
> ---
>  drivers/usb/gadget/udc/core.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c
> index c33ad8a333ad..4f82bcd31fd3 100644
> --- a/drivers/usb/gadget/udc/core.c
> +++ b/drivers/usb/gadget/udc/core.c
> @@ -1230,6 +1230,7 @@ int usb_add_gadget_udc_release(struct device *parent, 
> struct usb_gadget *gadget,
>   return 0;
>  
>   err_del_udc:
> + flush_work(>work);
>   device_del(>dev);
>  
>   err_unlist_udc:
> -- 
> 2.17.1
> 

Reviewed-by: Peter Chen 

-- 

Thanks,
Peter Chen

drivers/video/fbdev/aty/atyfb_base.c:3715:37: sparse: sparse: incorrect type in argument 1 (different address spaces)

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   07a56bb875afbe39dabbf6ba7b83783d166863db
commit: 670d0a4b10704667765f7d18f7592993d02783aa sparse: use identifiers to 
define address spaces
date:   4 weeks ago
config: arc-randconfig-s032-20200717 (attached as .config)
compiler: arc-elf-gcc (GCC) 9.3.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.2-49-g707c5017-dirty
git checkout 670d0a4b10704667765f7d18f7592993d02783aa
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=arc 

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/aty/atyfb_base.c:3715:37: sparse: sparse: incorrect type 
>> in argument 1 (different address spaces) @@ expected void const 
>> [noderef] __iomem *addr @@ got unsigned char [usertype] *addr @@
>> drivers/video/fbdev/aty/atyfb_base.c:3715:37: sparse: expected void 
>> const [noderef] __iomem *addr
   drivers/video/fbdev/aty/atyfb_base.c:3715:37: sparse: got unsigned char 
[usertype] *addr
--
>> sound/pci/echoaudio/echoaudio.c:1824:21: sparse: sparse: incorrect type in 
>> argument 1 (different modifiers) @@ expected void const [noderef] 
>> __iomem *addr @@ got unsigned int volatile [noderef] [usertype] __iomem 
>> *dsp_registers @@
>> sound/pci/echoaudio/echoaudio.c:1824:21: sparse: expected void const 
>> [noderef] __iomem *addr
   sound/pci/echoaudio/echoaudio.c:1824:21: sparse: got unsigned int 
volatile [noderef] [usertype] __iomem *dsp_registers

vim +3715 drivers/video/fbdev/aty/atyfb_base.c

c98959f566e0c6 drivers/video/aty/atyfb_base.c   Ville Syrjala  
2006-12-08  3691  
48c68c4f1b5424 drivers/video/aty/atyfb_base.c   Greg Kroah-Hartman 
2012-12-21  3692  static void atyfb_remove(struct fb_info *info)
^1da177e4c3f41 drivers/video/aty/atyfb_base.c   Linus Torvalds 
2005-04-16  3693  {
^1da177e4c3f41 drivers/video/aty/atyfb_base.c   Linus Torvalds 
2005-04-16  3694 struct atyfb_par *par = (struct atyfb_par *) info->par;
^1da177e4c3f41 drivers/video/aty/atyfb_base.c   Linus Torvalds 
2005-04-16  3695  
^1da177e4c3f41 drivers/video/aty/atyfb_base.c   Linus Torvalds 
2005-04-16  3696 /* restore video mode */
eafad22a05fdac drivers/video/aty/atyfb_base.c   Ville Syrjala  
2009-06-30  3697 aty_set_crtc(par, >saved_crtc);
eafad22a05fdac drivers/video/aty/atyfb_base.c   Ville Syrjala  
2009-06-30  3698 par->pll_ops->set_pll(info, >saved_pll);
^1da177e4c3f41 drivers/video/aty/atyfb_base.c   Linus Torvalds 
2005-04-16  3699  
37ce69a57ff217 drivers/video/aty/atyfb_base.c   Richard Purdie 
2007-02-10  3700 unregister_framebuffer(info);
37ce69a57ff217 drivers/video/aty/atyfb_base.c   Richard Purdie 
2007-02-10  3701  
5474c120aafe78 drivers/video/aty/atyfb_base.c   Michael Hanselmann 
2006-06-25  3702  #ifdef CONFIG_FB_ATY_BACKLIGHT
5474c120aafe78 drivers/video/aty/atyfb_base.c   Michael Hanselmann 
2006-06-25  3703 if (M64_HAS(MOBIL_BUS))
37ce69a57ff217 drivers/video/aty/atyfb_base.c   Richard Purdie 
2007-02-10  3704 aty_bl_exit(info->bl_dev);
5474c120aafe78 drivers/video/aty/atyfb_base.c   Michael Hanselmann 
2006-06-25  3705  #endif
7d89a3cb159aec drivers/video/fbdev/aty/atyfb_base.c Luis R. Rodriguez  
2015-07-09  3706 arch_phys_wc_del(par->wc_cookie);
5474c120aafe78 drivers/video/aty/atyfb_base.c   Michael Hanselmann 
2006-06-25  3707  
^1da177e4c3f41 drivers/video/aty/atyfb_base.c   Linus Torvalds 
2005-04-16  3708  #ifndef __sparc__
^1da177e4c3f41 drivers/video/aty/atyfb_base.c   Linus Torvalds 
2005-04-16  3709 if (par->ati_regbase)
^1da177e4c3f41 drivers/video/aty/atyfb_base.c   Linus Torvalds 
2005-04-16  3710 iounmap(par->ati_regbase);
^1da177e4c3f41 drivers/video/aty/atyfb_base.c   Linus Torvalds 
2005-04-16  3711 if (info->screen_base)
^1da177e4c3f41 drivers/video/aty/atyfb_base.c   Linus Torvalds 
2005-04-16  3712 iounmap(info->screen_base);
^1da177e4c3f41 drivers/video/aty/atyfb_base.c   Linus Torvalds 
2005-04-16  3713  #ifdef __BIG_ENDIAN
^1da177e4c3f41 drivers/video/aty/atyfb_base.c   Linus Torvalds 
2005-04-16  3714 if (info->sprite.addr)
^1da177e4c3f41 drivers/video/aty/atyfb_base.c   Linus Torvalds 
2005-04-16 @3715 iounmap(info->sprite.addr);
^1da177e4c3f41 drivers/video/aty/atyfb_base.c   Linus Torvalds 
2005-04-16  3716  #endif
^1da177e4c3f41 

[PATCH v2 6/6] tw68: use generic power management

[Vaibhav Gupta]

With legacy PM, drivers themselves were responsible for managing the
device's power states and takes care of register states.

After upgrading to the generic structure, PCI core will take care of
required tasks and drivers should do only device-specific operations.

The driver was invoking PCI helper functions like pci_save/restore_state()
which is not recommended.

Compile-Tested only.

Signed-off-by: Vaibhav Gupta 
---
 drivers/media/pci/tw68/tw68-core.c | 30 +++---
 1 file changed, 11 insertions(+), 19 deletions(-)

diff --git a/drivers/media/pci/tw68/tw68-core.c 
b/drivers/media/pci/tw68/tw68-core.c
index b45f3ffa3de5..065420b09250 100644
--- a/drivers/media/pci/tw68/tw68-core.c
+++ b/drivers/media/pci/tw68/tw68-core.c
@@ -359,10 +359,9 @@ static void tw68_finidev(struct pci_dev *pci_dev)
v4l2_device_unregister(>v4l2_dev);
 }
 
-#ifdef CONFIG_PM
-
-static int tw68_suspend(struct pci_dev *pci_dev , pm_message_t state)
+static int __maybe_unused tw68_suspend(struct device *dev_d)
 {
+   struct pci_dev *pci_dev = to_pci_dev(dev_d);
struct v4l2_device *v4l2_dev = pci_get_drvdata(pci_dev);
struct tw68_dev *dev = container_of(v4l2_dev,
struct tw68_dev, v4l2_dev);
@@ -373,24 +372,19 @@ static int tw68_suspend(struct pci_dev *pci_dev , 
pm_message_t state)
 
synchronize_irq(pci_dev->irq);
 
-   pci_save_state(pci_dev);
-   pci_set_power_state(pci_dev, pci_choose_state(pci_dev, state));
vb2_discard_done(>vidq);
 
return 0;
 }
 
-static int tw68_resume(struct pci_dev *pci_dev)
+static int __maybe_unused tw68_resume(struct device *dev_d)
 {
-   struct v4l2_device *v4l2_dev = pci_get_drvdata(pci_dev);
+   struct v4l2_device *v4l2_dev = dev_get_drvdata(dev_d);
struct tw68_dev *dev = container_of(v4l2_dev,
struct tw68_dev, v4l2_dev);
struct tw68_buf *buf;
unsigned long flags;
 
-   pci_set_power_state(pci_dev, PCI_D0);
-   pci_restore_state(pci_dev);
-
/* Do things that are done in tw68_initdev ,
except of initializing memory structures.*/
 
@@ -408,19 +402,17 @@ static int tw68_resume(struct pci_dev *pci_dev)
 
return 0;
 }
-#endif
 
 /* --- */
 
+static SIMPLE_DEV_PM_OPS(tw68_pm_ops, tw68_suspend, tw68_resume);
+
 static struct pci_driver tw68_pci_driver = {
-   .name = "tw68",
-   .id_table = tw68_pci_tbl,
-   .probe= tw68_initdev,
-   .remove   = tw68_finidev,
-#ifdef CONFIG_PM
-   .suspend  = tw68_suspend,
-   .resume   = tw68_resume
-#endif
+   .name  = "tw68",
+   .id_table  = tw68_pci_tbl,
+   .probe = tw68_initdev,
+   .remove= tw68_finidev,
+   .driver.pm = _pm_ops,
 };
 
 module_pci_driver(tw68_pci_driver);
-- 
2.27.0

[PATCH v2 4/6] cx88: use generic power management

[Vaibhav Gupta]

With legacy PM, drivers themselves were responsible for managing the
device's power states and takes care of register states.

After upgrading to the generic structure, PCI core will take care of
required tasks and drivers should do only device-specific operations.

The driver was invoking PCI helper functions like pci_save/restore_state(),
pci_enable/disable_device() and pci_set_power_state(), which is not
recommended.

Compile-tested only.

Signed-off-by: Vaibhav Gupta 
---
 drivers/media/pci/cx88/cx88-video.c | 52 -
 1 file changed, 13 insertions(+), 39 deletions(-)

diff --git a/drivers/media/pci/cx88/cx88-video.c 
b/drivers/media/pci/cx88/cx88-video.c
index ba0e9660a047..a06d5b8f31b9 100644
--- a/drivers/media/pci/cx88/cx88-video.c
+++ b/drivers/media/pci/cx88/cx88-video.c
@@ -1551,10 +1551,9 @@ static void cx8800_finidev(struct pci_dev *pci_dev)
kfree(dev);
 }
 
-#ifdef CONFIG_PM
-static int cx8800_suspend(struct pci_dev *pci_dev, pm_message_t state)
+static int __maybe_unused cx8800_suspend(struct device *dev_d)
 {
-   struct cx8800_dev *dev = pci_get_drvdata(pci_dev);
+   struct cx8800_dev *dev = dev_get_drvdata(dev_d);
struct cx88_core *core = dev->core;
unsigned long flags;
 
@@ -1575,40 +1574,17 @@ static int cx8800_suspend(struct pci_dev *pci_dev, 
pm_message_t state)
/* FIXME -- shutdown device */
cx88_shutdown(core);
 
-   pci_save_state(pci_dev);
-   if (pci_set_power_state(pci_dev,
-   pci_choose_state(pci_dev, state)) != 0) {
-   pci_disable_device(pci_dev);
-   dev->state.disabled = 1;
-   }
+   dev->state.disabled = 1;
return 0;
 }
 
-static int cx8800_resume(struct pci_dev *pci_dev)
+static int __maybe_unused cx8800_resume(struct device *dev_d)
 {
-   struct cx8800_dev *dev = pci_get_drvdata(pci_dev);
+   struct cx8800_dev *dev = dev_get_drvdata(dev_d);
struct cx88_core *core = dev->core;
unsigned long flags;
-   int err;
-
-   if (dev->state.disabled) {
-   err = pci_enable_device(pci_dev);
-   if (err) {
-   pr_err("can't enable device\n");
-   return err;
-   }
-
-   dev->state.disabled = 0;
-   }
-   err = pci_set_power_state(pci_dev, PCI_D0);
-   if (err) {
-   pr_err("can't set power state\n");
-   pci_disable_device(pci_dev);
-   dev->state.disabled = 1;
 
-   return err;
-   }
-   pci_restore_state(pci_dev);
+   dev->state.disabled = 0;
 
/* FIXME: re-initialize hardware */
cx88_reset(core);
@@ -1631,7 +1607,6 @@ static int cx8800_resume(struct pci_dev *pci_dev)
 
return 0;
 }
-#endif
 
 /* --- */
 
@@ -1647,15 +1622,14 @@ static const struct pci_device_id cx8800_pci_tbl[] = {
 };
 MODULE_DEVICE_TABLE(pci, cx8800_pci_tbl);
 
+static SIMPLE_DEV_PM_OPS(cx8800_pm_ops, cx8800_suspend, cx8800_resume);
+
 static struct pci_driver cx8800_pci_driver = {
-   .name = "cx8800",
-   .id_table = cx8800_pci_tbl,
-   .probe= cx8800_initdev,
-   .remove   = cx8800_finidev,
-#ifdef CONFIG_PM
-   .suspend  = cx8800_suspend,
-   .resume   = cx8800_resume,
-#endif
+   .name  = "cx8800",
+   .id_table  = cx8800_pci_tbl,
+   .probe = cx8800_initdev,
+   .remove= cx8800_finidev,
+   .driver.pm = _pm_ops,
 };
 
 module_pci_driver(cx8800_pci_driver);
-- 
2.27.0

[PATCH v2 3/6] cx25821: use generic power management

[Vaibhav Gupta]

The .suspend() and .resume() callbacks are not defined for this driver.
Still, their power management structure follows the legacy framework. To
bring it under the generic framework, simply remove the binding of
callbacks from struct "pci_driver".

Compile-tested only.

Signed-off-by: Vaibhav Gupta 
---
 drivers/media/pci/cx25821/cx25821-core.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/media/pci/cx25821/cx25821-core.c 
b/drivers/media/pci/cx25821/cx25821-core.c
index 41be22ce66f3..55018d9e439f 100644
--- a/drivers/media/pci/cx25821/cx25821-core.c
+++ b/drivers/media/pci/cx25821/cx25821-core.c
@@ -1374,9 +1374,6 @@ static struct pci_driver cx25821_pci_driver = {
.id_table = cx25821_pci_tbl,
.probe = cx25821_initdev,
.remove = cx25821_finidev,
-   /* TODO */
-   .suspend = NULL,
-   .resume = NULL,
 };
 
 static int __init cx25821_init(void)
-- 
2.27.0

[PATCH v2 5/6] meye: use generic power management

[Vaibhav Gupta]

With legacy PM, drivers themselves were responsible for managing the
device's power states and takes care of register states.

After upgrading to the generic structure, PCI core will take care of
required tasks and drivers should do only device-specific operations.

The driver was invoking PCI helper functions like pci_save/restore_state()
which is not recommended.

Compile-tested only.

Signed-off-by: Vaibhav Gupta 
---
 drivers/media/pci/meye/meye.c | 15 +--
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/media/pci/meye/meye.c b/drivers/media/pci/meye/meye.c
index 73e064e6f56d..7fb3b1853b87 100644
--- a/drivers/media/pci/meye/meye.c
+++ b/drivers/media/pci/meye/meye.c
@@ -1528,19 +1528,16 @@ static const struct v4l2_ctrl_ops meye_ctrl_ops = {
.s_ctrl = meye_s_ctrl,
 };
 
-#ifdef CONFIG_PM
-static int meye_suspend(struct pci_dev *pdev, pm_message_t state)
+static int __maybe_unused meye_suspend(struct device *dev)
 {
-   pci_save_state(pdev);
meye.pm_mchip_mode = meye.mchip_mode;
mchip_hic_stop();
mchip_set(MCHIP_MM_INTA, 0x0);
return 0;
 }
 
-static int meye_resume(struct pci_dev *pdev)
+static int __maybe_unused meye_resume(struct device *dev)
 {
-   pci_restore_state(pdev);
pci_write_config_word(meye.mchip_dev, MCHIP_PCI_SOFTRESET_SET, 1);
 
mchip_delay(MCHIP_HIC_CMD, 0);
@@ -1562,7 +1559,6 @@ static int meye_resume(struct pci_dev *pdev)
}
return 0;
 }
-#endif
 
 static int meye_probe(struct pci_dev *pcidev, const struct pci_device_id *ent)
 {
@@ -1788,15 +1784,14 @@ static const struct pci_device_id meye_pci_tbl[] = {
 
 MODULE_DEVICE_TABLE(pci, meye_pci_tbl);
 
+static SIMPLE_DEV_PM_OPS(meye_pm_ops, meye_suspend, meye_resume);
+
 static struct pci_driver meye_driver = {
.name   = "meye",
.id_table   = meye_pci_tbl,
.probe  = meye_probe,
.remove = meye_remove,
-#ifdef CONFIG_PM
-   .suspend= meye_suspend,
-   .resume = meye_resume,
-#endif
+   .driver.pm  = _pm_ops,
 };
 
 static int __init meye_init(void)
-- 
2.27.0

[PATCH v2 1/6] sta2x11: use generic power management

[Vaibhav Gupta]

With legacy PM, drivers themselves were responsible for managing the
device's power states and takes care of register states.

After upgrading to the generic structure, PCI core will take care of
required tasks and drivers should do only device-specific operations.

Thus, there is no need to call the PCI helper functions like
pci_enable_device(), pci_save/restore_sate(), etc.

Compile-tested only.

Signed-off-by: Vaibhav Gupta 
---
 drivers/media/pci/sta2x11/sta2x11_vip.c | 63 ++---
 1 file changed, 15 insertions(+), 48 deletions(-)

diff --git a/drivers/media/pci/sta2x11/sta2x11_vip.c 
b/drivers/media/pci/sta2x11/sta2x11_vip.c
index 798574cfad35..0fdb0fd6e764 100644
--- a/drivers/media/pci/sta2x11/sta2x11_vip.c
+++ b/drivers/media/pci/sta2x11/sta2x11_vip.c
@@ -1167,21 +1167,18 @@ static void sta2x11_vip_remove_one(struct pci_dev *pdev)
 */
 }
 
-#ifdef CONFIG_PM
-
 /**
  * sta2x11_vip_suspend - set device into power save mode
- * @pdev: PCI device
- * @state: new state of device
+ * @dev_d: PCI device
  *
  * all relevant registers are saved and an attempt to set a new state is made.
  *
  * return value: 0 always indicate success,
  * even if device could not be disabled. (workaround for hardware problem)
  */
-static int sta2x11_vip_suspend(struct pci_dev *pdev, pm_message_t state)
+static int __maybe_unused sta2x11_vip_suspend(struct device *dev_d)
 {
-   struct v4l2_device *v4l2_dev = pci_get_drvdata(pdev);
+   struct v4l2_device *v4l2_dev = dev_get_drvdata(dev_d);
struct sta2x11_vip *vip =
container_of(v4l2_dev, struct sta2x11_vip, v4l2_dev);
unsigned long flags;
@@ -1198,15 +1195,8 @@ static int sta2x11_vip_suspend(struct pci_dev *pdev, 
pm_message_t state)
vip->register_save_area[SAVE_COUNT + IRQ_COUNT + i] =
reg_read(vip, registers_to_save[i]);
spin_unlock_irqrestore(>slock, flags);
-   /* save pci state */
-   pci_save_state(pdev);
-   if (pci_set_power_state(pdev, pci_choose_state(pdev, state))) {
-   /*
-* do not call pci_disable_device on sta2x11 because it
-* break all other Bus masters on this EP
-*/
-   vip->disabled = 1;
-   }
+
+   vip->disabled = 1;
 
pr_info("VIP: suspend\n");
return 0;
@@ -1214,45 +1204,23 @@ static int sta2x11_vip_suspend(struct pci_dev *pdev, 
pm_message_t state)
 
 /**
  * sta2x11_vip_resume - resume device operation
- * @pdev : PCI device
- *
- * re-enable device, set PCI state to powered and restore registers.
- * resume normal device operation afterwards.
+ * @dev_d : PCI device
  *
  * return value: 0, no error.
  *
  * other, could not set device to power on state.
  */
-static int sta2x11_vip_resume(struct pci_dev *pdev)
+static int __maybe_unused sta2x11_vip_resume(struct device *dev_d)
 {
-   struct v4l2_device *v4l2_dev = pci_get_drvdata(pdev);
+   struct v4l2_device *v4l2_dev = dev_get_drvdata(dev_d);
struct sta2x11_vip *vip =
container_of(v4l2_dev, struct sta2x11_vip, v4l2_dev);
unsigned long flags;
-   int ret, i;
+   int i;
 
pr_info("VIP: resume\n");
-   /* restore pci state */
-   if (vip->disabled) {
-   ret = pci_enable_device(pdev);
-   if (ret) {
-   pr_warn("VIP: Can't enable device.\n");
-   return ret;
-   }
-   vip->disabled = 0;
-   }
-   ret = pci_set_power_state(pdev, PCI_D0);
-   if (ret) {
-   /*
-* do not call pci_disable_device on sta2x11 because it
-* break all other Bus masters on this EP
-*/
-   pr_warn("VIP: Can't enable device.\n");
-   vip->disabled = 1;
-   return ret;
-   }
 
-   pci_restore_state(pdev);
+   vip->disabled = 0;
 
spin_lock_irqsave(>slock, flags);
for (i = 1; i < SAVE_COUNT; i++)
@@ -1266,22 +1234,21 @@ static int sta2x11_vip_resume(struct pci_dev *pdev)
return 0;
 }
 
-#endif
-
 static const struct pci_device_id sta2x11_vip_pci_tbl[] = {
{PCI_DEVICE(PCI_VENDOR_ID_STMICRO, PCI_DEVICE_ID_STMICRO_VIP)},
{0,}
 };
 
+static SIMPLE_DEV_PM_OPS(sta2x11_vip_pm_ops,
+sta2x11_vip_suspend,
+sta2x11_vip_resume);
+
 static struct pci_driver sta2x11_vip_driver = {
.name = KBUILD_MODNAME,
.probe = sta2x11_vip_init_one,
.remove = sta2x11_vip_remove_one,
.id_table = sta2x11_vip_pci_tbl,
-#ifdef CONFIG_PM
-   .suspend = sta2x11_vip_suspend,
-   .resume = sta2x11_vip_resume,
-#endif
+   .driver.pm = _vip_pm_ops,
 };
 
 static int __init sta2x11_vip_init_module(void)
-- 
2.27.0

[PATCH v2 2/6] cx23885: use generic power management

[Vaibhav Gupta]

The .suspend() and .resume() callbacks are not defined for this driver.
Still, their power management structure follows the legacy framework. To
bring it under the generic framework, simply remove the binding of
callbacks from struct "pci_driver".

Compile-tested only.

Signed-off-by: Vaibhav Gupta 
---
 drivers/media/pci/cx23885/cx23885-core.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/media/pci/cx23885/cx23885-core.c 
b/drivers/media/pci/cx23885/cx23885-core.c
index 7e0b0b7cc2a3..4b0c53f61fb7 100644
--- a/drivers/media/pci/cx23885/cx23885-core.c
+++ b/drivers/media/pci/cx23885/cx23885-core.c
@@ -2235,9 +2235,6 @@ static struct pci_driver cx23885_pci_driver = {
.id_table = cx23885_pci_tbl,
.probe= cx23885_initdev,
.remove   = cx23885_finidev,
-   /* TODO */
-   .suspend  = NULL,
-   .resume   = NULL,
 };
 
 static int __init cx23885_init(void)
-- 
2.27.0

Re: [PATCH V2 2/2] arm64: imx: Select TPM driver by default

[Daniel Lezcano]

On 08/07/2020 05:16, Anson Huang wrote:
> Select CLKSRC_IMX_TPM for ARCH_MXC by default.
> 
> Signed-off-by: Anson Huang 
> ---
> No change.
> ---
>  arch/arm64/Kconfig.platforms | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index 8dd05b2..c52b7a0 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -169,6 +169,7 @@ config ARCH_MXC
>   bool "ARMv8 based NXP i.MX SoC family"
>   select ARM64_ERRATUM_843419
>   select ARM64_ERRATUM_845719 if COMPAT
> + select CLKSRC_IMX_TPM
>   select IMX_GPCV2
>   select IMX_GPCV2_PM_DOMAINS
>   select PM

Shall I take this patch also or just 1/2 ?


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

Follow Linaro:   Facebook |
 Twitter |
 Blog

[PATCH v2 0/6] [media] pci: use generic power management

[Vaibhav Gupta]

Linux Kernel Mentee: Remove Legacy Power Management.

The purpose of this patch series is to upgrade power management in media
drivers. This has been done by upgrading .suspend() and .resume() callbacks.

The upgrade makes sure that the involvement of PCI Core does not change the
order of operations executed in a driver. Thus, does not change its behavior.

In general, drivers with legacy PM, .suspend() and .resume() make use of PCI
helper functions like pci_enable/disable_device_mem(), pci_set_power_state(),
pci_save/restore_state(), pci_enable/disable_device(), etc. to complete
their job.

The conversion requires the removal of those function calls, change the
callbacks' definition accordingly and make use of dev_pm_ops structure.

v2: v1 possibly broke cx23885 and cx25821.

All patches are compile-tested only.

Test tools:
- Compiler: gcc (GCC) 10.1.0
- allmodconfig build: make -j$(nproc) W=1 all

Vaibhav Gupta (6):
  sta2x11: use generic power management
  cx23885: use generic power management
  cx25821: use generic power management
  cx88: use generic power management
  meye: use generic power management
  tw68: use generic power management

 drivers/media/pci/cx23885/cx23885-core.c |  3 --
 drivers/media/pci/cx25821/cx25821-core.c |  3 --
 drivers/media/pci/cx88/cx88-video.c  | 52 +--
 drivers/media/pci/meye/meye.c| 15 ++
 drivers/media/pci/sta2x11/sta2x11_vip.c  | 63 ++--
 drivers/media/pci/tw68/tw68-core.c   | 30 +--
 6 files changed, 44 insertions(+), 122 deletions(-)

-- 
2.27.0

Re: [virtio-dev] [RFC for Linux v4 0/2] virtio_balloon: Add VIRTIO_BALLOON_F_CONT_PAGES to report continuous pages

[teawater]

> 2020年7月16日 18:45，Michael S. Tsirkin  写道：
> 
> On Thu, Jul 16, 2020 at 03:01:18PM +0800, teawater wrote:
>> 
>> 
>>> 2020年7月16日 14:38，Michael S. Tsirkin  写道：
>>> 
>>> On Thu, Jul 16, 2020 at 10:41:50AM +0800, Hui Zhu wrote:
 The first, second and third version are in [1], [2] and [3].
 Code of current version for Linux and qemu is available in [4] and [5].
 Update of this version:
 1. Report continuous pages will increase the speed.  So added deflate
  continuous pages.
 2. According to the comments from David in [6], added 2 new vqs 
 inflate_cont_vq
  and deflate_cont_vq to report continuous pages with format 32 bits pfn 
 and 32
  bits size.
 Following is the introduction of the function.
 These patches add VIRTIO_BALLOON_F_CONT_PAGES to virtio_balloon. With this
 flag, balloon tries to use continuous pages to inflate and deflate.
 Opening this flag can bring two benefits:
 1. Report continuous pages will increase memory report size of each time
  call tell_host.  Then it will increase the speed of balloon inflate and
  deflate.
 2. Host THPs will be splitted when qemu release the page of balloon 
 inflate.
  Inflate balloon with continuous pages will let QEMU release the pages
  of same THPs.  That will help decrease the splitted THPs number in
  the host.
  Following is an example in a VM with 1G memory 1CPU.  This test setups an
  environment that has a lot of fragmentation pages.  Then inflate balloon 
 will
  split the THPs.
>> 
>> 
 // This is the THP number before VM execution in the host.
 // None use THP.
 cat /proc/meminfo | grep AnonHugePages:
 AnonHugePages: 0 kB
>> These lines are from host.
>> 
 // After VM start, use usemem
 // (https://git.kernel.org/pub/scm/linux/kernel/git/wfg/vm-scalability.git)
 // punch-holes function generates 400m fragmentation pages in the guest
 // kernel.
 usemem --punch-holes -s -1 800m &
>> These lines are from guest.  They setups the environment that has a lot of 
>> fragmentation pages.
>> 
 // This is the THP number after this command in the host.
 // Some THP is used by VM because usemem will access 800M memory
 // in the guest.
 cat /proc/meminfo | grep AnonHugePages:
 AnonHugePages:911360 kB
>> These lines are from host.
>> 
 // Connect to the QEMU monitor, setup balloon, and set it size to 600M.
 (qemu) device_add virtio-balloon-pci,id=balloon1
 (qemu) info balloon
 balloon: actual=1024
 (qemu) balloon 600
 (qemu) info balloon
 balloon: actual=600
>> These lines are from host.
>> 
 // This is the THP number after inflate the balloon in the host.
 cat /proc/meminfo | grep AnonHugePages:
 AnonHugePages: 88064 kB
>> These lines are from host.
>> 
 // Set the size back to 1024M in the QEMU monitor.
 (qemu) balloon 1024
 (qemu) info balloon
 balloon: actual=1024
>> These lines are from host.
>> 
 // Use usemem to increase the memory usage of QEMU.
 killall usemem
 usemem 800m
>> These lines are from guest.
>> 
 // This is the THP number after this operation.
 cat /proc/meminfo | grep AnonHugePages:
 AnonHugePages: 65536 kB
>> These lines are from host.
>> 
>> 
>> 
 
 Following example change to use continuous pages balloon.  The number of
 splitted THPs is decreased.
 // This is the THP number before VM execution in the host.
 // None use THP.
 cat /proc/meminfo | grep AnonHugePages:
 AnonHugePages: 0 kB
>> These lines are from host.
>> 
 // After VM start, use usemem punch-holes function generates 400M
 // fragmentation pages in the guest kernel.
 usemem --punch-holes -s -1 800m &
>> These lines are from guest.  They setups the environment that has a lot of 
>> fragmentation pages.
>> 
 // This is the THP number after this command in the host.
 // Some THP is used by VM because usemem will access 800M memory
 // in the guest.
 cat /proc/meminfo | grep AnonHugePages:
 AnonHugePages:911360 kB
>> These lines are from host.
>> 
 // Connect to the QEMU monitor, setup balloon, and set it size to 600M.
 (qemu) device_add virtio-balloon-pci,id=balloon1,cont-pages=on
 (qemu) info balloon
 balloon: actual=1024
 (qemu) balloon 600
 (qemu) info balloon
 balloon: actual=600
>> These lines are from host.
>> 
 // This is the THP number after inflate the balloon in the host.
 cat /proc/meminfo | grep AnonHugePages:
 AnonHugePages:616448 kB
 // Set the size back to 1024M in the QEMU monitor.
 (qemu) balloon 1024
 (qemu) info balloon
 balloon: actual=1024
>> These lines are from host.
>> 
 // Use usemem to increase the memory usage of QEMU.
 killall usemem
 usemem 800m
>> These lines are from guest.
>> 
 // This is the THP number after this operation.
 cat 

Re: [PATCH -next] rsxx: Convert to DEFINE_SHOW_ATTRIBUTE

[miaoqinglang]

在 2020/7/17 10:16, Jens Axboe 写道:

On 7/16/20 7:37 PM, miaoqinglang wrote:


在 2020/7/16 23:45, Jens Axboe 写道:

On 7/16/20 3:04 AM, Qinglang Miao wrote:

From: Liu Shixin 

Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.

None of these apply against the 5.9 block tree, looks like some
read -> read_iter conversion has happened in another branch that
I'm not privy to.


Hi Jens,

  Sorry I didn't mention it in commit log, but this patch is based
on linux-next where commit <4d4901c6d7> has switched over direct
seq_read method calls to seq_read_iter, this is why there's conflict in
your apply.

  Do you think I should send a new patch based on 5.8rc?


That'll just create a needless conflict. But I don't even know what tree
is carrying the patch that changes it to use seq_read_iter, so hard to
make other suggestions.

This patch is against linux-next, which is ahead of both
linux-block and mainline tree.  Here's the interlinkage:

https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next/+/4d4901c6d748efab8aab6e7d2405dadaed0bea50](javascript:;)

or you can find the commit <4d4901c6d7> which changes seq_read to 
seq_read_iter with the -next tag, in fact, it's just a simple script:


sed -i -e 's/\.read\(\s*=\s*\)seq_read/\.read_iter\1seq_read_iter/g'

By the way, there won't be needless confict because seq_read in both
file and macro are switched to seq_read_iter together.


Alternatively, I can hang on to them until the other change hits
mainline, and then queue them up after that.


That looks good to me. Let me know if patch based on 5.8rc is needed.

Thanks.

Qinglang

.

PROBLEM: [e1000e] 10% throughput drop on I219-LM after the buffer overrun fix even with TSO disabled

[qianshangshu.1997]

[1.] One line summary of the problem:

[e1000e] 10% throughput drop on I219-LM after the buffer overrun fix even
with TSO disabled

[2.] Full description of the problem/report:

With e1000e 3.6.2-k and 3.8.4-NAPI driver, which include the fix for the
buffer overrun problem
(https://github.com/torvalds/linux/commit/b10effb92e272051dd1ec0d7be56bf9ca8
5ab927, discussion: https://www.spinics.net/lists/netdev/msg460589.html),
I219-LM network card have a 10% throughput drop in the iperf3 test (with TSO
and GSO disabled) compared with the driver without such patch, and the
client is initiating the stream in such test (iperf3 client mode without -R
option). If the server is initiating the stream (with -R option in iperf3
client mode), the performance is not impacted.

That is to say, disabling TSO and GSO as suggested in that patch still have
performance impact on the TCP stream, and the throughput drops about 10%.

I tried to rollback the patch introduced to fix the buffer overrun problem
in the 3.8.4-NAPI driver, with TSO and GSO enabled, iperf3 test still cannot
max out my 1Gbps uplink. However, with TSO and GSO disabled, 1Gbps uplink
can be fully saturated.

I'll attach iperf3 test results for all these situations later in this
email.

[3.] Keywords

Network driver, e1000e

[4.] Kernel information
[4.1.] Kernel version (from /proc/version):

Linux version 5.4.0-31-generic (buildd@lgw01-amd64-059) (gcc version 9.3.0
(Ubuntu 9.3.0-10ubuntu2)) #35-Ubuntu SMP Thu May 7 20:20:34 UTC 2020

[4.2.] Kernel .config file:

https://kernel.ubuntu.com/~kernel-ppa/config/focal/linux/5.4.0-31.35/amd64-c
onfig.flavour.generic

[5.] Most recent kernel version which did not have the bug:

V4.14.2

[6.] Environment

00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (2)
I219-LM (rev 31) 

driver: e1000e
version: 3.2.6-k
firmware-version: 0.8-4
expansion-rom-version:
bus-info: :00:1f.6
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no

iperf3:
iperf 3.7 (cJSON 1.5.2)
Linux Hetzner 5.4.0-31-generic #35-Ubuntu SMP Thu May 7 20:20:34 UTC 2020
x86_64 Optional features available: CPU affinity setting, IPv6 flow label,
SCTP, TCP congestion algorithm setting, sendfile / zerocopy, socket pacing,
authentication

[X.] Other notes, patches, fixes, workarounds:

3.6.2-k w/ TSO & GSO

iperf3 -c bouygues.iperf.fr -d -P 5

[ ID] Interval   Transfer Bitrate Retr
[  5]   0.00-10.00  sec   120 MBytes   101 Mbits/sec0 sender
[  5]   0.00-10.02  sec   119 MBytes  99.4 Mbits/sec
receiver
[  7]   0.00-10.00  sec   120 MBytes   101 Mbits/sec0 sender
[  7]   0.00-10.02  sec   119 MBytes  99.4 Mbits/sec
receiver
[  9]   0.00-10.00  sec   120 MBytes   101 Mbits/sec0 sender
[  9]   0.00-10.02  sec   119 MBytes  99.4 Mbits/sec
receiver
[ 11]   0.00-10.00  sec   120 MBytes   101 Mbits/sec0 sender
[ 11]   0.00-10.02  sec   119 MBytes  99.5 Mbits/sec
receiver
[ 13]   0.00-10.00  sec   120 MBytes   101 Mbits/sec0 sender
[ 13]   0.00-10.02  sec   119 MBytes  99.5 Mbits/sec
receiver
[SUM]   0.00-10.00  sec   601 MBytes   504 Mbits/sec0 sender
[SUM]   0.00-10.02  sec   594 MBytes   497 Mbits/sec
receiver

iperf3 -c bouygues.iperf.fr -d -P 5 -R

[ ID] Interval   Transfer Bitrate Retr
[  5]   0.00-10.02  sec   351 MBytes   293 Mbits/sec  134 sender
[  5]   0.00-10.00  sec   344 MBytes   289 Mbits/sec
receiver
[  7]   0.00-10.02  sec   204 MBytes   171 Mbits/sec  331 sender
[  7]   0.00-10.00  sec   201 MBytes   168 Mbits/sec
receiver
[  9]   0.00-10.02  sec   174 MBytes   146 Mbits/sec  226 sender
[  9]   0.00-10.00  sec   171 MBytes   144 Mbits/sec
receiver
[ 11]   0.00-10.02  sec   177 MBytes   148 Mbits/sec  226 sender
[ 11]   0.00-10.00  sec   173 MBytes   145 Mbits/sec
receiver
[ 13]   0.00-10.02  sec   164 MBytes   138 Mbits/sec  229 sender
[ 13]   0.00-10.00  sec   161 MBytes   135 Mbits/sec
receiver
[SUM]   0.00-10.02  sec  1.04 GBytes   896 Mbits/sec  1146
sender
[SUM]   0.00-10.00  sec  1.03 GBytes   881 Mbits/sec
receiver

3.6.2-k w/o TSO & GSO

iperf3 -c bouygues.iperf.fr -d -P 5

[ ID] Interval   Transfer Bitrate Retr
[  5]   0.00-10.00  sec   190 MBytes   159 Mbits/sec0 sender
[  5]   0.00-10.02  sec   188 MBytes   157 Mbits/sec
receiver
[  7]   0.00-10.00  sec   190 MBytes   160 Mbits/sec0 sender
[  7]   0.00-10.02  sec   188 MBytes   157 Mbits/sec
receiver
[  9]   0.00-10.00  sec   191 MBytes   160 Mbits/sec0 sender
[  9]   0.00-10.02  sec   188 MBytes   158 Mbits/sec
receiver
[ 11]   0.00-10.00  sec   190 MBytes   160 Mbits/sec0 sender
[ 11]   0.00-10.02  sec   188 MBytes   158 Mbits/sec
receiver
[ 13]   0.00-10.00  sec   191 MBytes   160 Mbits/sec0 sender
[ 13]   

RE: [PATCH 0/2] Modularization of DFL private feature drivers

[Wu, Hao]

> Subject: Re: [PATCH 0/2] Modularization of DFL private feature drivers
> 
> Generally i think this is a good approach.
> 
> However I do have concern.
> 
> The feature_id in dfl is magic number, similar to pci id but without a vendor
> id.
> 
> Is it possible to add something like a vendor id so different vendors would
> not have to be so careful to use a unique id ?

Hi Tom,

Thanks for the comments.

Here is only one field defined in spec, that is feature id to distinguish one
feature with another one. There is no vendor id here I think, and several
cards are using this for now and seems not possible to change DFH format
for these products. : (

I fully understand the concern is the feature id management, and potential
conflicts there from different vendors. One possible method to resolve this
is managing the ids in a public place (web? Or just the driver header file for
feature id definition), all vendors can request some feature ids, and other
people can see which feature ids have been used so that they can avoid
using conflict ones with other people.

And in the later version DFH, this feature id will be replaced with GUID
I think, so it can resolve the conflict problems from different vendors?
But now, we still need to handle the existing ones. : )

Thanks
Hao

> 
> This touches some of the matching function of the bus ops.  Could there be a
> way for bus ops to be used so that there could be multiple matching
> function.  Maybe the one in 0002 as a default so users could override it ?
> 
> The use case I am worrying about is an OEM.  The OEM uses an unclaimed
> feature_id and supplies their own platform device device driver to match the
> feature_id.  But some later version of the kernel claims this feature_id and
> the OEM's driver no longer works and since the value comes from pci config
> space it is difficult to change.
> 
> So looking for something like
> 
> register_feature_matcher((*bus_match)(struct device *dev, struct
> device_driver *drv))
> 
> static int dfl_bus_match_default(struct device *dev, struct device_driver 
> *drv)
> {
>     struct dfl_device *dfl_dev = to_dfl_dev(dev);
>     struct dfl_driver *dfl_drv = to_dfl_drv(drv);
>     const struct dfl_device_id *id_entry = dfl_drv->id_table;
> 
>     while (id_entry->feature_id) {
>         if (dfl_match_one_device(id_entry, dfl_dev)) {
>             dfl_dev->id_entry = id_entry;
>             return 1;
>         }
>         id_entry++;
>     }
> 
>     return 0;
> }
> 
> register_feature_matcher(_bus_match_default)
> 
> static int dfl_bus_match(struct device *dev, struct device_driver *drv)
> {
> 
>     struct dfl_device *dfl_dev = to_dfl_dev(dev);
>     struct dfl_driver *dfl_drv = to_dfl_drv(drv);
>     const struct dfl_device_id *id_entry = dfl_drv->id_table;
> 
>     while (id_entry->feature_id) {
> 
>         matcher = Loop over matchers()
> 
>         if (matcher(dev, drv)) {
>         dfl_dev->id_entry = id_entry;
>         return 1;
>     }
>         id_entry++;
>     }
> 
>     return 0;
> }
> 
> Or maybe use some of the unused bits in the dfl header to add a second
> vendor-like id and change existing matcher to look feature_id and
> vendor_like_id.
> 
> Tom
> 
> 
> 
> On 7/14/20 10:38 PM, Xu Yilun wrote:
> > This patchset makes it possible to develop independent driver modules
> > for DFL private features. It also helps to leverage existing kernel
> > drivers to enable some IP blocks in DFL.
> >
> > Xu Yilun (2):
> >   fpga: dfl: map feature mmio resources in their own feature drivers
> >   fpga: dfl: create a dfl bus type to support DFL devices
> >
> >  Documentation/ABI/testing/sysfs-bus-dfl |  15 ++
> >  drivers/fpga/dfl-pci.c  |  21 +-
> >  drivers/fpga/dfl.c  | 435 
> > +++-
> >  drivers/fpga/dfl.h  |  91 ++-
> >  4 files changed, 492 insertions(+), 70 deletions(-)
> >  create mode 100644 Documentation/ABI/testing/sysfs-bus-dfl
> >

[git pull] drm fixes for 5.8-rc6

[Dave Airlie]

Hi Linus,

Weekly fixes pull, big bigger than I'd normally like, but they are
fairly scattered and small individually. The vmwgfx one is a black
screen regression, otherwise the largest is an MST encoder fix for
amdgpu which results in a WARN in some cases, and a scattering of i915
fixes.

I'm tracking two regressions at the moment that hopefully we get
nailed down this week for rc7.

Dave.

drm-fixes-2020-07-17-1:
drm fixes for 5.8-rc6

dma-buf:
- sleeping atomic fix

amdgpu:
- Fix a race condition with KIQ
- Preemption fix
- Fix handling of fake MST encoders
- OLED panel fix
- Handle allocation failure in stream construction
- Renoir SMC fix
- SDMA 5.x fix

i915:
- FBC w/a stride fix
- Fix use-after-free fix on module reload
- Ignore irq enabling on the virtual engines to fix device sleep
- Use GTT when saving/restoring engine GPR
- Fix selftest sort function

vmwgfx:
- black screen fix

aspeed:
- fbcon init warn fix
The following changes since commit 11ba468877bb23f28956a35e896356252d63c983:

  Linux 5.8-rc5 (2020-07-12 16:34:50 -0700)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-07-17-1

for you to fetch changes up to adbe8a3cae94a63e9f416795c750237a9b789124:

  Merge tag 'amd-drm-fixes-5.8-2020-07-15' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes (2020-07-17
13:29:00 +1000)


drm fixes for 5.8-rc6

dma-buf:
- sleeping atomic fix

amdgpu:
- Fix a race condition with KIQ
- Preemption fix
- Fix handling of fake MST encoders
- OLED panel fix
- Handle allocation failure in stream construction
- Renoir SMC fix
- SDMA 5.x fix

i915:
- FBC w/a stride fix
- Fix use-after-free fix on module reload
- Ignore irq enabling on the virtual engines to fix device sleep
- Use GTT when saving/restoring engine GPR
- Fix selftest sort function

vmwgfx:
- black screen fix

aspeed:
- fbcon init warn fix


Alex Deucher (1):
  drm/amdgpu/display: create fake mst encoders ahead of time (v4)

Charan Teja Kalla (1):
  dmabuf: use spinlock to access dmabuf->name

Chris Wilson (2):
  drm/i915/gt: Ignore irq enabling on the virtual engines
  drm/i915/gt: Only swap to a random sibling once upon creation

Dave Airlie (4):
  Merge branch 'vmwgfx-fixes-5.8' of
git://people.freedesktop.org/~sroland/linux into drm-fixes
  Merge tag 'drm-misc-fixes-2020-07-15' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
  Merge tag 'drm-intel-fixes-2020-07-15' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
  Merge tag 'amd-drm-fixes-5.8-2020-07-15' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes

Guenter Roeck (1):
  drm/aspeed: Call drm_fbdev_generic_setup after drm_dev_register

Jack Xiao (2):
  drm/amdgpu/gfx10: fix race condition for kiq
  drm/amdgpu: fix preemption unit test

Josip Pavic (1):
  drm/amd/display: handle failed allocation during stream construction

Maarten Lankhorst (1):
  drm/i915: Move cec_notifier to intel_hdmi_connector_unregister, v2.

Roland Scheidegger (1):
  drm/vmwgfx: fix update of display surface when resolution changes

Sudeep Holla (1):
  drm/i915/selftests: Fix compare functions provided for sorting

Umesh Nerlige Ramappa (1):
  drm/i915/perf: Use GTT when saving/restoring engine GPR

Ville Syrjälä (1):
  drm/i915: Recalculate FBC w/a stride when needed

Xiaojie Yuan (1):
  drm/amdgpu/sdma5: fix wptr overwritten in ->get_wptr()

chen gong (1):
  drm/amdgpu/powerplay: Modify SMC message name for setting power
profile mode

hersen wu (1):
  drm/amd/display: OLED panel backlight adjust not work with
external display connected

 drivers/dma-buf/dma-buf.c  | 11 +++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c| 20 ++--
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c |  9 +++-
 drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c | 26 ---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  | 14 ++
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h  | 11 -
 .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 53 +++---
 .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.h|  3 ++
 drivers/gpu/drm/amd/display/dc/core/dc_stream.c| 19 ++--
 drivers/gpu/drm/amd/powerplay/renoir_ppt.c |  2 +-
 drivers/gpu/drm/aspeed/aspeed_gfx_drv.c|  3 +-
 drivers/gpu/drm/i915/display/intel_fbc.c   | 33 +++---
 drivers/gpu/drm/i915/display/intel_hdmi.c  | 10 +---
 drivers/gpu/drm/i915/gt/intel_lrc.c| 19 ++--
 drivers/gpu/drm/i915/gt/selftest_rps.c |  8 ++--
 drivers/gpu/drm/i915/i915_drv.h|  1 +
 drivers/gpu/drm/i915/i915_perf.c   |  1 +
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c   |  8 ++--
 include/linux/dma-buf.h  

Re: [PATCH 1/2] libsubcmd: Fix OPT_CALLBACK_SET()

[Ravi Bangoria]

Hi Arnaldo,

Can you please consider this trivial fix.

Ravi

On 6/19/20 7:04 PM, Ravi Bangoria wrote:

Any option macro with _SET suffix should set opt->set variable which
is not happening for OPT_CALLBACK_SET(). This is causing issues with
perf record --switch-output-event. Fix that.

Before:
   # ./perf record --overwrite -e sched:*switch,syscalls:sys_enter_mmap \
--switch-output-event syscalls:sys_enter_mmap
   ^C[ perf record: Woken up 1 times to write data ]
   [ perf record: Captured and wrote 0.297 MB perf.data (657 samples) ]

After:

   $ ./perf record --overwrite -e sched:*switch,syscalls:sys_enter_mmap \
   --switch-output-event syscalls:sys_enter_mmap
   [ perf record: dump data: Woken up 1 times ]
   [ perf record: Dump perf.data.2020061918144542 ]
   [ perf record: dump data: Woken up 1 times ]
   [ perf record: Dump perf.data.2020061918144608 ]
   [ perf record: dump data: Woken up 1 times ]
   [ perf record: Dump perf.data.2020061918144660 ]
   ^C[ perf record: dump data: Woken up 1 times ]
   [ perf record: Dump perf.data.2020061918144784 ]
   [ perf record: Woken up 0 times to write data ]
   [ perf record: Dump perf.data.2020061918144803 ]
   [ perf record: Captured and wrote 0.419 MB perf.data. ]

Fixes: 636eb4d001b1 ("libsubcmd: Introduce OPT_CALLBACK_SET()")
Signed-off-by: Ravi Bangoria 
---
  tools/lib/subcmd/parse-options.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/tools/lib/subcmd/parse-options.c b/tools/lib/subcmd/parse-options.c
index dbb9efbf718a..39ebf6192016 100644
--- a/tools/lib/subcmd/parse-options.c
+++ b/tools/lib/subcmd/parse-options.c
@@ -237,6 +237,9 @@ static int get_value(struct parse_opt_ctx_t *p,
return err;
  
  	case OPTION_CALLBACK:

+   if (opt->set)
+   *(bool *)opt->set = true;
+
if (unset)
return (*opt->callback)(opt, NULL, 1) ? (-1) : 0;
if (opt->flags & PARSE_OPT_NOARG)

linux-next: build failure after merge of the mfd tree

[Stephen Rothwell]

Hi all,

After merging the mfd tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

drivers/mfd/kempld-core.c: In function 'kempld_register_cells_generic':
drivers/mfd/kempld-core.c:105:13: error: assignment of read-only location 
'devs[i++]'
  105 |   devs[i++] = kempld_devs[KEMPLD_I2C];
  | ^
drivers/mfd/kempld-core.c:108:13: error: assignment of read-only location 
'devs[i++]'
  108 |   devs[i++] = kempld_devs[KEMPLD_WDT];
  | ^
drivers/mfd/kempld-core.c:111:13: error: assignment of read-only location 
'devs[i++]'
  111 |   devs[i++] = kempld_devs[KEMPLD_GPIO];
  | ^
drivers/mfd/kempld-core.c:114:13: error: assignment of read-only location 
'devs[i++]'
  114 |   devs[i++] = kempld_devs[KEMPLD_UART];
  | ^

Caused by commit

  70d48975c152 ("mfd: core: Make a best effort attempt to match devices with 
the correct of_nodes")

I have added the following fix patch for today (I assume that there is
a better solution):

From: Stephen Rothwell 
Date: Fri, 17 Jul 2020 13:36:22 +1000
Subject: [PATCH] fix up for struct mfd_cell change

Fixes: 70d48975c152 ("mfd: core: Make a best effort attempt to match devices 
with the correct of_nodes")
Signed-off-by: Stephen Rothwell 
---
 drivers/mfd/kempld-core.c | 28 ++--
 1 file changed, 10 insertions(+), 18 deletions(-)

diff --git a/drivers/mfd/kempld-core.c b/drivers/mfd/kempld-core.c
index f48e21d8b97c..ad68ee699cb5 100644
--- a/drivers/mfd/kempld-core.c
+++ b/drivers/mfd/kempld-core.c
@@ -79,39 +79,31 @@ enum kempld_cells {
KEMPLD_UART,
 };
 
-static const struct mfd_cell kempld_devs[] = {
-   [KEMPLD_I2C] = {
-   .name = "kempld-i2c",
-   },
-   [KEMPLD_WDT] = {
-   .name = "kempld-wdt",
-   },
-   [KEMPLD_GPIO] = {
-   .name = "kempld-gpio",
-   },
-   [KEMPLD_UART] = {
-   .name = "kempld-uart",
-   },
+static const char *kempld_devs[] = {
+   [KEMPLD_I2C] = "kempld-i2c",
+   [KEMPLD_WDT] = "kempld-wdt",
+   [KEMPLD_GPIO] = "kempld-gpio",
+   [KEMPLD_UART] = "kempld-uart",
 };
 
 #define KEMPLD_MAX_DEVSARRAY_SIZE(kempld_devs)
 
 static int kempld_register_cells_generic(struct kempld_device_data *pld)
 {
-   struct mfd_cell devs[KEMPLD_MAX_DEVS];
+   struct mfd_cell devs[KEMPLD_MAX_DEVS] = {};
int i = 0;
 
if (pld->feature_mask & KEMPLD_FEATURE_BIT_I2C)
-   devs[i++] = kempld_devs[KEMPLD_I2C];
+   devs[i++].name = kempld_devs[KEMPLD_I2C];
 
if (pld->feature_mask & KEMPLD_FEATURE_BIT_WATCHDOG)
-   devs[i++] = kempld_devs[KEMPLD_WDT];
+   devs[i++].name = kempld_devs[KEMPLD_WDT];
 
if (pld->feature_mask & KEMPLD_FEATURE_BIT_GPIO)
-   devs[i++] = kempld_devs[KEMPLD_GPIO];
+   devs[i++].name = kempld_devs[KEMPLD_GPIO];
 
if (pld->feature_mask & KEMPLD_FEATURE_MASK_UART)
-   devs[i++] = kempld_devs[KEMPLD_UART];
+   devs[i++].name = kempld_devs[KEMPLD_UART];
 
return mfd_add_devices(pld->dev, -1, devs, i, NULL, 0, NULL);
 }
-- 
2.27.0

-- 
Cheers,
Stephen Rothwell


pgpOpqrsz0SzX.pgp
Description: OpenPGP digital signature

Re: [PATCH] clocksource: nomadik-mtu: Handle 32kHz clock

[Daniel Lezcano]

On 29/06/2020 00:01, Linus Walleij wrote:
> It happens on the U8420-sysclk Ux500 PRCMU firmware
> variant that the MTU clock is just 32768 Hz, and in this
> mode the minimum ticks is 5 rather than two.
> 
> I think this is simply so that there is enough time
> for the register write to propagate through the
> interconnect to the registers.
> 
> Signed-off-by: Linus Walleij 
> ---

Applied, thanks


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

Follow Linaro:   Facebook |
 Twitter |
 Blog

[PATCH] mmc: sdhci-pci-gli: Set SDR104's clock to 205MHz and enable SSC for GL975x

[Ben Chuang]

From: Ben Chuang 

Set SDR104's clock to 205MHz and enable SSC for GL9750 and GL9755

Signed-off-by: Ben Chuang 
---
 drivers/mmc/host/sdhci-pci-gli.c | 220 ++-
 1 file changed, 218 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/sdhci-pci-gli.c b/drivers/mmc/host/sdhci-pci-gli.c
index ca0166d9bf82..5da2b06d84ae 100644
--- a/drivers/mmc/host/sdhci-pci-gli.c
+++ b/drivers/mmc/host/sdhci-pci-gli.c
@@ -31,10 +31,18 @@
 #define   SDHCI_GLI_9750_ALL_RST  (BIT(24)|BIT(25)|BIT(28)|BIT(30))
 
 #define SDHCI_GLI_9750_PLL   0x864
+#define   SDHCI_GLI_9750_PLL_LDIV   GENMASK(9, 0)
+#define   SDHCI_GLI_9750_PLL_PDIV   GENMASK(14, 12)
+#define   SDHCI_GLI_9750_PLL_DIRBIT(15)
 #define   SDHCI_GLI_9750_PLL_TX2_INVBIT(23)
 #define   SDHCI_GLI_9750_PLL_TX2_DLYGENMASK(22, 20)
 #define   GLI_9750_PLL_TX2_INV_VALUE0x1
 #define   GLI_9750_PLL_TX2_DLY_VALUE0x0
+#define   SDHCI_GLI_9750_PLLSSC_STEPGENMASK(28, 24)
+#define   SDHCI_GLI_9750_PLLSSC_EN  BIT(31)
+
+#define SDHCI_GLI_9750_PLLSSC0x86C
+#define   SDHCI_GLI_9750_PLLSSC_PPMGENMASK(31, 16)
 
 #define SDHCI_GLI_9750_SW_CTRL  0x874
 #define   SDHCI_GLI_9750_SW_CTRL_4GENMASK(7, 6)
@@ -76,6 +84,21 @@
 #define PCIE_GLI_9763E_SCR  0x8E0
 #define   GLI_9763E_SCR_AXI_REQ   BIT(9)
 
+#define PCI_GLI_9755_WT   0x800
+#define   PCI_GLI_9755_WT_ENBIT(0)
+#define   GLI_9755_WT_EN_ON 0x1
+#define   GLI_9755_WT_EN_OFF0x0
+
+#define PCI_GLI_9755_PLL0x64
+#define   PCI_GLI_9755_PLL_LDIV   GENMASK(9, 0)
+#define   PCI_GLI_9755_PLL_PDIV   GENMASK(14, 12)
+#define   PCI_GLI_9755_PLL_DIRBIT(15)
+#define   PCI_GLI_9755_PLLSSC_STEPGENMASK(28, 24)
+#define   PCI_GLI_9755_PLLSSC_EN  BIT(31)
+
+#define PCI_GLI_9755_PLLSSC0x68
+#define   PCI_GLI_9755_PLLSSC_PPMGENMASK(15, 0)
+
 #define GLI_MAX_TUNING_LOOP 40
 
 /* Genesys Logic chipset */
@@ -280,6 +303,84 @@ static int gl9750_execute_tuning(struct sdhci_host *host, 
u32 opcode)
return 0;
 }
 
+static void gl9750_disable_ssc_pll(struct sdhci_host *host)
+{
+   u32 pll;
+
+   gl9750_wt_on(host);
+   pll = sdhci_readl(host, SDHCI_GLI_9750_PLL);
+   pll &= ~(SDHCI_GLI_9750_PLL_DIR | SDHCI_GLI_9750_PLLSSC_EN);
+   sdhci_writel(host, pll, SDHCI_GLI_9750_PLL);
+   gl9750_wt_off(host);
+}
+
+static void gl9750_set_pll(struct sdhci_host *host, u8 dir, u16 ldiv, u8 pdiv)
+{
+   u32 pll;
+
+   gl9750_wt_on(host);
+   pll = sdhci_readl(host, SDHCI_GLI_9750_PLL);
+   pll &= ~(SDHCI_GLI_9750_PLL_LDIV |
+SDHCI_GLI_9750_PLL_PDIV |
+SDHCI_GLI_9750_PLL_DIR);
+   pll |= FIELD_PREP(SDHCI_GLI_9750_PLL_LDIV, ldiv) |
+  FIELD_PREP(SDHCI_GLI_9750_PLL_PDIV, pdiv) |
+  FIELD_PREP(SDHCI_GLI_9750_PLL_DIR, dir);
+   sdhci_writel(host, pll, SDHCI_GLI_9750_PLL);
+   gl9750_wt_off(host);
+
+   /* wait for pll stable */
+   mdelay(1);
+}
+
+static void gl9750_set_ssc(struct sdhci_host *host, u8 enable, u8 step, u16 
ppm)
+{
+   u32 pll;
+   u32 ssc;
+
+   gl9750_wt_on(host);
+   pll = sdhci_readl(host, SDHCI_GLI_9750_PLL);
+   ssc = sdhci_readl(host, SDHCI_GLI_9750_PLLSSC);
+   pll &= ~(SDHCI_GLI_9750_PLLSSC_STEP |
+SDHCI_GLI_9750_PLLSSC_EN);
+   ssc &= ~SDHCI_GLI_9750_PLLSSC_PPM;
+   pll |= FIELD_PREP(SDHCI_GLI_9750_PLLSSC_STEP, step) |
+  FIELD_PREP(SDHCI_GLI_9750_PLLSSC_EN, enable);
+   ssc |= FIELD_PREP(SDHCI_GLI_9750_PLLSSC_PPM, ppm);
+   sdhci_writel(host, ssc, SDHCI_GLI_9750_PLLSSC);
+   sdhci_writel(host, pll, SDHCI_GLI_9750_PLL);
+   gl9750_wt_off(host);
+}
+
+static void gl9750_set_ssc_pll_205mhz(struct sdhci_host *host)
+{
+   /* set pll to 205MHz and enable ssc */
+   gl9750_set_ssc(host, 0x1, 0x1F, 0xFFE7);
+   gl9750_set_pll(host, 0x1, 0x246, 0x0);
+}
+
+static void sdhci_gl9750_set_clock(struct sdhci_host *host, unsigned int clock)
+{
+   struct mmc_ios *ios = >mmc->ios;
+   u16 clk;
+
+   host->mmc->actual_clock = 0;
+
+   gl9750_disable_ssc_pll(host);
+   sdhci_writew(host, 0, SDHCI_CLOCK_CONTROL);
+
+   if (clock == 0)
+   return;
+
+   clk = sdhci_calc_clk(host, clock, >mmc->actual_clock);
+   if (clock == 2 && ios->timing == MMC_TIMING_UHS_SDR104) {
+   host->mmc->actual_clock = 20500;
+   gl9750_set_ssc_pll_205mhz(host);
+   }
+
+   sdhci_enable_clk(host, clk);
+}
+
 static void gli_pcie_enable_msi(struct sdhci_pci_slot *slot)
 {
int ret;
@@ -295,6 +396,121 @@ static void gli_pcie_enable_msi(struct sdhci_pci_slot 
*slot)
slot->host->irq = pci_irq_vector(slot->chip->pdev, 0);
 }
 
+static inline void gl9755_wt_on(struct pci_dev *pdev)
+{
+   u32 wt_value;
+   u32 wt_enable;
+
+   pci_read_config_dword(pdev, PCI_GLI_9755_WT, _value);
+   wt_enable = 

drivers/tty/serial/ip22zilog.c:114:22: sparse: sparse: incorrect type in argument 2 (different address spaces)

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   07a56bb875afbe39dabbf6ba7b83783d166863db
commit: 670d0a4b10704667765f7d18f7592993d02783aa sparse: use identifiers to 
define address spaces
date:   4 weeks ago
config: mips-randconfig-s032-20200717 (attached as .config)
compiler: mips-linux-gcc (GCC) 9.3.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.2-49-g707c5017-dirty
git checkout 670d0a4b10704667765f7d18f7592993d02783aa
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=mips 

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


sparse warnings: (new ones prefixed by >>)

>> drivers/tty/serial/ip22zilog.c:114:22: sparse: sparse: incorrect type in 
>> argument 2 (different address spaces) @@ expected void volatile 
>> [noderef] __iomem *mem @@ got unsigned char volatile * @@
>> drivers/tty/serial/ip22zilog.c:114:22: sparse: expected void volatile 
>> [noderef] __iomem *mem
   drivers/tty/serial/ip22zilog.c:114:22: sparse: got unsigned char 
volatile *
>> drivers/tty/serial/ip22zilog.c:116:25: sparse: sparse: incorrect type in 
>> argument 1 (different address spaces) @@ expected void const volatile 
>> [noderef] __iomem *mem @@ got unsigned char volatile * @@
>> drivers/tty/serial/ip22zilog.c:116:25: sparse: expected void const 
>> volatile [noderef] __iomem *mem
   drivers/tty/serial/ip22zilog.c:116:25: sparse: got unsigned char 
volatile *
   drivers/tty/serial/ip22zilog.c:125:22: sparse: sparse: incorrect type in 
argument 2 (different address spaces) @@ expected void volatile [noderef] 
__iomem *mem @@ got unsigned char volatile * @@
   drivers/tty/serial/ip22zilog.c:125:22: sparse: expected void volatile 
[noderef] __iomem *mem
   drivers/tty/serial/ip22zilog.c:125:22: sparse: got unsigned char 
volatile *
   drivers/tty/serial/ip22zilog.c:127:24: sparse: sparse: incorrect type in 
argument 2 (different address spaces) @@ expected void volatile [noderef] 
__iomem *mem @@ got unsigned char volatile * @@
   drivers/tty/serial/ip22zilog.c:127:24: sparse: expected void volatile 
[noderef] __iomem *mem
   drivers/tty/serial/ip22zilog.c:127:24: sparse: got unsigned char 
volatile *
   drivers/tty/serial/ip22zilog.c:138:33: sparse: sparse: incorrect type in 
argument 1 (different address spaces) @@ expected void const volatile 
[noderef] __iomem *mem @@ got unsigned char volatile * @@
   drivers/tty/serial/ip22zilog.c:138:33: sparse: expected void const 
volatile [noderef] __iomem *mem
   drivers/tty/serial/ip22zilog.c:138:33: sparse: got unsigned char 
volatile *
   drivers/tty/serial/ip22zilog.c:144:24: sparse: sparse: incorrect type in 
argument 1 (different address spaces) @@ expected void const volatile 
[noderef] __iomem *mem @@ got unsigned char volatile * @@
   drivers/tty/serial/ip22zilog.c:144:24: sparse: expected void const 
volatile [noderef] __iomem *mem
   drivers/tty/serial/ip22zilog.c:144:24: sparse: got unsigned char 
volatile *
   drivers/tty/serial/ip22zilog.c:148:42: sparse: sparse: incorrect type in 
argument 2 (different address spaces) @@ expected void volatile [noderef] 
__iomem *mem @@ got unsigned char volatile * @@
   drivers/tty/serial/ip22zilog.c:148:42: sparse: expected void volatile 
[noderef] __iomem *mem
   drivers/tty/serial/ip22zilog.c:148:42: sparse: got unsigned char 
volatile *
   drivers/tty/serial/ip22zilog.c:170:26: sparse: sparse: incorrect type in 
argument 2 (different address spaces) @@ expected void volatile [noderef] 
__iomem *mem @@ got unsigned char volatile * @@
   drivers/tty/serial/ip22zilog.c:170:26: sparse: expected void volatile 
[noderef] __iomem *mem
   drivers/tty/serial/ip22zilog.c:170:26: sparse: got unsigned char 
volatile *
   drivers/tty/serial/ip22zilog.c:256:29: sparse: sparse: incorrect type in 
argument 1 (different address spaces) @@ expected void const volatile 
[noderef] __iomem *mem @@ got unsigned char volatile * @@
   drivers/tty/serial/ip22zilog.c:256:29: sparse: expected void const 
volatile [noderef] __iomem *mem
   drivers/tty/serial/ip22zilog.c:256:29: sparse: got unsigned char 
volatile *
   drivers/tty/serial/ip22zilog.c:263:42: sparse: sparse: incorrect type in 
argument 2 (different address spaces) @@ expected void volatile [noderef] 
__iomem *mem @@ got unsigned char volatile * @@
   drivers/tty/serial/ip22zilog.c:263:42: sparse: expected void volatile 
[noderef] __iomem *mem
   drivers/tty/serial/ip22zilog.c:263:42: sparse: got unsigned char 
volatile *
   

Re: [PATCH] perf evsel: Don't set sample_regs_intr/sample_regs_user for dummy event

[Jin, Yao]

Hi,

On 7/6/2020 8:55 AM, Jin, Yao wrote:

Hi Ian,

On 7/6/2020 8:47 AM, Ian Rogers wrote:

On Fri, Jul 3, 2020 at 5:31 PM Jin, Yao  wrote:


Hi Jiri,

On 7/3/2020 7:00 PM, Jiri Olsa wrote:

On Fri, Jul 03, 2020 at 08:42:15AM +0800, Jin Yao wrote:

Since commit 0a892c1c9472 ("perf record: Add dummy event during system wide 
synthesis"),
a dummy event is added to capture mmaps.

But if we run perf-record as,

   # perf record -e cycles:p -IXMM0 -a -- sleep 1
   Error:
   dummy:HG: PMU Hardware doesn't support sampling/overflow-interrupts. Try 
'perf stat'



Sorry for the breakage caused by modifying the dummy event. Could we
add a test to cover the issue? Perhaps in tools/perf/tests/shell/.
Trying to reproduce with a register on my skylakex on a 5.6.14 kernel
with:

$ perf record -e cycles:p -IAX -a -- sleep 1

succeeds.

Thanks,
Ian



-IAX should be no problem. The issue only occurs on the platform with extended regs supports, such 
as ICL. So I don't know if it's suitable to add it to perf test suite.


Thanks
Jin Yao



Can this fix patch be accepted?

Thanks
Jin Yao


The issue is, if we enable the extended regs (-IXMM0), but the
pmu->capabilities is not set with PERF_PMU_CAP_EXTENDED_REGS, the kernel
will return -EOPNOTSUPP error.

See following code pieces.

/* in kernel/events/core.c */
static int perf_try_init_event(struct pmu *pmu, struct perf_event *event)

{
  
  if (!(pmu->capabilities & PERF_PMU_CAP_EXTENDED_REGS) &&
  has_extended_regs(event))
  ret = -EOPNOTSUPP;
  
}

For software dummy event, the PMU should be not set with
PERF_PMU_CAP_EXTENDED_REGS. But unfortunately in current code, the dummy
event has possibility to be set with PERF_REG_EXTENDED_MASK bit.

In evsel__config, /* tools/perf/util/evsel.c */

if (opts->sample_intr_regs) {
  attr->sample_regs_intr = opts->sample_intr_regs;
}

If we use -IXMM0, the attr>sample_regs_intr will be set with
PERF_REG_EXTENDED_MASK bit.

It doesn't make sense to set attr->sample_regs_intr for a
software dummy event.

This patch adds dummy event checking before setting
attr->sample_regs_intr.

After:
    # ./perf record -e cycles:p -IXMM0 -a -- sleep 1
    [ perf record: Woken up 1 times to write data ]
    [ perf record: Captured and wrote 0.413 MB perf.data (45 samples) ]


LGTM, Adrian (cc-ed) just added another check to the same place,
but it looks like both of them should be there:

    https://lore.kernel.org/lkml/20200630133935.11150-2-adrian.hun...@intel.com/

jirka



Thanks Jiri! Yes, it looks like both of checks should be added here.

So do I post v2 (just rebase) once Adrian's patch gets merged?

Thanks
Jin Yao



Fixes: 0a892c1c9472 ("perf record: Add dummy event during system wide 
synthesis")
Signed-off-by: Jin Yao 
---
   tools/perf/util/evsel.c | 4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 96e5171dce41..df3315543e86 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -1020,12 +1020,12 @@ void evsel__config(struct evsel *evsel, struct 
record_opts *opts,
  if (callchain && callchain->enabled && !evsel->no_aux_samples)
  evsel__config_callchain(evsel, opts, callchain);

-    if (opts->sample_intr_regs) {
+    if (opts->sample_intr_regs && !is_dummy_event(evsel)) {
  attr->sample_regs_intr = opts->sample_intr_regs;
  evsel__set_sample_bit(evsel, REGS_INTR);
  }

-    if (opts->sample_user_regs) {
+    if (opts->sample_user_regs && !is_dummy_event(evsel)) {
  attr->sample_regs_user |= opts->sample_user_regs;
  evsel__set_sample_bit(evsel, REGS_USER);
  }
--
2.17.1

Re: [PATCH 1/1] clocksource: Ingenic: Add high resolution timer support for SMP/SMT.

[Daniel Lezcano]

On 26/05/2020 18:21, 周琰杰 (Zhou Yanjie) wrote:
> Enable clock event handling on per CPU core basis. Make sure that
> interrupts raised on the first core execute event handlers on the
> correct CPU core. This driver is required by Ingenic processors
> that support SMP/SMT, such as JZ4780 and X2000.
> 
> Tested-by: H. Nikolaus Schaller 
> Tested-by: Paul Boddie 
> Signed-off-by: Paul Cercueil 
> Signed-off-by: 周琰杰 (Zhou Yanjie) 
> ---

Applied, thanks

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

Follow Linaro:   Facebook |
 Twitter |
 Blog

[PATCH 10/13] pinctrl: rockchip: Add RK3288 definitions to separate from other SoCs

[Jianqun Xu]

Add RK3288 definitions to separate from other SoCs.

Signed-off-by: Jianqun Xu 
---
 drivers/pinctrl/pinctrl-rockchip.c | 21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-rockchip.c 
b/drivers/pinctrl/pinctrl-rockchip.c
index ec6a1a08f8b1..04e7027ec8e1 100644
--- a/drivers/pinctrl/pinctrl-rockchip.c
+++ b/drivers/pinctrl/pinctrl-rockchip.c
@@ -1855,6 +1855,11 @@ static void rk3188_calc_pull_reg_and_bit(struct 
rockchip_pin_bank *bank,
 }
 
 #define RK3288_PULL_OFFSET 0x140
+#define RK3288_PULL_PMU_OFFSET 0x64
+#define RK3288_PULL_BITS_PER_PIN   2
+#define RK3288_PULL_PINS_PER_REG   8
+#define RK3288_PULL_BANK_STRIDE16
+
 static void rk3288_calc_pull_reg_and_bit(struct rockchip_pin_bank *bank,
int pin_num, struct regmap **regmap,
int *reg, u8 *bit)
@@ -1864,22 +1869,22 @@ static void rk3288_calc_pull_reg_and_bit(struct 
rockchip_pin_bank *bank,
/* The first 24 pins of the first bank are located in PMU */
if (bank->bank_num == 0) {
*regmap = info->regmap_pmu;
-   *reg = RK3188_PULL_PMU_OFFSET;
+   *reg = RK3288_PULL_PMU_OFFSET;
 
-   *reg += ((pin_num / RK3188_PULL_PINS_PER_REG) * 4);
-   *bit = pin_num % RK3188_PULL_PINS_PER_REG;
-   *bit *= RK3188_PULL_BITS_PER_PIN;
+   *reg += ((pin_num / RK3288_PULL_PINS_PER_REG) * 4);
+   *bit = pin_num % RK3288_PULL_PINS_PER_REG;
+   *bit *= RK3288_PULL_BITS_PER_PIN;
} else {
*regmap = info->regmap_base;
*reg = RK3288_PULL_OFFSET;
 
/* correct the offset, as we're starting with the 2nd bank */
*reg -= 0x10;
-   *reg += bank->bank_num * RK3188_PULL_BANK_STRIDE;
-   *reg += ((pin_num / RK3188_PULL_PINS_PER_REG) * 4);
+   *reg += bank->bank_num * RK3288_PULL_BANK_STRIDE;
+   *reg += ((pin_num / RK3288_PULL_PINS_PER_REG) * 4);
 
-   *bit = (pin_num % RK3188_PULL_PINS_PER_REG);
-   *bit *= RK3188_PULL_BITS_PER_PIN;
+   *bit = (pin_num % RK3288_PULL_PINS_PER_REG);
+   *bit *= RK3288_PULL_BITS_PER_PIN;
}
 }
 
-- 
2.17.1

[PATCH 11/13] pinctrl: rockchip: Add RK3128 definitions to separate from other SoCs

[Jianqun Xu]

Add RK3128 definitions to separate from other SoCs.

Signed-off-by: Jianqun Xu 
---
 drivers/pinctrl/pinctrl-rockchip.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-rockchip.c 
b/drivers/pinctrl/pinctrl-rockchip.c
index 04e7027ec8e1..3b74455dcdb2 100644
--- a/drivers/pinctrl/pinctrl-rockchip.c
+++ b/drivers/pinctrl/pinctrl-rockchip.c
@@ -1799,6 +1799,8 @@ static void rk2928_calc_pull_reg_and_bit(struct 
rockchip_pin_bank *bank,
 };
 
 #define RK3128_PULL_OFFSET 0x118
+#define RK3128_PULL_PINS_PER_REG   16
+#define RK3128_PULL_BANK_STRIDE8
 
 static void rk3128_calc_pull_reg_and_bit(struct rockchip_pin_bank *bank,
 int pin_num, struct regmap **regmap,
@@ -1808,10 +1810,10 @@ static void rk3128_calc_pull_reg_and_bit(struct 
rockchip_pin_bank *bank,
 
*regmap = info->regmap_base;
*reg = RK3128_PULL_OFFSET;
-   *reg += bank->bank_num * RK2928_PULL_BANK_STRIDE;
-   *reg += ((pin_num / RK2928_PULL_PINS_PER_REG) * 4);
+   *reg += bank->bank_num * RK3128_PULL_BANK_STRIDE;
+   *reg += ((pin_num / RK3128_PULL_PINS_PER_REG) * 4);
 
-   *bit = pin_num % RK2928_PULL_PINS_PER_REG;
+   *bit = pin_num % RK3128_PULL_PINS_PER_REG;
 }
 
 #define RK3188_PULL_OFFSET 0x164
-- 
2.17.1

[PATCH 09/13] pinctrl: rockchip: Add RK3228 definitions to separate from other SoCs

[Jianqun Xu]

Add RK3228 definitions to separate from other SoCs.

Signed-off-by: Jianqun Xu 
---
 drivers/pinctrl/pinctrl-rockchip.c | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-rockchip.c 
b/drivers/pinctrl/pinctrl-rockchip.c
index 44f051af97c6..ec6a1a08f8b1 100644
--- a/drivers/pinctrl/pinctrl-rockchip.c
+++ b/drivers/pinctrl/pinctrl-rockchip.c
@@ -1918,6 +1918,9 @@ static void rk3288_calc_drv_reg_and_bit(struct 
rockchip_pin_bank *bank,
 }
 
 #define RK3228_PULL_OFFSET 0x100
+#define RK3228_PULL_BITS_PER_PIN   2
+#define RK3228_PULL_PINS_PER_REG   8
+#define RK3228_PULL_BANK_STRIDE16
 
 static void rk3228_calc_pull_reg_and_bit(struct rockchip_pin_bank *bank,
int pin_num, struct regmap **regmap,
@@ -1927,14 +1930,17 @@ static void rk3228_calc_pull_reg_and_bit(struct 
rockchip_pin_bank *bank,
 
*regmap = info->regmap_base;
*reg = RK3228_PULL_OFFSET;
-   *reg += bank->bank_num * RK3188_PULL_BANK_STRIDE;
-   *reg += ((pin_num / RK3188_PULL_PINS_PER_REG) * 4);
+   *reg += bank->bank_num * RK3228_PULL_BANK_STRIDE;
+   *reg += ((pin_num / RK3228_PULL_PINS_PER_REG) * 4);
 
-   *bit = (pin_num % RK3188_PULL_PINS_PER_REG);
-   *bit *= RK3188_PULL_BITS_PER_PIN;
+   *bit = (pin_num % RK3228_PULL_PINS_PER_REG);
+   *bit *= RK3228_PULL_BITS_PER_PIN;
 }
 
 #define RK3228_DRV_GRF_OFFSET  0x200
+#define RK3228_DRV_BITS_PER_PIN2
+#define RK3228_DRV_PINS_PER_REG8
+#define RK3228_DRV_BANK_STRIDE 16
 
 static void rk3228_calc_drv_reg_and_bit(struct rockchip_pin_bank *bank,
int pin_num, struct regmap **regmap,
@@ -1944,11 +1950,11 @@ static void rk3228_calc_drv_reg_and_bit(struct 
rockchip_pin_bank *bank,
 
*regmap = info->regmap_base;
*reg = RK3228_DRV_GRF_OFFSET;
-   *reg += bank->bank_num * RK3288_DRV_BANK_STRIDE;
-   *reg += ((pin_num / RK3288_DRV_PINS_PER_REG) * 4);
+   *reg += bank->bank_num * RK3228_DRV_BANK_STRIDE;
+   *reg += ((pin_num / RK3228_DRV_PINS_PER_REG) * 4);
 
-   *bit = (pin_num % RK3288_DRV_PINS_PER_REG);
-   *bit *= RK3288_DRV_BITS_PER_PIN;
+   *bit = (pin_num % RK3228_DRV_PINS_PER_REG);
+   *bit *= RK3228_DRV_BITS_PER_PIN;
 }
 
 #define RK3308_PULL_OFFSET 0xa0
-- 
2.17.1

[PATCH 12/13] pinctrl: rockchip: define common codes without special chip name

[Jianqun Xu]

Modify RK3399_DRV_3BITS_PER_PIN to ROCKCHIP_DRV_3BITS_PER_PIN, and
modify RK3288_DRV_BITS_PER_PIN to ROCKCHIP_DRV_BITS_PER_PIN.

Signed-off-by: Jianqun Xu 
---
 drivers/pinctrl/pinctrl-rockchip.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-rockchip.c 
b/drivers/pinctrl/pinctrl-rockchip.c
index 3b74455dcdb2..71a367896297 100644
--- a/drivers/pinctrl/pinctrl-rockchip.c
+++ b/drivers/pinctrl/pinctrl-rockchip.c
@@ -75,6 +75,9 @@ enum rockchip_pinctrl_type {
 #define IOMUX_WIDTH_3BIT   BIT(4)
 #define IOMUX_WIDTH_2BIT   BIT(5)
 
+#define ROCKCHIP_DRV_3BITS_PER_PIN (3)
+#define ROCKCHIP_DRV_BITS_PER_PIN  (2)
+
 /**
  * @type: iomux variant using IOMUX_* constants
  * @offset: if initialized to -1 it will be autocalculated, by specifying
@@ -2074,7 +2077,6 @@ static void rk3368_calc_drv_reg_and_bit(struct 
rockchip_pin_bank *bank,
 
 #define RK3399_PULL_GRF_OFFSET 0xe040
 #define RK3399_PULL_PMU_OFFSET 0x40
-#define RK3399_DRV_3BITS_PER_PIN   3
 #define RK3399_PULL_BITS_PER_PIN   2
 #define RK3399_PULL_PINS_PER_REG   8
 #define RK3399_PULL_BANK_STRIDE16
@@ -2154,7 +2156,7 @@ static int rockchip_get_drive_perpin(struct 
rockchip_pin_bank *bank,
switch (drv_type) {
case DRV_TYPE_IO_1V8_3V0_AUTO:
case DRV_TYPE_IO_3V3_ONLY:
-   rmask_bits = RK3399_DRV_3BITS_PER_PIN;
+   rmask_bits = ROCKCHIP_DRV_3BITS_PER_PIN;
switch (bit) {
case 0 ... 12:
/* regular case, nothing to do */
@@ -2197,7 +2199,7 @@ static int rockchip_get_drive_perpin(struct 
rockchip_pin_bank *bank,
case DRV_TYPE_IO_DEFAULT:
case DRV_TYPE_IO_1V8_OR_3V0:
case DRV_TYPE_IO_1V8_ONLY:
-   rmask_bits = RK3288_DRV_BITS_PER_PIN;
+   rmask_bits = ROCKCHIP_DRV_BITS_PER_PIN;
break;
default:
dev_err(info->dev, "unsupported pinctrl drive type: %d\n",
@@ -2251,7 +2253,7 @@ static int rockchip_set_drive_perpin(struct 
rockchip_pin_bank *bank,
switch (drv_type) {
case DRV_TYPE_IO_1V8_3V0_AUTO:
case DRV_TYPE_IO_3V3_ONLY:
-   rmask_bits = RK3399_DRV_3BITS_PER_PIN;
+   rmask_bits = ROCKCHIP_DRV_3BITS_PER_PIN;
switch (bit) {
case 0 ... 12:
/* regular case, nothing to do */
@@ -2291,7 +2293,7 @@ static int rockchip_set_drive_perpin(struct 
rockchip_pin_bank *bank,
case DRV_TYPE_IO_DEFAULT:
case DRV_TYPE_IO_1V8_OR_3V0:
case DRV_TYPE_IO_1V8_ONLY:
-   rmask_bits = RK3288_DRV_BITS_PER_PIN;
+   rmask_bits = ROCKCHIP_DRV_BITS_PER_PIN;
break;
default:
dev_err(info->dev, "unsupported pinctrl drive type: %d\n",
-- 
2.17.1